COFF Datei mit Codeblocks (WINAVR) erzeugen

[Peter (Gast)]

Hallo,

wie kann ich die COFF Datei mit Codeblocks und WINAVR erzeugen?

Ich bekomme nur eine Hex Datei aber damit kann das AVR-Studio nicht so 
viel anfangen.


Viele Grüsse, Peter

[... (Gast)]

Du brauchst die .elf Datei. Das AVRStudio will aber sowieso dwarf2. Beim 
gcc ist die -g Option dafür zuständig. Keine Ahnung wo man die in 
Codeblocks setzen kann/muß.

[Peter (Gast)]

-g ist gesetzt aber es kommt nicht raus.

Hoffentlich kann mir hier jemand helfen.
Ich werde aber zur Sicherheit mal ein Makefile bauen.

Peter

[... (Gast)]

Richtiger wäre auch -gdwarf-2
Trotzdem erzeugt WinAVR normalerweise ein .elf File, aus welchem 
anschließend mittels avr-objcopy das .hex erzeugt wird.
Benutzt Du ein eigenes Makefile oder bastelt Codeblocks sich da selbst 
was zusammen?
Wenn Du ein eigenes baust, dann benutze am besten mfile (ist bei WinAVR 
dabei).

[Peter (Gast)]

Code::Blocks bastelt sich das was eigenes.

Der Fehler sitzt aber zwischen den Ohren.

Die ELF-Datei ist die Debugdatei und nicht die AVR-Studio 
Brenner-ELF-Datei.

Blöde namens Vergabe.

[Jörg W. (dl8dtl) (Moderator)]

Peter schrieb:
> Blöde namens Vergabe.

Nö, bloß nicht richtig verstanden: ELF ist das Objektformat, das
vom GCC native benutzt wird.  Das wird sowohl benutzt für verschieb-
liche Objektmodule (compilierter und assemblierter Code, der noch
gelinkt werden muss) als auch für das fertig gelinkte Objekt.  In
der normalen Unix-Benamung (aus der der GCC stammt), würde man der
fertigen ELF-Datei gar keinen Dateinamenssuffix geben, da sie ja
letztlich ein ausführbares Kommando darstellt (das vom Betriebssystem
direkt geladen werden kann).  Da Windows nicht so sehr glücklich ist,
wenn es nicht seine von CP/M stammenden drei Buchstaben als Datei-
endung sieht, hat es sich im embedded-Bereich eingebürgert, dem
Ergebnis des Linkers ein .elf anzuhängen.

Wenn du beim Compilieren Debug-Informationen erzeugt hast (und diese
nicht später entfernen lassen hast), dann enthält die fertig gelinkte
ELF-Datei auch die kompletten Debuginformationen.  Da sie zugleich
aber auch alle Informationen enthält, die man zum Laden des Controllers
benötigt, bietet AVR Studio mittlerweile an, dass man diese ELF-Datei
auch direkt zum Befüllen des AVRs benutzen kann.  Damit spart man sich
den Umweg, die Ladedaten erst einmal mittels avr-objcopy aus der
ELF-Datei zu extrahieren, nur um sie anschließend dem Programmier-
werkzeug zum Fraß vorzuwerfen.

Technisch gesehen ist diese fertig gelinkte (und damit auf eine
feste Ladeadresse gebundene) ELF-Datei also sowohl die Debug-Datei
als auch die Lade-Datei.

[Peter (Gast)]

Man lernt immer wieder dazu.

Danke, Peter

[akurtj (Gast)]

In die Pre/post build steps z.B. folgendes eintragen:

cmd /c "avr-objdump -h -S $(TARGET_OUTPUT_FILE) > 
${TARGET_OUTPUT_DIR}$(TARGET_OUTPUT_BASENAME).lss"
avr-objcopy --debugging --change-section-address .data-0x800000 
--change-section-address .bss-0x800000 --change-section-address 
.noinit-0x800000 --change-section-address .eeprom-0x810000 -O 
coff-ext-avr $(TARGET_OUTPUT_FILE) 
${TARGET_OUTPUT_DIR}$(TARGET_OUTPUT_BASENAME).cof
avr-objcopy -O ihex -R .eeprom -R .eesafe $(TARGET_OUTPUT_FILE) 
${TARGET_OUTPUT_DIR}$(TARGET_OUTPUT_BASENAME).hex
avr-objcopy --no-change-warnings -j .eeprom 
--set-section-flags=.eeprom="alloc,load" --change-section-lma .eeprom=0 
-O ihex $(TARGET_OUTPUT_FILE) 
${TARGET_OUTPUT_DIR}$(TARGET_OUTPUT_BASENAME).eep
avr-size --mcu=atmega162 --format=avr $(TARGET_OUTPUT_FILE)

Gruß,
    Kurt

[Jörg W. (dl8dtl) (Moderator)]

akurtj schrieb:
> In die Pre/post build steps z.B. folgendes eintragen:

Und warum?  Hast du dir den Rest des Threads durchgelesen?  Das olle
AVR-COFF wird nämlich gar nicht mehr benötigt...

[akurtj (Gast)]

Weil Peter danach gefragt hat, wie er es in C::B 'einbaut'.
Ob eine coff-Datei sinnvoll ist, ist eine andere Frage... die Du ja 
umfassend beantwortet hast.