AVR-Studio mit WinAVR erzeugt plötzlich falsches HEX-Format

Liste der Anhänge anzeigen (Anzahl: 2)

Moin zusammen.

Hab ein merkwürdiges Problem:
Versuche gerade eine Steuerung für Servos zu basteln und als ich irgendwas im Programm geändert hab erzeugt der Compiler plötzlich ein merkwürdiges HEX-Format.
Das Hex-File ist auch auf einmal 29kB groß und hatte vor der Änderung bis etwas mehr über die Hälfte in den ATMega16 gepasst.

Ich hab schon in den Einstellungen alles versucht umzustellen, hatte aber keinen Erfolg.

Leider weiß ich auch nicht mehr was ich genau geändert habe, habe jedenfalls ein bisschen aufgeräumt und funktionen nach oben bzw. unten verschoben.

Das jetztige Format:
Bild hier

Ein anderes Projekt compiliert richtig:
Bild hier

Hat jemand eine Idee, woran das liegen könnte?

Hi,

das sieht nach dem Intel Hex Format aus. Ein Textfile Format für Binärdaten.
Das Ausgabeformat wird im Makefile festgelegt. Schau mal nach ob da

Zitat:

--oformat=ihex

drint steht.
Näheres steht auch im RN Wiki:
https://www.roboternetz.de/wissen/index.php/Avr-gcc

Gruß m.a.r.v.i.n

Nein, steht leider nicht drin...
Das Makefile, das von AVR-Studio erstellt wird beinhaltet folgendes:

Code:

############################################################################### # Makefile for the project Servo ############################################################################### ## General Flags PROJECT = Servo MCU = atmega16 TARGET = Servo.elf CC = avr-gcc.exe ## Options common to compile, link and assembly rules COMMON = -mmcu=$(MCU) ## Compile options common for all C compilation units. CFLAGS = $(COMMON) CFLAGS += -Wall -gdwarf-2 -DF_CPU=8000000UL -O0 -fsigned-char CFLAGS += -MD -MP -MT $(*F).o -MF dep/$(@F).d ## Assembly specific flags ASMFLAGS = $(COMMON) ASMFLAGS += -x assembler-with-cpp -Wa,-gdwarf2 ## Linker flags LDFLAGS = $(COMMON) LDFLAGS += ## Intel Hex file production flags HEX_FLASH_FLAGS = -R .eeprom HEX_EEPROM_FLAGS = -j .eeprom HEX_EEPROM_FLAGS += --set-section-flags=.eeprom="alloc,load" HEX_EEPROM_FLAGS += --change-section-lma .eeprom=0 ## Objects that must be built in order to link OBJECTS = Servo.o i2clcd.o twimaster.o ## Objects explicitly added by the user LINKONLYOBJECTS = ## Build all: $(TARGET) Servo.hex Servo.eep size ## Compile Servo.o: ../Servo.c $(CC) $(INCLUDES) $(CFLAGS) -c $< i2clcd.o: ../i2clcd.c $(CC) $(INCLUDES) $(CFLAGS) -c $< twimaster.o: ../twimaster.c $(CC) $(INCLUDES) $(CFLAGS) -c $< ##Link $(TARGET): $(OBJECTS) $(CC) $(LDFLAGS) $(OBJECTS) $(LINKONLYOBJECTS) $(LIBDIRS) $(LIBS) -o $(TARGET) %.hex: $(TARGET) avr-objcopy -O ihex $(HEX_FLASH_FLAGS) $< $@ %.eep: $(TARGET) avr-objcopy $(HEX_EEPROM_FLAGS) -O ihex $< $@ %.lss: $(TARGET) avr-objdump -h -S $< > $@ size: ${TARGET} @echo @avr-size -C --mcu=${MCU} ${TARGET} ## Clean target .PHONY: clean clean: -rm -rf $(OBJECTS) Servo.elf dep/* Servo.hex Servo.eep ## Other dependencies -include $(shell mkdir dep 2>/dev/null) $(wildcard dep/*)

Das gleicht dem funktionierenden Project genau (bis auf das, dass hier 3 Source-Dateien zu behandeln sind)

Also, wenn ich das Servo.elf durch

Code:

avr-objcopy -O binary Servo.elf Servo.hex

umwandle, siehts wieder normal aus, lässt sich mir Ponyprog übertragen und läuft :)

Aber was hab ich jetzt in AVRStudio verstellt, das er das im ihex format macht?
Vorallem ist das Makefile vom funktionierenden Projekt in dem Bereich identisch...

Idee?

Doch, ihex steht schon drin als Format. Das ist ja auch soweit ok. Ponyprog müßte beim Laden von einem Hex-File eigentlich wissen, das ein Intel Hexfile zu laden ist. Wie lädst du denn das File in Ponyprog?

Open Program (FLASH) File
Als Device Typ *.hex auswählen.
OK klicken.

Gruß m.a.r.v.i.n

Edit:

*.hex als Dateiendung für Intel Hex und Binärdatei zu verwenden, ist nicht so günstig. *.bin für Binärforamt wäre sinnvoller.

Normalerweise lade ich das File mit nem Script.
Wenn ich das so öffne, wie du sagst, dann hab ich aber genau das gleiche Problem.

Also wenn ich dich richtig verstehe, dann sollte Ponyprog die Umwandlung ins binäre Format selber machen?

Was mir auch noch auffällt:
Bei allen anderen Projekten sind die .hex-Files kleiner (ca. um den Faktor 3), als die .elf-Files. Nur bei diesem Projekt nicht, deshalb denke ich schon das es an AVRStudio liegt.

Das kann ich nicht nachvollziehen.
Lade ich ein Intel Hex File unter Ponyprog, wie oben beschrieben, dann wird dies korrekt konvertiert. Ich kann es dann auch binär speichern.

Save Program File as
Als Device Typ *.bin angeben
OK klicken.

Selbst wenn ich das Binärfile in *.hex oder ein Intel Hex File in *.bin umbenenne und lade, wird es immer korrekt konvertiert.

Welche ponyprog Version verwendest du? 2.06fBETA

Das elf File ist bei mir mehr als 10x größer als das Hex File. (evtl wg. Degug Optionen)

Gruß m.a.r.v.i.n

Ich hatte noch die Vorgängerversion.
Nach dem Update auf die 2.06fBETA funktioniert es :)

Ich wusste nicht, das Ponyprog automatsich konvertieren kann...

Es ist zwar immernoch merkwürdig, dass das AVR-Studio manchmal iHEX und manchmal das BIN-Format macht, aber so krieg ichs wenigstens gebrannt :)

--> DANKE!

Warum sagst du -O binary, wenn du ihex willst...? Evtl musst du sagen, welche Sections du im hex haben willst (hex ist zu dumm um Sections zu kennen). Das ich wichtig, demit eeprom-Info nicht ins Flash kommt und debug-Infos und so gefiltert werden.

Hier ein Makefile-Snipp, machs analog

Code:

%.hex: %.elf $(OBJCOPY) -j .text -j .data -O ihex $< $@ %_eeprom.hex: %.elf $(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O ihex $< $@

avr-objcopy

Sehr interessant die Bemerkung zum Hex.

Ich habe leider auch noch ein ungelöstes Problem und weiß nicht genau wo ich suchen muß:
Ich benutze WinAVR für die C-Programmierung, AVR-Studio für die Simulation. Für ein Bootlader-Experiment möchte ich im ATmega168 den Code auf 0x1c00 festnageln. Das geht nur leider schief. Aso der Reihe nach:
Mein makefile sieht so aus:

Code:

PRG = bootload OBJ = bootload.c MCU_TARGET = atmega168 OPTIMIZE = -O2 DEFS = LIBS = -lm # You should not have to change anything below here. CC = avr-gcc # Override is only needed by avr-lib build system. override CFLAGS = -g -Wall $(OPTIMIZE) -mmcu=$(MCU_TARGET) $(DEFS) override LDFLAGS = -Wl,--section-start=.bootloader=0x1c00,-Map,$(PRG).map OBJCOPY = avr-objcopy OBJDUMP = avr-objdump all: $(PRG).elf lst text eeprom $(PRG).elf: $(OBJ) $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $^ $(LIBS) clean: rm -rf *.o $(PRG).elf *.eps *.png *.pdf *.bak rm -rf *.lst *.map $(EXTRA_CLEAN_FILES) lst: $(PRG).lst %.lst: %.elf $(OBJDUMP) -h -S $< > $@ # Rules for building the .text rom images text: hex bin srec hex: $(PRG).hex bin: $(PRG).bin srec: $(PRG).srec %.hex: %.elf $(OBJCOPY) -j .text -j .data -O ihex $< $@ %.srec: %.elf $(OBJCOPY) -j .text -j .data -O srec $< $@ %.bin: %.elf $(OBJCOPY) -j .text -j .data -O binary $< $@ # Rules for building the .eeprom rom images eeprom: ehex ebin esrec ehex: $(PRG)_eeprom.hex ebin: $(PRG)_eeprom.bin esrec: $(PRG)_eeprom.srec %_eeprom.hex: %.elf $(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O ihex $< $@ %_eeprom.srec: %.elf $(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O srec $< $@ %_eeprom.bin: %.elf $(OBJCOPY) -j .eeprom --change-section-lma .eeprom=0 -O binary $< $@ # Every thing below here is used by avr-libc's build system and can be ignored # by the casual user. FIG2DEV = fig2dev EXTRA_CLEAN_FILES = *.hex *.bin *.srec dox: eps png pdf eps: $(PRG).eps png: $(PRG).png pdf: $(PRG).pdf %.eps: %.fig $(FIG2DEV) -L eps $< $@ %.pdf: %.fig $(FIG2DEV) -L pdf $< $@ %.png: %.fig $(FIG2DEV) -L png $< $@

Im C-Code ist <avr/boot.h> eingebunden und die Funktionen haben alle ihren Prototyp gemäß WinAVR-Doku:

Code:

// function prototypes that go into the bootloader section void wait1sec () __attribute__ ((section (".bootloader"))); char getChar () __attribute__ ((section (".bootloader"))); void putChar (char data) __attribute__ ((section (".bootloader"))); void sendString (char *string) __attribute__ ((section (".bootloader"))); void sendTheBuffer (int size) __attribute__ ((section (".bootloader"))); void receiveTheBuffer (int size) __attribute__ ((section (".bootloader"))); void xAbort () __attribute__ ((section (".bootloader"))); char xCalcSum(char *data) __attribute__ ((section (".bootloader"))); int xCalcCrc(char *data) __attribute__ ((section (".bootloader"))); void xSendPacket(char packetNum, char *data, char checkMethod) __attribute__ ((section (".bootloader"))); char xReceivePacket (char checkMethod) __attribute__ ((section (".bootloader"))); char receivePackets (char checkMethod) __attribute__ ((section (".bootloader"))); char sendPackets(int packets, char checkMethod) __attribute__ ((section (".bootloader"))); int main (void) BOOTLOADER_SECTION;//__attribute__ ((section (".bootloader")));

Bei der Übersetzung gibt es eine Warnung, weil bei diesem Controller die eeprom.h nicht funktioniert, aber das benutze ich hier auch nicht, also ignorieren.

Das erzeugte Map-File sieht auch noch vertrauenerweckend aus (besonders die letzten Zeilen):

Code:

Archive member included because of file (symbol) C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a(_copy_data.o) C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o (__do_copy_data) C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a(_clear_bss.o) C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o (__do_clear_bss) Allocating common symbols Common symbol size file xPacketBuffer 0x85 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o Memory Configuration Name Origin Length Attributes text 0x00000000 0x00020000 xr data 0x00800060 0x0000ffa0 rw !x eeprom 0x00810000 0x00010000 rw !x *default* 0x00000000 0xffffffff Linker script and memory map Address of section .data set to 0x800100 LOAD C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/crtm168.o Address of section .bootloader set to 0x1c00 LOAD C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o LOAD C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5\libm.a LOAD C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a LOAD C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5\libc.a LOAD C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a .hash *(.hash) .dynsym *(.dynsym) .dynstr *(.dynstr) .gnu.version *(.gnu.version) .gnu.version_d *(.gnu.version_d) .gnu.version_r *(.gnu.version_r) .rel.init *(.rel.init) .rela.init *(.rela.init) .rel.text *(.rel.text) *(.rel.text.*) *(.rel.gnu.linkonce.t*) .rela.text *(.rela.text) *(.rela.text.*) *(.rela.gnu.linkonce.t*) .rel.fini *(.rel.fini) .rela.fini *(.rela.fini) .rel.rodata *(.rel.rodata) *(.rel.rodata.*) *(.rel.gnu.linkonce.r*) .rela.rodata *(.rela.rodata) *(.rela.rodata.*) *(.rela.gnu.linkonce.r*) .rel.data *(.rel.data) *(.rel.data.*) *(.rel.gnu.linkonce.d*) .rela.data *(.rela.data) *(.rela.data.*) *(.rela.gnu.linkonce.d*) .rel.ctors *(.rel.ctors) .rela.ctors *(.rela.ctors) .rel.dtors *(.rel.dtors) .rela.dtors *(.rela.dtors) .rel.got *(.rel.got) .rela.got *(.rela.got) .rel.bss *(.rel.bss) .rela.bss *(.rela.bss) .rel.plt *(.rel.plt) .rela.plt *(.rela.plt) .text 0x00000000 0xa2 *(.vectors) .vectors 0x00000000 0x68 C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/crtm168.o 0x00000000 __vectors 0x00000000 __vector_default 0x00000068 __ctors_start = . *(.ctors) 0x00000068 __ctors_end = . 0x00000068 __dtors_start = . *(.dtors) 0x00000068 __dtors_end = . *(.progmem.gcc*) *(.progmem*) 0x00000068 . = ALIGN (0x2) *(.init0) *(.init1) *(.init2) .init2 0x00000068 0xc C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/crtm168.o *(.init3) *(.init4) .init4 0x00000074 0x16 C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a(_copy_data.o) 0x00000074 __do_copy_data .init4 0x0000008a 0x10 C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/avr5\libgcc.a(_clear_bss.o) 0x0000008a __do_clear_bss *(.init5) *(.init6) *(.init7) *(.init8) *(.init9) .init9 0x0000009a 0x4 C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/crtm168.o *(.text) .text 0x0000009e 0x4 C:/Programme/Atmel/WinAVR/bin/../lib/gcc/avr/3.4.3/../../../../avr/lib/avr5/crtm168.o 0x0000009e __vector_22 0x0000009e __vector_1 0x0000009e __vector_24 0x0000009e __vector_12 0x0000009e __bad_interrupt 0x0000009e __vector_6 0x0000009e __vector_3 0x0000009e __vector_23 0x0000009e __vector_25 0x0000009e __vector_11 0x0000009e __vector_13 0x0000009e __vector_17 0x0000009e __vector_19 0x0000009e __vector_7 0x0000009e __vector_5 0x0000009e __vector_4 0x0000009e __vector_9 0x0000009e __vector_2 0x0000009e __vector_21 0x0000009e __vector_15 0x0000009e __vector_8 0x0000009e __vector_14 0x0000009e __vector_10 0x0000009e __vector_16 0x0000009e __vector_18 0x0000009e __vector_20 0x000000a2 . = ALIGN (0x2) *(.text.*) 0x000000a2 . = ALIGN (0x2) *(.fini9) *(.fini8) *(.fini7) *(.fini6) *(.fini5) *(.fini4) *(.fini3) *(.fini2) *(.fini1) *(.fini0) 0x000000a2 _etext = . .data 0x00800100 0x146 load address 0x000000a2 0x00800100 PROVIDE (__data_start, .) *(.data) .data 0x00800100 0x146 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o *(.gnu.linkonce.d*) 0x00800246 . = ALIGN (0x2) 0x00800246 _edata = . 0x00800246 PROVIDE (__data_end, .) .bss 0x00800246 0x85 0x00800246 PROVIDE (__bss_start, .) *(.bss) *(COMMON) COMMON 0x00800246 0x85 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o 0x0 (size before relaxing) 0x00800246 xPacketBuffer 0x008002cb PROVIDE (__bss_end, .) 0x000000a2 __data_load_start = LOADADDR (.data) 0x000001e8 __data_load_end = (__data_load_start + SIZEOF (.data)) .noinit 0x008002cb 0x0 0x008002cb PROVIDE (__noinit_start, .) *(.noinit*) 0x008002cb PROVIDE (__noinit_end, .) 0x008002cb _end = . 0x008002cb PROVIDE (__heap_start, .) .eeprom 0x00810000 0x0 *(.eeprom*) 0x00810000 __eeprom_end = . .stab *(.stab) .stabstr *(.stabstr) .stab.excl *(.stab.excl) .stab.exclstr *(.stab.exclstr) .stab.index *(.stab.index) .stab.indexstr *(.stab.indexstr) .comment *(.comment) .debug *(.debug) .line *(.line) .debug_srcinfo *(.debug_srcinfo) .debug_sfnames *(.debug_sfnames) .debug_aranges 0x00000000 0x4c *(.debug_aranges) .debug_aranges 0x00000000 0x4c C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o .debug_pubnames 0x00000000 0xf3 *(.debug_pubnames) .debug_pubnames 0x00000000 0xf3 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o .debug_info 0x00000000 0x59e *(.debug_info) .debug_info 0x00000000 0x59e C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o *(.gnu.linkonce.wi.*) .debug_abbrev 0x00000000 0x1b2 *(.debug_abbrev) .debug_abbrev 0x00000000 0x1b2 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o .debug_line 0x00000000 0x529 *(.debug_line) .debug_line 0x00000000 0x529 C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o .debug_frame *(.debug_frame) .debug_str 0x00000000 0x24e *(.debug_str) .debug_str 0x00000000 0x24e C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o 0x292 (size before relaxing) .debug_loc *(.debug_loc) .debug_macinfo *(.debug_macinfo) OUTPUT(bootload.elf elf32-avr) .bootloader 0x00001c00 0x47c .bootloader 0x00001c00 0x47c C:\DOCUME~1\tfeli6\LOCALS~1\Temp/cck1aaaa.o 0x00001c00 wait1sec 0x00001cdc xCalcSum 0x00001dae xReceivePacket 0x00001e5c receivePackets 0x00001c70 sendTheBuffer 0x00001ec6 sendPackets 0x00001c36 putChar 0x00001f20 main 0x00001cfc xCalcCrc 0x00001d4c xSendPacket 0x00001cc8 xAbort 0x00001c46 sendString 0x00001c20 getChar 0x00001c9c receiveTheBuffer

Bis hierher haben die Tools verstanden was ich von Ihnen will. Die Adresslage paßt noch.

Das Hex-file steht dann aber "daneben":

Code:

:100000000C9434000C944F000C944F000C944F004F :100010000C944F000C944F000C944F000C944F0024 :100020000C944F000C944F000C944F000C944F0014 :100030000C944F000C944F000C944F000C944F0004 :100040000C944F000C944F000C944F000C944F00F4 :100050000C944F000C944F000C944F000C944F00E4 :100060000C944F000C944F0011241FBECFEFD4E02E :10007000DEBFCDBF12E0A0E0B1E0E2EAF0E002C0F6 :1000800005900D92A634B107D9F712E0A6E4B2E0CC :1000900001C01D92AB3CB107E1F70C94900F0C949A :0200A00000005E :1000A2000D0A582D4D4F44454D20746573740D0A49 :1000B200747970652027722720746F2072656365DA :1000C20069766520646174612066726F6D206F725B :1000D2002027732720746F2073656E642064617417 :1000E2006120746F207465726D696E616C0D0A0017 :1000F2000D0A3E003A20756E6B6E6F776E20636F4D :100102006D6D616E6400202D3E2072656164792000 :10011200746F20726563656976652C2077616974F6 :10012200696E6720666F722064617461207061631A :100132006B65747300202D2063616E63656C6C6562 :1001420064202873657276657220646964206E6F1C :100152007420726573706F6E642077697468696E5B :1001620020313230732900202D3E2072656164797E :1001720020746F2073656E642C2077616974696ED8 :100182006720666F72207265717565737400202D29 :10019200207472616E736D697373696F6E20636F21 :1001A2006D706C6574656400202D207472616E73CD :1001B2006D697373696F6E2061626F72746564003A :1001C200202D207472616E736D697373696F6E2076 :1001D20061626F727465642064756520746F206556 :0601E20072726F727300DF :00000001FF

Alles ist wie immer ab Adresse 0x0000 referenziert, auch AVR-Studio zeigt mir in der Simulation Nonsens in der falschen Adresslage an (die Bootreset-Option habe ich auf 0x1c00 eingestellt). Also scheint es am Generator für die Hex-Files / makfile zu liegen. Aber wo?

Muß ich dem Hex-File-Generator (avr-objcopy?) noch etwas im makefile mitteilen? Wenn ja was und wie? In der Doku (zu WinAVR) habe ich es noch nicht gefunden.

Bevor sich jetzt jemand wundert: Dies ist bisher irgendein Programm, das im Bereich des Bootloaders residieren soll, ohne SPM und alles. Erst wenn das stimmt, gehe ich an die Entwicklung des eigentlichen Bootladers...

Hi H.A.R.R.Y,

warum änderst du nicht einfach die Startadresse des .text Segment, statt ein neues zu erfinden. Außerdem müßte für den mega168 der Bootloader bei Adresse 0x3800 beginnen.

Zitat:

--section-start=.text=0x3800

Oder guck dir mal an, wie das beim chip45 Bootloader gemacht ist:
http://www.chip45.com/index.pl?page=chip45boot&lang=de

Gruß m.a.r.v.i.n

Bei erzeugen des Hex machst du eigene HEX für jedes Modul (.text, .bootloader, .eerom)

%_bootloader.hex: %.elf
$(OBJCOPY) -j .bootloader --change-section-lma .bootloader=0x1c00 -O ihex $< $@

Falls objcopy keine hex-Zahlen frisst, musst die 0x1c00 eben noch nach dezimal umrechnen.

Die Startadressen für die Lokatierungen findest du im linker description file.

Hi, ich wußte doch das hier professionelle Hilfe geboten wird :D

Okay, Danke Euch, ich versuche mal beide Varianten.

Bei der Option das .text-Segment komplett zu verschieben habe ich auch die komplette IRQ-Tabelle und jede Menge anderen Init-Code vom Compiler mit drin. VORTEIL: Abgesehen von der Startadresse ist alles "wie gewohnt". ABER: es gibt so ein paar "Härtefälle" in denen die absolute minimal-Init (IRQs aus, Stackpointer=RAMTOP und ein zwei Register für den Compiler) vollkommen ausreicht, der Rest steht mit für's Programm zur Verfügung. Dazu muß ich halt sehr genau wissen, was ich da treibe sonst hakt es später im compilierten Programm. Sehe ich das richtig? Über die Frage "guter Programmierstil" möchte ich hier jetzt bitte nicht diskutieren, es geht ums Verständnis.

Die 0x3800: Laut Doku wird im FLASH mit Wortadressen gerechnet? Naja, das ist aber glaub ich die geringste Schwierigkeit. Ich seh ja im Simulator wohin der mir den Code packt.

Danke auch für das Syntax-Beispiel, jetzt ist der Groschen gefallen ("... ah jetzt ja!") :idea:

Eine Frage hät' ich noch: Wie heißt so ein Linker Description File typischwerweise und wo kann ich es finden (im WinAVR-Verzeichnisbaum, GROBE Angabe reicht mir schon)? Reicht ein ordinärer Texteditor (notepad, xemacs, ...) zum ansehen? Falls nicht, welches Tool benötige ich dazu?

DANKE und Gruß
H.A.R.R.Y.

Zitat:

Zitat von H.A.R.R.Y.

Eine Frage hät' ich noch: Wie heißt so ein Linker Description File typischwerweise und wo kann ich es finden (im WinAVR-Verzeichnisbaum, GROBE Angabe reicht mir schon)?

https://www.roboternetz.de/wissen/in...erzeichnisbaum

Abhängig von den Linker-Flags wird ein anderes ld-Skript genommen (*.x, *.xb) aber frag mich jetzt nicht, was die Endungen bedeuten und wann welche genommen wird.

Vielleicht mal die specs befragen (welche genommen werden siehst du mit avr-gcc -v ...)

AFAIK kannst du auch einfach ein ld-Skript dazulinken. Alles, was kein elf32-avr ist, wird als ld-Skript interpretiert.

Ob die Lokatierungen stimmen siehst du im Mapfile.

Da IHEX keine Sektion-Information trägt (bzw alles in eine große Sektion gestopft wird) muss die lma (load memory address) für jeden Code-Block (.eeprom, ...) angegeben werden.

Zitat:

Zitat von H.A.R.R.Y.

Reicht ein ordinärer Texteditor (notepad, xemacs, ...) zum ansehen? Falls nicht, welches Tool benötige ich dazu?

Ein Skript ist ein Skript und damit plain text.

(x)emacs ist kein Editor, sonder ein Betriebssystem. Bzw wäre ein Betriebbsystem, wenn ein guter Editor dabei wäre ;-)

Feine Erklärung. Damit komme ich zurecht.
Danke

Gruß H.A.R.R.Y.