Guten Tag, hier mal kurz eine grundsätzliche Frage zum Flashen: Die gängigen Programmier-Tools (PonyProg, WinAVR, etc.) bieten ja an, Programm und Daten in unterschiedlichen "Formaten" zu behandeln. (etwa HEX, Binary, ASCII, Motorola s-record) Mich würden jetzt die speziellen Vor- und Nachteile Intel HEX-Format und Binary interessieren? Warum werden überhaupt immer mind. 2 Formate beim Flashen angeboten? Reicht es nicht aus, nur das Intel HEX-Format anzubieten? Soweit, wie ich das bisher verstanden habe: Binary: -------- Ist die Umsetzung zum 1:1 Speicherabbild und wird somit direkt in den Speicher übernommen. (einfach reingeschrieben) + schnelleres Flashen, da Speicherabbild bereits definiert (Daten erheblich geringer im Vergleich zu Intel HEX) --> nur NETTO - keine Beschreibung der Speicherkonf. möglich. Was ist wenn z.B. Daten in einem extra Speicher (etwa SDRAM) vorhalten möchte? Intel-HEX: --------- Format, dass den Inhalt des Speichers beschreibt - mehr Daten, da nicht nur der eigentliche Speicherinhalt, sondern auch die genaue Platzierung im Speicher definiert ist. Zudem sind die Daten mit einer Checksumme versehen + die Platzierung von Programm und Daten kann konfiguriert werden. (die Anwendung im SRAM, Daten im SDRAM, wie würde man so etwas im BINARY machen wollen???) Vielen DANK schon einmal für die Diskuss des Themas! Hoffentlich kann mir jemand weiterhelfen... PS: Gibt es beim BINARY eigtl. sowas wie Überprüfung der Daten wie beim Intel HEX-Format durch die Checksumme? Kann es von meinem Verständnis her, ja niemals geben... Vielen DANK
Ein Intel-HEX File muss nicht größer sein als ein BIN-File. Es wird ja nicht immer der komplette Speicher genutzt.
Sven Scholz wrote: > Die gängigen Programmier-Tools (PonyProg, WinAVR, etc.) ... WinAVR ist kein Programmier-Tool, aber es enthält ein solches (AVRDUDE). Das aber nur nebenbei. > Warum werden überhaupt immer mind. 2 Formate beim Flashen angeboten? Weil es einfach ist, zumindest binary noch zusätzlich zu den anderen zu implementieren. Datei einfach mit fread() einlesen, fertig. > Reicht es nicht aus, nur das Intel HEX-Format anzubieten? Es würde eins davon im Prinzip genügen, ja. Aber noch wenigstens ein zweites außerdem zu können, schadet dir als Anwender auch nichts, du musst ja nichts extra dafür bezahlen (außer einigen wenigen Bytes auf deiner Festplatte). > Ist die Umsetzung zum 1:1 Speicherabbild und wird somit direkt in > den Speicher übernommen. (einfach reingeschrieben) Ja. > + schnelleres Flashen, da Speicherabbild bereits definiert (Daten > erheblich geringer im Vergleich zu Intel HEX) --> nur NETTO Nein, das ist nicht schneller. Das Begrenzende in der Geschwindigkeit ist das Flashen selbst, nicht das Umrechnen der paar Hexzahlen. Allerdings sind die Dateien ca. 40 % kleiner, aber das interessiert vermutlich keinen. Es gibt ansonsten keinen nennenswerten Vorteil von binary. > - keine Beschreibung der Speicherkonf. möglich. Was ist wenn > z.B. Daten in einem extra Speicher (etwa SDRAM) vorhalten möchte? Das kann auch Ihex nicht. Allerdings kann Ihex Adressen mit übermitteln, sodass man beispielsweise auch auf Adressen verschieden von 0 anfangen kann (Stichwort: Bootloader). Falls man ein nicht zusammenhängendes Speicherabbild hat, kann man auf diese Weise auch die Lücken auslassen. Außerdem hat Ihex eine simple Prüfsumme als Schutz gegen Übertragungsfehler. Motorola S-Record hat im Prinzip gleiche Eigenschaften wie Intel Hex. Es ist ein wenig flexibler, es kann mehr Metadaten (z. B. eine Versionsnummer oder eine Programmstartadresse) mit übertragen und kann 2-, 3- oder 4-byte-Adressierung. Das originale Ihex konnte nur 2-byte-Adressierung, allerdings wird heutzutage praktisch nur noch eine erweiterte Form von Ihex benutzt, die mit einer Art Segmentierungsschema effektiv auch auf 4-byte-Adressierung aufgebohrt worden ist. Keins der beiden Formate hat sich aber jemals ,endgültig' durchgesetzt, daher implementieren die Tools oft beide.
Weitere Fragen (an Herrn Wunsch) die aufgekommen sind: - Wann wird die Checksumme des Intel HEX-Format denn eigentlich überprüft bzw. wer (Bootloader, Programmier-Tool, etc.) ist dafür zuständig??? > Das kann auch Ihex nicht. Allerdings kann Ihex Adressen mit > übermitteln, sodass man beispielsweise auch auf Adressen verschieden > von 0 anfangen kann (Stichwort: Bootloader). An wen oder was werden denn die Adressen übermittelt, doch an das Programmer-Tool oder nicht? Der Flash-Inhalt ist doch bei beiden Formaten (Ihex & binary) bereits gleich... (Jedenfalls bekomme ich die gleiche Flash-Ausnutzung, egal für welches Format ich mich entscheide!)
Vielleicht solltest Du Dir mal die Beschreibung des Intel-Hex-Formates ansehen. Google zeigt Dir bestimmt, wo diese zu finden ist. Gruß aus dem Karvendel, Bert
Sven Scholz wrote: > - Wann wird die Checksumme des Intel HEX-Format denn eigentlich > überprüft bzw. wer (Bootloader, Programmier-Tool, etc.) ist dafür > zuständig??? (Deine Fragezeichentaste klemmt.) Derjenige, der das Format einliest, sollte die Prüfsumme prüfen. Das kann das Programmier-Tool sein (bei AVRDUDE ist es so), du kannst aber natürlich auch einen Bootloader schreiben, der ihex direkt versteht. Dann könnte man auf einem Unix sowas machen:
1 | cat myimage.hex > /dev/ttyXXX |
...falls and /dev/ttyXXX eine serielle Leitung zum Bootloader dran klemmt. > An wen oder was werden denn die Adressen übermittelt, doch an das > Programmer-Tool oder nicht? Ja, wer sonst?
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.