Fehler bei SRAM Berechnung?

[Michael B. (planlessmichi)]

Hallo Profis,

ich habe heute versucht, auf meinem Atmega128 eine zusätzliche 
Komponente (einen DS1820) anzusteuern und mir einen Beipielcode gesucht. 
Diesen habe ich dann in mein Projekt eingebunden und jetzt kommt ständig 
ein Fehler, den ich mir überhaupt nicht erklären kann.

Beim Übersetzen im AVR Studio 6 erhalte ich jetzt diese Fehlermeldung:

Error  93  #error "size of UART_RX_BUFFER_SIZE + UART_TX_BUFFER_SIZE larger than size of SRAM"

O.k., etwas überrascht mache ich einen Doppelklick auf die Meldung und 
lande in der uart.h von Peter Fleury (Version v 1.12 2012/11/19 
19:52:27).

Dort ist dieser Code enthalten:

/* test if the size of the circular buffers fits into SRAM */
#if ( (UART_RX_BUFFER_SIZE+UART_TX_BUFFER_SIZE) >= (RAMEND-0x60 ) )
#error "size of UART_RX_BUFFER_SIZE + UART_TX_BUFFER_SIZE larger than size of SRAM"
#endif

Kurz darüber werden die beiden UART_RX_BUFFER_SIZE und 
UART_TX_BUFFER_SIZE jeweils mit einem Wert von 32 definiert:

/** Size of the circular receive buffer, must be power of 2 */
#ifndef UART_RX_BUFFER_SIZE
#define UART_RX_BUFFER_SIZE 32
#endif
/** Size of the circular transmit buffer, must be power of 2 */
#ifndef UART_TX_BUFFER_SIZE
#define UART_TX_BUFFER_SIZE 32
#endif

Jetzt bin ich erst recht überrascht: Der Atmega128 hat 4kByte SRAM; 
wieso sollen denn jetzt plötzlich 64 Byte da nicht mehr reinpassen!?

Also habe ich mir die Werte der defines mal ausgeben lassen und zwischen 
den defines und dem "Check" noch ein paar Zeilen - testweise - 
eingebaut.
Insgesamt sieht das alles jetzt gerade so aus:

/** Size of the circular receive buffer, must be power of 2 */
#ifndef UART_RX_BUFFER_SIZE
#define UART_RX_BUFFER_SIZE 32
#endif
/** Size of the circular transmit buffer, must be power of 2 */
#ifndef UART_TX_BUFFER_SIZE
#define UART_TX_BUFFER_SIZE 32
#endif

#define STRING2(x) #x
#define STRING(x) STRING2(x)

#pragma message("Wert = " STRING(RAMEND))
#pragma message("Wert = " STRING(UART_RX_BUFFER_SIZE))
#pragma message("Wert = " STRING(UART_TX_BUFFER_SIZE))
#pragma message("Wert = " STRING(UART_RX_BUFFER_SIZE+UART_TX_BUFFER_SIZE))
#pragma message("Wert = " STRING(RAMEND-0x60))

/* test if the size of the circular buffers fits into SRAM */
#if ( (UART_RX_BUFFER_SIZE+UART_TX_BUFFER_SIZE) >= (RAMEND-0x60 ) )
#error "size of UART_RX_BUFFER_SIZE + UART_TX_BUFFER_SIZE larger than size of SRAM"
#endif

Was soll ich sagen: Im Outputfenster kommt dann Folgendes:

<Pfad>\uart.h: #pragma message: Wert = 0x10FF
<Pfad>\uart.h: #pragma message: Wert = 32
<Pfad>\uart.h: #pragma message: Wert = 32
<Pfad>\uart.h: #pragma message: Wert = 32+32
<Pfad>\uart.h: #pragma message: Wert = 0x10FF-0x60

Bin ich jetzt völlig beschugge??
32+32 ist doch immernoch 64, oder?
Und 0x10FF-0x60 = 0x109F oder eben 4255 (dezimal).

Seit wann ist denn jetzt 64 größer oder gleich 4255???

Wäre super, wenn mir hierbei jemand mal helfen könnte...

Verzweifelte Grüße,
Michael

[Andreas B. (andreasb)]

Ich rätsle. Schon seit ein paar min.

Nicht nachvollziehbar, weder mit GCC noch mit avr-gcc.

avr-gcc --version
avr-gcc (GCC) 4.5.3

Clean und nochmals versuchen?



mfg Andreas

[Michael B. (planlessmichi)]

Schon gemacht... Mehrmals... Auch Rechner-Reboot und so ein Zeug...
Wenn's hilft, laufe ich auch gerne mal um das Haus, aber...
Irgendwie habe ich keine große Hoffnung, dass das helfen könnte...

[Hmm (Gast)]

Möglicherweise ist es hilfreich, wenn Du mal Deine gcc Version hier 
postest, Michael.

[amateur (Gast)]

Kann es sein dass Du über Kuddel-Muddel stolperst.
Deine Ausgabe sieht nach einem Gemisch aus Text und Zahl aus.
Wenn ... 32 eine Ausgabe von "32" bewirkt,
dann müsste bei 0x10FF "4351" und nicht 0x.. stehen.
Möglicherweise ziehst Du Zahlen von Text ab - oder umgekehrt.
Oder anders ausgedrückt: Irgendwo werden Deine Makros nicht richtig 
aufgelöst.

[Michael B. (planlessmichi)]

Das müsste wohl die 3.4.1.95 sein...
Zumindest habe ich auf einem - vor einer Woche - frisch aufgesetztem 
Rechner so ein Verzeichnis:
C:\Program Files (x86)\Atmel\Atmel Studio 
6.0\extensions\Atmel\AVRGCC\3.4.1.95

Edit: Unter:
C:\Program Files (x86)\Atmel\Atmel Studio 
6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\bin

liegen eine avr-gcc.exe und eine avr-gcc-4.6.2.exe

[Johann L. (gjlayde)]

Schau dir das i-File an, das du mit -save-temps -g3 erzeugt hast und 
schau nach, welches Makro falsch (oder nicht) gesetzt ist.

Hier kontextfreie Code-Schnippel zu posten bringt doch nix. Wo ist zB 
RAMEND definiert?

[Michael B. (planlessmichi)]

Zusatz: Beide Versionsabfragen liefern 4.6.2:

avr-gcc-4.6.2.exe --version
avr-gcc-4.6.2.exe (AVR_8_bit_GNU_Toolchain_3.4.1_830) 4.6.2

avr-gcc.exe --version
avr-gcc.exe (AVR_8_bit_GNU_Toolchain_3.4.1_830) 4.6.2

[Michael B. (planlessmichi)]

Johann L. schrieb:
> Hier kontextfreie Code-Schnippel zu posten bringt doch nix. Wo ist zB
> RAMEND definiert?

In C:\Program Files (x86)\Atmel\Atmel Studio 
6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\avr\include\avr\iom128 
.h
#define RAMEND     0x10FF     /* Last On-Chip SRAM Location */

[amateur (Gast)]

Klammere doch mal den ganzen Teil aus, der moniert wird.
Weise anschließend verschiedenen Variablen deine Makros zu.
Schau Dir dann im List File oder im Debugger an welcher Meinung
Präprozessor bzw. Compiler sind.

[Michael B. (planlessmichi)]

Also ich habe jetzt dieses "-save-temps -g3" mit aktiviert und die 
defines sehen in den *.i Dateien so aus, wie erwartet:

#define RAMEND 0x10FF
#define UART_RX_BUFFER_SIZE 32
#define UART_TX_BUFFER_SIZE 32

@amateur:
Welche Makros meinst Du? Die String und pragma message Zeilen können wir 
getrost ignorieren; die sollten mir nur die verwendeten Werte auflisten, 
mehr nicht.

[Johann L. (gjlayde)]

Michael B. schrieb:
> Johann L. schrieb:
>> Hier kontextfreie Code-Schnippel zu posten bringt doch nix. Wo ist zB
>> RAMEND definiert?
>
> In C:\Program Files (x86)\Atmel\Atmel Studio
> 6.0\extensions\Atmel\AVRGCC\3.4.1.95\AVRToolchain\avr\include\avr\iom128 .h
> #define RAMEND     0x10FF     /* Last On-Chip SRAM Location */

Ja, ich weiß.  Daß es da steht hilft aber nix...  Du musst avr/io.h auch 
includen, und zwar vor der Verwendung von RAMEND.

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

Ich kann's auch mit keinem der hier vorhandenen Compiler nachvollziehen.

Ansonsten ist die ganze Rechnung da aber sowieso Kokolorus.  Die
0x60 sind nur eine Hausnummer, die bereits beim ATmega128 nicht
mehr stimmte (dort wären es 0x100), bei neueren Controllern erst
recht nicht (0x200).  Außerdem bliebe natürlich keinerlei Platz
mehr für den Stack.

[Oliver S. (oliverso)]

Ich meine mich vage erinnern zu können, daß ich den Fehler auch schon 
einmal hatte, mit einer älterern gcc- bzw. libavr-Version,
und für einen anderen Prozessor.

Jörg Wunsch schrieb:
> Ansonsten ist die ganze Rechnung da aber sowieso Kokolorus.

Eben. Wenn sicher ist, daß die Buffer nicht zu groß sind, einfach die 
Zeilen auskommentieren, fertig.

Oliver

[Michael B. (planlessmichi)]

Also ich gebe auf; selbst in der Arbeit konnte sich das keiner erklären.
Aaaaaber: Ich habe es zumindest reproduzierbar eingrenzen können: Grund 
für dieses komische Verhalten scheinen die Demo-Sourcen zu sein, die ich 
für die Anbindung des DS1820 benutzen wollte. Wenn ich diese Sourcen 
wieder entferne, lässt sich wieder alles fehlerfrei übersetzen; binde 
ich sie wieder ein, habe ich den Fehler wieder. Das Komische ist nur: In 
den Sourcen und den dort wiederum eingebundenen Dateien finde ich keine 
offensichtlichen "Problemursachen"!?!?
Ich habe jetzt aber eine andere, funktionierende 1-wire Implementierung 
gefunden, auf die ich aufsetzen kann.

Oliver S. schrieb:
> Eben. Wenn sicher ist, daß die Buffer nicht zu groß sind, einfach die
> Zeilen auskommentieren, fertig.

Ja, wäre möglich... Nur bin ich eigentlich kein Fan vom Modifizieren 
fremder Sourcen... Irgendwann gibt es ein Update jener Dateien und dann 
habe ich ganz sicher vergessen, dass ich da auch meine Hände im Spiel 
hatte...
Hier wäre es zwar wohl einfach, weil im schlimmsten Fall wäre die 
aktuelle Version wieder nicht übersetzbar, aber trotzdem... Ich bin 
froh, dass ich jetzt eine funktionierende Version einer 1-Wire 
Implementierung gefunden habe.

Trotzdem an alle: Vielen Dank für die Bemühungen

[Oliver S. (oliverso)]

Michael B. schrieb:
> Ich habe es zumindest reproduzierbar eingrenzen können: Grund
> für dieses komische Verhalten scheinen die Demo-Sourcen zu sein, die ich
> für die Anbindung des DS1820 benutzen wollte.

Was mal wieder ein Beispiel dafür ist, daß Diskussionen über nicht 
komplett gepostete Sourcecodes reine Zeitverschwendung sind...

Oliver

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

Michael B. schrieb:
> Grund
> für dieses komische Verhalten scheinen die Demo-Sourcen zu sein, die ich
> für die Anbindung des DS1820 benutzen wollte.

Dann poste jene doch mal, oder einen Zeiger drauf.

[Michael B. (planlessmichi)]

So, hat etwas gedauert, aber die "Freizeit" ist halt immer zu wenig :-)

Anbei mein stark gekürztes Projekt, dass aber den gleichen Fehler zeigt.
Umgebung: Atmel Studio 6 (Version 6.0.1996 - Service Pack 2), keinerlei 
weiteren Pakete wie WinAVR etc. Nur dieses Studio auf einem frisch 
aufgesetztem Rechner Win7 64bit.

Oliver S. schrieb:
> Was mal wieder ein Beispiel dafür ist, daß Diskussionen über nicht
> komplett gepostete Sourcecodes reine Zeitverschwendung sind...

Ich hoffe, dass dieser Code den Ansprüchen genügt. Aber ich sehe nun 
wirklich keinen Grund, den kompletten SourceCode für diesen Fehler 
hier zu posten. Der enthielt in der aktuellen Version nämlich noch 
persönliche Daten (Handynummern, Adressen,..) etc., die erst später - 
durch per SMS konfigurierbare Werte - ersetzt werden. Darum diese sehr 
gekürzte Version hier.

Jörg Wunsch schrieb:
> Dann poste jene doch mal, oder einen Zeiger drauf.

Den 1-Wire Code habe ich aus einer Zip mit diesem Namen entnommen:
ds18x20_demo_20091001.zip

Von welcher Seite ich den jetzt genau heruntergeladen hatte, weiß ich 
jetzt nicht mehr, aber wenn man danach googelt, dann findet man etliche 
Seiten mit dieser Zip-Datei.

Viele Grüße - und schöne Feiertage,
Michael

[Stefan E. (sternst)]

Ursache ist genau das, was Johann schon vermutet hat: avr/io.h wird beim 
Kompilieren von uart_ext.c nicht inkludiert, ergo ist RAMEND dort gar 
nicht definiert.

Und noch was: deine Pragma-Ausgaben kannst du vergessen. Die erfolgen ja 
schließlich erst beim eigentlichen Kompilieren. Der Abbruch erfolgt ja 
aber bereits beim Pre-Processing, also siehst du gar keine Ausgaben, die 
zum Fehler-Fall gehören. Die Ausgaben, die du siehst, gehören zu den 
erfolgreichen Fällen, wo ebenfalls uart.h inkludiert wird.

[Oliver (Gast)]

Stefan Ernst schrieb:
> Ursache ist genau das, was Johann schon vermutet hat: avr/io.h wird beim
> Kompilieren von uart_ext.c nicht inkludiert, ergo ist RAMEND dort gar
> nicht definiert.

Was man anhand der Fehlermeldung des Compilers auch hätte erahnen 
können:
>In file included from ../Temperature/uart_ext.h:9:0,
>from ../Temperature/uart_ext.c:1:
>C:\Dokumente und Einstellungen\sce\Desktop\DemoProjekt\UART\uart.h(94,2): #error 
>"size of UART_RX_BUFFER_SIZE + UART_TX_BUFFER_SIZE larger than size >of SRAM"

Oliver

Michael B. schrieb:
> Ich hoffe, dass dieser Code den Ansprüchen genügt.

Tut er. Wie du siehst, dauert die Fehlersuche damit nur ein paar 
Minuten.

Michael B. schrieb:
> Also ich gebe auf; selbst in der Arbeit konnte sich das keiner erklären.

Ich hoffe mal, ihr macht nicht in Software...

Oliver

[Michael B. (planlessmichi)]

Oliver schrieb:
> Ich hoffe mal, ihr macht nicht in Software...

Doch. Wir haben alle Sicherheitseinrichtungen in Deinem Auto entwickelt.
Viel Spaß bei Deinen nächsten Fahrten.
Du sprichst schon ziemlich von oben herab. Hast absolut keine Ahnung, ob 
ich meinen Kollegen überhaupt etwas gezeigt habe oder ihnen nur davon 
erzählt habe, aber in Deinen Augen sind die auch gleich alles 
Nichtskönner. So viel <piep> habe ich echt schon lange nicht mehr 
gehört.

An all die anderen - qualifizierten! - Antwortgeber: Vielen Dank für 
Eure Hilfe und schöne Feiertage!

[Bernd (Gast)]

Michael B. schrieb:
> (planlessmichi)

nomen est omen

[Michael B. (planlessmichi)]

3x darfst Du raten, warum ich genau diesen Namen ausgesucht habe! Das 
hatte schon seinen Sinn.
Kommt halt nicht jeder direkt als Profi auf die Welt. Ich muss 
tatsächlich das ganze Zeug erst lernen. Umso dankbarer bin ich dann über 
Leute wie gjlayde, dl8dtl und sternst die mir dabei helfen (wozu ein 
Forum - so dachte ich - auch da ist). Sollte mir der Fehler dann ein 
zweites Mal unterlaufen, kann man sich gerne zu Recht über mich lustig 
machen; vorher finde ich es eigentlich eher arrogant.