Hallo!
Beim Kompilieren meines SourcesCodes erscheinen folgende Fehler:
C:\{Pfad} ccEXaaaa.s: 2492: Error: operand out of range: -2049
C:\{Pfad} ccEXaaaa.s: 2495: Error: operand out of range: -2051
C:\{Pfad} ccEXaaaa.s: 2498: Error: operand out of range: -2053
C:\{Pfad} ccEXaaaa.s: 2501: Error: operand out of range: -2055
C:\{Pfad} ccEXaaaa.s: 2504: Error: operand out of range: -2057
Ich habe schon verschiedene Möglichkeiten probiert und
selbstverständlich auch im Internet bzw. verschieden Foren gesucht, bin
dabei aber leider nicht glücklich geworden. Aus diesem Grund wollte ich
euch bitten, mir bei diesem Problem behilflich zu sein!
Vielen Dank im Voraus!
LG NoSiCo
Hallo Kosmo!
Yep, da hast Du sicherlich Recht, habe den Beitrag ein bisschen
überstürzt, aber genau hier beginnt mein Problem ;)
Ich verwende einen ATMega2560 und das derzeitige HEX-File weißt eine
Größe von 12KB auf. Es ist noch nicht sehr viel inkludiert außer SPI und
USARTs.
Der oben beschriebene Fehler erscheint auch nicht immer und vorallem ist
er nicht auf einzelene Zeilen/Operationen beschränkbar. Ich habe zum
Beispiel ca. 7 Zeilen, die folgendermaßen aussehen:
RTC_date = ((temp & 0x30) >> 4)*10 + (temp %10);
Wenn ich jetzt aber mehr als 5 von diesen 7 Zeilen stehen lasse (egal
welche, switchen bringt keinen Unterschied!!!), dann erscheinen die
Fehler! Ich tippe mal Richtung Makefile, kann aber den Verdacht nicht
untermauern. Ich finde es nur sehr faszinierend, dass es bei der
gesamten Problematik nicht davon abhängt, "welchen Sourcecode ich
schreibe".
LG NoSiCo
Wie sind RTC_date und temp deklariert? Was steht in der temporären Datei
ccEXaaaa.s in den Zeilen 2492, 2495, 2498, 2501, 2504?
Wenn du die temporäre Datei nicht einsehen kannst, versuche es mit einer
Compilierung mit der -S Option (Ausgabe als Assemblerquelltext).
RTC_date und temp sind beide BYTE (#define BYTE unsigned char).
Hm. leider kann ich "ccEXaaaa.s" nicht einsehen, jetzt probiere ich es
mal die dem Assemblerquelltext.
Ich möchte aber noch anmerken, dass dieser Fehler nicht das erste mal
bei meinen Programmen auftritt, sondern viel öfter erscheint. Wie
gesagt, ich kann dabei nie auf einen offensichtlichen Fehler in einer
Zeile schließen, es sieht eher danach aus, wie wenn den uCs der Speicher
ausgeht, aber auch das kann ich ausschließen, da ich der Fehler
teilweise damit behoben werden kann, dass ich an völlig anderen Stellen
im Courcecode etwas streiche!
ich nehme an, die ca. 7 zeilen unterscheiden sich, ansonsten spielt dir
bekanntlich der optimierer einen streich.
schau mal, ob du den asm-code zusammenkriegst, wie stefan vorgeschlagen.
und die deklarationen auch.
Yep, die 7 Zeilen unterscheiden sich ;)
Hm, ich habe leider noch nicht herausgefunden, wo ich dieses "-s"
schreiben muss, damit mir ein Assembler-Code ausgegeben wird, weil ich
das bis dato noch nie gemacht habe.
Ich habe aber jetzt einmal die Optimierung auf -00 gestellt und die
Fehler sind weg :|
Ich werde mich aber auf alle Fälle wieder melden, wenn ich weiß, wie das
mit dem AssemblerCode aussieht!
LG NoSiCo
NoSiCo wrote:
> Hm, ich habe leider noch nicht herausgefunden, wo ich dieses "-s"> schreiben muss, damit mir ein Assembler-Code ausgegeben wird, ...
Es ist ein -S (das ist was anderes). Du gibst es statt eines -c
beim Aufruf des AVR-GCC an.
Wenn du das Makefile von WinAVR nimmst, genügt es, wenn du auf der
Kommandozeile "make foo.s" sagst, wenn deine C-Datei "foo.c" heißt.
Welchen Compiler nimmst du für den ATmega2560, die AtmanAVR-Variante?
> Ich habe aber jetzt einmal die Optimierung auf -00 gestellt und die> Fehler sind weg :|
Ja klar. Ist ja dann auch komplett anderer Code, der da generiert
wird.
Sorry, Kopierfehler!
void init_uart0(void)
{
UBRR0L = 25; // 38462 (0.2%)
UCSR0B = 0xD8;
UCSR0C =
((0<<UMSEL01)|(0<<UMSEL00)|(1<<UPM00)|(1<<UPM01)|(1<<UCSZ01)|(1<<UCSZ00)
);
}
Achja, wenn ich init_uart0 rausnehme, bekomme ich den Fehler bei
init_uart1 und wenn ich die dann auch rausnehme ist er weg!?!
NoSiCo wrote:
> Die Fehlermeldungen beziehen sich jetzt auf die Zeilen: 3047, 3049 und> 3936.> 3047: rcall init_uart0
Nun, was wird es wohl bedeuten, wenn der Operand eines rcall out of
range ist?
Du solltest an dieser Stelle keine rcalls benutzen, sondern calls.
da hat der große meister recht:
http://www.mikrocontroller.net/articles/AVR_Assembler_-_Unterprogramme
auszug:"Mittels rcall ist es nur möglich, relative Adressen im Bereich
von -2K+1 und +2K Worten anzuspringen"
bei dir:
-2049
-2051
-2053
-2055
-2057
(gut zu wissen, habe ich bisher noch nirgends bei avr gelesen)
Hm, ich weiß, dass ich schön langsam zu nerven beginne, aber ich weiß
jetzt nicht, wie ich in C zw. CALL und RCALL unterscheiden kann. :( Kann
mich hier jemand bitte einen hint geben? Danke!
> Du solltest an dieser Stelle keine rcalls benutzen, sondern calls.
Wenn ich ihn richtig verstanden habe, dann schreibt
er ja gar nicht in Assembler sondern in C.
Es ist also der Compiler, der den Murks macht.
Dann stellst sich doch direkt die Frage, welcher Prozessor beim
Kompilieren eingestellt ist.
Was steht in der Kommandozeile (Beispiel -mmcu=atmega8) oder im Makefile
(Beispiel MCU=atmega8)?
Vielleicht ist dort ein "kleiner" AVR eingestellt und die
Codeoptimierung innerhalb GCC geht davon aus, dass auf dem "Kleinen"
RCALLs immer passen.
nein, habe eigentlich im Makefile den richtigen uC eingestellt:
MCU=atmega2560
Hm, ich weiß leider nicht, ob ich die AtmanAVR-Variante verwende oder
nicht, weil ich nicht weiß, was das ist :(
Falls es weiterhilft: WinAVR vom 20060421 (AVR-gcc3.4.6)
Ok, habe auf ATMega 1280 umgestellt, sowohl Hard- als auch Software,
aber leider noch immer daselbe Problem, ich weiß nicht, wie ich die
RCALLs in CALLs wandeln kann, da ich mit C programmiere!
Außerdem ist ein neuer für mich absolut unerklärlicher Fehler
aufgetreten, obwohl ich in diesem Bereich nichts geändert habe:
g:\{Pfad}\SPI.c:9 relocation truncated to fit: R_AVR_13_PCREL against
symbol '__udivmoidqi4' defined in .text.libgcc section in
C:/{Pfad}/libgcc.a(_udivmodqi4.o)
8: void SPI_MasterTransmit(BYTE cData)
9: {
10: SPDR = cData; // Start transmission
11: while(!(SPSR & (1 << SPIF)));// Wait for transmissionc omplete
12:}
Außerdem wird mir dieser Erorr ca. 10 mal angezeigt :(
entschuldigung, winavr ist wohl aktuell, vergiss den letzten unsinn von
mir :(
benutze ich selber nicht, daher. weiß aber, dass der avr-gcc bei 4.1.1
ist, iirc.
NoSiCo wrote:
> Ok, habe auf ATMega 1280 umgestellt, sowohl Hard- als auch Software,> aber leider noch immer daselbe Problem, ich weiß nicht, wie ich die> RCALLs in CALLs wandeln kann, da ich mit C programmiere!
Kannst du den relevanten Sourcecode posten?
Ich fürchte immer noch, dass das ein pilot error irgendwie ist.
> g:\{Pfad}\SPI.c:9 relocation truncated to fit: R_AVR_13_PCREL against> symbol '__udivmoidqi4' defined in .text.libgcc section in
Linke bitte immer gegen -lm (libm.a), insbesondere dann, wenn du mit
Gleitkommazahlen in irgendeiner Form arbeitest. (Da gibt's einen
known bug, der nicht so einfach zu reparieren ist.) Wenn sie nicht
gebraucht wird, stört sie auch nicht.
Ich habe leider ein Problem damit, dass ich den relevanten Sourcecode
poste, weil die Fehler quer durch den gesamten Sourcecode springen.
Einmal sind sie in Zeile 2400, dann wieder in 4500 (z.B. Port_init), das
nächste mal wieder ganz wo anders. Ich bin schön langsam am verzweifeln,
weil kein Vorwärtskommen erkennbar ist.
Wenn ich irgendwo anders wieder einen Teil eines Sourcecodes
rauskommentiere (der hat gar nichts damit zu tun!), dann funktioniert es
wieder, aber ich habe derzeit erst ein 10K-Hex-File.
Hm, ist es vielleicht möglich, dass jemand ein Makefile zur Verfügung
stellt, weil so wie es aussieht (Beispiel -lm) gibt es vielleicht doch
noch ein paar Dinge, die ich noch nicht habe.
Vielen Dank und LG NoSiCo
