|
|
- Das von der
Firma Intel stammende Intel.hex -Dateiformat wird zum Austausch
von Programmen und Daten mit Programmiergeräten
(EPROM-Brennern), Kleincomputern bzw. beim 'Update' von Geräten
(Fernsehern, Telefonen, PCs usw.) verwendet. Seine Vorteile
bestehen gegenüber den ebenfalls gebräuchlichen,
reinen Binärdateien darin, dass ein Datenraum,
beispielsweise ein Flash-ROM, an jeder beliebigen Stelle seines
Datenraums gefüllt werden kann, ohne dass Daten für
die Bereiche in denen nichts abgelegt werden soll, angegeben
werden müssen. Zudem wird die Übertragungssicherheit
durch eine Prüfsumme gesteigert und zuletzt lassen sich
die Daten einer Intel.hex Datei in jedem ASCII-Texteditor
ansehen .. und, wenn man die Mühe nicht scheut, ändern.
Dateien, die in diesem Format aufgebaut sind, besitzen
überwiegend die Endung '.HEX'.
-
-
Datenrecords
-
Die in einer Intel.hex Datei enthaltenen
Daten sind in Datenblöcke unterteilt, die man Records
nennt. Die Records werden in mehrere Typen unterschieden, von
denen hier folgende Typen genauer betrachtet werden ..
-
-
Typ
0 -Datenrecord
-
Typ
1 -End of File (EOF) -Record
-
Typ
2 -Segmentaddress -Record
-
-
Records werden durch eine Startkennung
eingeleitet und benennen in der Folge ihren Typ. Sie können
jede Anzahl, zwischen 0 bis 255 Datenbytes enthalten. Diesen
wird eine Zieladresse beigefügt welche die Ablagestelle
des ersten Datenbytes im Zielspeicherraum beschreibt. Zuletzt
wird jedem Record eine Prüf- oder Checksumme angefügt.
-
Die Zeichen <cr> Carriage Return
(Wagenrücklauf) und <lf> Line Feed (neue Zeile)
schliessen den Record ab, so dass bei einem Texteditor jeder
Record auf einer eigenen Zeile ausgegeben wird. Für die
Codierung und Decodierung der Intel.hex Datei bei
Übertragungsprogrammen sind diese zwei Zeichen nicht
zwingend notwendig.
-
-
 -
-
ASCII-Codierung der Informations- und
Prüfsummenbytes
-
Die obige Tabellen erklärt die
Reihenfolge und den Inhalt der Bytes einer realen
Übertragungsfolge eines Intel.hex-Records. Dabei ist zu
beachten, dass alle Zahlen der Informationsbytes und der
Checksumme die übertragen werden sollen, als ASCII-Zeichen
codiert, übertragen werden. Soll beispielsweise das
Datenbyte 3C gesendet werden, so wird es in zwei ASCII-Codes
zerlegt und das eine Byte 3C wird zu der zwei Byte umfassenden
Übertragungsfolge 33 | 43 was den ASCII-Zeichen 33='3' und
43='C' entspricht. Entsprechend stehen die Symbole obiger
Tabelle für die Anzahl der Ziffern die in der angegebenen
Bytezahl übertragen werden. So bezeichnet aaaa vier
Ziffern einer 2 Byte umfassenden Adresse, die von links nach
rechts in der Folge HighByte dann Low Byte zu lesen ist. Sie
kann maximal FFFFh lauten. Gesendet worden wären für
diesen Fall, 46 | 46 | 46 | 46 also 4 Bytes.
-
Die Angaben zur Anzahl der Datenbytes und
der Prüfsumme beziehen sich dabei nicht auf die
ASCII-codiert gesendeten Bytefolgen, sondern auf die
uncodierten Bytes.
-
-
Nach der Tabelle unterteilt sich ein
Record demnach in die..
-
-
1.
.. ASCII-Startkennung : des Records, die immer 3A lautet
-
2.
.. Informationsbytes bestehend aus ..
-
..
der Anzahl n zu sendender Bytes
-
..
der Ablage-Zieladresse a des ersten Datenbytes
-
..
dem Recordtyp t
-
3.
.. Check- oder Prüfsumme 0- sum Modulo 256 (=100h))
-
4.
.. ASCII-Codes für eine neue Zeile <cr><lf>.
-
-
-
Bildung der Prüfsumme
-
Zur Bildung der Prüfsumme werden die
uncodierten Bytes herangezogen. Alle Bytes werden addiert, dann
wird diese Summe von 0 abgezogen, was bei mehren Bytes
typischerweise eine große negative Zahl ergibt, die
ihrerseits mehrere Bytes füllt. Von dieser Zahl, bzw.
ihren Ablagebytes ist nur der Teil interessant, welcher sich in
dem niedrigsten Byte der Ablage befindet. Dieser Teil
entspricht der gesuchten Prüfsumme.
-
-
Beispiel: die 6 zu übertragenden
Bytes mögen 8A | 4C | 39 | 56 | 9B | C3 lauten. Dann
ergibt sich die Prüfsumme aus der Rechnung ...
-
0-( 8A+ 4C + 39 + 56 + 9B + C3) = 0- 8A -
4C - 39 - 56 - 9B - C2 = FD3C
-
-
Ohne weitere Rechnung lässt sich die
Prüfsumme als 3C ermitteln, denn FD3C benötigt zwei
Bytes in der Ablage und in dem niederwertigen Byte soll sich
die Prüfsumme befinden. Dies wäre dann 3C.
-
Die Moduloberechnung ergäbe das
gleiche Ergebnis, denn die Restwertrechnung ..
-
FD3Ch mod 100h fragt nach dem Rest der
Division von FD3Ch : 100h was ebenfalls 3Ch ergibt. In FD3Ch
ist 100h genau FDh mal enthalten, als Rest bleibt 3Ch.
-
-
Es ist zu beachten, dass es sich bei der
Prüfsumme einer Intel.hex Datei um das Zweierkomplement
der normalen mod 256 Prüfsumme handelt. Bei letzterer
werden alle Bytes nur addiert und nicht noch von 0 abgezogen,
was dem Zweierkomplement der Summe entspricht.
-
-
Datenrecords vom Typ 0
-
Eine komplette Intel.hex -Datei enthält
einen oder mehrere Datenrecords vom Typ 0. Sie sind von der
Struktur her alle gleich aufgebaut, die Anzahl der übertragenen
Daten kann jedoch schwanken.
-
-
 -
-
Datenrecord vom Typ 1
-
Der letzte Record einer Intel.hex -Datei
ist der End of File (EOF) -Record. Auch seine Struktur
entspricht der eines Datenrecords .. jedoch ohne Daten. Die
Startkennung ist auch bei ihm 3Ah. Es folgt die Anzahl der
enthaltenen Datenbytes die immer 0 ist, ebenso wie die
Zieladresse deren Wert 0000h lautet. Sein Typ ist jedoch 01.
Die Checksumme lautet dann 0-(0 + 0 + 0 +1) MOD 256 = -1 = FFh.
Übersetzt in ASCII -codierte Ziffern 46h, 46h.
-
-
 -
-
-
Zusammenfassung
-
In der Urdefinition einer Intel.hex
-Datei können zwei Recordtypen übertragen werden, die
mit den Typen 0 -Datenrecord und 1 -EOF-Record bezeichnet
werden. In einem Datenrecord können maximal 255 Datenbytes
übertragen werden, wobei sich die Datenmenge pro Record
unterscheiden kann. Alle Records zusammen könne 64kByte
Daten enthalten, denn die grösste übertragbare
(Offset)-Adresse ist FFFFh. Die in den Records genannten
Adressen müssen nicht in irgend einer Weise ansteigen oder
abfallen. Zwischen ihnen können sich Lücken ergeben
und sie können beliebige Adresssprünge enthalten.
Sinnvollerweise sollten sich die Adressen jedoch nicht
überschneiden. Auf diese Weise ist es möglich, einen
Zielspeicherraum komplett, oder nur an ausgewählten
Stellen zu beschreiben.
-
Moderne Definitionen kennen weitere
Recordtypen, die es ermöglichen grössere
Zielspeicherräume der Segmet-Offset Adressierung bzw. der
linearen 32-Bit Adressierung zu beschreiben.
-
-
-
Weitere Recordtypen
-
Mit der Einführung moderner
Prozessoren wurde es notwendig die Grunddefinition des
Intel.hex Formats zu erweitern. Dies geschah abwärtskompatibel
durch die Einführung weiterer Recordtypen.
-
-
Datenrecord vom Typ 02:
Erweiterter Segment-Adress-Record.
-
Bei diesem wird die Adresse mit 0000h
angegeben und die zwei Datenbytes ergeben eine Segment-Adresse
(sa), wie sie beispielsweise bei der 8086CPU im Real-Mode
verwendet wird. Die Übertragungs- und Empfangsprogramme
müssen diese Segmetadresse, mit der in den folgend
übertragenen Datenrecords enthaltenen (Offset)Adresse zur
Bildung der absoluten Adresse im Speicherraum benutzen, und ab
dort die enthaltenen Daten ablegen. Die Segmentadresse ist von
links nach rechts in der Abfolge High Byte dann Low Byte zu
lesen.
-
-
 -
-
-
Datenrecord vom Typ
03: Start-Segment-Adress-Record
-
Bei diesem wird die Adresse mit 0000h
angegeben und die vier Datenbytes geben den Einsprungpunkt für
eine Segment-Offset Programmausführung in der Folge CS:IP
an.
-
-
Datenrecord vom Typ 04: Erweiterter
Linear-Adress-Record
-
Bei diesem wird die Adresse mit 0000h
angegeben und die (zwei) Datenbytes geben die oberen 16 Bit
einer linearen 32Bit Adresse an, wie sie bei der 8086CPU im
Protected-Mode verwendet wird. Die Übertragungs- und
Empfangsprogramme müssen diesen hohen 16Bit Adressteil,
mit dem, in den folgend übertragenen Datenrecords
enthaltenen zweiten und niedrigen 16Bit Adressteil zur Bildung
der absoluten Adresse im Speicherraum benutzen, und ab dort die
enthaltenen Daten ablegen.
-
-
Datenrecord vom Typ 05:
Start-Linear-Adress-Record
-
Bei diesem wird die Adresse mit 0000h
angegeben und die (vier) Datenbytes geben den Einsprungpunkt
für die Programmausführung als 32Bit EIP an.
|
|
Theorie
Computertechnik
.de