Hallo liebe Gemeinde!
Vielleicht kann mir jemand einen kleinen Tip bei meiner Überlegung zur
Machbarkeit meines Vorhabens geben?
Es gibt viele gute Bootloader für die Atmegas (speziell verwende ich den
Atmega8), nur haben alle gemeinsam,das ein Programm auf dem PC als
"Gegenstück" den Bootloader mit den Daten zum Update füttert und die
Flusskontrolle übernimmt um auf Fehler zu reagieren.
Da ich ein "Fernupdate" über eine vorgeschaltete Hardware machen muss,
habe ich sozusagen keine direkte Möglichkeit mit der RS232 zu
kommunizieren,allerdings kann ich dieser "Blackbox" eine Textdatei
schicken und diese kann sie über ihre rs232-Schnittstelle an den Atmega8
weiter reichen.
Eine rückwärtige Kommunikation ist auf ein paar Statusbefehle beschränkt
und auch nicht in "Echtzeit" möglich, so das ein paketorientiertes
"Handshake" einfach die Updatezeit ins unermessliche treibt.
Nun suche ich einen Bootloader, welcher evtl. einfach das Hexfile (wie
es
z.B. vom AVR-Studio im Intel-Hex-Format erzeugt wird..) über die rs232
entgegen nimmt und ins flash schreibt,dabei die Checksummen der
einzelnen Datensätze prüft und einfach am ende mitteilt ob ein Fehler
aufgetreten ist oder nicht.
Der Bootloader sollte im Fehlerfall im "Updatemodus" bleiben und einfach
auf die erneute Einleitung eines Updates warten, da das Hauptprogramm ja
fehlerhaft geflasht ist und damit nicht lauffähig wäre.
Jetzt könnte ich erneut das Hexfile schicken und auf eine positive
Rückmeldung warten.
Als weitere Schwierigkeit kommt hinzu,das nur die Baudrate von
38400Bit/s
zur Verfügung steht und das Schreiben einer Page in den Flash ja auch
eine
gewisse Zeit benötigt....
Jetzt habe ich die Befürchtung das es etwas eng mit dem Timing wird?
Man könnte max. 64 Byte in den Sram zwischenpuffern um die Flashzeit der
gerade zu schreibenden Page zu überbrücken,aber das wird eng?!
Eine "Atempause" kann man durch das fehlende Handshake nicht einbauen...
Stand jemand schon mal vor dem Problem und kann mir mit Rat zur Seite
stehen??
LG Der Fragende
Der Fragende schrieb:> Jetzt habe ich die Befürchtung das es etwas eng mit dem Timing wird?> Man könnte max. 64 Byte in den Sram zwischenpuffern um die Flashzeit der> gerade zu schreibenden Page zu überbrücken,aber das wird eng?!>> Eine "Atempause" kann man durch das fehlende Handshake nicht einbauen...
Laut Datenblatt dauert ein page write maximal 4,5ms. Bei 38400 Baud
kommen in der Zeit 22 Bytes an, wenn ich mich nicht verrechnet habe. Ein
page erase brauchst Du auch noch. Das dauert genau so lange, macht 44
Bytes. Würde also gerade gehen. Die page erase könntest Du aber auch
vorab machen, dann bist Du wieder bei 22 Bytes.
Eine andere Möglichkeit wäre, in die Hex-Datei nach jeder Page ein paar
Dummy-Bytes einzufügen, die der Bootloader einfach ignorieren kann. So
gewinnt er Zeit zum schreiben ins Flash.
Hey,super....hätte nicht so schnell mit einer Antwort gerechnet, erst
mal vielen Dank ;-)
Hatte die Suchfunktion bemüht,aber irgendwie ist mir dieser Beitrag
durch die Finger geschlüpft!
Man findet ja sehr viel zum Thema Bootloader, aber zu meinem Problem ist
dieser Link der erste welcher wirklich in die richtige Richtung geht.
Theoretisch wäre es genau das was ich suche,nur leider habe ich eben
kein XON/XOFF zur Verfügung, sonst wäre es kein Problem......mir kommt
aber momentan auch keine gute Idee, wie man diese Hürde umgehen kann.
Den Bootloader umzuschreiben, damit nicht nach einem Reset gewartet
wird,
sondern bei einem bestimmten "Befehl" über die RS232 in den Update-Modus
gewechselt wird, sollte ich hinbekommen....somit könnte der
"Updatebefehl"
gleich mit am Anfang des Hexfiles stehen und ich brauch damit einfach
nur das File zu senden.....in etwa so:
$!%upd
:100000000BC0FFFFFFFFFFFFFFFFFFFFEDC8FFFF7C
:10001000FFFFFFFFFFFF40C304E00EBF0FE50DBF72
:10002000E3C897D9B9D906D81FD84BD8BAD804E2B3
:1000300010D802E50ED803E50CD804E50AD80FE481
:1000400008D80BE406D80AE004D80DE002D853D74C
:1000500053D4C8D602E000936801009168010023E0
:10006000E1F7B1D342D2F6CFFFD70FEFFAD70F3F68
:10007000E1F3EFD7FACF90D964696573206973749F
---------------> Schnipp <-----------------
....aber das Problem mit dem Timing wird mir auf die Füße fallen!
Naja,vielleicht kommt mir ja noch eine Erleuchtung gg
Also,noch mal vielen Dank für deine investierte Zeit ;-)
LG Der Fragende
Die Zeit für das Schreiben einer Page ist nicht das Problem. Man sollte
sie vorher allerdings löschen. Von daher müsste man ein paar Kommandos
an den Bootloader senden können. Da eine Zeile in HEX-Files mit
Doppelpunkt angestoßen wird, könnte man ein anderes Sonderzeichen für
das Kommando nehmen. Weit interessanter und komplexer ist das Dekodieren
des HEX-Files und das einsortieren in die entsprechenden
Speicherbereiche. Hierfür gehen die meiste Rechenzeit und der meiste
Code drauf. Je nach Taktfrequenz kann es für den ATMEGA dort eng werden.
Aus der Praxis kann ich aber sagen, dass ein mit Interrupten arbeitender
und gut optimierter Bootloader bei einem mit 12MHz laufenden ATMEGA eine
Baudrate bis etwa 70kBaud locker wegsteckt. Es wird allerdings fast der
gesamten Boot-Bereich für den Bootloader benötigt.
Schon die nächste Antwort....wahnsinn ;-)
Die Idee mit den Dummybytes ist gut!
Sowas kann man ja zur Not mit einem kleinen Skript auf dem PC
automatisiert
konvertieren....
Die damaligen Versuche das Hexfile direkt zu verarbeiten, scheiterten
kurioser weise am Timing,obwohl meine Rechnung mit deiner übereinstimmte
war es sehr knapp....kleine Updates bis 10 Pages gingen zu 99% gut,
alles darüber war irgendwie sehr fehlerbehaftet! (wobei 1% auch nicht
gut ist..)
Leider habe ich mein Projekt von damals verschludert, sonnst könnte man
daran anlehnen.
Bevor ich alles noch einmal aufrolle, wollte ich gerne eure Meinung
hören,
ob ich vollkommen daneben liege, oder ob ihr auch die Möglichkeit einer
solchen Updatefunktion seht, oder ein grundsätzliches scheitern
vorprogrammiert ist.
LG Der Fragende
Der Fragende schrieb:> ob ich vollkommen daneben liege,
Nein. Eigentlich nicht.
Der Fragende schrieb:> oder ein grundsätzliches scheitern> vorprogrammiert ist.
Nein. Es ist aber ein wenig Gehirnschmalz für den Programmablauf nötig
und es wäre nicht schlecht, wenn Du in ASM fit bist. So kann man viele
der zeitkritischen Sachen optimieren. Gerade die SPM-Routinen schreibt
man sinnvollerweise in ASM. Siehe Bootcode im Datenblatt. Ich kann Dir
nur aus Erfahrung sagen, dass es funktioniert, schicken darf ich Dir
aber nichts ;-/.
@ Knut Ballhause,
Hallo ;-)
Ich denke auch,das damals die Rechenzeit irgendwo ein Schnippchen ge-
schlagen hat.
Das Projekt war in Assembler realisiert und alle
Umcodierungen,Prüfsummen-
berechnungen und Sortierungsverfahren waren mehrfach überarbeitet und
optimert...allerdings habe ich die Sache nie in Griff bekommen.
Die MCU lief mit 7372800Hz , einer Baudrate von 38400 ohne die
Verwendung von Interrupts....
LG Der Fragende
Der Fragende schrieb:> Die MCU lief mit 7372800Hz , einer Baudrate von 38400 ohne die> Verwendung von Interrupts....
Ganz auf Interrupte zu verzichten, kann den nötigen Speed kosten. Dein
UART sollte zumindest den RX-Complete Interrupt nutzen, um die Daten
anzunehmen, umzukodieren und wegzuspeichern. Ein Timer für eventuelle
TimeOut Messungen und andere feste intervalle ist auch immer recht
hilfreich. Lässt Du alles in der Main, kann diese eine zu langsame
Umlaufzeit haben, um die ankommende Bytes sicher abzuholen. Wichtig bei
der konzeptionellen Umsetzung ist es auch, mit Puffern für die
Hex-Umkodierung und die Page-Aufbereitung zu arbeiten. Nur so kann man
während des Flashens weiterarbeiten. Und dran denken: eine HEX-Datei
kann auch fragmentiert sein, das heißt, es können Adressen für
verschiedene Pages direkt aufeinanderfolgen. Das muß der Loader
ebenfalls beherrschen.
@ Knut Ballhause
vielen Dank für deine Tips, da bin ich ja wieder zuversichtlich ;-)
Codebeispiele sind zwar nett, aber selber schreiben macht den meisten
Spaß, vor allem "wenn" es dann funktioniert! **gg**
Wie schon geschrieben,nutze ich fast ausschließlich Assembler,ist ja
auch
auf so einer kleinen MCU das effektivste, vor allem im begrenzten
Bootloaderbereich....
LG Der Fragende
Knut Ballhause schrieb:> Wichtig bei> der konzeptionellen Umsetzung ist es auch, mit Puffern für die> Hex-Umkodierung und die Page-Aufbereitung zu arbeiten.
...das funktionierte ganz gut,hatte quasi einen Puffer im Ram
entsprechend
der Pagegröße um wärend der Pageoperation dort alles für den nächsten
"Pagetransfer" vorzubereiten.
Knut Ballhause schrieb:> Und dran denken: eine HEX-Datei> kann auch fragmentiert sein, das heißt, es können Adressen für> verschiedene Pages direkt aufeinanderfolgen. Das muß der Loader> ebenfalls beherrschen.
...fürs erste hatte ich immer das gesamte Flash-abbild (bis auf den
Loader selbst)geschrieben,wodurch alle Pages schön aufeinander folgten.
Damit war es einfacher,allerdings nicht wirklich zufriedenstellend ;-)
LG Der Fragende
