Teensy 3.2 +++ Interrupt, Übergabeparameter

[Mxt]

Wenn es nur um ein einfaches Beispiel zur Tastenentprellung geht, ist das beim Teensy schon dabei, wenn man die mitgelieferten Libraries mit installiert hat.

Die Bounce2 Library
https://github.com/thomasfredericks/Bounce2
macht so was, auf drei verschiedene Arten. Bounce2 und Vorgänger Bounce sind in Teensyduino enthalten, den Quelltext kann man sich ansehen, der ist nicht groß und arbeitet ohne Interrupts.

30 ms in einer ISR sind für einen so schnellen Controller viel zu lang, das Sperren der Interrupts bringt natürlich alles durcheinander (USB, Serial, millis) usw.

[Klebwax]

Die Bounce2 Library
https://github.com/thomasfredericks/Bounce2
macht so was, auf drei verschiedene Arten. Bounce2 und Vorgänger Bounce sind in Teensyduino enthalten, den Quelltext kann man sich ansehen, der ist nicht groß und arbeitet ohne Interrupts.

30 ms in einer ISR sind für einen so schnellen Controller viel zu lang, das Sperren der Interrupts bringt natürlich alles durcheinander (USB, Serial, millis) usw.

Die von dir gezeigte Library und der Code von HaWe haben ein gemeinsames Problem: sie erwarten, daß loop() nicht länger als einige Millisekunden läuft. Dauert da eine Berechnung mal etwas länger, können kurze und lange Tastendrücke nicht mehr unterschieden werden oder gehen ganz verloren. Für ne Demo mag das passen, in einer nutzbaren Anwendung ist das aber unbrauchbar.

void loop() {
   debouncer.update(); // Update the Bounce instance
   if ( debouncer.fell() ) {  // Call code if button transitions from HIGH to LOW
     ledState = !ledState; // Toggle LED state
     digitalWrite(LED_PIN,ledState); // Apply new LED state
   }
}

In jedem loop() Durchlauf wird hier debouncer.update() aufgerufen, ist der Abstand großer als die Zeit, die die Taste gedrückt wird, wird sie nicht erkannt.

Normalerweise erledigt man das in einem Timerinterrupt, der so im einstelligen Millisekundenbereich kommt. Da können alle Tasten bzw. Eingänge entprellt werden und auch Drehencoder ausgewertet werden. In diesem wird dann z.B. der gezeigte oder ein ähnlicher Code abgearbeitet. Die Ergebnisse können dann aus loop() abgefragt werden, wenn der Code dort bereit ist, sie zu verarbeiten.

So ein Interrupt existiert beim Arduino, der kümmert sich da um die Millis (und lastet die CPU dabei sicher nicht aus). Leider habe ich bisher noch nichts gesehen, wie man eigenen Code in den vorhandenen Interrupt einbinden kann. Das einzige, was ich mal gesehen habe, war einen zweiten Timerinterrupt aufzusetzen, der dann parallel zum Millis-Interrupt läuft. Das ist natürlich suboptimal und für mich eine der großen Schwächen des Arduino.

Inka hat für seine Stepper am Anfang die AccelStepper Library eingesetzt. da heiß es in der Doku:

Poll the motor and step it if a step is due, implementing accelerations and decelerations to acheive the target position. You must call this as frequently as possible, but at least once per minimum step time interval, preferably in your main loop.

Der Code in loop() muß hier kürzer als die Zeit für eine Schritt sein. Da ist bei Mikroschritten eigentlich gar nichts mehr in loop() möglich. Auch der Aufruf der Stepper-Lib gehört in einen (den) Timerinterrupt.

MfG Klebwax

[Mxt]

Die von dir gezeigte Library und der Code von HaWe haben ein gemeinsames Problem:

Das ist im Prinzip richtig, aber zumindest im Falle meiner Antwort didaktisch so gewollt. Ich denke der Fragesteller sollte erstmal dazu gebracht werden, seinen Code so hinzukriegen, dass er nicht blockierend wartet. Das geht am besten in der Loop.

Dieser Thread ist ja offensichtlich in einem gewissen Bezug zu dem hier
https://www.roboternetz.de/community...ttimer-via-RTC
Ich bin mir nicht sicher, ob der Fragesteller schon so weit ist, mit der IntervalTimer Library zu arbeiten. Er würde sicher auch wieder versuchen, die Timer ISR für 30 ms zu blockiern.

Auf das ganze "Arduino ist ungeeignet" und "habe ich nicht gesehen" gehe ich gar nicht weiter ein. In der Frage geht es um einen Teensy 3.2. Die Doku für die Interval Library ist hier
https://www.pjrc.com/teensy/td_timin...rvalTimer.html

Ja, es gäbe Alternativen z.B. mit den FTM, PDB oder LPTMR Timern. Nein, den Systick, der millis zählt, würde ich eher nicht erweitern.

[HaWe]

ich habe für single-thread Programme bisher keine loops, die länger als 20ms gedauert haben (was schon sehr viel ist für schnelle MCUs wie esp8266/32, Arduino Due, SAMD51), und wenn einzelne Funktionen in Einzelfällen in speziellen Programmen viel Zeit brauchen, verwende ich den ESP32 oder den Due mit multithreading, die sind mit dem Teensy vergleichbar - dann lauft die btn lib in einem eigenen thread sehr schnell durch und die zeitintensive Funktion tut es auch ungestört in einem eigenen Thread.
Alles also kein Problem, aber @Klebwax: du kannst sicher gerne deinen eigenen kompilierbaren Code hier posten, er muss nur eben auch für den Teensy funktionieren (edit: und ntl passend für Arduino IDE und API, die für den Teensy verwendet werden).
Für den Teensy andererseits gibt es eine eigene MT lib (falls die Teensy-Entprell-Lib nicht ausreicht): TeensyThread, doch ob das für den OP wirklch ein Zeit-Problem ist, wird er selber erstmal testen und dann mitteilen müssen.
Das einfachste wäre IMO aber als erster Schritt eine einfache Statemachine, die einfach mindestens 30ms wartet.

[Mxt]

Für den Teensy andererseits gibt es eine eigene MT lib (falls die Teensy-Entprell-Lib nicht ausreicht): TeensyThread, doch ob das für den OP wirklch ein Zeit-Problem ist, wird er selber erstmal testen und dann mitteilen müssen.
Das einfachste wäre IMO aber als erster Schritt eine einfache Statemachine, die einfach mindestens 30ms wartet.

Ja, das sehe ich auch so.

Wichtig ist es noch zu wissen: Auf einem ARM haben Interrupts Prioritäten und können sich teilweise gegenseitig unterbrechen. Nur so ist es auch möglich, die vielen Hardwarekomponenten des Chips quasi parallel zu benutzen. Ein Interrupt sollte also nur wie ein kurzes Augenzwinkern sein, nur die allernötigsten Dinge tun. Niemals aktiv warten und erst recht nicht während des Wartens alle anderen Interrupts sperren. Damit legt man nur Sachen lahm, die man wahrscheinlich als nächstes gebraucht hätte.

Im Prinzip ist es schon richtig, dass die Zeit in der Loop nur das ist "was übrig bleibt". Aber, wie HaWe schon sagte, ist das bei einem schnellen Controller sehr viel. Außerdem ist die Arbeit mit der loop nun mal der "Arduino Way" und die Programme bleiben portabel zu anderen Typen. Außerdem bekommt man bei loop Programmen besser ein Gefühl für die vorhandene Rechenleistung. Wenn man alles in Timer Interrupts packt, sieht man das nicht so gut.

Wenn man später feststellt, dass manche Dinge in der Loop nicht so gut aufgehoben sind, kan man im nächsten Schritt zu einem Timer oder ggf. DMA greifen.

[Klebwax]

Im Prinzip ist es schon richtig, dass die Zeit in der Loop nur das ist "was übrig bleibt". Aber, wie HaWe schon sagte, ist das bei einem schnellen Controller sehr viel.

Nun, alle Embeded-Programme haben die "Mainloop". Wenn man aber das Timing fürs Tastenentprellen oder die Mikroschritte in die Mainloop zieht, sind brauchbare Systeme kaum möglich. Ich versuche mir gerade vorzustellen, wie ich einen G-Code Interpreter aufbaue, der immer kürzer als ein Mikroschritt des Steppers läuft. Ansonsten würde der Motor schon bei der Ansteuerung Schritte verlieren. Man kann natürlich immer einen schnelleren Prozessor nehmen muß sich aber fragen, warum es andere mit einem langsameren auch schaffen.

Die Arm sind schon mächtig, in einem Hoverboard steuert einer das Timing von 2 BLDC und das Balancieren, aber sicher nicht mit einem Arduino Framework.

Außerdem ist die Arbeit mit der loop nun mal der "Arduino Way" und die Programme bleiben portabel zu anderen Typen. Außerdem bekommt man bei loop Programmen besser ein Gefühl für die vorhandene Rechenleistung. Wenn man alles in Timer Interrupts packt, sieht man das nicht so gut.

Richtig, ein System, programmieren zu lernen und die Komplexität von Interrupten und Dingen wie DMA vor dem Anwender zu kapseln. Zum Üben, wie man etwas macht ohne die CPU mit delays zu blockieren mag das angehen.

Ich versuche meine Systeme so aufzubauen, daß die Mainloop möglichst leer ist. Eigentlich will ich da nur ein sleep() sehen. Der ganze Rest läuft in Interrupt Handlern. Nested Interrupts können einem dabei helfen, es geht häufig aber auch so. Bei alten 386 SBCs konnte man das direkt fühlen. Wenn der im DOS-Prompt stand, wurde die CPU richtig heiß, stand er im Linux-Prompt blieb sie kalt. Da war wohl ein sleep() in der Mainloop.

MfG Klebwax

[HaWe]

Klebwax,
du bist hier im Arduino Forum, da arbeitet man mit der Arduino IDE und Arduino APIs, aber nichtsdestotrotz mit völlig legalem C++, das man sogar auf Raspberry Pis zum Laufen bekommt. Und dabei sogar zusätzlich MT mit pthread, std::thread oder teensyThread zur Verügung stellt.
Wenn du also hier Lösungen vorschlägst, dann ist es wschl für den OP wenig zweckdienlich, soweit du hier die gesamte Teensy-Arduino-Programmierbasis schlechtredest und dann noch nicht einmal einen konstruktiven compilierbaren Gegenvorschlag als Alternative für das Problem des OPs anbietest:
Das ist eine ziemlich billige Miesmachertour, wie schon öfters.