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
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.
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...
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.
