Gast
#6809929
Hallo, wenn ich ein Hex-File flashe (80c166)) und dann komplett wieder auslese, ist das Ergebnis dann genauso wie die Ursprungsdatei?
Gast
#6809938
Koi schrieb: > wenn ich ein Hex-File flashe (80c166)) und dann komplett wieder auslese, > ist das Ergebnis dann genauso wie die Ursprungsdatei? Nein, nicht unbedingt. Es kommt auf dein Leseprogramm und die Bedienung an. Und natürlich auf den Aufbau der Ursprungsdatei.
Die Zeilenlänge ist bei Hexfiles nicht genormt. Dadurch kann es optische Unterschiede geben. Der Inhalt des ausgelesenen Files ist "ein Stück von Anfang bis Ende, fortlaufend". Ein Hexfile darf mehrere Speicherblöcke enthalten, die nicht fortlaufend angeordnet sein müssen. Es dürfen auch Lücken vorhanden sein. Ein Hexfile darf zusätzliche Informationen wie Kommentare oder Debug-Infos enthalten, die im ausgelesenen File aber fehlen werden.
Gast
#6810026
Der direkte Vergleich macht nur bei Binärdateien Sinn.
Gast
#6810050
Koi schrieb: > wenn ich ein Hex-File flashe (80c166)) und dann komplett wieder auslese, > ist das Ergebnis dann genauso wie die Ursprungsdatei? Wenn das selbe Tool das Schreiben und Lesen des µC vornimmt, ist die Chance durchaus groß, dass es (fast) identisch ist. Manchmal wird die letzte Datenzeile noch mit 0xFF aufgefüllt, was aber keine Bedeutung hat. Siehe den Aufbau des Intel-HEX-Files bei z.B. https://de.wikipedia.org/wiki/Intel_HEX - da ist schon die Zeilenlänge variabel, was sich zwangsläufig auf den Zeilenanfang (RECLEN, Adresse) und am Ende auf die Checksumme auswirkt. Anbei ein Ausschnitt mit farblich markierten Bereichen, nur das Schwarze sind die Nutzdaten. Die kannst du generell nur manuell vergleichen, wenn mit anderen Parametern gearbeitet wurde, z.B. mit anderer Nutzdatenlänge oder bei Lücken in den Adressen. - Beige die Länge der Zeile - blau die Speicheradresse - braun der Datensatztyp - schwarz die Nutzdaten - grün die Checksumme für die Zeile
Angehängte Dateien:
-
Ausschnitt_IntelHex.png
(4,2 KB)
Gast
#6810053
Stefan ⛄ F. schrieb: > Der direkte Vergleich macht nur bei Binärdateien Sinn. Nein. Viele Files im Intel-Hex Format verwenden im Wesentlichen eine Zeilenlänge von 0x10 Bytes und fangen auf einer 0x10-Byte Grenze an. Beim Vergleich mit einem File-Merger sieht man dann schnell was Sache ist. Nur gilt eben nicht, das geflashter und zurückgelesener File identisch sind.
Gast
#6810057
... und zurückgelesener File unbedingt identisch sind.
Georg G. schrieb: > Ein Hexfile darf zusätzliche Informationen wie Kommentare oder > Debug-Infos enthalten, die im ausgelesenen File aber fehlen werden. Hab ich noch nie gesehen, liegt da vielleicht eine Verwechselung mit einem anderen Dateiformat vor?
Gast
#6810251
Dieter W. schrieb: > Hab ich noch nie gesehen, liegt da vielleicht eine Verwechselung mit > einem anderen Dateiformat vor? Dass du das noch nie gesehen hast, schließt Kommentare im Hex-File doch nicht aus. Bei einem Datensatz mit Daten, die geflasht werden sollen, muss die Zeile zwingend mit einem ":" eingeleitet werden. Jetzt kannst du dir überlegen, was mit Zeilen ist, bei denen das nicht der Fall ist. https://people.ece.cornell.edu/land/courses/ece4760/FinalProjects/s2012/ads264_mws228/Final%20Report/Final%20Report/Intel%20HEX%20Standard.pdf
Dieter W. schrieb: > Hab ich noch nie gesehen, liegt da vielleicht eine Verwechselung mit > einem anderen Dateiformat vor? Debug Infos fingen bei Intel mit einem "$" an. Dann kamen der Name des Symbols und die Adresse. Kommentare hatten als erstes Zeichen ein ";".
Gast
#6810362
Georg G. schrieb: > Debug Infos fingen bei Intel mit einem "$" an. Dann kamen der Name des > Symbols und die Adresse. > Kommentare hatten als erstes Zeichen ein ";". Hast du das schriftlich? In der oben verlinkten Spec vom Intel Hexadecimal Object File Format ist dazu nichts aufgeführt.
Wolfgang schrieb: > Hast du das schriftlich? Nein, bzw keine Lust, danach zu suchen. Du musst es nicht glauben, darfst die Info gern ignorieren. Als Tipp noch: Der ASM48 unter ISIS-2 produzierte solche Hexfiles, iirc der ASM86 auch.
Gast
#6810764
Georg G. schrieb: > Nein, bzw keine Lust, danach zu suchen. Du musst es nicht glauben, > darfst die Info gern ignorieren. Warum, ich bin ganz deiner Meinung. Mich wundert nur, das Intel das nicht in der Spezifikation drin stehen hat und hätte gerne gewusst, ob das irgendwo in dem Zusammenhang spezifiziert ist.
Ich denke, der Begriff Hex-File ist nicht genormt. Auch Eprom-Daten wurden gelegentlich mal rein binär unter .bin oder .hex abgespeichert. Nur "Intel-Hex" oder der Motorola-S-Record" sind eindeutig. Vorteil ist die reine ASCII-Notierung, die auch mit einem Texteditor lesbar ist, und die Angaben zum Speicherort, auch mehrere Bereiche in einer Datei. Komplizierter wird es, wenn der Mikrocontroller neben dem Programmspeicher noch Konfigurationsbits und EEPROM enthält. Die werden beim Auslesen nicht unbedingt mit abgelegt. Im Hexeditor eines Programmiergeräts werden sie oft als Fortführung des Adressbereichs zusammen mit dem Programmspeicher dargestellt. In Eproms verwirrt auch die Adressbezeichnung, im Programmiergerät beginnt er mit Null, aber im Zielgerät kann er auch ganz hinten im Adressraum liegen. Deshalb kann man oft einen Adressversatz angeben. Das steht alles nicht in der Bin-Datei, man muss es sich gesondert notieren. Für 16-Bit-Rechner kann auch das untere und obere Byte in getrennten Eproms liegen, alles im Datenfile nicht erkenntlich.
Gast
#6811400
Wolfgang schrieb: > Jetzt kannst du dir überlegen, was mit Zeilen ist, bei denen das nicht > der Fall ist. Naja viele Programme werden eine solche Datei einfach als unverständlich zurückweisen. Ein weiterer Punkt ist, dass in .hex-Dateien nicht für alle möglichen Speicherzellen ein Wert stehen muss. Es kann also Löcher in der Beschreibung geben. Und meist ist auch die Datei zu Ende, wenn das Programm zu ende ist. Aber im Programmspeicher wird natürlich nicht markiert, ob der enthaltene Wert so sein muss oder nur zufällig noch von früher mal so da steht und eigentlich auch für die aktuelle Software völlig Mumpe ist.
FOp schrieb: > Und meist ist auch die Datei zu Ende, wenn das Programm zu ende ist. Für das Dateiende ist das EOF Record definiert, das optional die Startadresse des Programms enthalten kann. > Datei einfach als unverständlich zurückweisen. Das wäre unzulässig. Alle Zeilen, die nicht mit einer der definierten Markierungen beginnen, werden überlesen. Das HEX-File Format ist sehr robust. Deshalb hat es sich auch so lange gehalten.
Gast
#6811553
Christoph db1uq K. schrieb: > Ich denke, der Begriff Hex-File ist nicht genormt. Auch Eprom-Daten > wurden gelegentlich mal rein binär unter .bin oder .hex abgespeichert. > > Nur "Intel-Hex" oder der Motorola-S-Record" sind eindeutig. Vorteil ist > die reine ASCII-Notierung, die auch mit einem Texteditor lesbar ist, und > die Angaben zum Speicherort, auch mehrere Bereiche in einer Datei. Vielleicht ist es einfach mal an der Zeit, dass sich der TO mal meldet und verrät, worum es bei seinen HEX-Files genau geht.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.