Hallo, wir haben für diverse AVR Projekte 2 .hex files FLASH.hex (für den Flash-Teil) EEPROM.hex (für den EEPROM-Teil) (erstellt über völlig verschiedene Tool-Chains) Um Kleinserien zu programmieren haben wir .bat files mit atprogramm.exe erstellt, um flash und eeprom in Serie zu flashen. Um Sachen zu vereinfachen und um Fehler auszuschließen, würden wir gerne beide files in ein .elf "zusammenpacken". Atmel-Studio geht das auch recht schön (sogar die fuses & lock-bits kann man dazupacken). Noch schöner wäre es aber für uns, wenn man das "automatisieren" könnte (auf Kommandozeilen-Ebene). Mittels objcopy.exe -I ihex -O elf32-avr --rename-section .sec1=.text -v FLASH.a90 output_flash.elf und objcopy.exe -I ihex -O elf32-avr --rename-section .sec1=.eeprom -v EEPROM.a90 output_eeprom.elf bekommen wir schonmal je ein .elf für den Flash und EEprom. Jedoch haben wir nichts gefunden, um ein "gemeinsames" .elf zu erzeugen, geschweige dann fuse-bits abzulegen. Irgendwelche Ideen? Robert
Du machst also: Source Code -> Compiler -> .o Datei ELF -> Linker -> Gelinktes Programm als ELF -> objcopy -> .hex -> objcopy -> .elf? Warum lässt du nicht einfach die letzten 2 Schritte weg, d.h. verwendest direkt die Ausgabe des Linkers, welche ja bereits eine ELF Datei ist, anstatt die erstmal nach hex und dann wieder zurück nach ELF zu konvertieren? Klingt ziemlich redundant, auch weil das originale ELF ja auch noch zusätzliche (Debug) Informationen enthalten kann die dadurch verloren gehen.
Hmm. Erzeugt werden die Files bei uns wie folgt: FLASH.hex kommt aus dem IAR for AVR (da kommt halt .hex raus) und die Parameter im EEPROM.hex (Parameter) werden aus einem "komplizierten" EXCEL-Tool mit nach gelagerten Übergabeprogramm erzeugt. Da ist in der "Toolchain" erstmal kein objcopy drinnen. Gruß Robert
Robert Goldner schrieb: > FLASH.hex kommt aus dem IAR for AVR (da kommt halt .hex raus) Und die IAR Toolchain produziert nicht erstmal ein ELF File welches dann nach .hex konvertiert wird? Robert Goldner schrieb: > die Parameter im EEPROM.hex (Parameter) werden aus einem "komplizierten" > EXCEL-Tool mit nach gelagerten Übergabeprogramm erzeugt. Die allseits beliebten Excel-Tools... konvertier das doch in ein Binärformat und binde das dann in den Linker-Prozess ein, z.B. so: Beitrag "Re: Externen Dateinhalt als String beim Kompilieren importieren" Da dann die gewünschte EEPROM Section statt .rodata verwenden. Dann sparst du dir alle Umwege über hex Dateien.
Hallo, meines Wissens produziert die IAR Toolchain kein elf-file. Wäre aber auch egal, weil unser Work-Flow sieht so aus: Es gibt 4 zentrale Flash-Files (FLASH0-3.HEX), welche sich "nie" ändern. Die Parametrisierung für einzelne Applikationen wird über das EEPROM.HEX durchgeführt. Davon gibt es dann ganz viele verschiedene (>50), und es werden mit der Zeit immer mehr. Eigentlich gut, weil so ist der Plattformgedanke umgesetzt. Die Parameter erstellen auch (meist) nicht die Programmierer der FLASH0-3.HEX, sondern Personen, die von Programmierung nicht so viel Ahnung haben. Jetzt wäre es halt schön, wenn man ohne den Umweg über die "Bunti-Klicki-Gui" vom Atmel-Studio aus dem passenden z.B. FLASH1.HEX und EEPROM27.HEX (und gerne auch mit Fuse und Lock Bits) sich per Commando-Zeile ein .elf-File basteln könnte. Wie schon gesagt, über Amtel-Studio (Device-Programming ==> Simulator ==> Production File ==> "Save to ELF production file") funktioniert es, ist aber nicht intuitiv und vernünftig automatisierbar. Gruß Robert
Entweder mehrere --add-section beim objcopy oder mehrere elfs mit "ld -r" zusammenlinken.
Hallo, wenn ich das richtig verstehe, hast du als Ausgangsbasis 2 Hex-Dateien, die du gerne in einer zusammenfassen würdest, um das Flashen zu vereinfachen. Diese zusammengefasste Datei sollte auch wieder eine Hex-Datei sein. Falls das so ist, ist die Lösung denkbar einfach. Hex-Dateien sind Textdateien in einem bestimmten Format. Diese lassen sich aneinanderhängen, z.B. mit cat file1.hex file2.hex >> file3.hex Ich mache das bei einem Projekt mit STM32 so, wo Bootloader und Firmware in eine Datei gepackt werden um beim Dienstleister geflasht zu werden. Das funktioniert einwandfrei.
Tipp: Man kann Binary in ELF "einbetten" bzw. einbeziehen auf unterschiedliche Arten, gibt sogar ein Artikel im Wiki dazu.
:
Bearbeitet durch User
Oliver R. schrieb: > wenn ich das richtig verstehe, hast du als Ausgangsbasis 2 Hex-Dateien, > die du gerne in einer zusammenfassen würdest, um das Flashen zu > vereinfachen. Diese zusammengefasste Datei sollte auch wieder eine > Hex-Datei sein. > > Falls das so ist, ist die Lösung denkbar einfach. Hex-Dateien sind > Textdateien in einem bestimmten Format. Diese lassen sich > aneinanderhängen, z.B. mit > > cat file1.hex file2.hex >> file3.hex Das funktioniert in diesem Fall natürlich nicht. Flash und EEPROM (und auch Fuses/Lockbits/SignatureRow) sind beim AVR8 völlig verschiedene Adressräume und müssen mit unterschiedlichen Kommandos programmiert werden. Theoretisch könnte man das trotzdem in einem Hexfile unterbringen, dann müßte man aber einen Standard für das Mapping in einen gemeinsamen Adressraum vereinbaren. Ein solcher Standard existiert aber nicht. Wenn man die volle Kontrolle über die Programmiersoftware hat (weil man sie ebenfalls selbst programmiert hat), dann kann man sich seinen eigenen Standard schaffen. Dann geht das. Wir machen das z.B. so. Aber es geht dann eben nur mit der eigenen Programmiersoftware. Das ist halt der ganze Gültigkeitsbereich des selbstgesetzten Standards...
Der Linker linearisiert doch den Adressraum?
Oliver R. schrieb: > Hex-Dateien sind > Textdateien in einem bestimmten Format. Diese lassen sich > aneinanderhängen, z.B. mit Leider nur fast richtig. Intel Hex Dateien haben einen "Ende" Record, d.h. man muss beim Zusammenbacken die letzte Zeile entfernen - außer beim letzten File.
Jim M. schrieb: > Leider nur fast richtig. Intel Hex Dateien haben einen "Ende" Record, > d.h. man muss beim Zusammenbacken die letzte Zeile entfernen - außer > beim letzten File. Gute Anmerkung! Scheint allerdings zumindest das ST-Utility beim Flashen nicht zu interessieren. Wird vermutlich einfach ignoriert.
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.