Forum: Mikrocontroller und Digitale Elektronik HEX > BIN, warum BIN überhaupt verwenden?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Entwickler (Gast)


Lesenswert?

Hallo Leute,

Mikrocontroller ist STM32F303VC

Mit CubeIDE erzeugt HEX hat in der ersten Zeile den Offset stehen.

:020000040800F2
:100000 0000A00020(*) 1D290008391F00083F1F00081C
:10001000451F00084B1F0008511F0008000000008A
:10002000000000000000000000000000571F000852

Die Zuordnung Daten -> Adresse scheint damit vollständig definiert zu 
sein.

Mit CubeIDE erzeugte BIN scheint Stackpointer und isr_vector auf
Adresse 0 zu mappen. Wobei über Linker Script diese auf den
FLASH Anfang 0x08000000 gelegt sind.

$ xxd -a -e -c32 *.bin | head -10
00000000: 2000a000(*) 0800291d 08001f39 08001f3f 08001f45 08001f4b 
08001f51 00000000

(*) = initiale stack pointer. Wobei bei BIN xxd das ending gedreht hat.

STI-LINK_CLI will für BIN auch die Ladeadresse hinter Dateinamen.

Haben BIN überhaupt irgendwelche Vorteile gegenüber HEX?
Wie steht SREC hier im Vergleich?

Viele Grüße

von Achim M. (minifloat)


Lesenswert?

0x08000000... bin kennt keine Offsets; mit 128MB voll 0x00 am Anfang ist 
so ein binary irgendwie unhandlich. Nimm ihex oder eines der 
Motorola-Formate.

mfg mf

von Georg (Gast)


Lesenswert?

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

von DerEinzigeBernd (Gast)


Lesenswert?

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.

von Marc X. (marc_x)


Lesenswert?

Naja ein .bin File enthält nur die reine Payload, Intel Hex und 
Tektronix Hex enthalten auch die Information wohin die Daten sollen und 
einen Mechanismus um die Datei auf Validität zu prüfen (Prüfsumme), 
Motorola S-Record erlaubt theoretisch durch den Header sogar noch 
weitere Meta-Informationen in die Programmierdatei mitaufzunehmen. Zudem 
sind alle 3 Formate auch menschenlesbar und könnten Daten enthalten, 
welche auch in nicht zusammenhängende Speicherbereiche geschrieben 
werden sollen.

Einziger Vorteil der Binärdatei ist die geringere Dateigröße bei 
vollständigen Abbildern von Speicherbereichen, weil es keinen Overhead 
durch Meta-Informationen gibt.

von Georg (Gast)


Lesenswert?

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

von PittyJ (Gast)


Lesenswert?

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.

von Nop (Gast)


Lesenswert?

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.

von Steve van de Grens (roehrmond)


Lesenswert?

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.

: Bearbeitet durch User
von Michael F. (Firma: IAR Systems) (michael_iar)


Lesenswert?

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

von Nop (Gast)


Lesenswert?

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.

von Walter K. (walter_k488)


Lesenswert?

Einigt Euch doch in der Mitte - also bei Oktal

von Michael F. (Firma: IAR Systems) (michael_iar)


Lesenswert?

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

von Nop (Gast)


Lesenswert?

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.

von A. B. (Gast)


Lesenswert?

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.

von michael_ (Gast)


Lesenswert?

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.

von A. S. (achs)


Lesenswert?

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.

von Michael F. (Firma: IAR Systems) (michael_iar)


Lesenswert?

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

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]
  • [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.

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