region text is full (aber warum bloss???)

> Kann das sein, das der Compiler da irgendo eine Macke hat in Verbindung mit 
Fliesskommaarithmetik?

Klar und zwar folgende, er bindet die nötigen Fliesskomma-Bibliotheken 
für doppelte Präzision dazu und da ist man mit 2K Ram schnell am 
Anschlag, was hast du denn erwartet? Sobald in dem Code auch nur eine 
Variable als double oder sogar als long double deklariert ist (wie in 
deinem Fall!), dann werden die entsprechend notwenigen Routinen 
dazugebunden und das kostet Platz. Was hast du denn erwartet?

Tja, ein bischen schwanger geht halt nicht, sorry ;-)

guten Rutsch!

Notker

Kann ja alles sein, aber in der Zeile direkt oberhalb der Betroffenen 
wird ja schon mächtig mit Fliesskommarithmetik gewurstelt und das 
scheint die Grösse des Programms kaum zu beeinflussen. Die Bibliotheken 
müssten ja eigentlich da schon dazu gelinkt werden.
Abgesehen davon passiert in der auskommentierten Codezeile ja gar nichts 
mit Berechnungen (mal abgesehen vom Vergleich), schon gar nicht mit 
Fliesskomma.
Deswegen verstehe ich das Ganze nicht.

Also Schwanger vom 1. direkt in den 9. Monat ohne Zwischenhalt ?

Dann rutsch auch mal gut rüber!

Gruss
Christian

Hi Christian,

hab auf dem AVR noch keinen C-Compiler benutzt. Ich gehe einfach davon 
aus, das Du durch diese Zeile die Fließkomma-Lib dazulinkst. Vorher kann 
der Compiler das ftime ja wegoptimieren. Ein Ausweg wäre dann, das ganze 
auf Integerrechnung umzustellen und ein wenig zu optimieren...


fTime = DISTANCE / ((nCycles * 65536L + (long) nTicks) * 0.0000008);
if (fTime > LIMIT_H) outp (1, PORTB);

einsetzen ergibt dann

if(DISTANCE*1250000>(nCycles*65536L+(long)nTicks)*LIMIT_H) outp (1, 
PORTB);

und dann noch DISTANCE=0.2 und LIMIT_H=100.0 einsetzen und ein wenig 
kürzen...

if(2500>nCycles*65536L+(long)nTicks) outp(1,PORTB);

und das ist dann das gleiche wie

if(nCycles==0 && nTicks<2500) outp(1,PORTB);


Peter

@Christian

> Also Schwanger vom 1. direkt in den 9. Monat ohne Zwischenhalt ?

Im Prinzip fast, ja! Er hatte nämlich das Problem, dass der Code ohne 
diese Zeile mit eingeschalteter Optimierung gerade so noch in die 2k 
hineingepasst hat und sobald diese Zeile dazu kam, lag er knapp drüber 
(was er allerdings nicht wusste!). Ich will ja nun niemanden 
diskreditieren aber er hätte schon mal auf die Idee kommen können, beim 
avrgcc testweise einen anderen Controller-Typ mit mehr Flash 
auszuwählen, dann wäre das Programm auch mit dieser Zeile übersetzt 
worden und er hätte diese Tatsache erkannt.

Tatsächlich war nämlich diese eine Zeile, die er im Verdacht hatte, 
sozusagen nur der Tropfen, der das Fass zum Überlaufen gebracht hatte.

Aber es ist in der Tat so, dass sobald Flieskommaroutinen ins Spiel 
kommen, der Speicherbedarf einen kräftigen Ruck nach oben macht und die 
Kombination AT90S2313 + Flieskommaarithmetik kann er getrost vergessen. 
Unter 4k Flash würde ich mit sowas erst garnicht anfangen.

Ebenso wünsche ich allen einen guten Rutsch ins neue Jahr!

Notker

@Notker

Auf die Idee wäre ich schon gekommen, wenn das Programm ohne diese 
ominöse Zeile auch nur annähernd an die 2k Programmgrösse herangekommen 
wäre. Aber offensichtlich hat der GCC die darüber liegende Berechnung 
tatsächlich so weit optimiert, dass er die Fliesskommabibliothek gar 
nicht geladen hat, und dies, obwohl in der Codezeile eine echte 
Fliesskommakonstante vorhanden ist (0.0000008).

Was soll's. Ich habe jetzt das Ganze ohne Fliesskommaarithmetik gelöst. 
Kann im Tutorial nachgelesen werden.

Guten Rutsch und Tschüss
Christian