Anfängerproblem: Im Zustand "gefangen"

[Daniel J. (Gast)]

Hallo,

zunächst mal muss ich dazu sagen, dass ich gerade erst angefangen habe, 
mit der Programmierung von AVRs, verzeiht mir daher bitte, wenn ich 
möglicherweise noch etwas grün wirke :-)

Ich habe hier das STK 500 mit einem ATmega 32. Nachdem ich mir die Timer 
angeschaut habe, beschäftige ich mich nun mit Interrupts im Allgemeinen 
und nutze dazu die Taster am STK. Über eine Zustandsmaschine möchte ich 
die Zustände "alle LEDs an", "LEDs laufen von hinten bis vorne durch" 
und "alle LEDs aus" realisieren. Den Code findet ihr unten.

Ihr könnt es euch denken: Wenn ich den Taster an PD2 drücke und wieder 
los lasse, passiert leider gar nichts. Durch die Simulation in AVR 
Studio konnte ich folgendes feststellen: Der ext. Interrupt wird 
grundsätzlich ausgelöst und die Variable "state" auch entsprechend 
verändert. Aber es scheint, als wäre das Programm in der "if(state == 
0)"-Verzweigung gefangen. Jedenfalls springt der Debugger nur zwischen 
den beiden Befehlen hin und her, obwohl "state" nicht 0 ist.

Könnte mir jemand dabei helfen, die Tomaten von den Augen zu bekommen? 
:-)

LG,
Daniel

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

int i    = 0;      // Timer Overflow counter
int state  = 0;      // Status

int main(void)
{
  DDRB  = 0xFF;      // Port B as output
  PORTB  = 0xFF;      // LEDs off

  DDRD  = 0x00;      // Port D as input

  MCUCR  |= 0x02;    // INT 0 falling edge
  GICR  |= 0x40;    // INT 0 enable

  TCCR0  = 0x05;      // Normal Timer Mode, Prescaler: 1024

  sei();
  
  while(1) {
    if(state == 0) {
      TIMSK &= ~(1 << TOIE0);
      PORTB = 0x00;
    }
    else if(state == 1) {
      PORTB = 0xFE;
      TIMSK |= (1 << TOIE0);
    }
    else {
      TIMSK &= ~(1 << TOIE0);
      PORTB = 0xFF;
    }
  }
}

ISR(TIMER0_OVF_vect)
{
  if(++i == 14) {
    if(PINB == 0x7F) {
      PORTB = 0xFE;
    }
    else {
      PORTB = ~(~PINB << 1);
    }
    
    i = 0;
  }
}

ISR(INT0_vect)
{
  if(state < 2) {
    state++;
  }
  else {
    state = 0;
  }
}

[Jens (Gast)]

Setz mal volatile vor die Variablen.
volatile int i    = 0;      // Timer Overflow counter
volatile int state  = 0;      // Status

[Daniel J. (Gast)]

Hey Jens,

vielen Dank, das funktioniert (und dadurch gleich den Fehler 
festgestellt, dass das Laufmuster im zweiten Zustand immer gleich zurück 
gesetzt wird ^^).
Kannst du mir erklären, was sich dadurch bei der Abarbeitung im 
Controller ändert?

LG
Daniel

[Jens (Gast)]

Kann ich so genau auch nicht. Mit volatile zwingst du dem Compiler, dass 
die Variablen bei jedem aufruf auf dem Speicher geholt, verändert und 
wieder in den Speicher zurückgeschrieben wird usw.

Ich glaube ohne volatile erzeugt der ISR eine Kopie der Variable, die 
nur für den ISR gültig ist.

[Volkmar D. (volkmar)]

Kurz gesagt, volatile teilt dem Compiler mit, das diese Variabel 
außerhalb des normalen Programmablaufs (zum Beispiel in einer ISR) 
verändert werden kann. Es ist zum Beispiel #1 in der FAQ: 
http://www.nongnu.org/avr-libc/user-manual/FAQ.html#faq_volatile

Was mir noch aufgefallen ist:
Daniel J. schrieb:
> ISR(TIMER0_OVF_vect)
> {
>   if(++i == 14) {
>     if(PINB == 0x7F) {
>       PORTB = 0xFE;
>     }
>     else {
>       PORTB = ~(~PINB << 1);
>     }
>
>     i = 0;
>   }
> }

Hier solltest Du nicht PINB einlesen, denn damit wird der Wert an den 
Portpins eingelesen und der kann sich von dem Wert, den Du geschrieben 
hast, unterscheiden. Du verwendest den PORTB an dieser Stelle aber als 
Variable, dann solltest Du auch PORTB wieder einlesen:

> ISR(TIMER0_OVF_vect)
{
  if(++i == 14) {
    if(PORTB == 0x7F) {
      PORTB = 0xFE;
    }
    else {
      PORTB = ~(~PORTB << 1);
    }
    
    i = 0;
  }
}

[Volkmar D. (volkmar)]

Jens schrieb:
> Kann ich so genau auch nicht. Mit volatile zwingst du dem Compiler, dass
> die Variablen bei jedem aufruf auf dem Speicher geholt, verändert und
> wieder in den Speicher zurückgeschrieben wird usw.

Richtig

> Ich glaube ohne volatile erzeugt der ISR eine Kopie der Variable, die
> nur für den ISR gültig ist.

Falsch. Ohne volatile erkennt der Compiler nicht, daß diese Variable 
außerhalb des 0815-Programmablaufs verändert wird, und optimiert 
entsprechend. Siehe FAQ-Link weiter oben.

[Christian Erker (Gast)]

Der Compiler liest eine Variable nur neu ein, wenn er eine Änderung 
erwartet, ein kurzes Beispiel:

a = eingabewert();
b = a + 3;
c = a + 4;
d = a + 6;

Hier wird A nur einmal gelesen und dann 3 mal verarbeitet, im Normalfall 
geht dies problemlos gut.

Schlägt nun aber ein Interrupt dazwischen:


a = eingabewert();
b = a + 3;
  [ a = interruptwert; ]
c = a + 4;
d = a + 6;

Sind c und d, die EVENTUELL noch mit dem alten Wert von a arbeiten (es 
ist kein muss, wenn kein Register frei ist wird a auch vielleicht nach C 
nochmal gelesen und stimmt für d, das kann man nicht vorhersehen (es ist 
zwar deterministisch, also, das gleiche Programm sollte immer den 
gleichen Code erzeugen .. aber es gibt keine einfachen allgemeingültigen 
Regeln).

"volatile" erzwingt das die Variable vor jeder Verwendung neu gelesen 
wird UND nach jeder Änderung neu geschrieben, um dies zu vermeiden.

Beispiel zum schreiben:

a = 5;
{Haufen anderer Code der nichts mit A macht}
a = Eingabewert();
b = a + 3;

Hier wird a, zunächst offensichtlich, nur mit Eingabewert, nie mit 5 
beschrieben, da 5 nie verwendet wird. Möchte man aber z.B. das ein 
Interrupt während der Ausführung des Codeblocks zwischen den 2 
Zuweisungen etwas anderes macht (oft der Fall bei gemeinsam genutzter 
Hardware) und die 5 als Marker verwenden, ist auch hier "volatile" zu 
verwenden.

Gruß,
Christian

[Daniel J. (Gast)]

Vielen Dank Jens und Volkmar!
Ich habe parallel ein wenig zu "volatile" gelesen und versucht aus dem 
Disassembly was herauszulesen, zumindest die Unterschiede zwischen 
beiden Varianten.

"state" verändert sich auf jeden Fall, das zeigt mit auch der Debugger 
an. Habe mir daher auch überlegt, dass der Compiler da wohl was weg 
optimiert und durch Volker weiß ich jetzt auch, warum er das macht (er 
betrachtet den ISR dabei nicht).

Danke auch für den Tipp mit der Verwendung von PINB!

[Daniel J. (Gast)]

Dir natürlich auch ein Dankeschön, Christian. Super Erklärung, da wirds 
dann spätestens komplett klar! :-)

[Daniel J. (Gast)]

Insofern erklärt sich auch, warum ich "volatile" bei "state" brauche, 
bei "i" hingegen nicht. Das hat nämlich vorher auch ohne funktioniert.

[Volkmar D. (volkmar)]

Daniel J. schrieb:
> Insofern erklärt sich auch, warum ich "volatile" bei "state" brauche,
> bei "i" hingegen nicht. Das hat nämlich vorher auch ohne funktioniert.

Ergänzend möchte ich noch hinweisen, daß "i" üblicherweise als lokaler 
Schleifenzähler verwendet wird und daher als globale Variable nicht 
verwendet werden sollte. Da wäre ein aussagekräftiger Name angebracht.

Volkmar

[Karl H. (kbuchegg)]

Volkmar Dierkes schrieb:
> Daniel J. schrieb:
>> Insofern erklärt sich auch, warum ich "volatile" bei "state" brauche,
>> bei "i" hingegen nicht. Das hat nämlich vorher auch ohne funktioniert.
>
> Ergänzend möchte ich noch hinweisen, daß "i" üblicherweise als lokaler
> Schleifenzähler verwendet wird und daher als globale Variable nicht
> verwendet werden sollte. Da wäre ein aussagekräftiger Name angebracht.

Entweder das, oder überhaupt dieses 'i' komplett in die ISR verbannen

ISR(TIMER0_OVF_vect)
{
  static int i = 0;

  if(++i == 14) {
    if(PINB == 0x7F) {
      PORTB = 0xFE;
    }
    else {
      PORTB = ~(~PINB << 1);
    }
    
    i = 0;
  }
}

Am besten wäre natürlich beides. Denn Volkmar hat natürlich schon recht: 
Dieser Zähler hier ist ein wichtiger Zähler, so dass er sich einen etwas 
bessereren Namen als 'i' verdient hätte. Einbuchstabige Variablen-Namen 
sollte man ausschliesslich für Hilfsvariablen (wie zb Laufvariablen in 
for-Schleifen) benutzen, deren Gültigkeitsbereich im überschaubaren 
Rahmen liegt. Globale Variablen bzw. wichtige Variablen sollten auch 
angemessen benannt werden. Die Codequalität inklusive Lesbarkeit des 
Codes wird einem dafür dankbar sein.