Interrupt ATtiny85 - Hilfe

[Michael (oti)]

Bin nun aus Langeweile dabei eine alte Taschenlampe umzubauen. Ehemals 
Bleiakku ..., nun Hardware (NE555) alles fertig. Will die Steuerung aber 
mit einem ATtiny85 vornehmen. Habe vor langer Zeit so etwas programmiert 
(Z80 noch mit HEX-Code) und mit dem Versuchssteuerungen für 
physiologische Experimente aufgebaut.
Sehe nun offensichtlich durch die IR-Funktionsweise des uC nicht durch.
Programmablauf ist ja relativ simpel. Power on schaltet Modus 1 ein. 
Tasterdruck setzt Variable auf true und schaltet Modus weiter (4 
Leuchtmodi).
Diese werden in der while Schleife ausgewertet (wenn true, nächster 
Modus, sonst alter). Vor dem Verlassen der IR-Routine wird IR disabled 
und nach dem neuen Modus wieder enabled. Die IR wird auch ausgeführt. 
Mit der meiner While() komme ich nicht weiter.
Simulieren geht (Variable event & modus von Hand gesetzt). AT85 sitzt 
auf Breadboard mit entsprechender Hardware zum testen.
Kann mir da jemand helfen. Kenne das Datenblatt mitterlerweile fast 
auswendig und auch ein paar Bücher neben mir.
Den Skript habe gekürzt (Bibliotheken, Definition und Deklarationen) 
denn der Compiler zeigt keine Fehler an. (Skript nochmal als Anhang).
Hoffe jemand gibt mir etwas Nachhilfe.

//Interrupt Service Routine for INT0
ISR(INT0_vect) {
  Button_event=true;
  _delay_ms(10);        // button debounce
  GIMSK &= ~ (1<<INT0);    // disable IR
  //Test_LED_toggle();      // visual control toggle PORTB 
  //_delay_ms(20);
}

int main(void)
{
  // setting i/o ports
  DDRB &= ~ (1<< PB2);                            // PB2 input - clear bit
  PORTB |= (1 << PB2);                            // PB2 pull up
  DDRB  |= (1<< PB1) ;
  DDRB |= (1<< PB4);                              // PB1 and PB4 output
  PORTB &= ~( (1<<PB1) | (1<<PB4));                      // LED off  
  //PORTB |= (1<<PB1) | (1<<PB4);                        // LED on 
    
  Full_Light();                                
    
  // setting interrupt
  GIMSK |= (1<<INT0);                              // ext. interrupt enable
  MCUCR |=(1<<ISC00); 
  MCUCR |= (1<<ISC01);                            //  Trigger INT0 on rising edge
  sei();  
                                    
  Light_mode=0;
  Button_event=true;
  
  while (1)
    {
      if (Button_event==true) {
        Button_event=false;
        Light_mode++;
      }
      if (Light_mode>=4) {
        Light_mode=0;
      }    
      while (Light_mode==0) {
        Full_Light();
        GIMSK |= (1<<INT0);
        sei();
      }
      while (Light_mode==1){
        Half_Light();
        GIMSK |= (1<<INT0);
        sei();
      }
      while (Light_mode==2) {
        SOS();
        GIMSK |= (1<<INT0);
        sei();
      }
      while (Light_mode==3)  {
        Flash_Ligt_1();
        GIMSK |= (1<<INT0);
        sei();
        //Light_mode=0;
      }    
    }
}

void Test_LED_toggle() {
  PORTB=~PORTB;  
  //_delay_ms(1000);
}

void Full_Light() {
  
  PORTB |= (1 << LED_Vcc_Warning);          // red on blue 0ff
}

void Half_Light() {
  PORTB |= (1 << LED_Light);              // blue on red off
  PORTB &=~(1 << LED_Vcc_Warning);                          
}

void SOS() {
  PORTB |= (1 << LED_Vcc_Warning);          // rot blau an               
}

void Flash_Ligt_1()  {
  _delay_ms(2000);                  // blinc              
  PORTB |= (1 << LED_Light);                            
  _delay_ms(500);
  PORTB &=~(1 << LED_Light);                            
  _delay_ms(500);
  PORTB &=~(1 << LED_Vcc_Warning);                      
}

[Mod: c-Tags das nächste Mal bitte selber einfügen. Und längeren 
Sourcecode als Anhnag posten]

[Falk B. (falk)]

Michael schrieb:
> Sehe nun offensichtlich durch die IR-Funktionsweise des uC nicht durch.

IR? Infrarot? Oder eher Interrupt?

> Programmablauf ist ja relativ simpel. Power on schaltet Modus 1 ein.
> Tasterdruck setzt Variable auf true und schaltet Modus weiter (4
> Leuchtmodi).
> Diese werden in der while Schleife ausgewertet (wenn true, nächster
> Modus, sonst alter). Vor dem Verlassen der IR-Routine wird IR disabled
> und nach dem neuen Modus wieder enabled. Die IR wird auch ausgeführt.
> Mit der meiner While() komme ich nicht weiter.

Dein Programm ist nicht sonderlich sinnvoll.

> Den Skript habe gekürzt (Bibliotheken, Definition und Deklarationen)
> denn der Compiler zeigt keine Fehler an. (Skript nochmal als Anhang).

Warum nicht den originalen Quelltext unverändert anhängen? Zu einfach? 
Zu wenig fehleranfällig? OMG! Und wozu dann nochmal als Text im Beitrag?

> Hoffe jemand gibt mir etwas Nachhilfe.

Ja, lies was über Netiquette. Und Entprellung.
Tasten wertet man im Normalfall NICHT per externem Interrupt aus. Dann 
braucht man dort auch keine komischen Delays.
Das macht man bestenfalls, wenn man sehr stromsparend mit dem [[Sleep 
Mode]] arbeitet, was du hier aber nicht tust.
Deine Tastenauswertung und zentrale Programmlogik ist auch nicht 
sonderlich brauchbar.

[Steve van de Grens (roehrmond)]

Michael schrieb:
> Mit der meiner While() komme ich nicht weiter.

Was ist denn dein Problem mit der while Schleife?

[Michael (oti)]

Vermute, dass die IR da nicht reinkommt.

prinzipielle Funktionsweise der IR habe ich getestet mit (funzt auch).
Vielleicht hast Du, Steve, eine Idee?.

/*Interrupt Service Routine for INT0*/
ISR(INT0_vect)
{
  PORTB=~PORTB;    /* Toggle PORTC */
  _delay_ms(50);    /* Software debouncing control delay */
}

int main(void)
{
  //DDRB=0xFF;    /* Make PORTC as output PORT*/
   // PB2 - input
  DDRB &= ~ (1<< PB2);                            // PB2 input
  PORTB |= (1 << PB2);                            // Pull Up PIN7-PB2

  // PB1 - output
  DDRB = (0<< PB1);                              // PB1 output
  PORTB |= (1 << PB1);                            //PB1 (PIN6)

  // PB4 - output
  DDRB = (0<< PB4);                              // PB4 output
  PORTB &= ~(1 << PB4);                            //PB4 (PIN3)

  GIMSK = 1<<INT0;                              /* Enable INT0*/
  MCUCR = 1<<ISC01 | 1<<ISC00;                        /* Trigger INT0 on 
rising edge */
  sei();                                    /* Enable Global Interrupt 
*/

  while (1);
}

[Steve van de Grens (roehrmond)]

Falk B. schrieb:
> Dein Programm ist nicht sonderlich sinnvoll.
> Tasten wertet man im Normalfall NICHT per externem Interrupt aus.
> Dann braucht man dort auch keine komischen Delays.

Für mich sieht das Programm durchaus sinnvoll und Prinzipiell 
funktionsfähig aus.

Konzentriere dich auf das Problem, nicht auf den Programmierstil. Lass 
die Kurve mal gerade sein. Jeder hat mal angefangen.

[Steve van de Grens (roehrmond)]

Michael schrieb:
> Vermute, dass die IR da nicht reinkommt.

Schreibe vollständige Sätze. "Ich" ist kein Tabu-Wort.

Ich vermute das ebenfalls. Damit sind wir schon zu zweit, Grund genug, 
genau das zu überprüfen. Was kam denn bei deinem Versuch mit 
Test_LED_toggle() heraus?

[Steve van de Grens (roehrmond)]

Du könntest den Wert der Variable Button_event in main() kontrollieren, 
indem du ihren Wert durch ein Blinkmuster anzeigst.

Ich nehme an, dass das Schlüsseldorf "volatile" vor "Button_event=true;" 
helfen wird. Probiere das aus.

[Rolf (rolf22)]

Steve van de Grens schrieb:
> Michael schrieb:
>> Mit der meiner While() komme ich nicht weiter.
>
> Was ist denn dein Problem mit der while Schleife?

Es sind Endlos-Schleifen:
      while (Light_mode==0) {
        Full_Light();
        GIMSK |= (1<<INT0);
        sei();
      }

statt 'while' muss es 'if' heißen.  :-))

Davon abgesehen ist das Programm verwirrend und viel zu kompliziert. In 
diesem einfachen Fall braucht man gar keinen Interrupt. Man kann die 
Taste in der Hauptschleife abfragen.

[Falk B. (falk)]

So könnte es funktionieren.

[Michael (oti)]

>
> Es sind Endlos-Schleifen:
>       while (Light_mode==0) {
>         Full_Light();
>         GIMSK |= (1<<INT0);
>         sei();
>

ja das ist eine Endlosschleife aber nur solange bis ein IR erfolgt 
dachte ich. Oder liege ich da falsch?

[Steve van de Grens (roehrmond)]

Rolf schrieb:
> Es sind Endlos-Schleifen:
>       while (Light_mode==0) {
> statt 'while' muss es 'if' heißen.  :-))

Stimmt, Adlerauge sei wachsam!

Änderungsvorschlag (zusätzlich zum Volatile):

  while (1) {

      if (Button_event==true) {
        Button_event=false;
        Light_mode++;
      }

      switch (Light_mode) {
        case 4: {
          Light_mode=0;
        }  

        case 0:
          Full_Light();
          break;

        case 1:
          Half_Light();
          break;

        case 2:
          SOS();
          break;

        case 3:
          Flash_Ligt_1();
          break;
   
       default:
          Light_mode=0;
    }
}

Bitte entschuldige, falls da Syntaxfehler drin sind. Ich arbeite seit 
mehr als einem Jahr mit anderen Programmiersprachen.

Den Teil "Light_mode++" könnte man in die ISR verschieben, dann entfällt 
die Variable Button_event. Light_mode sollte müsste dann volatile sein.

[Michael (oti)]

Danke, das probiere ich gleich.

[Steve van de Grens (roehrmond)]

Michael schrieb:
> ja das ist eine Endlosschleife aber nur solange bis ein IR erfolgt
> dachte ich. Oder liege ich da falsch?

Dein Fehler ist: Light-mode wird bei Tastendruck nicht geändert, weil

      if (Button_event==true) {
        Button_event=false;
        Light_mode++;
      }

außerhalb der "endlosen" while Schleife liegt.

[Steve van de Grens (roehrmond)]

Michael schrieb:
> Danke, das probiere ich gleich.

Sorry, lass den "case 4" weg. Ich habe vergessen, diese Zeilen zu 
löschen. Was da passiert ist durch den default case abgedeckt. Ich 
hoffe, das ist offensichtlich.

[Michael (oti)]

die funktioniert natürlich, Sonst hätte ich (hier hast Du Dein fehlendes 
ICH) nicht weitergemacht.

[Michael (oti)]

ja ist logisch

[Michael (oti)]

ja das war es, nun muss ich nur den Unterschied verstehen.
Danke Dir sehr. Mit dem Break kommt er wieder in die Endlosschleife, das 
ist bei mir nicht so. Da hatte ich gedacht, dass er diese mit dem 
IR-Request verlässt und mit der Whileschleife wieder anfängt.
Gruß Michael
p.s.  benutze Atmel7 mit einem STK500-Clone

[Michael (oti)]

> Ich nehme an, dass das Schlüsseldorf "volatile" vor "Button_event=true;"
> helfen wird. Probiere das aus.

probiere ich auch nochmal
Danke

[Michael (oti)]

Steve van de Grens schrieb:
> Michael schrieb:
>> ja das ist eine Endlosschleife aber nur solange bis ein IR erfolgt
>> dachte ich. Oder liege ich da falsch?
>
> Dein Fehler ist: Light-mode wird bei Tastendruck nicht geändert, weil
>

>       if (Button_event==true) {
>         Button_event=false;
>         Light_mode++;
>       }
>

>
> außerhalb der "endlosen" while Schleife liegt.
 das verstehe ich nicht. Der Code lautet:

while (1)
    {
      if (Button_event==true) {
        Button_event=false;
        Light_mode++;
      }

[Arduino F. (Firma: Gast) (arduinof)]

Michael schrieb:
> PORTB=~PORTB;    /* Toggle PORTC */

1. der Tiny kennt keinen PortC
2. damit stirbt der Pullup ab, und danach ist nix mehr mit 
kontrolliertem "rising"

Michael schrieb:
> // PB4 - output
>   DDRB = (0<< PB4);                              // PB4 output

So wird kein Pin zum Output gemacht.

[Michael (oti)]

> Ich nehme an, dass das Schlüsseldorf "volatile" vor "Button_event=true;"
> helfen wird. Probiere das aus.
Danke, das habe ich versucht, aber ergebnislos.

[Rolf (rolf22)]

@Michael
Du scheinst die Vorstellung zu haben, mit einem Interrupt könne man 
Schleifen verlassen. Nein, kann man nicht. Eine Schleife kann man nur 
durch eine 'break'-Anweisung verlassen, oder dadurch, dass die 
Schleifenbedingung nicht (mehr) erfüllt ist.

[Michael (oti)]

Arduino F. schrieb:
> Michael schrieb:
>> PORTB=~PORTB;    /* Toggle PORTC */
>
> 1. der Tiny kennt keinen PortC
>
ist Dir wohl entgangen, dass das ein Kommentar ist und in in der 
Anweisung PORTB steht. Mit dem Rest kann ich folgen. Also C ist 
bedeeutungsloser Schreibfehler. | ist Unterlassung aber unauffällig da 
Port trotzdem getoggelt wird ein Pin als Ausgang geschaltet ist. What 
now???

[Arduino F. (Firma: Gast) (arduinof)]

Reduziert, und getestet mit einem Digispark in der Arduino IDE.
Als C und nicht C++ kompiliert

#include <Arduino.h>

/*Interrupt Service Routine for INT0*/
ISR(INT0_vect)
{
  PINB  = (1 << PB1); // toggle
}

int main(void)
{
  PORTB |= (1 << PB2);    // Pullup
  DDRB  |= (1 << PB1);    // output

  GIMSK = 1<<INT0;              // Enable INT0
  MCUCR = 1<<ISC01 | 1<<ISC00;  // Trigger INT0 on rising edge
  sei();                        // Enable Global Interrupt 

  while (1);
}

[Michael (oti)]

Rolf schrieb:
> @Michael
> Du scheinst die Vorstellung zu haben, mit einem Interrupt könne man
> Schleifen verlassen. Nein, kann man nicht. Eine Schleife kann man nur
> durch eine 'break'-Anweisung verlassen, oder dadurch, dass die
> Schleifenbedingung nicht (mehr) erfüllt ist.

Ja, die hatte ich, dass war zumindest beim Z80 so. Kannst Du mir auch 
erklären, warum das so ist???

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

Michael schrieb:
> Kannst Du mir auch erklären, warum das so ist???
Eine Schleife kann von einem Interrupt lediglich unterbrochen werden, 
aber sie kann von diesem Interrupt nicht abgebrochen werden.

> Ja, die hatte ich, dass war zumindest beim Z80 so.
Eigentlich auch nicht, aber: in welcher Sprache hast du den 
programmiert?

[Arduino F. (Firma: Gast) (arduinof)]

Michael schrieb:
> ist Dir wohl entgangen, dass das ein Kommentar ist und in in der
> Anweisung PORTB steht.

Nein, mir ist da gar nichts entgangen!

Ich formuliere das mal so um, dass es jeder versteht:
> Kein Kommentar, ist besser, als ein falscher Kommentar!

Falsche Kommentare haben nur einen einzigen Zweck, Sinn oder Aufgabe, 
sie sollen den Leser und vielleicht sogar den Autor selber ins Bockhorn 
jagen.
Ich möchte nicht so verarscht werden, und ich möchte auch nicht dass 
sich der TO so selber verarscht.

Michael schrieb:
> | ist Unterlassung aber unauffällig da
> Port trotzdem getoggelt wird ein Pin als Ausgang geschaltet ist. What
> now???

Der Pullup wird auch abgeschaltet, und damit endet die kontrollierte ISR 
Aufruferei.
Datt is now!

[Michael (oti)]

Steve van de Grens schrieb:
> Rolf schrieb:
>> Es sind Endlos-Schleifen:
>>       while (Light_mode==0) {
>> statt 'while' muss es 'if' heißen.  :-))
>
> Stimmt, Adlerauge sei wachsam!
>

also mit if funktioniert das, wie gewünscht. Das bedeutet nun wirklich, 
dass diese while-Schleifen nicht unterbrechbar sind. WEiß jemand warum 
das so ist???

Danke Euch allen. Wünsche einen fleißigen Weihnachtsmann.
Michael

[Arduino F. (Firma: Gast) (arduinof)]

Michael schrieb:
> Das bedeutet nun wirklich,
> dass diese while-Schleifen nicht unterbrechbar sind.

Natürlich sind sie unterbrechbar!
break beendet eine Schleife
(allerdings nur von innen, nicht von außen)

Michael schrieb:
> Kannst Du mir auch
> erklären, warum das so ist???
Ja!
Weil C und C++ so definiert sind, wie sie definiert sind.
Es ist eine Spezifikation und kein "ich wünsch mir was"

[Michael (oti)]

> Der Pullup wird auch abgeschaltet, und damit endet die kontrollierte ISR
> Aufruferei.
> Datt is now!

Wenn Du meinst, teste doch mal auf Deinem Digi den Script. Da wirst Du 
staunen.

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

Michael schrieb:
> Das bedeutet nun wirklich, dass diese while-Schleifen nicht
> unterbrechbar sind.
Nochmal, weil es offenbar untergegangen ist: klar können die jederzeit 
**unterbrochen** werden, aber sie können eben durch diese 
Unterbrechungen nicht **abgebrochen** werden.

> WEiß jemand warum das so ist???
Ja: weil es die Sprachdefinition so verlangt.

Und weil es zudem die alltäglich erlebte Logik nahelegt: ein "Interrupt" 
ist eben nur eine "Unterbrechung" und kein "Teminator", der jede 
aktuelle Tätigkeit abbricht. Nach einer "Unterbrechung" arbeitet der 
Prozessor dort weiter, wo er unterbrochen wurde.

Wenn du Milch koscht und der Postbote klingelt an der Tür, dann holst du 
schnellstmöglich das Einschreiben ab und siehst zu, dass du mit der 
Milch weitermachen kannst. Denn sonst könnte ja der Postbote den Pudding 
zur Nachspeise durch sein Klingeln vehindern.

Arduino F. schrieb:
> break beendet eine Schleife
Sie könnten auch bei jedem Druchlauf ganz regulär abgebrochen werden, 
wenn einfach die Schleifenbedingung nicht mehr zutrifft.

[Arduino F. (Firma: Gast) (arduinof)]

Michael schrieb:
> Wenn Du meinst, teste doch mal auf Deinem Digi den Script. Da wirst Du
> staunen.

Da gibts nichts zu testen!
Vielleicht solltest du nochmal ins Datenblatt schauen und die C 
Operatoren = und ~ in der Sprachdoku nachlesen.

Michael schrieb:
> PORTB=~PORTB;

Dort werden alle Bits im PORTB Register invertiert/getoggelt
Und damit ist der Pullup an PB2 auch aus.

[Arduino F. (Firma: Gast) (arduinof)]

Lothar M. schrieb:
> Sie könnten auch bei jedem Druchlauf ganz regulär abgebrochen werden,
> wenn einfach die Schleifenbedingung nicht mehr zutrifft.

Ich danke dir für die Korrektur, aber wenn du so bist, solltest du evtl 
auch noch return erwähnen.

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

Arduino F. schrieb:
> solltest du evtl auch noch return erwähnen.
... und konsequenterweise auch goto.

[Arduino F. (Firma: Gast) (arduinof)]

Lothar M. schrieb:
> auch goto

abort();

[Harald K. (kirnbichler)]

Michael schrieb:

/*Interrupt Service Routine for INT0*/
ISR(INT0_vect)
{
  PORTB=~PORTB;    /* Toggle PORTC */
  _delay_ms(50);    /* Software debouncing control delay */
}

Warum nur bereitet mir das ... Unbehagen?

_delay_ms in einer ISR aufrufen? Warum nur?

[Falk B. (falk)]

Harald K. schrieb:
> Warum nur bereitet mir das ... Unbehagen?
>
> _delay_ms in einer ISR aufrufen? Warum nur?

Weil der Taster prellt. HIER ist das OK, denn der Controller hat so oder 
so nix zu tu.

[Michael (oti)]

> Michael schrieb:
>> Das bedeutet nun wirklich, dass diese while-Schleifen nicht
>> unterbrechbar sind.
> Nochmal, weil es offenbar untergegangen ist: klar können die jederzeit
> **unterbrochen** werden, aber sie können eben durch diese
> Unterbrechungen nicht **abgebrochen** werden.
ok, dass war eine falsche Schlussfolgerung von mir.

>  ein "Interrupt"
> ist eben nur eine "Unterbrechung" und kein "Teminator", der jede
> aktuelle Tätigkeit abbricht. Nach einer "Unterbrechung" arbeitet der
> Prozessor dort weiter, wo er unterbrochen wurde.
stimmt, war wieder mein Gedankenfehler

> Arduino F. schrieb:
> Sie könnten auch bei jedem Druchlauf ganz regulär abgebrochen werden,
> wenn einfach die Schleifenbedingung nicht mehr zutrifft.

Jetzt hab ich es gefressen. Meine While-Schleife wertet das Flag nicht 
aus und verbleibt. Ich müsste also die Variable Modus in der ISR 
inkrementieren, denn die wertet die While-Schleife aus.

Richtig???

[Michael (oti)]

Falk B. schrieb:
> Harald K. schrieb:
>> Warum nur bereitet mir das ... Unbehagen?
>>
>> _delay_ms in einer ISR aufrufen? Warum nur?
>
> Weil der Taster prellt. HIER ist das OK, denn der Controller hat so oder
> so nix zu tu.

genauso sah ich das auch

[Arduino F. (Firma: Gast) (arduinof)]

Wenn das Programm sonst nichts zu tun hat, dann brauchts auch keinen 
Interrupt für einen Taster.
Polling wäre dann voll ausreichend.

[Michael (oti)]

Michael schrieb:
> Jetzt hab ich es gefressen. Meine While-Schleife wertet das Flag nicht
> aus und verbleibt. Ich müsste also die Variable Modus in der ISR
> inkrementieren, denn die wertet die While-Schleife aus.
>
> Richtig???


16:45 so ist es, nun geht alles, wie ich es wollte.
Thread kann geschlossen werden.

[Rolf (rolf22)]

Michael schrieb:

>> @Michael
>> Du scheinst die Vorstellung zu haben, mit einem Interrupt könne man
>> Schleifen verlassen. Nein, kann man nicht. Eine Schleife kann man nur
>> durch eine 'break'-Anweisung verlassen, oder dadurch, dass die
>> Schleifenbedingung nicht (mehr) erfüllt ist.
>
> Ja, die hatte ich, dass war zumindest beim Z80 so. Kannst Du mir auch
> erklären, warum das so ist???

Oh nein, das war nicht so. Und das war und ist todsicher bei keiner CPU 
so. Es ist eine Eigenschaft der Programmiersprache.

Übrigens hast du gesagt, du habest Z80 "in HEX-Code" programmiert. Da 
gibt es gar keine while-Schleifen und auch sonst keine Schleifen, die 
der Prozessor als solche erkennen kann.

[Michael (oti)]

Arduino F. schrieb:

> Dort werden alle Bits im PORTB Register invertiert/getoggelt
> Und damit ist der Pullup an PB2 auch aus.

Daraus folgt aber nicht, dass die IR-Routine nicht aufgerufen wird.

[Falk B. (falk)]

Michael schrieb:
> Jetzt hab ich es gefressen. Meine While-Schleife wertet das Flag nicht
> aus und verbleibt.

Ja

> Ich müsste also die Variable Modus in der ISR
> inkrementieren,

Nein. Du musst dein Software umstrukturieren.

Beitrag "Re: Interrupt ATtiny85 - Hilfe"

[Falk B. (falk)]

Arduino F. schrieb:
> Wenn das Programm sonst nichts zu tun hat, dann brauchts auch keinen
> Interrupt für einen Taster.

Doch, wenn man Strom sparen will und keinen extra Hauptschalter einbauen 
will.

[Arduino F. (Firma: Gast) (arduinof)]

Michael schrieb:
> Daraus folgt aber nicht, dass die IR-Routine nicht aufgerufen wird.

Habe ich auch nicht behauptet!

Das sind meien Aussagen dazu:
Arduino F. schrieb:
> 2. damit stirbt der Pullup ab, und danach ist nix mehr mit
> kontrolliertem "rising"

Arduino F. schrieb:
> Der Pullup wird auch abgeschaltet, und damit endet die kontrollierte ISR
> Aufruferei.
> Datt is now!

Da steht ausdrücklich nicht, dass keine rising ISR mehr kommen kann, 
sondern dass du und der Taster damit die Kontrolle über den Zeitpunkt 
verloren hast.

Natürlich kann ein floatender Pin jederzeit HIGH werden.

[Arduino F. (Firma: Gast) (arduinof)]

Falk B. schrieb:
> Doch, wenn man Strom sparen will

Das habe ich dem Code nirgendwo erkennen können.
Habe ich da was übersehen?

[Falk B. (falk)]

Arduino F. schrieb:
>> Doch, wenn man Strom sparen will
>
> Das habe ich dem Code nirgendwo erkennen können.
> Habe ich da was übersehen?

Ist auch nicht sichtbar, aber der OP bastelt an einer Taschenlampe.

[Arduino F. (Firma: Gast) (arduinof)]

Falk B. schrieb:
> Ist auch nicht sichtbar,
Aha, ja.....

[Michael (oti)]

Rolf schrieb:
> Übrigens hast du gesagt, du habest Z80 "in HEX-Code" programmiert. Da
> gibt es gar keine while-Schleifen und auch sonst keine Schleifen, die
> der Prozessor als solche erkennen kann.

richtig, die mussten selbst gebaut werden. Denn einen Assembler 
geschweige denn eine IDE mit einer höheren Progranmmiersprache hatte ich 
nicht.

[Michael (oti)]

Arduino F. schrieb:
> Da steht ausdrücklich nicht, dass keine rising ISR mehr kommen kann,
> sondern dass du und der Taster damit die Kontrolle über den Zeitpunkt
> verloren hast.
>
> Natürlich kann ein floatender Pin jederzeit HIGH werden.

Dann sind wir uns ja einig, dass die ISR-Routine funktioniert, wie 
behauptet hatte, dass es prinzipiell io ist.

[Michael (oti)]

Falk B. schrieb:
> Arduino F. schrieb:
>> Wenn das Programm sonst nichts zu tun hat, dann brauchts auch keinen
>> Interrupt für einen Taster.
>
> Doch, wenn man Strom sparen will und keinen extra Hauptschalter einbauen
> will.

so ist es gedacht.

[Michael (oti)]

Falk B. schrieb:
> Michael schrieb:
>> Jetzt hab ich es gefressen. Meine While-Schleife wertet das Flag nicht
>> aus und verbleibt.
>
> Ja
>
>> Ich müsste also die Variable Modus in der ISR
>> inkrementieren,
>
> Nein. Du musst dein Software umstrukturieren.
>
> Beitrag "Re: Interrupt ATtiny85 - Hilfe"

Ja, das wars. In der IR-Routine die Variable noch inkrementiert und 
schon geht alles. Ebenso wie die case-Variante als auch die if Variante.

 Lothar M. (Firma: Titel) (lkmiller) (Moderator) hat mir auf die Sprünge 
geholfen.

[Arduino F. (Firma: Gast) (arduinof)]

Michael schrieb:
> Dann sind wir uns ja einig, dass die ISR-Routine funktioniert, wie
> behauptet hatte, dass es prinzipiell io ist.

Wenn der Kontrollverlust für dich OK ist, wenn du das so beabsichtigt 
hast, dann ja.

[Steve van de Grens (roehrmond)]

Was das  Unterbrechen der while Schleife angeht, habt ihr die Frage von 
Michael offenbar missverstanden. Ich zitiere nochmal den relevanten 
Code:

ISR(INT0_vect) {
  Button_event=true;
  ...
}

int main(void) {
  ...                           
  while (1) {

      if (Button_event==true) {
        Button_event=false;
        Light_mode++;
      }

      ...

      while (Light_mode==0) {
         ...
      }

      while (Light_mode==1){
         ...
      }

      while (Light_mode==2) {
         ...
      }

      while (Light_mode==3)  {
         ...
      }   
    }
}

Mit ungewollten "Endlosschleifen" meinte Rolf die inneren while 
Schleifen für die vier Licht-Modi.

Michael ist der Meinung, dass die Schleifen nur solange laufen, wie der 
jeweilige Licht-Modus gewählt ist. Sobald man den Licht-Modus ändert, 
wird die gerade laufende while Schleife verlassen und die nächste while 
Schleife für den nächsten Licht-Modus ausgeführt. Zumindest was das sein 
Plan.

Der Knackpunt ist, dass jedoch nichts den Licht-Modus ändert, während 
eine der vier inneren Schleifen läuft. Zwar gibt es eine ISR, die auf 
Tastendruck reagiert. Diese ändert aber nur die Variable Button_event 
und nicht Light_mode.

Wenn die ISR den Light_mode ändern würde, dann würde es wie gewünscht 
funktionieren. Etwa so:

ISR(INT0_vect) {
  Light_mode++;
  ...
}

int main(void) {
  ...                           
  while (1) {
      while (Light_mode==0) {
         ...
      }

      while (Light_mode==1){
         ...
      }

      while (Light_mode==2) {
         ...
      }

      while (Light_mode==3)  {
         ...
      }   
    }
}

Die Variable, die innerhalb der ISR geändert wird und außerhalb der ISR 
gelesen wird sollte volatile sein. Ansonsten kann es passieren, dass der 
vom Compiler erzeugte Code die Variable in einem Register cached und 
dann Änderungen im RAM durch die ISR gar nicht mit bekommt:

ISR(INT0_vect) {
  Light_mode++;
  ...
}

int main(void) {
  ...        

  R5 = Light_mode                   
  while (1) {
      while (R5==0) {
         ...
      }

      while (R5==1){
         ...
      }

      while (R5==2) {
         ...
      }

      while (R5==3)  {
         ...
      }   
    }
}

Der Compiler macht das, weil Zugriffe auf Register schneller sind, als 
Zugriffe auf RAM. Leider ist der Compiler so "dumm", nicht zu 
berücksichtigen, dass Light_mode verändert wird während main() läuft. Er 
liest die Speicherzelle nur einmal und benutzt dann wiederholt das 
schnellere Register R5.

Volatile ist eine einfache Holzhammer Methode, den Compiler dazu zu 
zwingen, jeden schreib- und Lesezugriff sofort im RAM auszuführen. Also 
nicht in einem Register zu cachen.

Die Registernummer sei hier nur ein Beispiel. Der Compiler kann dafür 
jedes beliebige freie Register verwenden. Man sieht das ggf. im 
Assembler-Listing.

[Peter D. (peda)]

Harald K. schrieb:
> Warum nur bereitet mir das ... Unbehagen?
>
> _delay_ms in einer ISR aufrufen? Warum nur?

Weil der Kommentar falsch ist.
Delay war noch nie eine gut funktionierende Entprellung und wird es auch 
nie sein.

[Steve van de Grens (roehrmond)]

Peter D. schrieb:
> Delay war noch nie eine gut funktionierende Entprellung
> und wird es auch nie sein.

Das wird der Michael schon noch merken, wenn seine Projekte komplexer 
werden. Genehmigt ihm die Zeit zum lernen, die er braucht.

[Peter D. (peda)]

Michael schrieb:
> Ja, die hatte ich, dass war zumindest beim Z80 so. Kannst Du mir auch
> erklären, warum das so ist???

Das bezweifle ich mal stark, daß Interrupts beim Z80 das blanke Chaos 
hinterlassen.
Im Gegenteil, die CPU sichert den Status soweit, daß sich Seiteneffekte 
auf die unterbrochenen Programmteile vollständig vermeiden lassen. Dazu 
wurden auch PUSH/POP implementiert, damit keine Register zerstört 
werden.
Nach einem Interrupt wird also genau da weiter gemacht, wo die 
Unterbrechung erfolgte.

In C kann man jedoch mit setjmp/longjmp einen Abbruch erzwingen. Aus 
guten Grund sind das aber mit Abstand die am seltensten benutzten 
Funktionen, da man genau wissen muß, was man tut.

[Rolf (rolf22)]

Steve van de Grens schrieb:
> Leider ist der Compiler so "dumm", nicht zu
> berücksichtigen, dass Light_mode verändert wird während main() läuft.

Das ist nicht "leider dumm", sondern das Konzept von C/C++: Möglichst 
effizient sein.

Solche Veränderungen können ja auch in einer anderen Quelldatei 
vorkommen. Um das sicher zu erkennen, müsste der Compiler grundsätzlich 
immer die Inhalte aller Quelltexte beachten. Das wäre aufwendig und 
würde trotzdem nicht immer gut funktionieren, weil der Compiler die 
zeitlichen Abläufe nicht erkennen kann und deswegen auf Verdacht zu 
vorsichtig sein müsste. Das Compilieren würde also unnötig langsam, und 
das Compilat würde unnötig ineffektiv.

Außerdem kann der Compiler nur Quelltexte beachten, die er kennt. Die 
von vorübersetzten Libs (womöglich in anderen Sprachen) kennt er aber u. 
U. gar nicht.

[Rolf (rolf22)]

Falk B. schrieb:

>> Wenn das Programm sonst nichts zu tun hat, dann brauchts auch keinen
>> Interrupt für einen Taster.

> Doch, wenn man Strom sparen will und keinen extra Hauptschalter einbauen
> will.

Dann würde ich in diesem Fall zwar einen Interrupt auf den Taster 
setzen, aber die Interrupt-Routine leer lassen und alles in der 
Hauptschleife machen:

set_sleep_mode(SLEEP_MODE_PWR_DOWN);
while(true) { sei(); sleep_cpu(); doAll(); }
Wäre einfacher/übersichtlicher und kürzer.