AVR-Gcc Array Initialisierung

Johannes Bauer schrieb:

a.) Compiler-Fehler: Extrem unwahrscheinlich. b.) Simulator-Fehler. Relativ unwahrscheinlich c.) Mikrocontroller-Defekt: Schon möglich, aber eher selten. d.) Elektronik um Mikrocontroller defekt: Hohe Wahrscheinlichkeit. e.) Du suchst den Fehler an falscher Stelle: Nahezu sicher.

Michael Roth schrieb:

Okay. Testprogramm (vollständig!):

#include

unsigned char numbers[] = { 9, 12, 18, 20, 31, 44, 66, 77 };

void tx(unsigned char c) { while (!(UCSRA & (1

Warum meinst Du, dass die Initializerung ins TEXT Segment soll? Mach mal ein avr-size avr-size test1 text data bss dec hex filename 264 8 0 272 110 test1

und rate, woher die 8 Bytes im Datensegment kommen?

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

versuchs mal mit avr-objcopy -j .text -j .data -O binary test test1.bin

--
MFG Gernot

Weil es auf einem AVR keinen Sinn ergbibt, ein Datensegment zu erzeugen, das nie auf die MCU kommt. Auf meinem Mega habe ich ein Text- und ein EEPROM-Segment, aus.

Schon klar. Deswegen sagte ich auch "Im SRAM wird in der Data Section dafür Platz eingeplant, im Objectdump sehe ich auch die Werte." und das ist auch der Grund, weshalb die Simulation korrekt funktioniert (sie läd eben die Data Section!).

Nur: Wie bekomm ich die auf die MCU?

Gruß, Johannes

--
durch dei Verdunstung kült das sogar ziemlich gut
das ist wie schweiß. Hünde müssen da hecheln so wie Lüfter.
                              Markus Gronotte in de.sci.electronics

Johannes Bauer schrieb:

AAAAAH!

Wer code liest, ist schlauer.

00000060 : 60: 10 e0 ldi r17, 0x00 ; 0 62: a0 e6 ldi r26, 0x60 ; 96 64: b0 e0 ldi r27, 0x00 ; 0 66: ec e8 ldi r30, 0x8C ; 140 68: f9 e1 ldi r31, 0x19 ; 25 6a: 02 c0 rjmp .+4 ; 0x70

Das eine ist der Anfang des RAM (0x0060), das andere das ENDE des Programms (0x198c -> Ein anderes Programm, das eben genau 6540 Bytes groß ist).

Wenn ich das richtig verstehe, muss ich einfach nur die Daten-Sektion mit der Text-Sektion konkatenieren, flashen, feritg.

Hab jetzt aber leider keine Zeit zum testen mehr. Danke für die Hilfe!

Viele Grüße, Johannes

--
durch dei Verdunstung kült das sogar ziemlich gut
das ist wie schweiß. Hünde müssen da hecheln so wie Lüfter.
                              Markus Gronotte in de.sci.electronics

Warum soll der AVR-GCC die Anweisung unsigned char bla[] = { 2, 3, 5, 7, 11, 13, 17 };

ins Flash Segment legen? Du hast da variable Daten vereinbart, in die Du auch zur Laufzeit ohne Klimmzuege Daten schreiben kannst.

Wenn die Daten konstant sind und aus dem Flash geladen werden soll, dann schau Dir mal die avr/pgmspace.h Header Datei an.

--
Uwe Bonnes                bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik  Schlossgartenstrasse 9  64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Johannes Bauer schrieb:

Mein Makefile (angelehnt an das, was mit WinAVR mitgeliefert wird) macht immer

avr-objcopy -O ihex -R .eeprom foobar.elf foobar.hex

Damit sind bisher immer alle Sektionen in der richtigen Reihenfolge im Flash gelanden.

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA

Christian Zietz schrieb:

Bist du dir sicher, dass du nicht "-j .text -j .data" meinst?

Damit tut's jetzt nämlich.

Gruß, Johannes

--
durch dei Verdunstung kült das sogar ziemlich gut
das ist wie schweiß. Hünde müssen da hecheln so wie Lüfter.
                              Markus Gronotte in de.sci.electronics

Johannes Bauer schrieb:

In meinem Makefile steht halt "-R .eeprom". Damit tut's nämlich auch.

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA