Tasterabfrage per Interrupt

[J. K. (jk-med)]

Hallo Forum,

ich habe eine Frage zum Thema Tasterabfrage während der Laufzeit in der 
Endlosschleife.
Dazu habe ich an einen Interrupt gedacht, der ausgelöst wird, wenn einer 
der unterschiedlichen Taster betätigt wird.

Ziel:
Wird ein an den Input des Controllers angeschlossener Taster parallel 
mit dem Interrupt-Eingang des Controllers verbunden, wird eine 
Interrupt-Routine aufgerufen, die dann den Zustand der jeweiligen Inputs 
abfragt. Somit könnte doch innerhalb dieser Routine erkannt werden, 
welcher Taster gedrückt wurde.

Pseudocode:

ISR(INT0)
{
   if(PIN0 == HIGH)
   {  // mach etwas, was bei Taster-1 geschehen soll 
   }

  if(PIN1 == HIGH)
  { //mach was anderes, was bei Taster-2 geschehen soll
  }
}

Würde das so funktionieren?

Vielen Dank

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

J. K. schrieb:
> Würde das so funktionieren?
Taster prellen. Wenn es dumm läuft bekommst du viele Interrupts.

Ich programmiere Tasterabfragen und -entprellungen immer wie Peda in 
einer Timer-ISR.

[J. K. (jk-med)]

>Taster prellen.

Ok, das weiß ich. Aber ich meine ob man so innerhalb eines Interrupts 
theoretisch den jeweiligen Taster "abrufen" kann, der an einen der 
Eingänge angeschlossen ist...Die Entprellung müsste man dann 
entsprechend machen, wie du sagst.

[Peter D. (peda)]

Dein Schaltplan ist Nonsens. Du zeigst 3 Eingänge miteinander 
kurzgeschlossen.

Man kann an den Tasteneingängen die Pin-Change-Interrupts freigeben und 
damit den µC aus dem Stromsparen aufwachen lassen.
Das Entprellen und Auswerten macht man danach in bewährter Weise mittels 
Timerinterrupt.

[Obelix X. (obelix)]

Zum Thema Tasterabfrage gibt es zig Beiträge hier im Forum und im 
Internet. Was unterscheidet deine Frage von allen anderen. Es muss nicht 
alles 1000 mal durchgekaut werden.

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

J. K. schrieb:
> Aber ich meine ob man so innerhalb eines Interrupts theoretisch den
> jeweiligen Taster "abrufen" kann, der an einen der Eingänge
> angeschlossen ist
Theoretisch geht das.

> Die Entprellung müsste man dann entsprechend machen, wie du sagst.
Und weil man die dann sowieso "extra" noch mit einem Timer/Zähler/... 
machen muss, ist es sinnvoll das gleich im Timerinterrupt zu tun.

J. K. schrieb:
> ich habe eine Frage zum Thema Tasterabfrage während der Laufzeit in der
> Endlosschleife.
Warum fragst du die Taster dann nicht gleich genau dort in der 
Endlosschleife ab? So ein Taster ist ja ein kreuzlangsames Bauteil, auf 
den muss nicht mit einer Programmunterbrechung innerhalb von Bruchteilen 
von µs reagiert werden.

Obelix X. schrieb:
> Zum Thema Tasterabfrage gibt es zig Beiträge hier im Forum und im Internet.
In der Tat:
- https://www.google.com/search?q=taster+entprellen+peda

[Adam P. (adamap)]

J. K. schrieb:
> Würde das so funktionieren?

Kannst ja mal hier lesen
https://developerhelp.microchip.com/xwiki/bin/view/products/mcu-mpu/8-bit-avr/getting-started/8-bit-avr-pin-change-interrupts/

und dann weiter nach "Pin-Change-Interrupts" googeln, so wie Peter es 
schon sagte.

[Andras H. (andras_h)]

J. K. schrieb:
> Würde das so funktionieren?

Nein. Man kann den uC durch den Interrupt praktisch larmlegen. Tasten 
prellen, dann hast du da auch unmengen an interrupt.

Mach doch taster pollen. Das muss reichen.

[Bauform B. (bauformb)]

Es geht sehr gut, man kann sogar noch einen Pin sparen. Man spendiert 
pro Taster einen Interrupt-Eingang und macht die Entprellung in Hardware 
mit einem RS-Flip-Flop. Dann braucht man nur noch Taster mit 
Umschaltkontakt.

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

Bauform B. schrieb:
> Man spendiert pro Taster einen Interrupt-Eingang und macht die
> Entprellung in Hardware mit einem RS-Flip-Flop.
Jetzt wirds langsam, naja, sagen wir mal "krude".

Warum nicht gleich einen Coprozessor pro Taster, der die Entprellung und 
die Entstörung erledigt, die Anzahl der Tastendrücke mitzählt sowie 
irgendwelche Repeatfunktionen beinhaltet und den man per Ethernet 
auslesen kann?

[Axel S. (a-za-z0-9)]

Lothar M. schrieb:
> ... und den man per Ethernet auslesen kann?

Bluetooth! Sheldon Cooper sagt: alles ist besser mit Bluetooth!

[Harald K. (kirnbichler)]

Lothar M. schrieb:
> und den man per Ethernet auslesen kann?

Das ist unter der Latte durchgesprungen. Wenn schon Programmieren im 
Jahr 2025, dann mindestens mit irgendeinem Cloud-Service, bei dem man 
via MQTT/Thread/suchdireinanderestollesprotokollaus die Tasten abfragen 
kann.

Und eine auf AWS laufende KI-Anwendung übernimmt das Entprellen, die 
kann sich dann auch an das Alterungsverhalten der Taster anpassen, durch 
ML.

[Thomas S. (Firma: Chipwerkstatt) (tom_63)]

Andras H. schrieb:
> Nein. Man kann den uC durch den Interrupt praktisch larmlegen. Tasten
> prellen, dann hast du da auch unmengen an interrupt.
>
> Mach doch taster pollen. Das muss reichen.

Ein kleines C mit ca. 47nF über den Kontakt, bzw nach Gnd, und gut ist 
es.

Pollen wäre auch mein Weg. In der der Routine kann man ja festlegen, 
dass der Kontakt mindestens 50 ms anliegen mus um 'gültig' zu sein. In 
Verbindung mit dem kleinen C ist das perfekt.

[Rainer W. (rawi)]

Lothar M. schrieb:
>> Die Entprellung müsste man dann entsprechend machen, wie du sagst.
> Und weil man die dann sowieso "extra" noch mit einem Timer/Zähler/...
> machen muss, ist es sinnvoll das gleich im Timerinterrupt zu tun.

Es gibt Anwendungen, wo der Prozessor schläft und kein regelmäßiger 
Timerinterrupt aufläuft. Dann wird der Prozessor erst durch den 
Tastendruck geweckt.

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

Das ist hier offenbar nicht der Fall.

[Dieter W. (dds5)]

Thomas S. schrieb:
> Ein kleines C mit ca. 47nF über den Kontakt, bzw nach Gnd, und gut ist
> es.

Dann aber bitte einen Widerstand in Reihe zum Taster sonst ruiniert der 
beim Schließen entstehende Funke den Kontakt.

[Rolf M. (rmagnus)]

Rainer W. schrieb:
> Es gibt Anwendungen, wo der Prozessor schläft und kein regelmäßiger
> Timerinterrupt aufläuft. Dann wird der Prozessor erst durch den
> Tastendruck geweckt.

Da nutzt man den Interrupt aber nur zum Aufwecken und schaltet ihn dann 
gleich wieder ab.

[Marci W. (marci_w)]

Dieter W. schrieb:
> Thomas S. schrieb:
>> Ein kleines C mit ca. 47nF über den Kontakt, bzw nach Gnd, und gut ist
>> es.
>
> Dann aber bitte einen Widerstand in Reihe zum Taster sonst ruiniert der
> beim Schließen entstehende Funke den Kontakt.

Full ACK! Dieses Schaltungsdetail, bei dem ein Taster einen Kondensator 
kurzschließt oder ohne R auflädt, habe ich schon 100te Male gesehen. Ich 
würde das auch nicht so machen.

ciao

Marci

[Peter D. (peda)]

Marci W. schrieb:
> Full ACK! Dieses Schaltungsdetail, bei dem ein Taster einen Kondensator
> kurzschließt oder ohne R auflädt, habe ich schon 100te Male gesehen. Ich
> würde das auch nicht so machen.

Berühmt dafür wurde das Pollin-Board. Da erzeugt der Tastendruck einen 
schönen Einbruch der VCC:

Beitrag "Pollin AVR Board Fehler beim drücken der Taster / Qualität der Bauteile"

[Bruno V. (bruno_v)]

J. K. schrieb:
> Die Entprellung müsste man dann
> entsprechend machen, wie du sagst.

Das Problem: Dann kann man es auch direkt nur so machen, ist deutlich 
einfacher. Eventbasierte Systeme haben den Nachteil, dass "nur" bei 
Events die Rechenleistung hoch geht, so dass Fehler schwer zu finden 
sind.

Es gibt 2 Sonderfälle

a) Aufwachen aus Sleep --> ja, dafür ist ein Interrupt gut. Ggf. mehrere 
Taster über Dioden (oder Gatter) auf einen Int-Pin geben. Aber nur zum 
Starten, nicht um im Interrupt auszuwerten.

B) Ein-Ausschalten des Gerätes --> Da gibt es Schaltungen, wo mit einer 
(oder mehreren) Tasten ein Fet geschaltet wird (oft über einen 
speziellen FET-Treiber) der das Gerät erst einschaltet.

Das einfachste Entprellen ist übrigens, den Taster nur alle ~60-100ms 
auszulesen. Schnelle Tastendrücke (5/s) sind dann zwar nicht mehr 
möglich, aber das stört am Anfang nicht. Du kannst es einfach später 
besser machen, wenn das, was Du eigentlich machen möchtest, rund läuft.

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

Bruno V. schrieb:
> B) Ein-Ausschalten des Gerätes --> Da gibt es Schaltungen, wo mit einer
> (oder mehreren) Tasten ein Fet geschaltet wird (oft über einen
> speziellen FET-Treiber) der das Gerät erst einschaltet.
Gerade da ist ein Entprellen nicht nötig, weil so eine Schaltung 
üblicherweise erst dann in Selbsthaltung geht, wenn der µC angelaufen 
ist.

> Das einfachste Entprellen ist übrigens, den Taster nur alle ~60-100ms
> auszulesen.
Das "seltene" Abfragen allein hilft aber nicht gegen Störungen. Denn 
wenn grade mal zum Einlesezeitpunkt irgendwie eine Störung drauffunkt, 
dann wird prompt ein Tastendruck erkannt.

Die sicherste Art (und das sollte eigentlich das Ziel bei der 
SW-Entwicklung sein) des Entprellens samt Störungsunterdrückung ist also 
das mehrfache Einlesen des Tasters mit ein paar ms Abstand und erst dann 
den Tastendruck als "gültig" anzusehen, wenn der Pegel mehrere Abfragen 
nacheinander stabil auf "betätigt" ist.

[Teo D. (teoderix)]

Bruno V. schrieb:
> Das einfachste Entprellen ist übrigens, den Taster nur alle ~60-100ms

Das is aber schon ziemlich lang.
Kürzer "warten" 10-20ms und ab da mehrfach (3-5x) bestätigen lassen, 
bzw. einen stabilen Zustand erfassen. Da is man dann so bei knapp 30ms 
und da merkt eh keiner mehr, wenn da ein Tastendruck fehlgeht.
Wenn's dann noch hapert, würde ich mir mal "Sorgen" um den min. Strom 
machen.

[Axel S. (a-za-z0-9)]

Bruno V. schrieb:
> Das einfachste Entprellen ist übrigens, den Taster nur alle ~60-100ms
> auszulesen.

Nein. Das ist gar kein Entprellen. Denn wenn die Störung genau dann 
passiert, wenn man abfragt, wird es trotzdem Murks. Eine zuverlässige 
Entprellung in Software geht so, daß man den Taster mehrfach abfragt und 
erst dann "gedrückt" signalisiert, wenn der Zustand zwei oder mehrere 
Male gleich war.

Mit Abtastfrequenz und der Anzahl der geforderten gleichen Zustände kann 
man dabei spielen. Wenn Anzahl × Abtastintervall > Prellzeit ist, dann 
passt es.

[Cyblord -. (cyblord)]

Thomas S. schrieb:

> Ein kleines C mit ca. 47nF über den Kontakt, bzw nach Gnd, und gut ist
> es.

Unvermögen bei der Programmierung KANN man natürlich durch zusätzliche 
Hardware ausgleichen.
Versteht man aber sein SW Handwerk, kommt man ganz ohne Kondensator aus.

[Mi N. (msx)]

Lothar M. schrieb:
> Warum nicht gleich einen Coprozessor pro Taster, der die Entprellung und
> die Entstörung erledigt,

Richtig!
Der MC14490 hat sich seit Jahrzehnten bewährt und vegan.

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

Oder gleich der MAX6816/6818:
- http://www.lothar-miller.de/s9y/categories/5-Entprellung

Das kann man aber eben mit ein wenig Nachdenken auch ganz einfach in 
Software abbilden.

[Michael B. (laberkopp)]

J. K. schrieb:
> Würde das so funktionieren?

Nein.

Wenn egal welcher Taster gedrückt wird, werden alle 3 miteinander 
verbundenen Eingänge auf high gezogen.

Ausserdem gibt es niemanden der die Eingänge auf low zieht, dein 
Widerstand ist falsch.

Man kann die Taster mit (z.B. 1N4148) Dioden voneinander entkoppeln 
bevor man sie auf den Interrupteingang legt

    +5V             +5V
     |               |
  Taster1  InInt  Taster2
     |       |       |
In1--+--|>|--+--|<|--+--In2
     |       |       |
     R       R       R
     |       |       |
    GND     GND     GND

aber du musst einen uralten uC benutzen wenn der nicht auch bei In1 und 
In2 Interrupts auf PinChange auslösen kann.

Doch wie geschildert prellen Taster und lösen teils hunderte von 
Interrupts aus beim Drücken, manche nur Mikrosekunden lang.

Selbst wenn nach dem ersten Interrupt der uC innerhalb der 
Interruptroutine erstmal nicht auf weitere Interrupts reagiert weil 
gesperrt, und selbst wenn man innerhalb der Interruptroutine den Eingang 
für weitere 5ms sperren würde (was deine Programmierfähigkeiten 
wahrscheinlich übersteigt), gibt es eben das Problem das bei Abfrage auf 
PIN0 oder PIN1 in sagen wir 5 Mikrosekunden nach dem Interruptbeginn der 
Eingang schon wieder low ist.

Man könnte den Taster in Hardware entprellen mit zusätzlichem 
Kondensator und Widerstand, braucht aber weil man ihn ja auf 2 Eingänge 
verteilt noch extern Schmitt-Trigger wie 74LV2G14.

 VCC
  |
Taster
  |        74HC14/CD40106 
  +-100k-+--|>o-- low wenn Taster gedrückt
  |      |
 4k7   100nF
  |      |
 GND    GND

Das ist ein unsinniger Aufwand, wo es doch so einfach in Software geht 
und sogar einen Pin und die ganze Hardware spart:

Starte einen Timer der alle 10ms einen Timerinterrupt auslöst und frage 
die Taster darin ab. Waren sie beim letzten Durchlauf nicht gedrückt und 
sind sie in diesem Durchlauf gedrückt wurden sie wohl gerade 
runtergedrückt. Das entsprellt auch gleich.

char taster1, taster2, taster1alt, taster2alt;
void timerinterrupt(void)
{
   taster1=PIN0;
   if(taster1&&!taster1alt) taster1gedrueckt();
   taster1alt=taster1;
   taster2=PIN1;
   if(taster2&&!taster2alt) taster2gedrueckt();
   taster2alt=taster2;
}

Axel S. schrieb:
> Bruno V. schrieb:
>> Das einfachste Entprellen ist übrigens, den Taster nur alle ~60-100ms
>> auszulesen.
>
> Nein. Das ist gar kein Entprellen

Bitte Axel, wenn man noch nie uC Tastenabfragen programmiert hat, sollte 
man hier nicht so einen Unsinn schreiben. Wobei 100ms störend langsam 
ist.

Lothar M. schrieb:
> Das "seltene" Abfragen allein hilft aber nicht gegen Störungen

Prellen sind keine Störungen, sondern da hat wirklich jemand den Finger 
auf dem Taster. Störungen streuen in lange Leitungen bei unzureichendem 
pull down Widerstand ein oder wenn die Stromversorgung des uC schlecht 
abgeblockt ist. Vor allen wenn der Schalter durch Analogtechnik mit 
Kondensator und Widerstand und womöglich ohne Schmitt-Trigger Eingang 
versucht wurde zu entprellen so dass Signale teils nah an 
Schaltschwellen liegen statt sauber digital sind. Da hat man also ein 
Hardwareproblem das mit Software nur unzureichend behandelbar ist.

[Cyblord -. (cyblord)]

Michael B. schrieb:
> Prellen sind keine Störungen, sondern da hat wirklich jemand den Finger
> auf dem Taster.

Prellen kann sein:
1.) Taster lange gedrückt oder auch
2.) Tasterkontakt öffnet und schließt sehr schnell hintereinander obwohl 
nur einmal gedrückt wird.

Und natürlich bekämpft man letzteres über die ZEIT. Man akzeptiert keine 
Tastflanken die mit weniger Zeitabstand als X ankommen. Ganz einfach.
Ersteres bekämpft man in dem man nur auf Flanken und nicht auf Zustände 
reagiert. Das sollte man immer so machen und dann ist 1. automatisch 
gelöst.

Und wenn wirklich ein Taster 100ms prellen sollte, ja dann kann man den 
nur sehr langsam bedienen. Liegt dann am Taster. Nicht am System des 
Entprellens. Aber das ist wohl eher unrealistisch.

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

Peter D. schrieb:
> Dein Schaltplan ist Nonsens.
Besonders auch, weil der Widerstand dort nur zum dauerhaften Heizen über 
die 5V Versorgung dient und nicht als Pulldown. Der µC dort müsste also 
schaltbare Pulldowns haben, damit das überhaupt funktioniert. Das können 
nur wenige µC.

Michael B. schrieb:
> Lothar M. schrieb:
>> Das "seltene" Abfragen allein hilft aber nicht gegen Störungen
> Prellen sind keine Störungen
Ganz meine Worte. Allerdings kann es zusätzlich zum Prellen eben auch 
noch eingekoppelte Störungen geben.

> Störungen streuen in lange Leitungen bei unzureichendem pull down
> Widerstand ein
So ist es. Und ein Pullwiderstand im µC ist üblicherweise im Bereich um 
30k..50k. Das ist aus EMV-Sicht viel zu hochohmig, 20cm Leitung bis zum 
Taster reichen da locker zum Einfangen von Störungen. Und wenn man durch 
eine brauchbare Entprellroutine solche Störungen auch gleich noch 
ausfiltern kann, dann ist das ein klassischer Win-Win.

Michael B. schrieb:
> Axel S. schrieb:
>> Bruno V. schrieb:
>>> Das einfachste Entprellen ist übrigens, den Taster nur alle ~60-100ms
>>> auszulesen.
>> Nein. Das ist gar kein Entprellen
> sollte man hier nicht so einen Unsinn schreiben.
Axel hat Recht, denn natürlich hat keine einzelne Abfrage (und sei sie 
noch so verzögert) irgendeine Wirkung, die tatsächlich entprellt. Die 
gefühlte "Entprellfunktion" geschieht dabei nur durch die künstliche 
Verzögerung der Abfrage. Wenn in der Zwischenzeit der Taster wieder 
losgelassen und neu gedrückt wurde, wird kein erneuter Tastendruck 
erkannt.

Fazit: es gibt ganz viele Geräte mit schlechter Software, die mit (im 
Laufe der Lebensdauer zunehmend stärker/länger) prellenden Tastern nicht 
zurechtkommt. Und dabei wäre es doch ganz einfach, das gleich von vorn 
herein richtig zu machen.

[Bruno V. (bruno_v)]

Lothar M. schrieb:
> Axel hat Recht, denn natürlich hat keine einzelne Abfrage (und sei sie
> noch so verzögert) irgendeine Wirkung, die tatsächlich entprellt.

Doch. Prellen bedeutet mehrere Tastendrücke statt einem. Das ist 
ausgeschlossen, wenn die Prellzeit <= der Abtastzeit ist.


> Die gefühlte "Entprellfunktion" geschieht dabei nur durch die künstliche
> Verzögerung der Abfrage. Wenn in der Zwischenzeit der Taster wieder
> losgelassen und neu gedrückt wurde, wird kein erneuter Tastendruck
> erkannt.

Das habe ich nicht nur dabei geschrieben, sondern auch warum das egal 
ist:

Bruno V. schrieb:
> Schnelle Tastendrücke (5/s) sind dann zwar nicht mehr
> möglich, aber das stört am Anfang nicht. Du kannst es einfach später
> besser machen, wenn das, was Du eigentlich machen möchtest, rund läuft.

Dass ein Anfänger alles perfekt oder gar nicht machen soll, ist 
abschreckend.

[Peter D. (peda)]

Bruno V. schrieb:
> Dass ein Anfänger alles perfekt oder gar nicht machen soll, ist
> abschreckend.

Für den privaten Gebrauch oder als Lernschritt sind halbgare Lösungen 
voll o.k.
Leider sieht man in der Praxis aber auch haufenweise kommerzielle 
Bedienungen, die entweder von Ignoranten oder Anfängern programmiert 
wurden.
Taster schalten mehrfach oder verlieren Betätigungen, Drehgeber zählen 
wirr vor und zurück. Aber auch hohe elektrostatische Empfindlichkeit 
(übern Teppich schlurfen, Pullover ausziehen, Gerät in der Nähe 
einschalten) ist die Folge.