Hallo zusammen, ich habe mich einige Jahre mit diversen Atmel mega beschäftigt und dort auch mit Bootloadern gearbeitet. Bei diesen Typen ist der Bootloader immer am Ende des Speichers untergebracht, d.h. eine Application startete immer an der Adresse 0x0000. Und ich kann das selbe .hex-file entweder mit dem Programmer oder mit dem Bootloader flashen. Jetzt arbeite ich mich in die AVR-DB-Typen ein. Dort steht der Bootloader am Anfang und die Application sitzt hinter dem Speicherbereich, den ich für den Bootloader reserviert habe. Habe ich das richtig verstanden: Beim Compilieren muss ich also im Linker (durch z.B. -Ttext=0x1000) die Startadresse der Application vorgeben? Ich muss also schon beim Built wissen, ob ich auf der Ziel-HW einen Bootloader habe und wie groß dieser ist? Falls ich also später den reservierten Bereich für den Bootloader ändern muss, weil dieser größer oder kleiner ist, muss ich die Application neu compilieren? Ein .hex-file, das ich zum Flashen mit dem Programmer geschrieben habe, kann ich also mit einem Bootloader nicht flashen? oder habe ich da etwas falsch verstanden?
Martin schrieb: > Jetzt arbeite ich mich in die AVR-DB-Typen ein. > Dort steht der Bootloader am Anfang und die Application sitzt hinter dem > Speicherbereich, den ich für den Bootloader reserviert habe. Ja, wo genau ist jetzt das Problem? War doch z.B. bei den Tinys auch schon immer so.
Warum willst Du überhaupt einen Bootloader benutzen? UPDI ist doch so schön einfach als half-duplex-serial.
Wilhelm M. schrieb: > Warum willst Du überhaupt einen Bootloader benutzen? UPDI ist doch so > schön einfach als half-duplex-serial. Richtig. Das ist ja quasi ein serieller (in Hardware gegossener) Bootloader.
c-hater schrieb: > Ja, wo genau ist jetzt das Problem? War doch z.B. bei den Tinys auch > schon immer so. Habe nie mit Tinys gearbeitet. Das Problem habe ich geschildert. Beispiel aus der Praxis: Wenn in einigen Jahren ein Kollege ein altes .hex-file flashen möchte, aber inzwischen ein neuer Bootloader drauf ist, funktioniert das nicht. Blöd, wenn dann derjenige, der die Ahnung hat, nicht verfügbar ist. Wilhelm M. schrieb: > Warum willst Du überhaupt einen Bootloader benutzen? UPDI ist doch so > schön einfach als half-duplex-serial. Du hast völlig Recht, wenn es um das Entwickeln und Debuggen geht. Ist aber völlig ungeeignet, wenn es um Updates von Geräten geht, auf die kein physischer Zugriff besteht, wenn die Geräte mehrere hundert oder tausend km entfernt betrieben werden. Ich mag nicht so richtig glauben, dass ich der einzige bin, der dieses Problem sieht. Deshalb nochmal die Frage an die Runde: Gibt es eine Möglichkeit, das Problem zu umgehen?
Hallo, @ TO: sextion start text=0x1000 wäre etwas viel, weiß nicht wie groß dein Bootloader ist, 0x200 sollte eigentlich ausreichend sein. @ Wilhlem & c-hater: Ein Bootloader macht schon Sinn. Eine Serielle ist doch irgendwie immer in Benutzung. Wenn man über UPDI flasht braucht dafür irgendeinen Adapter von USB > Serial > UPDI. Und für die Serielle nochmal einen USB-Serial Adapter. Macht doch doppelt Sinn. Also Bootloader drauf und über eine USB-Serial Verbindung flashen und diese Serielle nutzen. Einfacher gehts nicht. Einmaliger Aufwand und dann einfache Handhabung.
Martin schrieb: > c-hater schrieb: >> Ja, wo genau ist jetzt das Problem? War doch z.B. bei den Tinys auch >> schon immer so. > > Habe nie mit Tinys gearbeitet. > Das Problem habe ich geschildert. > Beispiel aus der Praxis: Wenn in einigen Jahren ein Kollege ein altes > .hex-file flashen möchte, aber inzwischen ein neuer Bootloader drauf > ist, funktioniert das nicht. Blöd, wenn dann derjenige, der die Ahnung > hat, nicht verfügbar ist. Deswegen ist es gut, UPDI zu benutzen. > Wilhelm M. schrieb: >> Warum willst Du überhaupt einen Bootloader benutzen? UPDI ist doch so >> schön einfach als half-duplex-serial. > > Du hast völlig Recht, wenn es um das Entwickeln und Debuggen geht. > Ist aber völlig ungeeignet, wenn es um Updates von Geräten geht, auf die > kein physischer Zugriff besteht, Wie möchtest Du dann in diesem Fall das Update mit Deinem Bootloader machen?
Veit D. schrieb: > @ Wilhlem & c-hater: > Ein Bootloader macht schon Sinn. Eine Serielle ist doch irgendwie immer > in Benutzung. Wenn man über UPDI flasht braucht dafür irgendeinen > Adapter von USB > Serial > UPDI. UPDI ist einfach ein UART, Das Protokoll ist half-duplex. Deswegen braucht man keinen Adapter. > Und für die Serielle nochmal einen > USB-Serial Adapter. Macht doch doppelt Sinn. Also Bootloader drauf und > über eine USB-Serial Verbindung flashen und diese Serielle nutzen. Wenn es nach außen tatsächlich dieselben Pins auf dem Board sein sollten, kannst Du auch einfach UPDI bspw. mit TX schaltbar verbinden.
Martin schrieb: > Ist aber völlig ungeeignet, wenn es um Updates von Geräten geht, auf die > kein physischer Zugriff besteht, wenn die Geräte mehrere hundert oder > tausend km entfernt betrieben werden. Dann hast du hoffentlich vernünftig dokumentiert, welche Hardware-, Firmware-, und Bootloader-Version in der 1000km entfernten Anlage werkelt. => Kein Problem, für das Firmware-Update eine passende Version zu bauen. Und auch wenn sich der Bootloader ab und an ändern sollte, bleibt die Größe eher gleich... Ansonsten eben von Anfang an etwas Luft für die Bootloader-Section einplanen.
Applikation immer ans obere Speicherende, höchste Adresse hat Pointer auf den Startup Code.
Martin schrieb: > Jetzt arbeite ich mich in die AVR-DB-Typen ein. > Dort steht der Bootloader am Anfang und die Application sitzt hinter dem > Speicherbereich, den ich für den Bootloader reserviert habe. Ja, das ist super blöd gemacht, die Sektionen sind jetzt vertauscht. Man muß sich daher für die Applikation ein spezielles Linkerscript erzeugen. Und das muß genau wissen, wie groß der Bootloader ist. Ändert man die Bootloadergröße, kracht es. Man könnte es so machen, wie bei den ATtiny. Der Bootloader steht wieder am Ende des Flash, greift sich den ersten Sprungbefehl der Applikation und ersetzt ihn durch einen Sprung zu sich selber. Die Bootsektion wird quasi die Applikationssektion und umgekehrt. Dann können auch beide ihre Interrupts benutzen. Die Applikation muß das IVSEL setzen, der Bootloader muß es löschen.
Veit D. schrieb: > Ein Bootloader macht schon Sinn. Sicher. Umso mehr, wenn die Hardware bereits einen eingebauten liefert. > Wenn man über UPDI flasht braucht dafür irgendeinen > Adapter von USB > Serial > UPDI. Nein, man braucht einfach nur einen stinknormalen seriellen USB-Schnittstellenadapter mit Logikpegeln. Sowas kostet um die 2 Euro. Die muss noch mit einer Diode oder einem Widerstand ergänzt werden und fertig ist das Werk. Jedenfalls für die größeren der neuen AVR8 (also auch AVR128DBxx), denn die haben ein dedizierten Pin für UPDI und brauchen deshalb keinen 12V-Startpuls. > Also Bootloader drauf Wozu? Es ist doch bereits einer in Hardware vorhanden und dieser läßt einfach keinerlei Wünsche offen. Es gibt nichts, was darüber nicht geht.
c-hater schrieb: > Wozu? Es ist doch bereits einer in Hardware vorhanden und dieser läßt > einfach keinerlei Wünsche offen. Es gibt nichts, was darüber nicht geht Meine Vermutung: er möchte nicht zwei serielle Schnittstellen haben: eine für UPDI und eine für "normale" serielle Kommunikation, sondern nach außen nur eine. Man kann UPDI und z.B. TX der normalen seriellen Schnittstelle zusammen schalten (mit OpenDrain konfiguriert und auch half-duplex (LBME)). Dann ergeben sich aber zwei Nachteile: 1) man hat eben nur half-duplex 2) die UPDI-Schnittstelle hört mit, d.h. das "normale" Protokoll muss disjunkt zu UPDI sein. Wenn das nicht geht, muss man eben zwei Schnittstellen verwenden. Oder man kann ein Schalter (P-Ch Mosfet) dazwischen setzen, und UPDI gezielt darüber abschalten. UPDI ist wirklich gut in meinen Augen, weil man z.B. auch die UserRow beschreiben kann. Ein Nachteil finde ich, dass man UPDI durch die CPU nicht abschalten kann (bis zum nä. HW-Reset), weil die UPDI-Register nur vom UPDI-Prozessor aus zugreifbar sind.
:
Bearbeitet durch User
c-hater schrieb: > Es gibt nichts, was darüber nicht geht. Naja, wir haben z.B. die Anforderung, daß ein Update narrensicher sein muß. Der Bootloader lehnt daher ein Update ab, was nicht zu der Hardwarekonfiguration paßt. Auch muß verhindert werden, daß Daten im EEPROM geändert werden. Ansonsten müßte man das Gerät zum Kalibrieren wieder einschicken.
:
Bearbeitet durch User
Peter D. schrieb: > c-hater schrieb: >> Es gibt nichts, was darüber nicht geht. > > Naja, wir haben z.B. die Anforderung, daß ein Update narrensicher sein > muß. Der Bootloader lehnt daher ein Update ab, was nicht zu der > Hardwarekonfiguration paßt. Man kann per UPDI die UserRow auslesen und mit dem hex/elf vergleichen, um so etwas zu verhindern. > Auch muß verhindert werden, daß Daten im EEPROM geändert werden. > Ansonsten müßte man das Gerät zum Kalibrieren wieder einschicken. Man kann das LockBit setzen.
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.