AVR: timing mit _delay_us()

[Empage (Gast)]

Guten Abend,
ich habe ein Problem bezüglich der Funktion _delay_us() mit einem 
ATMega32.
Mit dem folgenden Code steuere ich einen Lautsprecher (Port A0) an und 
möchte einen konstanten Ton ausgeben:

#include <avr/io.h>
#include <util/delay.h>

int main(void) {
  uint32_t udelay = 360UL;
  uint32_t i;
  DDRA = 0xFF;
  PORTA = 0;
  
  while(1) {
    PORTA ^= 0b00000001;
    
    for (i = 0UL; i < udelay; i++) {
      _delay_us(1);
    }
    
    //_delay_us(1000UL);
  }
  return 0;
}

Mit der auskommentierten delay-Funktion klappt das so auch ganz gut und 
der Ton ist sauber und liegt wohl auch ungefähr bei 1kHz. Wenn ich 
jedoch die Funktion mit der for-Schleife benutze, wie ich sie hier im 
Forum gefunden habe, um eine variable Zeit abzuwarten, geht das 
irgendwie schief. Bei udelay < 350 funktioniert das auch noch, bis auf 
das der Ton nicht bei (1000000 / 350) Hz liegt, sondern etwas tiefer 
ist. Sobald ich jedoch für udelay einen Wert von 360 oder höher 
eintrage, krisselt der Lautsprecher total und hat keinen guten 
konstanten Ton mehr, obwohl das ja eigentlich bis 1 kHz kein Problem 
darstellen sollte.

Woran kann das liegen? Ist die for-Schleife soviel langsamer als ein 
einfaches delay? Aber dann müsste ich ja mit einem anderen Wert ein 
Äquivalent zur einfachen delay-Funktion schaffen, das ist aber nicht 
möglich.

Gruß,
Empage

[Karl H. (kbuchegg)]

Empage schrieb:

> Woran kann das liegen? Ist die for-Schleife soviel langsamer als ein
> einfaches delay?

32 Bit Arithmetik ist für einen 8-Bit µC nun mal ziemlich aufwändig.

> Aber dann müsste ich ja mit einem anderen Wert ein
> Äquivalent zur einfachen delay-Funktion schaffen, das ist aber nicht
> möglich.

Ich denke mal, dass der Optimizer da bei kleinen Werten zugeschlagen hat 
und die for-Schleife soweit beschleunigt hat, dass es noch einigermassen 
hinkommt. Bei größeren Werten schägt dann der 32 Bit Overhead gnadenlos 
zu.


Solche Dinge macht man mit Timern.

[Rolf Magnus (Gast)]

Welchen Takt hat der Prozessor denn? _delay_us(1) sind ja bei 8 MHz nur 
8 Taktzyklen.  Da ist der Overhead für die for-Schleife pro Durchlauf 
mindestens genauso groß. Bei niedrigeren Prozessortakten überwiegt der 
Overhead deutlich gegenüber dem delay.