www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik UART-Bootloader für ATMega > 64kiB


Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Info (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Detlev T. schrieb:
> - Unterstützung durch avrdude
> - Quelltext frei verfügbar (GPL?) Assembler oder avr-gcc

Erfüllt es aber nicht.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Detlev T. (detlevt)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Schon okay.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Knut Ballhause (Firma: TravelRec.) (travelrec) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.