AVR-GCC: Was ist denn an diesem Code so schlimm?

[Claus (Gast)]

Hallo zusammen,

bin gerade dabei mein altes Canda Starterkit-Board zu entsorgen
und verbaue damit auch einen alten Atmel 90S8515 ...
Lange rede kurzer Sinn wenn ich das folgende Code segment
verwende sind das mal locker 4000 Bytes die der Flash mehr
braucht...
Mag ein Anfängerfehler sein, doch irgendwie kapier ich's nicht
Wo braucht der soviel Speicher ?
(der restliche Code ist erheblich grösser braucht aber
summa summarum nur 2600 bytes)

Macht der die setLed routine inline ? (Compiler optimierung steht bei 
-Os)

void setLed(uint8_t delay,uint8_t bit1,uint8_t bit2)
{
  PORTB=0xff;
  PORTB&= ~ ( 1 << bit1);
  if ( bit2 < 8 )
  {
    PORTB&=~(1<< bit2);
  }
  while (delay > 100 )
  {
    _delay_ms(100);
    delay-=100;
  }
  _delay_ms(delay);
}

void animate1(void)
{
  uint8_t i;
  for ( i = 0 ; i < 4 ; i++ )
  {
    setLed(200,0,7);
    setLed(200,1,6);
    setLed(200,2,5);
    setLed(200,3,4);
  }
}

void animate2(void)
{
  uint8_t i;
  for ( i = 0 ; i < 4 ; i++ )
  {
    setLed(200,0,1);
    setLed(200,1,2);
    setLed(200,2,3);
    setLed(200,3,4);
    setLed(200,4,5);
    setLed(200,5,6);
    setLed(200,6,7);
    setLed(200,7,0);
  }
}

Helft mir mal bitte auf die Sprünge - Danke

[Johannes M. (johnny-m)]

Wenn die _delay_XX-Funktionen mit Parametern aufgerufen werden, die zur 
Compile-Zeit nicht bekannt (konstant) sind, dann wird die komplette 
float-lib eingebunden, und die braucht Platz. Abgesehen davon 
funktionieren die _delay_XX-Funktionen dann nicht mehr korrekt. Es gibt 
zwei unabdingbare Voraussetzungen für die Verwendung von _delay_us und 
_delay_ms aus der util/delay.h:
1.: Parameter müssen konstant und zur Compiler-Laufzeit bekannt sein.
2.: Die Compiler-Optimierung muss eingeschaltet sein.

Steht alles auch in der libc-Dokumentation.

Übrigens: Falsches Forum...

[... (Gast)]

...

3.: Der Parameter darf nur einen bestimmten maximalen Wert haben, der 
von der Taktfrequenz abhängig ist.

Steht ebenfalls in der libc-Dokumentation.

CU

[Claus (Gast)]

Ok danke erstmal
Sorry das mit dem falschen Forum -
außerdem muß ich gestehen ich hab die doku
zu libc nicht gelesen <-)
Link ?

Das heisst die alternative würde darin bestehen, die
die while schleife mit dem delay
durch einen aufruf von

void wait_tenth_second ( uint8_t count )
{
        uint8_t i=0;
        for ( ; i < count ; i++ )
        {
                _delay_ms ( 100 );
        }
}

zu ersetzen (und dementsprechen die zeiten anzupassen)?

Übrigens falls es hilfreich ist,
der ganze code befindet sich hier:
https://trex-online.no-ip.info/websvn/listing.php?repname=Remote+Board&path=%2Fsrc%2F#_src_

[Stefan B. (stefan)]

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

Warteschleifen
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#Warteschleifen_.28delay.h.29

Die Idee mit der mehrfachen Schleife ist prinzipiell OK. Eine andere 
Lösung statt Zeitvertrödeln wäre ein Timer.

[Rolf Magnus (Gast)]

> Link ?

http://www.google.de/search?q=avr-libc+documentation

[Falk B. (falk)]

@ Claus (Gast)

>außerdem muß ich gestehen ich hab die doku
>zu libc nicht gelesen <-)

Pöser Pursche!

void wait_tenth_second ( uint8_t count )
{
        uint8_t i=0, j;
        for ( ; i < count ; i++ )
        {
      for (j=0; j<10; j++)
                _delay_ms ( 10 );
        }
}

So isses besser, weil die Funktion _delay_ms() nur maximal ~270ms bei 1 
MHz CPU Takt warten kann, bei 20 MHz nur noch 13ms!

MFG
Falk