Timer0 mit Interrupt (ATMega8) - Denkfehler im Code?

[Clemens B. (Gast)]

Hallo,

mein Ziel ist es timer0 für 20ms(3,6864MHz Quarz) laufen zu lassen, und 
in der ISR zu deaktivieren.
Die LED ist laut Oszi immer an. Wieso?
Ich bin für alle Hinweise und Erklärungen dankbar.

Das ist der Code:

#include <avr/io.h>
#include <avr/interrupt.h>
#include "Header/timer.h"

#define TIMER0_LAEUFT     !(TIFR & (1<<TOV0))

int main(void)
{
  DDRB |= (1<<PB2);
  timer0_init();
  sei();

  while(1)
  {
    PORTB  &= ~(1<<PB2);
    TIMER0_START

    while(TIMER0_LAEUFT)
    {
      PORTB  |= (1<<PB2);
    }
  }
}

#ifndef HEADER_TIMER_H_
#define HEADER_TIMER_H_

#include <avr/io.h>
#include <avr/interrupt.h>

#define TIMER0_START TCCR0 |= ((1<<CS02) | (1<<CS00));  // prescaler 1024 -> 3600Hz
#define TIMER0_STOP TCCR0 &= ~((1<<CS02) | (1<<CS00));

void timer0_init(void);
ISR(TIMER0_OVF_vect);

#endif /* HEADER_TIMER_H_ */

#include <avr/io.h>
#include <avr/interrupt.h>
#include "../Header/timer.h"

void timer0_init(void)
{
  TCNT0 = 0x48;  // 3600Hz / 72 = 50Hz -> 20ms. TCNT0 = 0x48 (183 =255-72)
  TIMSK |= (1<<TOIE0);
  TCCR0 &= ~((1<<CS02) | (1<<CS01) | (1<<CS00));  // timer0 deaktiviert initialisieren
                          // mit Makro "timer0_start" (siehe timer.h) im Code starten
}

ISR(TIMER0_OVF_vect)
{
  TCNT0 = 0x48;  // preload Wert fuer 20ms bei 3,6kHz
  TIMER0_STOP
}

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

Clemens B. schrieb:
> Die LED ist laut Oszi immer an.
Welche LED und was bedeutet "an"?

[Oliver S. (oliverso)]

Wenn du den Timer in deiner Hauptschleife immer wieder einschaltest, was 
meinst du, wie lange der nach einem Interrupt aus bleibt?

Oliver

[Clemens B. (Gast)]

Sorry, an PB2 ist die LED angeschlossen. An der liegt dauerhaft high an, 
sprich es hängt hier im Code:

 while(TIMER0_LAEUFT)
    {
      PORTB  |= (1<<PB2);
    }

[Clemens B. (Gast)]

Oliver S. schrieb:
> Wenn du den Timer in deiner Hauptschleife immer wieder
> einschaltest, was
> meinst du, wie lange der nach einem Interrupt aus bleibt?
>
> Oliver

#define TIMER0_LAEUFT     !(TIFR & (1<<TOV0))

while(TIMER0_LAEUFT)

Diese while Schleife sollte er doch erst nach der ISR verlassen oder 
nicht?

[Marc V. (Firma: Vescomp) (logarithmus)]

Clemens B. schrieb:
> while(TIMER0_LAEUFT)
>
> Diese while Schleife sollte er doch erst nach der ISR verlassen oder
> nicht?

 Ja, und ?

    PORTB  &= ~(1<<PB2);   // LED AUS   --+ Wieviel Zeit
    TIMER0_START           //             | vergeht
                           //             | zwischen
    while(TIMER0_LAEUFT)   //             | diesen
    {                      //             | zwei
      PORTB  |= (1<<PB2);  // LED AN    --+ Befehlen ?
    }

[Oliver S. (oliverso)]

Clemens B. schrieb:
> Diese while Schleife sollte er doch erst nach der ISR verlassen oder
> nicht?

Diese while-Schleife wird niemals verlassen. Die ISR funkt zwar 
dazwischen, aber danach geht's munter im while-Kreis weiter.

Oliver

[Clemens B. (Gast)]

Oliver S. schrieb:
> Clemens B. schrieb:
>> Diese while Schleife sollte er doch erst nach der ISR verlassen oder
>> nicht?
>
> Diese while-Schleife wird niemals verlassen. Die ISR funkt zwar
> dazwischen, aber danach geht's munter im while-Kreis weiter.
>
> Oliver

Ach verdammt stimmt, da ist der Denkfehler. Danke!

[Clemens B. (Gast)]

Ps. Für den Fall, dass es irgendwann mal jemanden hilft. Ich hab es 
jetzt so gelöst und es läuft wie erwartet:

#define TIMER0_LAEUFT   TCCR0 && 0x05

Kann geschlossen werden.
Danke nochmal.

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

Clemens B. schrieb:
> es läuft wie erwartet:
> #define TIMER0_LAEUFT   TCCR0 && 0x05
Tatsächlich mit dem logischen &&?
Dann wäre es das selbe wie
#define TIMER0_LAEUFT   TCCR0
(denn 0x05 ist immer "true" und kann für ein logisches Und ignoriert 
werden)
Und damit muss nur irgendein Bit im TCCR0 gesetzt sein, dass auch 
TIMER0_LAEUFT "true" ist...

[Clemens B. (Gast)]

Lothar M. schrieb:
> Clemens B. schrieb:
>> es läuft wie erwartet:
>> #define TIMER0_LAEUFT   TCCR0 && 0x05
> Tatsächlich mit dem logischen &&?
> Dann wäre es das selbe wie
> #define TIMER0_LAEUFT   TCCR0
> (denn 0x05 ist immer "true")
> Und damit muss nur irgendein Bit im TCCR0 gesetzt sein, dass auch
> TIMER0_LAEUFT "true" ist...

Natürlich das bitweise UND. Vorm posten prüfe ich nächstes Mal..

[Falk B. (falk)]

@Clemens B. (Gast)

>Natürlich das bitweise UND. Vorm posten prüfe ich nächstes Mal..

Eine gute Idee. Außerdem sollte man derartige Makros IMMER mit einer 
Klammer versehen, damit es nicht zu komischen Nebeneffekten kommt, wenn 
das Makro in einem komplexeren Ausdruck eingesetzt wird und dort 
höherpriorisierte Operatoren angewendet werden. Aber deine Makro ist 
immer noch nicht wasserdicht. Warum prüfst du nicht einfach alle drei 
CSx Bits? Und wenn man es ordentlich und direkt verständlich schreiben 
will, nimmt man die Bitnamen und keine magic numbers.

Siehe Bitmanipulation und
Strukturierte Programmierung auf Mikrocontrollern.

Also eher so.

#define TIMER0_LAEUFT   ( TCCR0 & ((1<<CS02) | (1<<CS01) | (1<<CS00)) )

[Marc V. (Firma: Vescomp) (logarithmus)]

Clemens B. schrieb:
> Ps. Für den Fall, dass es irgendwann mal jemanden hilft. Ich hab es
> jetzt so gelöst und es läuft wie erwartet:
> #define TIMER0_LAEUFT   TCCR0 && 0x05
>
> Kann geschlossen werden.
> Danke nochmal.

 Was läuft wie erwartet ?

    PORTB  &= ~(1<<PB2);

 Diesen Befehl kannst du ruhig weglassen, absolut nutzlos.

 Somit ist deine LED praktisch immer an (oder aus) - je nachdem wie
 du das angeschlossen hast - wozu das Ganze ?

[Jim M. (turboj)]

Marc V. schrieb:
> Was läuft wie erwartet ?
>
>     PORTB  &= ~(1<<PB2);
>
>  Diesen Befehl kannst du ruhig weglassen, absolut nutzlos.

Wieso? Der löscht doch zuverlässig das PB2 Bit. Und mit 'nem guten Oszi 
hätte man das sogar gesehen...

[Patrick J. (ho-bit-hun-ter)]

Hi

Nebenfrage:

Clemens B. schrieb:
> #define TIMER0_LAEUFT     !(TIFR & (1<<TOV0))

Dieses Define wird bei jedem Aufruf im Programm erneut hergeleitet?
Hätte jetzt erwartet, daß der Wert Rechts beim Compilieren berechnet 
wird und danach Timer0_Laeuft eine Konstante ist - hätte nebenbei auch 
erklärt, warum nicht aus dem While raus gegangen wird.

Vll. sollte ich doch Mal in C rein schnuppern :/

MfG

[Falk B. (falk)]

@ Patrick J. (ho-bit-hun-ter)

>> #define TIMER0_LAEUFT     !(TIFR & (1<<TOV0))

>Dieses Define wird bei jedem Aufruf im Programm erneut hergeleitet?

Ja logisch! Es ist eine Bitmanipulation eines Steuerregisters.

>Vll. sollte ich doch Mal in C rein schnuppern :/

Tu das.

[Clemens B. (Gast)]

@Falk
Da hast du vollkommen recht, die Leerzeichen zwischen den äußersten 
Klammern hatte ich vorher nie gemacht, ansonsten mache ich das identisch 
;) schöner Tipp zur besseren Lesbarkeit.
So habe ich mein define aktuell, das CS01 Bit wird bei mir nie gesetzt.

#define TIMER0_LAEUFT   ( TCCR0 & ((1<<CS02) | (1<<CS00)) )

@Marc
So wie Jim schon erkannt hat. Es ist ein reiner Funktionstest. Und bei 
meinem Oszi geht's bis 2ns runter, mehr als ausreichend und den Puls zu 
sehen der entsteht..

@Patrick
#define ist eine sogenannte Präprozessor Direktive:
https://de.wikibooks.org/wiki/C-Programmierung:_Präprozessor

Erhöht halt die Lesbarkeit im Code(richtig angewandt). Dazu kommt das 
was Falk geschrieben hat.

[Clemens B. (Gast)]

@Falk
Da hast du vollkommen recht, die Leerzeichen zwischen den äußersten 
Klammern hatte ich vorher nie gemacht, ansonsten mache ich das identisch 
;) schöner Tipp zur besseren Lesbarkeit.
So habe ich mein define aktuell, das CS01 Bit wird bei mir ja nie 
gesetzt.

#define TIMER0_LAEUFT   ( TCCR0 & ((1<<CS02) | (1<<CS00)) )

@Marc
So wie Jim schon erkannt hat. Es ist ein reiner Funktionstest. Und bei 
meinem Oszi geht's bis 2ns runter, mehr als ausreichend und den Puls zu 
sehen der entsteht..

@Patrick
#define ist eine sogenannte Präprozessor Direktive:
https://de.wikibooks.org/wiki/C-Programmierung:_Präprozessor

Erhöht halt die Lesbarkeit im Code(richtig angewandt). Dazu kommt das 
was Falk geschrieben hat.