Teensy 3.2 +++ Interrupt, Übergabeparameter

[HaWe]

volatile alleine nutzt nur etwas, wenn die Variablen nicht weiterverarbeitet oder unbemerkt (z.B. bei multithreading) verändert werden könnten. Es wird nur verhindert, dass sie in Registern verbleiben (edit) oder vom Compiler herausoptimiert bleiben.

ansonsten:
static
oder
volatile static
 

wo ist
ISR_Uebergabe
definiert?

[frabe]

Vor void setup()

volatile int ISR_Uebergabe = 0;

Ohne static funktionierts einwandfrei - Zufall?

void loop() {
  digitalWrite(LEDgnPin, 1);
  digitalWrite(LEDrtPin, 0);
  __TP__(1);
  ISR_Uebergabe = 1;
  Pausen_ms(3000);
  
  digitalWrite(LEDgnPin, 0);
  digitalWrite(LEDrtPin, 1);
  __TP__(2);
  ISR_Uebergabe = 2;
  Pausen_ms(3000);

  digitalWrite(LEDgnPin, 1);
  digitalWrite(LEDrtPin, 1);
  __TP__(3);
  ISR_Uebergabe = 3;
  Pausen_ms(3000);
}

[HaWe]

also global?
dann ist es automatisch "static" und "volatile" brauchst du dann überhaupt nicht.

- - - Aktualisiert - - -
edit - Frage hat sich erübrigt
- dann allerdings verstehe ich deinen Code nicht, da muss jemand anderes 'ran

[frabe]

Derzeit wird nach Pin-Interrupt, innerhalb der ISR-Funktion "ISR_Taste1()" eine Tastenentprellungs-Funktion "Entprell(Pin)" aufgerufen.
Dauert ca.30ms.
Eine Var. mit 1 für Entprellt oder 0 für Fehlerhaft kommt zurück.
Die "ISR_Uebergabe" wird innerhalb des void loop() verändert

void ISR_Taster1() {  // Funktion wirdausggeführt, sobald ISR auslöst
  if(Entprell(TasterPin1 == 1) {
   if (ISR_Uebergabe == 1) {
     SummerTon();
   }
   if (ISR_Uebergabe == 2) {
     SummerTon();
     Pausen_ms(100);
     SummerTon();
    }
    if (ISR_Uebergabe == 3) {
      SummerTon();
      Pausen_ms(100);
      SummerTon();
      Pausen_ms(100);
     SummerTon();
   }
  }
}

Ich Frage mich, ob ich der ISR-Routine nicht zu viel zu mute.

[Rabenauge]

Mach das nicht.
Das geht ganz schnell schief.
Nimm dir irgendeine Variable, die innerhalb der ISR geändert wird- nichts weiter.
Alles andere (z.B. die Variable auswerten, dass sie erst ab dem 30. Mal zählt (Entprellung für Arme, einfach, reicht aber oft) mach ausserhalb.

Wenn du sicher gehen wllst, dann mach in der ISR folgendes:

-Interrupts deaktivieren
-tun, was zu tun ist
-Interrupts aktivieren

So stellst du sicher, dass innerhalb der ISR kein Interrupt ausgelöst wird- das nämlich ist das Problem mit ISR's.
Wenn dir sowas passiert, wird die ISR aufgerufen, während sie noch läuft...du kannst dir denken, wie _das_ endet.

[HaWe]

Nimm dir irgendeine Variable, die innerhalb der ISR geändert wird- nichts weiter.
Alles andere (z.B. die Variable auswerten, dass sie erst ab dem 30. Mal zählt (Entprellung für Arme, einfach, reicht aber oft) mach ausserhalb.

genau, und Variable, die innerhab einer ISR geändert werden, sollten wieder global deklariert werden und volatile sein.

[frabe]

-Interrupts deaktivieren
-tun, was zu tun ist
-Interrupts aktivieren

DANKE - toller Hinweis!
Genau darüber hatte ich mir auch schon Gedanken gemacht.
noInterrupts(), interrupts() ist die Lösung!

[Klebwax]

-Interrupts deaktivieren
-tun, was zu tun ist
-Interrupts aktivieren

Vorsicht, das geht in die Hose.

Von vorne mal angefangen. Das Deaktivieren des Interrupts am Anfang ist nicht das erste, was im Interrupthandler passiert. Da laufen noch ein Dutzend oder mehr Assemblerbefehle vorher ab, wie Status und Register retten. Wenn dort der Interrupt nicht automatisch gesperrt wäre, würde der Interrupt sofort wieder zuschlagen, da das Interruptflag noch nicht gelöscht ist. Der Interrupt muß also noch vor dem ersten Assemblerbefehl gesperrt werde, und das geht nur, wenn es automatisch passiert. Und so ist es auch. Beim Eintritt in den Interrupthandler ist mindestens dieser interrupt gesperrt. Den Interrupt im Handler zu deaktivieren ist zwar nicht unbedingt schädlich aber überflüssig und käme auch viel zu spät.

Das Aktivieren ist aber schlecht. Zwischen dem letzten C-Befehl und dem Ende der Funktion wird das, was am Anfang des Handlers gesichert wurde, wiederhergestellt. Das sind nochmal ein Dutzend oder mehr Befehle. Die laufen jetzt mit offenen Interrupts und das ist gefährlich. Erst ganz am Ende, wenn der Prozessor den Interruptkontext verlassen hat, dürfen die Interrupte wieder zugelassen werden. Daher endet ein Interrupthandler auch nicht mit einem Return (from Subroutine) sondern einem Return from Interrupt. Das heißt häufig RETI. Der stellt den Interrupstatus wieder so ein, wie er vor dem Interrupt war.

MfG Klebwax

[frabe]

Kann sein, aber wie macht man´s besser?

Zwischen
attachInterrupt(Taster01Pin, ISR_Taster1, RISING);
und

ISR_Taster1() {
  noInterrupts(); // alle Interrupts ausschalten
  Variable = Entprellung();  // volatile, ~30ms
  interrupts();  // alle Interrupts wieder einschalten
}

ist nicht mehr viel Platz.