Frage zum .hex File

Volker Gast #1543475
Lesenswert?
• ▲
▼ 
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
Antwort Zitieren Bearbeiten Thread verschieben Thread sperren Anmeldepflicht aktivieren Anpinnen Thread löschen Thread mit anderem zusammenführen Beitrag melden
HEXER Gast #1543517
Lesenswert?
• ▲
▼ 
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)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Jörg W. Moderator Persönliche Seite #1543538
Lesenswert?
• ▲
▼ 
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.
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Volker Gast #1543618
Lesenswert?
• ▲
▼ 
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!
Antwort Zitieren Bearbeiten Löschen Beitrag melden
HEXER Gast #1543784
Lesenswert?
• ▲
▼ 
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....)
Antwort Zitieren Bearbeiten Löschen Beitrag melden
Thread beobachten

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

Bestehender Account

oder

Mit Google-Account einloggen

Noch kein Account?

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren