Code braucht extrem viel Speicher

[Andi (Gast)]

Hallo,

habe mir gerade einen ATMEGA 48-20 geholt, der 4KB Speicher hat.
4KB sind nicht die Welt, sollten für meine Zwecke jedoch ausreichen.

Ich habe 3 LEDs an PORTB angeschlossen.
Diese will ich zum Test ein- und ausblenden.

Dafür habe ich folgenden kurzen Code geschrieben:

#define F_CPU 1000000UL

//-----------------------------------------------------------------------------
// INCLUDES
//-----------------------------------------------------------------------------
#include <avr/io.h>
// #include <avr/interrupt.h>
// #include <avr/sleep.h>
#include <util/delay.h>


int main(void)
{
  //directions
  DDRB = 0b00000111;

  PORTB |= 0b00000111;

  uint8_t up = 1;      //Zaehlrichtung
  uint8_t counter = 0; //Zaehlvariable

  while(1)
  {
    _delay_us(counter);  //warte 0-255us
    PORTB &= 0b11111000;
    _delay_us(255-counter);  //warte 255-0us
    PORTB |= 0b00000111;

    if (counter == 255) up=0;  //IF1
    if (counter == 0) up=1;    //IF2

    if (up==1)                 //IF3
    {
      counter++;
    }
        else
    {
      counter--;
    }
  }
}

Nach dem Kompilieren mit der (-Os)-Option kommt eine Code-Größe von 4602 
Bytes raus. Das ist viel zu viel für meinen µC.

Zum test habe ich die drei IF-Abfragen mal auskommentiert. Größe nach 
dem Kompilieren: 176 Bytes!

Was mache ich falsch???
Kann es sein, dass diese 3 IF-Abfragen wirklich den Code von 176 Bytes 
auf 4602 Bytes aufblähen?

Danke für eure Tipps!

[Purzel H. (hacky)]

ich wuerd mal das delay_us() rausschmeissen.

[g457 (Gast)]

>_delay_us(counter);  //warte 0-255us
und
> _delay_us(255-counter);

..machtens möglich. Mach stattdessen Warteschleifen a la

for (uint8_t i = 0; i < counter; i++) _delay_us(1);

Details stehen in der Doku.

[Hannes (Gast)]

Hast Du im makefile die floating point Option ausgeschaltet?

[Lukas K. (carrotindustries)]

g457 schrieb:
>>_delay_us(counter);  //warte 0-255us
> und
>> _delay_us(255-counter);
>
> ..machtens möglich. Mach stattdessen Warteschleifen a la

for
> (uint8_t i = 0; i < counter; i++) _delay_us(1);

>
> Details stehen in der Doku.

Genau, wenn man sich den erzeugten Assemblercode ansieht stehen da 
solche Monster wie 0x430 <__floatunsisf> und ähnliches was auf dazu 
gelinkten Floatbloat hinweist. Das Verursacht das enorme Aufblähen des 
Codes.

[Andi (Gast)]

Vielen Dank, das hat tatsächlich geholfen!!!
Verrückt, was eine For-Schleife gleich ändert...

Kann ich die Floating-Point-Option auch in den "configuration options" 
vom AVR Studio abschalten? Nutze im Moment noch kein Makefile, muss mich 
da erst noch etwas mehr einarbeiten...

[Julian O (Gast)]

In 
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29 
steht "Die Bibliotheksfunktionen funktionieren allerdings nur dann 
korrekt, wenn sie mit zur Übersetzungszeit (beim Compilieren) bekannten 
konstanten Werten aufgerufen werden. Der Quellcode muss mit 
eingeschalteter Optimierung übersetzt werden, sonst wird sehr viel 
Maschinencode erzeugt und die Wartezeiten stimmen nicht mehr mit dem 
Parameter überein."

Aber am Ende ists sowieso wurscht: in der Realität wird wohl keiner mit 
Delay Funktionen arbeiten

[Hannes L. (hannes)]

Andi schrieb:
> Verrückt, was eine For-Schleife gleich ändert...

Den Unterschied macht der Aufruf von Delay mit einer Variable oder einer 
Konstante.

...

[Werner B. (werner-b)]

http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html

In order for these functions to work as intended, compiler optimizations 
must be enabled, and the delay time must be an expression that is a 
known constant_at_compile-time. If these requirements are not met, the 
resulting delay will be much longer (and basically unpredictable), and 
applications that otherwise do not use floating-point calculations will 
experience severe code bloat by the floating-point library routines 
linked into the application.