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
Suchfunktion auf dieser WebSite: http://www.mikrocontroller.net/articles/Kavr:_AVR_Hexfile_Boot_Loader Das mit der "Atempause" wird allerdings ein Problem bleiben. Es sei denn die zwischengeschaltete Hardware reagiert auf XOFF/XON bzw. auf die RS232 Handshakes.
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
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.