Warum soviel Speicher

Moin,

Wenn man im AVR-Studio folgenden Code hinzufügt [1], ist der Programmcode plötzlich 2506 Byte größer. Weiß jemand von euch warum der Code plötzlich so viel größer wird bzw. wie man den Programmcode wieder kleiner bekommt?

[1] int sleep(int16_t msec) { //32768 msec maximum double max_delay = 262.14 / CPUFREQUENCY; msec = msec * CPUFREQUENCY; while (msec>0) { if (msec > max_delay) { //_delay_ms(max_delay); msec = msec - max_delay; } else { //_delay_ms(msec); msec = msec - max_delay; }; }; };

Am Anfang steht noch: #include #include //#include

// ab avr-libc Version 1.2.0 möglich und empfohlen: #include // veraltet: #include

//#define F_CPU 1000000UL #define CPUFREQUENCY 8 // 8 MHz

Reply to
Markus
Loading thread data ...

Markus schrieb:

Vermutlich, weil das die erste Verwendung von Gleitkommazahlen (Datentyp double) ist und die ganzen Funktionen dafür dazugelinkt werden müssen. Ein AVR hat nun einmal keine Fließkommaeinheit und alles mit 8-bit Integer-Datentypen zu emulieren, kostet halt Codespace.

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

Markus schrieb:

[...]

!!!

Assembler-Output mal angesehen? Durch dutzende, unnütze (!) Floatroutinen aufgebäht.

Tu dir einen gefallen und lies K & R. Offenbar hast du nicht so nen Plan, was in C hinter den Kulissen passiert.

Viele Grüße, Johannes

--
PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen.
                         Markus "Makus" Gronotte in de.sci.electronics
Reply to
Johannes Bauer

Wieso? Gerade diese Zeile sollte der GCC schon zur Compilezeit berechnen können (vorrausgesetzt natürlich, dass CPUFREQUENCY 'ne Konstante is..)

Das die restliche Funktion wat für'n Arsch ist, will ich mal nicht zur Diskussion stellen ;)

-v bitte!

--
thomas.kindler@gmx.de,
www.bredobrothers.de
www.microsoft-hellhounds.de
Reply to
Thomas Kindler

Markus schrieb:

Übrigens, was versprichst Du Dir davon, max_delay als double zu definieren, ...

... wenn es letztendlich eh nur von der Integervariable msec subtrahiert wird bzw. als Integerparameter an _delay_ms übergeben wird?

CU Christian

--
Christian Zietz  -  CHZ-Soft  -  czietz (at) gmx.net
WWW: http://www.chzsoft.com.ar/
PGP/GnuPG-Key-ID: 0x6DA025CA
Reply to
Christian Zietz

"Christian Zietz"

_delay_ms verlangt aber double.

BTW: Das Problem hat sich mittlerweile erledigt. Für das was ich damit machen wollte ist diese Funktion leider viel zu ungenau. Danke euch trotzdem.

@Christian: Es lag tatsächlich nur an der Division.

Reply to
Markus

Thomas Kindler schrieb:

Aber nur bei -O1 oder höher.

Reply to
Michael Roth

Thomas Kindler schrieb:

Ist eine Frage der Optimierungen, wie Michael schreibt. Wer explizit nach Floats fragt, bekommt eben manchmal welche. Um solche Klippen zu umschiffen benutzt die avr-gcc libc gern das Präprozessor-Symbol "F_CPU", das als Int zu definieren ist:

#define F_CPU 1000000UL

Brian Kernighan und Dennis Ritchie "The C Programming Language"

*Das* Standardwerk für ANSI-C. In jeder gut sortierten Stadtbibliothek und in jeder naturwissenschaftlichen Unibib erhältlich.

Bei dem Murks-C, das Markus drauf hat, sicher keine schlechte Idee. Obwohl ich glaube, dass er den Tipp genauso verwerfen wird, wie fast alle Tipps, die er zu egal welchem Problem hat.

Viele Grüße, Johannes

--
PS: Ein Realname wäre nett. Ich selbst nutze nur keinen, weil mich die
meisten hier bereits mit Namen kennen.
                         Markus "Makus" Gronotte in de.sci.electronics
Reply to
Johannes Bauer

Die Frage wird auch in der Manpage der Funktion beantwortet:

... Two wrapper functions allow the specification of microsecond, and millisecond delays directly, using the application-supplied macro F_CPU as the CPU clock frequency (in Hertz). These functions operate on double typed arguments, however when optimization is turned on, the entire floating-point calculation will be done at compile-time. ...

Grüße Eckhard

Reply to
Eckhard Neber

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.