elf file aus .hex files erstellen

elf?
Wohl eher eine bin, oder?

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.

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

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.