_delay_ms mit zufälligem Wert

Phil schrieb:
> "__builtin_avr_delay_cycles expects a compile time integer",
_delay_ms will einen zum Compilezeit bekannten Wert.

Man könnte es so lösen:

1

char cnt;

2

3

while(1)

4

{

5

  cnt=rand();

6

  while(cnt--)

7

    _delay_ms(1); 

8

}

Das _delay fest vorgeben und in eine, durch eine Zufallszahl 
festgelegte, Schleife laufen lassen.

du kanst aber den random wert in eine for schleife packen und dann das 
_delay_us(1) in die schleife schreiben.
da wie bereits gesagt das delay eine feste Zahl braucht.
Ebenso wenig ist es möglich eine Variable in das delay zu schreiben

expl.
for (a= 0; a<random a++)
{_delay_us(random);
}

Sebastian Balz schrieb:
> for (a= 0; a<random a++)
> {_delay_us(random);
> }
"__builtin_avr_delay_cycles expects a compile time integer"

außer du hast radom vorher mit einem Würfelwurf oder ähnlichem bestimmt 
und dann mit einem #define definiert.

@ Phil (Gast)

>Warum erwartet die delay Funktion einen Wert, der beim Kompilieren schon
>bekannt ist? Bringt das irgendwelche Stabilitätsvorteile?

Weil sie so gemacht ist! Lies die Doku der libc im WinAVR!

Phil schrieb:
> Warum erwartet die delay Funktion einen Wert, der beim Kompilieren schon
> bekannt ist?

Weil sie daraus die einzusetzenden Befehle möglichst exakt ermitteln
will.  Wie willst du um eine Mikrosekunde genau verzögern können,
wenn bereits deine Rechnung 50 oder 100 Mikrosekunden dauert?

_delay_us() und _delay_ms() sind Bequemlichkeits-Funktionen, die das
umständliche Vorberechnen der CPU-Zyklenzahl auf den Compiler verlagern
möchten, damit der Nutzer den Stress nicht hat.  Sie arbeiten intern
mit Gleitkommazahlen, damit man auch sowas angeben kann, wie

1

#define F_CPU 3.686E6 /* 3.686 MHz */

oder

1

_delay_ms(0.8);

Du wärst schätzungsweise besser beraten, einen Timer damit zu
beauftragen.  Dafür sind die Dinger da.