Hallo Leute, ich gockel und gockel und schaue nicht mehr durch. Ich suche einen Bootloader für den ATMega1284p. Ich vermute, dass die üblichen Programme (z.B. Beitrag "UART Bootloader ATtiny13 - ATmega644" ) da nicht mehr skalieren, weil Zugriffe jenseits der 64kB andere Methoden brauchen (espm/RAMPZ). Habe ich da recht? Meine Wünsche sind: - Unterstützung von 128kiB (oder mehr?) Flash - Kommunikation via USART, Baudrate darf fest sein. - Unterstützung durch avrdude - Quelltext frei verfügbar (GPL?) Assembler oder avr-gcc - EEPROM sollte auch beschrieben werden können - Natürlich möglichst klein (bei 128kiB aber nicht soooooo wichtig ;) ) Vielen Dank für eure Hinweise. Gruß, DetlevT
Detlev T. schrieb: > - Unterstützung durch avrdude > - Quelltext frei verfügbar (GPL?) Assembler oder avr-gcc Erfüllt es aber nicht.
Hallo Leute, aus der für dieses Forum sehr geringen Resonanz schließe ich, dass es da wohl wirklich noch keine (gute) Lösung gibt. Gefunden habe ich etwas für den ATMEGA128, wo es dieselben Probleme geben sollte. "foodloader", der offenbar nicht weiterentwickelt wird, kann das aber nur in der (unstabilen?) "Entwicklerversion". Und boofa von Roland Riegel ist mir zu unübersichtlich, um es anzupassen. Da habe ich wahrscheinlich schneller selbst etwas programmiert. Ich bin ohnehin im Zweifel, ob Größen über 64kiB in das Schema der Application Note AVR109 passen, das ja eigentlich nur zwei Bytes für die Adresse vorsieht. Ich werde da wohl den Weg über das XModem-Protokoll gehen. Das hat für den Nur-Anwender den Vorteil, keine "Spezial-"Programme wie avrdude zu benötigen, wenn er ein Update einspielen will. Ein - wahrscheinlich ohnehin vorhandenes - Terminal-Programm reicht. Und die 128 Byte Blockgröße passt da auch sehr gut zur Pagegröße (256 Byte). Das dürfte nicht so schwer sein zu programmieren. Das EEPROM kann man so zwar nicht beschreiben, aber man kann halt nicht alles haben im Leben. :D Gruß, DetlevT
Detlev T. schrieb: > Ich vermute, dass die üblichen Programme > (z.B. Beitrag "UART Bootloader ATtiny13 - ATmega644" ) da nicht mehr > skalieren, weil Zugriffe jenseits der 64kB andere Methoden brauchen > (espm/RAMPZ). Habe ich da recht? Nö, man kann bloß nicht nachträglich den Titel editieren. Getestet isser mit dem ATmega2561. Peter
Hallo Peter, Mich hat wohl abgeschreckt, dass ziemlich am Ende jemand Probleme gerade mit dem ATMega1284p meldete. Die "Lösung" kam mir da zu eilig gehackt und vorläufig vor. Vor allem: Sehe ich es richtig, dass dieser Bootloader nur mit seinem eigenen Hostprogramm (fboot.exe) kommunizieren kann? Wenn ich also Nutzern ein Update in Form einer Binärdatei anbieten will, müsste ich also für alle möglichen Plattformen ein entsprechendes Programm erzeugen? Gruß, DetlevT
Detlev T. schrieb: > Wenn ich also > Nutzern ein Update in Form einer Binärdatei anbieten will, müsste ich > also für alle möglichen Plattformen ein entsprechendes Programm > erzeugen? So ist das wohl. Schicker ist ein Bootloader, der eine .hex-Datei von einem Terminalprogramm annehmen kann und in Echtzeit umformatiert und in´s Flash schreibt. Hex-Dateien sind durch die Prüfsumme unanfälliger gegen Übertragungsfehler, als Binärdateien. Diese Dateienübertragung unterstützen alle Betriebssysteme, sogar DOS per 'COPY' ;-). Da braucht man allerdings ein bisserl mehr Boot-Code im AVR, wofür der M1284 aber genug Platz bietet.
Knut Ballhause schrieb: > Schicker ist ein Bootloader, der eine .hex-Datei von > einem Terminalprogramm annehmen kann und in Echtzeit umformatiert und > in´s Flash schreibt. Daran hatte ich auch schon gedacht. Ich sehe da aber zwei Probleme: 1.) Es ist nicht garantiert, dass die Daten im iHex-File nach aufsteigender Adresse sortiert sind. Die dürfen auch wild durcheinander vorliegen. Da müsste man vor dem konvertieren erst die ganze Datei einlesen und da reicht das SRAM nicht. 2.) Man braucht im Zweifelsfall eine Flusskontrolle, falls die Daten "zu schnell" kommen. Für eine Hardware-Flusskontrolle habe ich aber keinen Pin mehr frei :-D, und XON/XOFF ist mir zu unsicher. Beim XModem hingegen wartet der Host schon von selbst auf ein ACK/NAK bevor er weiter sendet. Eine Prüfsumme bietet XModem übrigens auch. Die ist zwar nicht sonderlich sicher, aber die Übertragung via (kurzem) Kabel ist ja relativ zuverlässig. Ggf. könnte man sogar auf XModem/CRC ausweichen, das ist noch besser als die Prüfsumme im iHex, aber das kann aber leider nicht jedes Terminalprogramm.
Detlev T. schrieb: > Mich hat wohl abgeschreckt, dass ziemlich am Ende jemand Probleme gerade > mit dem ATMega1284p meldete. Die "Lösung" kam mir da zu eilig gehackt > und vorläufig vor. Nö, die Lösung ist korrekt. > Vor allem: Sehe ich es richtig, dass dieser Bootloader nur mit seinem > eigenen Hostprogramm (fboot.exe) kommunizieren kann? Das ergab sich aus meinen Anforderungen: 1. Es darf kein zusätzlicher Pin fürs Bootloader einschalten verschwendet werden. 2. Die Applikation darf nicht merkbar verzögert starten. 3. Der Bootloader muß auch bei defekter Applikation immer erreichbar sein. 4. Der Bootloader darf nicht versehentlich anspringen, z.B. wenn die Applikation regulär was über die UART empfängt. Daher das Protokoll, daß das PC-Programm ständig einen Paßwort-Text sendet, worauf der Bootloader nach dem Power-On-Reset innerhalb von 0,3s antworten kann. Peter
Detlev T. schrieb: > 1.) Es ist nicht garantiert, dass die Daten im iHex-File nach > aufsteigender Adresse sortiert sind. Die dürfen auch wild durcheinander > vorliegen. Da müsste man vor dem konvertieren erst die ganze Datei > einlesen und da reicht das SRAM nicht. Nicht ganz. Zuerst wird das AVR-Flash im Applikationsbereich gelöscht. Im Bootloader wird ein Puffer in der Größe einer Flash-Page angelegt und mit $FF gefüllt. Die Adressen aus der .hex-Datei werden in diesen Puffer gemappt und die Daten entsprechend eingetragen. Bei vollem Puffer oder einem kommenden Adressbereich außerhalb der aktuellen Page wird der Puffer in die Page ohne vorheriges Löschen geschrieben und anschliessend wieder komplett auf $FF gesetzt. Taucht ein Adressbereich einer bereits teilbeschriebenen Page auf, werden die neuen Bytes in die Page geschrieben, die anderen werden mit $FF überschrieben und somit nicht geändert. Somit finden auch fragmentierte Daten den richtigen Ort. Detlev T. schrieb: > 2.) Man braucht im Zweifelsfall eine Flusskontrolle, falls die Daten "zu > schnell" kommen. Für eine Hardware-Flusskontrolle habe ich aber keinen > Pin mehr frei :-D, und XON/XOFF ist mir zu unsicher. Beim XModem > hingegen wartet der Host schon von selbst auf ein ACK/NAK bevor er > weiter sendet. Das ist korrekt, meine Bootloader laufen bis etwa 95kBaud ohne Flusskontrolle, da sie die Daten schnell genug wegspeichern. Der aktuelle Bootloader meiner Anwendung läuft mit 250kBaud über FT232RL und mit Flusskontrolle. Detlev T. schrieb: > Ggf. könnte man sogar auf XModem/CRC ausweichen, > das ist noch besser als die Prüfsumme im iHex, Bisher war keine zusätzliche Prüfsumme nötig, alles landete da, wo es sollte :-)
Knut Ballhause schrieb: > Nicht ganz.[..]Somit finden auch fragmentierte Daten den richtigen Ort. So könnte man das machen. Wenn es aber ganz dumm läuft, dann muss man einen solchen Read-Rewrite-Zyklus wegen eines einzigen Bytes machen und Murphy sagt, dass dies dann immer auch gleich mehrere Bytes hintereinander betrifft. ;-) Man müsste das also wegen der fehlenden Flusskontrolle buffern und das macht zusätzliche Programmierarbeit. Auf der anderen Seite ist die Erstellung eines Binärfiles auch nicht komplizierter als die Erstellung eines Hexfiles ("avr-objcopy --target=binary"?) > Detlev T. schrieb: >> Ggf. könnte man sogar auf XModem/CRC ausweichen, > > Bisher war keine zusätzliche Prüfsumme nötig, alles landete da, wo es > sollte :-) War auch nur mal so angedacht. Vielleicht als Option für spätere Versionen. Wie ich inzwischen herausgefunden habe, kann man durchaus beides anbieten. Erst 'C' senden, um CRC zu aktivieren und wenn das Terminalprogramm das nicht versteht, per Time-Out auf NAK und eine einfache Prüfsumme zurückfallen.
Detlev T. schrieb: > So könnte man das machen. Mache ich auch so, schon lange ;-). Detlev T. schrieb: > Wenn es aber ganz dumm läuft, dann muss man > einen solchen Read-Rewrite-Zyklus wegen eines einzigen Bytes machen und > Murphy sagt, dass dies dann immer auch gleich mehrere Bytes > hintereinander betrifft... Es wird nichts gelesen. Es werden alle ankommenden Bytes je nach Adresse in einen mit $FF gefüllten Puffer sortiert. Dann wird die betreffende Page mit diesem Puffer überschrieben und nur Bytes, die nicht $FF sind, beeinflussen den Inhalt dieser Page. Da im .hex jedes Byte nur 1x addressiert wird, wird jedes Byte einer Page auch maximal 1x beschrieben. Eine, wie von Dir beschriebene, derart zerstückelte .hex-Datei ist mir noch nicht untergekommen ;-) Detlev T. schrieb: > Man müsste das also wegen der fehlenden > Flusskontrolle buffern und das macht zusätzliche Programmierarbeit. Eine komplette HEX-Zeile landet immer in einem Puffer. Wird der LineFeed-Character erkannt, erfolgt die Prüfung der Zeile und deren Bearbeitung. Erst bei vollem oder überadressiertem Page-Puffer wird eine Wartezeit von 4ms fällig, die aber weitgehend im Hintergrund abläuft, während eine neue HEX-Zeile eintrudelt. Wenn es der Bootloader tatsächlich einmal nicht packt, wird eine Fehlermeldung ausgegeben. Ist aber in dem Zusammenhang noch nicht vorgekommen. Detlev T. schrieb: > Auf der anderen Seite ist die Erstellung eines Binärfiles auch nicht > komplizierter als die Erstellung eines Hexfiles Das nicht, aber es ist nicht durch den Bootloader prüfbar.
Knut Ballhause schrieb: > Das nicht, aber es ist nicht durch den Bootloader prüfbar. Wie du selbst schreibst, ist die Übertragung via UART in der Praxis ausreichend sicher. Bei Binärdateien kann man zudem mit der Übertragungsrate runter, weil nur etwa 40% der Datenmenge übertragen werden muss. Den Download der Binärdatei via Internet könnte man dann noch durch ein Archivprogramm absichern, das eine Prüfsumme verwendet. Ich will mir auch nicht so viel Arbeit machen, das eigentliche Projekt ist ganz anders. (Ich betrachte das Thema selbst als abgeschlossen, deshalb mag eine Diskussion um solche Nebensächlichkeiten erlaubt sein.)
Knut Ballhause schrieb: > Das ist korrekt, meine Bootloader laufen bis etwa 95kBaud ohne > Flusskontrolle, da sie die Daten schnell genug wegspeichern. Das ergibt dann an Binärdaten etwa 34kB effektiv. Auch kannst Du so nur die untere Sektion beschreiben, in der oberen Sektion steht die CPU beim Schreiben und Du brauchst eine Flusskontrolle. D.h. beim ATmega8 sind nur max 6kB statt 7,5kB nutzbar. Peter
Hallo Peter, Das ist richtig und ist insofern beabsichtigt, dass der Bootloader nicht überschrieben werden soll. Ein Schreiben in der oberen Sektion ist somit nicht erforderlich und auch nicht erwünscht ;-)
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.