Hallo zusammen, mir ist aufgefallen, dass in meinem .hex File immer wieder Zeilen gibt, die sich zu allen anderen in der Datenlänge unterscheidet. Zum Beispiel hier: :104A50000895E199FECFBFBBAEBB0DBA11960FB65C :104A6000F894E29AE19A0FBE0895F3DF012CF1DF8A :044A70001124089570 :104A74000101010101FF0A050001030101417567FC :104A8400203135203230303831373A34343A313607 Neugierig geworden habe ich auch andere hex Files geöffnet und in jedem einen Block mit unterschiedlicher Datenlänge gefunden, mal 4 Datenbytes, aber auch mal 10, sonst sind es immer 16. Was ist der Grund hierfür? Es handelt sich ja nicht um das Ende des Files. Meine Programme sind übrigens mit AVR-GCC in unterschiedlichen Versionen entstanden, auch die verwendeten Atmels sind verschieden (ATmega 16 bis 128) Würde mich freuen, wenn mir jemand erklären könnte? Danke! Viele Grüße Volker
Hallo Volker, nur mal 4 "Nutzbyte" pro Zeile im Hex File gibt es auch bei 805xx- HEX-Files. (Intel-HEX-Forma) Das ist nicht ungewöhnlich. Ich habe das ebenfalls beobachtet, es kann sogar sein, daß die Startadressen (am Beginn der Zeile) nicht in aufsteigender Reihenfolge sind. Ich vermute daß der Linker die "Codeschnipsel" nicht immer in 10-Byte-Portionen bereitstellen kann(??) und dann gibt es eine "kleinere Zeile" mit entsprechend angepaßten Zusatzinformationen wie Anzahl der Bytes, absoluter Startadresse und Checksumme.... Eine Anpassung an immer volle 10-Byte Zeilen würde letzten Endes bedeuten das gesamte übersetzte Programm erst mal in einem Array abzulegen. anschließend wieder 10-Byte weise auszulesen und mit den Zusatzinformationen im HEX-File abzulegen. Man spart also einigen Programmieraufwand. (Und Speicher) Solange die Programmiersoftware das verarbeiten kann (habe schon böse Überraschungen erlebt) stören die untereschiedlichen Längen nicht. Schönen Feiertag! (wenigstens hier in BY)
Volker schrieb: > Hallo zusammen, > > mir ist aufgefallen, dass in meinem .hex File immer wieder Zeilen gibt, > die sich zu allen anderen in der Datenlänge unterscheidet. > > Zum Beispiel hier: > :104A50000895E199FECFBFBBAEBB0DBA11960FB65C > :104A6000F894E29AE19A0FBE0895F3DF012CF1DF8A > :044A70001124089570 Das hängt einfach davon ab, wer das File wie produziert. Wenn du beispielsweise mittels objcopy mehrere sections aus einem ELF-File in ein Hex-File kopierst, dann werden die sections jede einzeln transformiert. Am Ende einer section entsteht dann ein kürzerer Datenblock, falls die Zahl der Bytes innerhalb der section nicht durch 16 teilbar ist.
Hallo! Danke für die Informationen! Ich bin also gut beraten, wenn ich das hex File an meinen Bootloader übertrage, dieses auf die richtige Reihenfolge der Startadressen zu überprüfnen, sowie auf die Datenlänge zu achten. Viele Grüße Volker ...der heut auch nen Feiertag hat!
Volker schrieb: > Danke für die Informationen! Ich bin also gut beraten, wenn ich das hex > File an meinen Bootloader übertrage, dieses auf die richtige Reihenfolge > der Startadressen zu überprüfnen, sowie auf die Datenlänge zu achten. Du bist gut beraten, wenn du dich einfach an die iHex-Spec hälst. ;-)
Hallo Jörg, kannst Du mir sagen, wo ich die iHex-Spec finden kann? Ich hab mich bislang an das hier gehalten: http://www.schulz-koengen.de/biblio/intelhex.htm Viele Grüße Volker
Hallo Volker, ich kenne auch nur diese Definition der Intel-Spezifikation. Wenn man sich daran hält, funktioniert die Sache. Beachte aber, daß die Checksummenbildung über die Bytes! erfolgt. Also wenn im File "31" steht, ist sind das zwei (ASCII!)-Bytes, 0x30 und 0x31; das muß erst in 0x31 (EIN BYTE!) umgewandelt werden bevor die Checksumme gebildet wird. Bei einem Programm das Daten per Bootlader in einen ADUC832, ein 8051-Derivat, schreibt habe ich die Hex-Datei erst mal nach aufsteigenden Daten geordnet. Der Bootlader auf dem Chip hat sich dadurch deutlich vereinfacht, ist aber auch davon abhängig wieviele Bytes pro Page (hier waren es 256) vom Bootlader auf einmal programmiert werden. Sinnvoll ist es auf alle Fälle die unbenutzten Bytes mit 0xFF zu füllen. Der Code für "NOP" tut es auch. Zumindest bei den 805x-Derivaten kann es vorkommen daß es "Lücken" von einigen Bytes im Prog.-Speicher gibt, Z.B. weil Programmteile bewußt auf bestimmte Adressen gelegt wurden (oder der Linker das für nötig hielt....)
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.