HEX > BIN, warum BIN überhaupt verwenden?

Entwickler schrieb:

Haben BIN überhaupt irgendwelche Vorteile gegenüber HEX?

Bei BIN muss man die Adresse im ROM, an die geladen werden soll, manuell eingeben. Hex ist solange bequemer und sicherer, solange die Daten auch an der angegebenen Adresse landen sollen, was nicht immer der Fall ist. Z.B. wenn Programme vom ROM ins RAM kopiert werden sollen. Ev. hat man auch nur BIN, aber das lässt sich ja umwandeln in HEX, z.B. auch mit der Prommer-Software.

Georg

Ein Grund für BIN ist historisch - wenn man ein ROM als separaten Baustein programmiert, dann ist das ein Abbild dessen Speicherinhalts, unabhängig, an welcher Adresse der Inhalt dann für den das ROM nutzenden Prozessor zu sehen ist. Das ist dann unmissverständlicher in ein EPROM oder Flash-ROM zu brennen als ein Hex-File mit Adressinformationen.

Marc X. schrieb:

weil es keinen Overhead durch Meta-Informationen gibt.

Das ist das wenigste, hauptsächlich ist bei BIN ein Byte eben ein Byte und nicht 2 Hex-Ziffern - braucht also nur die Hälfte so viel Platz.

DerEinzigeBernd schrieb:

Das ist dann unmissverständlicher in ein EPROM oder Flash-ROM zu brennen als ein Hex-File mit Adressinformationen.

Ja, aber man muss dann wissen in welche Fassung das EPROM zu stecken ist, also muss man die jeweilige Startadresse zusätzlich aufheben oder zumindest die laufende Nummer des EProms - ich habe den Speicherbereich oft auf dem Aufkleber auf dem EProm vermerkt, damals war da ja noch so schön viel Platz.

Georg

Ich nehme nur die BINs. Diese werden mit dfu-util an eine feste, immer gleich Adresse geschrieben, und gut ist. Ich mußte mir noch nie irgendwelche Adressen merken.

dfu-util --device 0483:df11 --alt 0 -s 0x08000000 --download $NAME

Danach Reset und das Programm startet.

PittyJ schrieb:

Ich mußte mir noch nie irgendwelche Adressen merken.

dfu-util --device 0483:df11 --alt 0 -s 0x08000000 --download $NAME

0x08000000 ist die Adresse, die Du Dir da gemerkt hast.

PittyJ schrieb:

dfu-util --device 0483:df11 --alt 0 -s 0x08000000 --download $NAME

Solche Kommandos zu Scripten ist auf jeden Fall eine gute Idee. Mit einer interaktiven GUI zu arbeiten ist fehleranfälliger.

Entwickler schrieb:

Haben BIN überhaupt irgendwelche Vorteile gegenüber HEX?

Moin,

Du kannst ein *.bin direkt zu einem anderen Executable dazu linken (z.B. Bootloader + Applikation), wenn am Ende ein kombiniertes Executable beider Teile gewünscht ist.

Gruß, Michael

Michael F. schrieb:

Du kannst ein *.bin direkt zu einem anderen Executable dazu linken (z.B. Bootloader + Applikation), wenn am Ende ein kombiniertes Executable beider Teile gewünscht ist.

Kannste mit Hex doch auch - einfach in eine Datei zusammenführen.

Nop schrieb:

Michael F. schrieb:

Du kannst ein *.bin direkt zu einem anderen Executable dazu linken (z.B. Bootloader + Applikation), wenn am Ende ein kombiniertes Executable beider Teile gewünscht ist.

Kannste mit Hex doch auch - einfach in eine Datei zusammenführen.

Moin,

es geht nicht darum, zwei fertige *.hex zusammenzuführen.

Der Linker kann z.B. das Binary der Applikation ins Executable des Bootloaders integrieren, um dann ein gemeinsames ELF zu haben, welches man debuggen kann.

Gruß, Michael

Michael F. schrieb:

Der Linker kann z.B. das Binary der Applikation ins Executable des Bootloaders integrieren, um dann ein gemeinsames ELF zu haben, welches man debuggen kann.

Im BIN sind aber keine Debugging-Informationen drin - also ich sehe da keinen Unterschied zum Zusammenführen auf Ebene des Hexfiles.

Tja, und auf ST's Community fragen sich die Leute gelegentlich, warum aus ein paar MByte plötzlich ein paar GByte als Binärdatei werden: Weil interner und externer Flash sich nicht unmittelbar aneinander anschließen, sondern eine Riesenlücke dazwischen ist. Da im Binärformat keine Adressinformation drin ist, wird die Lücke dann halt schön aufgefüllt und die Platte rödelt und rödelt ... ;-)

Nebenbei ist Intel-Hex eher ein Krampf, weil die Adressen nicht unmittelbar drin stehen, sondern aus Offset und Basis ermittelt werden müssen. Echt lästig, wenn man da einen Teil herausschneiden muss ... Da lob' ich mir Motorola.

Und ganz früher, als noch die Saurier hier hausten, gab es erst mal nur .HEX. Daraus wurden dann .BIN, da das Intel-HEX usw. aufkam. Für den PC entwickelt. Nur interessant für Compiler, die aber für den Bastler nicht interessant waren. Für Microprozessoren eher nicht nötig.

Zum Brennen sind .hex oder Motorola besser geeignet, da Offset und Lücken möglich sind.

Neben kleiner hat .bin auch den Vorteil durchsuchbar zu sein. Die Ausgabe "Hello World" in "Hallo Welt" zu ändern, fällt vielen binär einfacher.

Nop schrieb:

Michael F. schrieb:

Der Linker kann z.B. das Binary der Applikation ins Executable des Bootloaders integrieren, um dann ein gemeinsames ELF zu haben, welches man debuggen kann.

Im BIN sind aber keine Debugging-Informationen drin - also ich sehe da keinen Unterschied zum Zusammenführen auf Ebene des Hexfiles.

Moin,

korrekt, im dazugelinkten *.bin sind keine Debug-Infos drin. Der IAR C-SPY Debugger kann aber bei einer Debug-Session zusätzliche Infos aus einem ELF/DWARF laden und somit hätte man beim genannten Beispiel sowohl im Bootloader, als auch in der Applikation dann den vollen Komfort beim Debuggen.

Also so in der Art:

1

Bootloader   *.elf   <= Debug Info enthalten

2

Applikation  *.bin   <= Debug Info wird aus zugehörigem ELF/DWARF geladen

Hier wird der Ansatz im Kapitel "Debugging considerations" beschrieben: https://www.iar.com/knowledge/support/technical-notes/general/creating-a-bootloader-for-cortex-m/

Gruß, Michael