Ampelsteuerung mit Potentiometer

so wird das aber nichts.
Der Grund dafür ist, dass du in delay_ms keine variablen Zeiten 
vereinbaren darfst (weil sonst die Zeiten nicht stimmen).

D.h du kannst nicht einfach irgendeine Anzahl von Millisekunden so 
abwarten lassen

1

  int k = 4500;

2

3

4

  ....

5

  delay_ms( k );

aber:
getreu dem Motto "Wer 60 mal 1 Sekunde wartet, hat in Summe auch 60 
Sekunden gewartet", das hier machen

1

void wait_ms( uint16_t ms )

2

{

3

  uint16_t i;

4

5

  for( i = 0; i < ms; i++ )

6

    _delay_ms( 1 );

7

}

Jetzt hast du eine Funktion, der du die Anzahl an Millisekunden vorgeben 
kannst und die diese (na ja) so einigermassen einhält. Und: du kannst 
diese Zeit beim Aufruf aus irgendwelchen anderen Zahlen errechnen. Zum 
Beispiel aus dem Wert, den du vom ADC bekommst und der die Potistellung 
wiederspiegelt.
Und ja, ab jetzt stimmt dein prinipieller Gedankengang:
Du liest mittels ADC die Potistellung aus. Das Ergebnis speicherst du 
dir in einer Variablen (das ist dann ein Wert im Bereich 0 und 1023). 
Mit diesem Wert kannst du dann rumrechnen, wie du lustig bist und wie es 
dir gefällt um daraus auf eine dir genehme Zeit zu kommen, die du dann 
an wait_ms übergibst, die diese Zeit abwartet.


Zum Thema ADC
http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial/Analoge_Ein-_und_Ausgabe#Der_interne_ADC_im_AVR

Georg schrieb:
> Karl Heinz schrieb:
>> Der Grund dafür ist, dass du in delay_ms keine variablen Zeiten
>> vereinbaren darfst (weil sonst die Zeiten nicht stimmen).
>
> Und woher weiss delay_ms, ob der übergebene Wert konstant oder variabel
> ist? Spukhafte Fernwirkung?

Der Compiler weiß es.
Hinter delay_ms verbirgt sich ein Mechanismus, der aus der angebenen 
Zahl eine entsprechende Anzahl an Schleifendurchläufen generiert. Dabei 
werden unter anderem auch Floating Point Berechnungen durchgeführt.
Der ganze Mechanismus ist darauf angewiesen, dass der Compiler das alles 
wegoptimieren kann, weil er zur Compilezeit bereits die entsprechenden 
Berechnungen macht. Im entstehenden Code stehen dann nur noch die daraus 
generierten Schleifen mit einer entsprechenden Anzahl an Durchläufen.

Kommt dieser Optimierungsmechanismus nicht in Gang, zum Beispiel weil 
der Compiler die Zeit nicht als Zahlenwert kennt, dann stimmt auch das 
Codeergebnis insofern nicht, als die Zeiten krass daneben sind.

Und nein: delay_ms ist nicht einfach irgendeine Funktion, die aufgerufen 
wird. Hinter delay_ms verbirgt sich eine Funkion, die auf jeden Fall 
inline aufgelöst wird. Eben damit die Optimierungen greifen können und 
das Ergebnis stimmt.