www.mikrocontroller.net

Forum: Compiler & IDEs Frage zum .hex File


Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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

Autor: HEXER (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht 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.

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan Ernst (sternst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: HEXER (Gast)
Datum:

Bewertung
0 lesenswert
nicht 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 schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.