LEDs blinken mit einstellbarer Frequenz/Leuchtdauer

[Stefan S. (derprogrammierer2)]

Hey!

Das eine LED blinkt ist kein Problem. Ich habe jetzt aber versucht in 
meiner _delay_ms() Funktion eine Variable zu setzen statt einer Zahl: 
_delay_ms(x)  -> das geht nicht. mit google fand ich die erklärung wieso 
das nicht funktioniert. Doch jetzt stellt sich mir die Frage, wie sonst 
geht das ?? Ich will das mit einem Poti sozusagen einstellen (den Wert 
-- zB 200 -> 200ms --> in _delay_ms(200);))

[Oliver R. (orb)]

Nimm _delay_ms(1), pack den in eine Schleife und lass die 200mal 
durchlaufen.

[Wolfgang A. (Gast)]

Stefan S. schrieb:
> Doch jetzt stellt sich mir die Frage, wie sonst geht das ??
Wenn dein µC auch noch andere Aufgaben übernehmen soll, vergiss die 
Funktion _delay_ms() ganz schnell wieder. Damit legst du den µC lahm, 
weil er die ganze Zeit mit Zeittotschlagen beschäftigt ist.

Besser ist es, einen Timer so zu programmieren, dass er von sich aus 
läuft und entweder direkt (wenn du ihn anderweitig nicht brauchst) oder 
über regelmäßige Interrupts, in denen du Zählerstände auswertest (z.B. 
LED 200 Takte an, 50 Takte aus), die LED steuert.

[Draco (Gast)]

Grundsätzlich stimme ich Patryk zu, nimm einen Timer und versuche es 
"Thread-ähnlich" aufzubauen. Solltest du dennoch, für einfache Aufgaben, 
den Delay nutzen wollen, mach es einfach so:

void delayMS(uint16_t delay)
{
   for(uint16_t i = 0;i<delay;i++)
   {
      _delay_ms(1);
   }
}

Aufrufen tust du das ganze dann halt einfach so:

 
delayMS(1000);
 
//oder eben mit Variable:
 
uint16_t Warte = 2300;
delayMS(Warte);

[Lothar M. (Firma: Titel) (lkmiller) (Moderator)]

Draco schrieb:
> Solltest du dennoch, für einfache Aufgaben, den Delay nutzen wollen
Ich sehe das so:
ein Delay zur bewussten Rechenzeitverschwendung hat in einer 
Hauptschleife nichts zu suchen und ist als Programmierfehler (oder 
besser Konzeptfehler) zu sehen...
Gerade an einer simplen blinkenden LED kann man ideal z.B. mal einen 
Timer mit Interrupt ausprobieren und das Ganze mit einem 
Zustandsautomaten abhandeln. Damit wäre das ein Ansatz:
http://www.lothar-miller.de/s9y/categories/22-Zeiten

Wenn man keine ganz so langen Zeiten braucht (ein long reicht für einen 
ms-Takt von Montag früh bis Donnerstag Mittag), dann reicht auch eine 16 
Bit Zählvariable.

[Stefan S. (derprogrammierer2)]

das mit der for-schleife in einem unterprogramm, das habe ich mir auch 
schon überlegt. ich werde mich etwas mit den timern spielen. mal sehen 
ob sich da was gscheit's ergibt. falls ich was interessantes hab poste 
ich es

[spess53 (Gast)]

Hi

>gibt es eigentlich eine Beschreibung zu dem Blockschaltbild von der ADU
>(eine gute?) Also was zB ADMUX; ADCSRA,SFIOR, also die ganzen Register
>machen bzw wozu sie dienen.

Aktuelles Datenblatt?

MfG Spess

[Stefan S. (derprogrammierer2)]

else if (counter == 3)
      {
        ADC_Wert = ADC_Umsetzung(1);
        itoa(ADC_Wert,Text,10);
        lcd_print(1,0,Text);
        lcd_write("           ");
        
        if(!(PIND & (1<<PD3))) break;
      }

uint16_t ADC_Umsetzung(uint8_t AD_Channel)
{
  // Kanal auswählen
  ADMUX |= AD_Channel;
  // Umsetzung starten
  ADCSRA |= (1<<ADSC);
  // warten bis Umsetzung beendet
  while (ADCSRA & (1<<ADSC));
  
  return(ADC);
}

Das AD_Init ist richtig eingestellt.

Mein Programm: Drücke ich das dritte mal den blauen Taster komme ich in 
diese If Bedingung die oben abgebildet ist.
Gestern war der Wert am LCD immer aktuell, sobald ich am Poti gedreht 
habe. Solang der counter==3 war. Ich hab immer den richtigen Wert 
gehabt.

Doch heute muss ich feststellen, (habe ein bisschen mit MUX0 gespielt, 
jedoch wieder den Bit gelöscht dann!) dass der immer nur einen Wert (den 
ersten anzeigt). War mein Poti ganz am Ende als ich in den counter==3 If 
reingekommen bin, hat er nur 1023 angezeigt, egal ob ich drehe oder 
nicht,.. woran kann das liegen?

(gestern gings noch ohne eine while...........)

[Dietrich L. (dietrichl)]

Zumindest das ist falsch:

Stefan S. schrieb:
> ADMUX |= AD_Channel;

Das setzt nur zusätzliche "1"-Bits (ODER-Verknüpfung!).
Du musst vorher alle Channel-Bits löschen (mit UND-Verknüpfung) bevor Du 
den neuen Channel-Wert hinein-ODER-st.

Ob das jetzt Dein beschriebenes Problem löst habe ich nicht geschaut.

Gruß Dietrich

[Stefan S. (derprogrammierer2)]

Tut es leider nicht :(

[Stefan S. (derprogrammierer2)]

habs geschafft. falsche { am falschen Ort

[c-hater (Gast)]

Draco schrieb:

> Grundsätzlich stimme ich Patryk zu, nimm einen Timer und versuche es
> "Thread-ähnlich" aufzubauen.

Sowas nennt sich "ereignisorientierte Programmierung".

Hat mit Threads nur sehr bedingt etwas zu tun, eigentlich garnix. Eine 
gewisse Analogie entsteht nur daraus, das Ereignisse (im abstrakten 
Sinn) bei µC-Applikationen oft sehr direkt aus Interrupts stammen statt 
dass diese Tatsache durch Unmassen zeitfressender Schichten nutzlosen 
Glue-Codes vor dem Anwendungsprogrammierer verborgen wird, wie das bei 
"richtigen OS" gewöhnlich der Fall ist.

[Dieter F. (Gast)]

Na, das hättest Du doch dort

Beitrag "Atmega32, Poti, ADC, Poti-am LCD ausgeben"

gleich dranhängen können ...



Stefan S. schrieb:
> if(!(PIND & (1<<PD3))) break;

Hast Du da nur die MAIN-(WHILE-) Schleife drum? Falls ja, solltest Du 
mal nachlesen, was so ein BREAK-Statement macht :-)
Wenn der Prozessor nicht mehr arbeitet wird auch das LCD nicht mehr 
aktualisiert ...