LCD C-Code so groß?

[Andy A. (crusty)]

Servus, also entweder steh ich grad auf dem Schlauch oder die Sache ist 
einfach so.

Also, ich hab mir eine LCD Ansteuerung in C geschrieben, der Code ist 
ziemlich an dem auf dem Tutorial angelehnt (leichte Veränderungen hab 
ich vorgenommen).

In der Main.c hab ich einfach mal versuch eine A auf das LCD zu 
schreiben, was auch Prima funktioniert, so wie auch alle anderen 
Funktionen die ich eingebaut hab.

Meine Frage ist nun, wieso ist der Code über 6.5kB groß?
Überseh ich grad irgendwelche Funktionen die den Code aufblasen oder was 
ist da los?

Ich hab hier einen Atmega 8 dort würde ja das Programm noch drauf 
passen, jedoch geht da dann nicht mehr viel mehr drauf.


Das AVR-Studio gibt mir folgendes nach dem compilieren aus:

    AVR Memory Usage
    ----------------
    Device: atmega8
    Program:    6514 bytes (79.5% Full)
    (.text + .data + .bootloader)
    Data:          8 bytes (0.8% Full)
    (.data + .bss + .noinit)


Schon mal danke für eure Hilfe.

[Läubi .. (laeubi)]

Optimierung nicht eingeschaltet oder floatingpoint verwendet?

[Andy A. (crusty)]

Oh gott bin ich doof :-)

Die Optimierung wars.
Ich dachte zwar ich hätte sie eingeschaltet aber anscheinend hat er das 
nicht übernommen.

Schon ist der Code nur noch 354Byte groß.

Wusste gar nicht das dass so einen großen Unterschied macht.
Kann das sein?

[Der müde Joe (Gast)]

stdlib.h braucht sehr viel Speicher.

Der müde Joe.

[Läubi .. (laeubi)]

Andy Andy schrieb:
> Kann das sein?

Kann das sein das der Compiler eine Warnung ausgegeben hat bezüglich der 
delay.h ;-)

[Andy A. (crusty)]

Ne da ist keine Warnung, wieso denn auch?

F_CPU ist in den Projekteinstellungen, falls du das meinst.

Wie gesagt jetzt mit der Optimierung ist der Code nur noch 356Byte groß

[Karl H. (kbuchegg)]

Andy Andy schrieb:

> Wusste gar nicht das dass so einen großen Unterschied macht.
> Kann das sein?


Natürlich.

_delay_ms und _delay_us berechnen die Anzahl der notwendigen 
Schleifendurchläufe mittels Floating Point Arithmetik. Macht ja auch 
Sinn, denn ich will ja auch mal 2.5 Millisekunden warten können und dazu 
braucht man Floating Point.

Aber: Ist der Optimizer nicht eingeschaltet, dann bleibt die komplette 
Berechnung inklusive dazu notwendiger Floating Point Arithmetik 
Funktionen im Code erhalten und wird zur Laufzeit ausgeführt.
Ist der Optimizer abe reingeschaltet, dann 'optimiert' der Compiler das 
alles weg, weil dann er selber die Berechnung macht und nur noch das 
Ergebnis weiterbenutzt.
Die Differenz sind dann eben die rund 6kB Code bzw. Wartezeiten die dann 
auch tatsächlich mit den angeforderten übereinstimmen. Denn wenn der µC 
die Berechnung zur Laufzeit machen muss, dann dauert alleine das 
Berechnen der notwendigen Anzahl an Schleifenwiederholungen schon länger 
als zb mittels _delay_us(10.0) angeforderte 10µs.

Fazit:
* bei Benutzung der _delay_xx Funktionen IMMER den Optimizer einschalten
* nur Konstante beim Aufruf angeben, damit der Compiler die
  Berechnung zur Compilezeit machen kann.

All das ist aber im delay.h dokumentiert, ist im AVR-GCC-Tutorial 
dokumentiert und wird hier im Forum jede Woche mindestens 15 mal 
diskutiert.

[Karl H. (kbuchegg)]

Andy Andy schrieb:
> Ne da ist keine Warnung, wieso denn auch?

Doch, da ist eine Warnung.
Schon seit ewigen Zeiten wird in diesen Fällen eine Warnung ausgegeben.

[Andy A. (crusty)]

Super danke für die ausführliche erklärung.

Normal hab ich die Optimierung ja immer an.
Das Tutorial zur delay.h werd ich mir nun mal genauer ansehen, wusste 
gar nicht das es hier sowas gibt.

Jetzt versteh ich das auch mal, warum immer die Rede davon ist, das man 
nur Konstanten beim Aufruf einer delay Funktionen nehmen soll :-))

Besten dank, ich seit großartig :-)