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
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
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.
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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.