Der Grund ist: Du hast die Optimierung abgeschaltet. Dadurch werden die floating point Routinen eingebunden (rund 2kByte).

Moin.

_delay_ms() und Verwandte sind Inline-Funktionen. An die Stelle des Aufrufs wird nicht bloß eine CALL-Instruktion gesetzt, sondern die ganze Routine. Ob das allein den Größenzuwachs erklärt...: sieh dir das Assemblerfile an.

Außerdem gibt es in der Headerdatei den Hinweis, soweit es geht als Argument für _delay_ms() usw. nur Konstanten und keine Ausdrücke, die erst zur Laufzeit berechnet werden müssen, zu verwenden. Gut, hier nicht zutreffend, wenn der Aufruf wie geschrieben lautet.

D.

Ich weiss ja nicht was der Compiler da genau macht, noch kenne ich mich mit der Hardware des AVR genau aus (nur PIC)
Aber wenn man davon ausgeht dass er mit 20 Mhz rennt, 4 Taktschritte für einen Befehl verwendet und Dann mal 10 ms Pause mit nop befehlen füllt, dann kommt man Bei 16 bit Worten ziemlich genau auf 10Kb Nop

Guck dir doch mal den Sourcecode in Assembler an.
Ich kann mir zwar nicht vorstellen, dass der den delay mit NOP füllt, aber evtl gibt es ja einen besseren befehl dafür.

Nein, definitiv nicht:
_delay_us() verwendet eine 8bit Schleife:
ldi variable, wert
schleife:
dec variable
brne schleife

_delay_ms() verwendet eine 16bit Schleife
ldi variablehi, hi(wert)
ldi variablelo, low(wert)
schleife:
subiw variable, 1
brne schleife

Die Berechnungen von Wert läuft über Fließkomma aus dem Zeitwert, der Taktfrequenz und den Takten die ein Schleifendurchlauf braucht. Ist die Verzöerungszeit also keine Konstante, oder die Optimierungen sind deaktiviert, dann wird der Wert (mittels Fließkomma) zur Laufzeichnet berechnet.

Zitat :

Dadurch werden die floating point Routinen eingebunden (rund 2kByte).

Nun musst du uns nur noch erklären, wofür die übrigen 8k verpulvert werden.

Mein Rabe ist noch nicht wieder da, aber ich denke, ohne den Hersteller / Namen des Compuilers zu kennen, würde er auch nichts verraten.


_________________
Haftungsausschluß:



Bei obigem Beitrag handelt es sich um meine private Meinung.



Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.



Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !

AVR Studio von Atmel?

Zitat : perl hat am 20 Apr 2007 12:29 geschrieben :

Zitat : Dadurch werden die floating point Routinen eingebunden (rund 2kByte). Nun musst du uns nur noch erklären, wofür die übrigen 8k verpulvert werden.

Gerne:

stuckima hat am 19 Apr 2007 15:13 geschrieben :

Nun wird leider das .hex file

Hex Dateien verbrauchen etwa den 3 fachen Platz.

Aua, Aua, Aua !
Damit, daß jemand die Leerzeichen mitzählt, habe ich nun wirklich nicht gerechnet.
Ich dachte dabei natürlich(?) an die Codegröße.

_________________
Haftungsausschluß:



Bei obigem Beitrag handelt es sich um meine private Meinung.



Rechtsansprüche dürfen aus deren Anwendung nicht abgeleitet werden.



Besonders VDE0100; VDE0550/0551; VDE0700; VDE0711; VDE0860 beachten !

Dem widerspricht allerdings das hier

Zitat :

AVR Studio meldet, dass das .hex file zu gross für meinen AVR (ATmega48)ist.

Der mega8 hat 4kB Flashlänge, demnach hat der Fragesteller entweder versucht, die ASCII-Werte aus dem *.hex-Inhalt zu brennen (klappt logischerweise nicht!) oder aber der Kode ist wirklich so megalang.

Als ich mit C @AVR-Studio angefangen habe, habe ich auch mal die delay-Sachen benutzt, und auch bei mir war anschließend der comp. Kode extrem lang; eben zu lang.


Was ich machen würde (und auch gemacht habe):

Eine Funktion schreiben, die das per Assembler macht, ähnlich Benedikts Kode oben und wo bereits fertig berechnete Werte zum Verzögern benutzt werden, und nicht erst, wie ebenfalls schon erwähnt, erst zur Laufzeit berechnet wird, was davon mal abgesehen auhc ziemlich lange dauern kann.

_________________

Das Problem war wirklich das mit der Optimierung.
Wir haben heute im Makefile die Optimierung eingeschaltet und so wurde das file wieder klein. Also Problem gelöst.
Ich danke euch allen für die Mühe und wünsche ein schönes Wochenende.

@perl ich versuche mich mit den Angaben zu bessern damit auch dein Rabe wieder sprechen kann

Wie oft denn noch: Das ist komplett unnötig ! Es reicht die Optimierungen einzuschalten, dann erzeugt der Compiler die von mir angegebenen Funktionen aus den µs oder ms Werten.

Zitat : Benedikt hat am 20 Apr 2007 16:06 geschrieben :

Wie oft denn noch: Das ist komplett unnötig ! Es reicht die Optimierungen einzuschalten, ...

Was genau soll unnötig sein? Beziehst du dich auf das Posting von DonComi?

Edit: war wohl wirklich an die Adresse DonComi gerichtet, ich habe übersehen, dass die vorherigen zwei Postings sehr zeitnah abeschickt wurden.

[ Diese Nachricht wurde geändert von: cholertinu am 20 Apr 2007 22:48 ]

Ja, war wohl an mich gerichtet.

Es kann ja nie schaden, wenn man auch selbst weiß, wie die Verzögerung funktioniert bzw. wie das gemacht wird und wie man seinen Assemblerkode in C einbindet und Parameter drin verarbeiten kann.

Aber grundsätzlich stimm ich Benedikt zu, wenn man schnell und produktiv arbeiten will dann nutzt man fertige Routinen und Berechnungen, ohne das Rad neu zu erfinden.




_________________