Hi, ich habe mich schonmal ein wenig bei den ganzen Bootloadern umgeschaut, aber "der richtige" war irgendwie noch nicht dabei. Ich suche einen Bootloader für die Mega AVR, also ab Mega8 bis zum Mega2560, der möglichst schlank ist und nur die wichtigen Grundfunktionen bietet, also hauptsächlich Flash und Eeprom programmieren, aber keine Fusebits. Auslesen ist auch nicht nötig. Er braucht kein Autobaud, darf gerne den Hardware UART verwenden und sollte ohne propitäre Windowssoftware auskommen. Angeschaut hab ich mir vor allem den von Peter Fleury, Peter Dannegger und Megaload, aber auch ein paar kleinere. Was gibt es denn noch auf dem Markt?
Ja, stimmt, den hab ich vergessen. Allerdings finde ich das auch nicht gerade glücklich mit dem Terminal und dem Motorola s-record Und ich hatte gehofft den Code in 512 Byte zu kriegen. Naja, mal schauen
Programmier ihn dir einfach selber ist wirklich nicht schwer. Seriell sollte das in 2h erledigt sein. die avr libc liefert ja schon alles was aufwendiger ist mit.
Markus Burrer wrote: > Ja, stimmt, den hab ich vergessen. Allerdings finde ich das auch nicht > gerade glücklich mit dem Terminal und dem Motorola s-record Du willst also einen Bootloader, der auf PC-Seite weder spezielle Software benötigt, noch mit einem Terminalprogramm arbeitet. Wie stellst du dir das vor?
Ich meine damit das der Bootloader zb mit avrdude zusammenarbeitet bzw AVR109 kompatibel ist. Aber mal schauen, ich denke ich werde ihn selbst schreiben.
Oder hier: http://www.siwawi.arubi.uni-kl.de/avr_projects/#avrprog_boot http://www.siwawi.arubi.uni-kl.de/avr_projects/#bf_boot Rick
Andreas Kaiser wrote:
> So einer steckt im Butterfly drin.
Wobei damit doch recht viel Leute Probleme melden.
Er soll sich wohl öfter mal selbst zerstören und muß dann per SPI wieder
draufgebrannt werden.
Peter
Keine Windwos software... Die bestehende Windowssoftware is eher auf der mageren seite.
Aeh, ich hab'n Bootloader geschrieben, der benoetigt nur einen kleinen Socket_zu_Serial Umsetzter, dann kann man den Browser verwenden. Wird bald auf den Markt kommen.
Peter Dannegger wrote: > Andreas Kaiser wrote: >> So einer steckt im Butterfly drin. > > Wobei damit doch recht viel Leute Probleme melden. Die Probleme beruhen darauf, das einige Versionen des BF mit einem Bootloader ausgeliefert wurden, der eine "write avr lock-bits"-Funktion bietet. Eine für ein Einsteigerbastelspielboard unglückliche Funktion, da man sich so aussperren kann, dass nur noch ISP/JTAG/HV-Prog hilft. Eigentlich ist das aber kein Fehler. Da lock-bits mit einem Bootloader nicht zurückgesetzt werden können, kann man sich damit "ausgesperren". In den ersten BF-Bootloader Versionen von Atmel gab es diese Funktion nicht. In der aktuellen wohl auch nicht mehr (habe nur "alte"). Meine GNU-Portierungen auf den o.g. "siwawi-Seiten" beruhen für "bf_boot" auf dem alten Atmel Code ohne Lock-Bits, "avrprog_boot" hat nicht mehr viel mit dem BF-Bootloader gemeinsam und viele Leute haben Verbesserungen beigesteuert. > Er soll sich wohl öfter mal selbst zerstören und muß dann per SPI wieder > draufgebrannt werden. "Selbst zersören" bis dato nicht gehört, die Standardeinstellung für BF ab Werk ist, dass der Bootloader sich nicht selbst überschreiben kann (SPM in boot-section nicht erlaubt per fuse). Auch wenn die Lock-setzen Funktion verfügbar ist und verwendet wurde, ist die letzte per Bootloader eingespielte Applikation als auch der Bootloader noch "drin".
Mal ne blöde Frage: was soll der Support von Fuse-/Lockbits via Bootloader überhaupt? Fusebits kann ich in einigen wenigen Fällen ja gerade noch verstehen wenn man BOD oder so umstellen will, aber sonst...
Die Lockbits ? Na, wenn man debugen will sollten die nicht gesetzt sein.
6641 wrote:
> Die Lockbits ? Na, wenn man debugen will sollten die nicht gesetzt sein.
Gibt es (außer in der Serienproduktion) überhaupt einen Grund, mit den
Lockbits zu spielen?
...
Es soll ja auch Menschen geben, die am Gummiseil von der Brücke springen.
>6641 wrote: >> Die Lockbits ? Na, wenn man debugen will sollten die nicht gesetzt sein. > >Gibt es (außer in der Serienproduktion) überhaupt einen Grund, mit den >Lockbits zu spielen? Ja. Wenn man das ding dann weitergibt, und die Internas fuer sich behalten moechte. Neben dem Spielerischen gibt es hin und wieder auch noch den kommerziellen Aspekt der Elektronik... Nein ? :-)
6641 wrote: >>6641 wrote: >>> Die Lockbits ? Na, wenn man debugen will sollten die nicht gesetzt sein. >> >>Gibt es (außer in der Serienproduktion) überhaupt einen Grund, mit den >>Lockbits zu spielen? > > Ja. Wenn man das ding dann weitergibt, und die Internas fuer sich > behalten moechte. Neben dem Spielerischen gibt es hin und wieder auch > noch den kommerziellen Aspekt der Elektronik... Nein ? Doch... Das meinte ich mit "Serienproduktion". Ich hätte vielleicht "kommerzielle Serienproduktion" schreiben sollen. Meist werden die Lockbits aber gesetzt, um den Pfusch zu verbergen und nicht um das geniale Programm vor Diebstahl zu schützen. > > :-) auch :-) ...
Es gibt auch noch die kommerziellen Einzelanfertigungen. Ich gehe mit dir einig, dass damit meist der Pfusch verborgen werden soll. Was da alles unter IP laeuft... das meiste ist eher trivial.
Warum sollte man einen Bootloader in der Produktion verwenden, wenn der nur ein einziges Mal benutzt wird um sich abschliessend per Lockbits den eigenen Ast abzusägen? Von allein kommt der Bootloader nicht in den AVR rein, irgendwann muss der mal ISP oder HVP gesehen haben. Weshalb man sich den Bootloader dann auch sparen kann. Einen Bootloader verwendet man beispielsweise, um später aktualisieren zu können. Und wenn darum geht, den Code davor zu schützen, ausgelesen zu werden: Wenn der Bootloader das nicht eigens vorsieht, geht das nur per ISP/HVP.
6641 wrote:
> Es gibt auch noch die kommerziellen Einzelanfertigungen.
Aber wenn das nicht grad ein Trivialprogramm ist, dann ist grad dabei
nachträgliche Änderung eher die Regel als die Ausnahme.
Eben. Der Bootloader kann beliebig of gestartet werden, und die lockbits neu setzten. Die Lockbits verhindern keine Neuprogrammierung, nur das Auslesen. Neue Produkte von mir werden immer den bootloader drin haben. Dann kann der Kunde den Firmwareupgrade selbst machen und ich muss das Porto fuer den Versand nicht mehr bezahlen.
6641 wrote: > Die Lockbits verhindern keine Neuprogrammierung, nur das > Auslesen. Wenn man es "richtig" macht schon. Insofern kommt doch dafür vor allem diese Konfiguration in Frage: - Auslesen per ISP/HVP abgeklemmt. - Lock Bits so gesetzt, dass der Bootloader noch arbeiten kann. Wozu muss man dann noch nachträglich die Lockbits ändern?
Andreas Kaiser wrote: > Warum sollte man einen Bootloader in der Produktion verwenden, wenn der > nur ein einziges Mal benutzt wird um sich abschliessend per Lockbits den > eigenen Ast abzusägen? Ein Bootloader kann auch dazu dienen, bei Fremdfertigung den Hersteller vor "versehentlicher" Überproduktion zu bewahren. Du läßt die Geräte extern fertigen und brennst dann per Bootloader nur noch die Firmware rein. Oder Du läßt Dir eine universelle Schaltung fertigen, die erst durch die Firmware ihre spezielle Funktion erhält. Peter
Andreas Kaiser wrote: > Warum sollte man einen Bootloader in der Produktion verwenden, wenn der > nur ein einziges Mal benutzt wird um sich abschliessend per Lockbits den > eigenen Ast abzusägen? Siehe Automobilindustrie, in den Steuergeräten schlummern auch Bootloader. Und die Software auslesen kannst du vergessen. Was denkst du den was bei einer Autoinspektion unter anderem gemacht wird, wenn ein dicker Fehler bekannt ist, es wird eine neue Software geflasht, wenn der Fehler nicht mit Parameter - Einstellungen gefixt werden kann. Und die Service - Techniker haben mit sicherheit kein Debugger usw. Gruss
jim wrote: > Was denkst du den was bei einer Autoinspektion unter anderem gemacht > wird, wenn ein dicker Fehler bekannt ist, es wird eine neue Software > geflasht, wenn der Fehler nicht mit Parameter - Einstellungen gefixt > werden kann. Ich bezog mich darauf, inwieweit Bootloader Sinn ergeben, die sich per Programmierung der Lockbits selbst den Ast absägen können und danach mangels Zugriff aufs Flash funktionslos werden. Nicht auf Bootloader generell.
Peter Dannegger wrote: > Ein Bootloader kann auch dazu dienen, bei Fremdfertigung den Hersteller > vor "versehentlicher" Überproduktion zu bewahren. Ok, das ergibt Sinn.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.