AVRGCC Laufzeit / Anfängerfrage

[Jan S. (jannemann)]

Hallo,
ich bin noch relativ neu in der AVR Szene, und habe eine Frage zu der 
Programmlaufzeit von AVRGCC Programmen.

Mir ist schon seit längerem Aufgefallen, dass die _delay_XX() Funktionen 
bei mir nicht so ganz richtig laufen.

Hier mal ein kurzes Programm:

#define F_CPU 1000000L

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


int main(void)
{
  DDRB=0xff;
  
    while(1)
    {
       PORTB |=1;
     _delay_us(30);
     PORTB &=0;
     _delay_us(30);
    }
}

Der MEGA8 Läuft mit dem internen Oszi auf 1MHz und sollte eine Frequenz 
von ca 16kHz erzeugen. (Für die Schlaumichel: ich weiß dass man dafür ne 
PWM nimmt.)
Der AVR Simulator sagt mir aber, dass ich ne Schleifendauer von 7,1ms 
habe und mein Oszi sagt mir das selbe. Das macht nach Adam Riese eine 
Abweichung von etwas mehr als 6ms bzw eine Abw. um das 100fache. So 
ungenau kann doch selbst der interne Oszillator nicht sein oder?

Deshalb meine Frage: Ist die Nutzung der delay Funktion richtig?

Na klar, kann ein C-Programm nie so schnell laufen wie ein ASM-Programm, 
aber ich finde die Zeiten teilweise ganzschön erschreckend. Wo liegen 
bei euch die Typischen Zeiten für eine while(), for() oder if() 
anweisung?
Oder ist es normal, dass C-Code soooo lange Programmlaufzeiten hat?

Optimierungsstufe ist null.

Bin dankbar für jeden ernstgemeinten Rat.

[Ed (Gast)]

Hi,

Zitat aus der avrlibc-Doku, Abschnitt über die Delay-Funktionen:
"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."

Versuchs doch mal mit aktiver Compiler-Optimierung.

-Ed

[Ed (Gast)]

Nachtrag:
Hier noch der Link:
http://www.nongnu.org/avr-libc/user-manual/group__util__delay.html

[Cyblord -. (cyblord)]

Jan S. schrieb:
>
> Optimierungsstufe ist null.
>

Unabhängig davon dass die delays damit nicht korrekt laufen ist diese 
Einstellung grundsätzlich schlecht. -Os sollte benutzt werden wenn man 
keinen sehr gute Grund hat, etwas anderes zu benutzen.

gruß cyblord

[Jan S. (jannemann)]

Tatsächlich.. mit Optimierung läuft es! :-)
Danke für die schnellen Antworten!

Ich hatte mich darauf berufen, dass in vielen Tutorials und Büchern 
immer von der Optimierung null ausgegangen wird.
Kann mir jemand sagen, warum diese in der Literatur so oft verwendet 
wird? Bis jetzt kenne ich die Optimierung nur als Problem bei leeren for 
oder while Schleifen. Die werden bei einigen Compilern dann 
rausoptimiert. Das kann doch aber mit ASM-Einbindungen umgangen werden.

[Krapao (Gast)]

Mit eingeschalteter Optimierung kann es schwieriger sein, im Simulator 
dem Programmfluß zu folgen. Der Optimierer kann überflüssigen Code 
entfernen und Code umordnen. Das kann den Anfänger beim Nachvollziehen 
eines Tutorials verwirren.

[Krapao (Gast)]

Die Empfehlung generell pro -O0 aus "den Tutorials" halte ich aber für 
überzogen. Ich würde das nur machen, wenn ein bestimmter Abschnitt des 
Tutorials das erfordert z.B. ein Vergleich C-Source und Disasseblat. In 
dem µC.net Tutorials ist die -O0 Voraussetzung hoffentlich nicht drin, 
oder?

[Jan S. (jannemann)]

Nein im µC Tutorial wird die Einstellung -Os empfohlen.
Hätte ich es mal mit diesem Tutorial gelernt :)