Gast
#1708097
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
#1708108
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ß.
Gast
#1708120
-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
#1708144
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).
Gast
#1708164
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.
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.
Gast
#1708173
Man lernt immer wieder dazu. Danke, Peter
Gast
#1708934
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
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...
Gast
#1709573
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.