====== Prellen - Studie mittels Forth ======

Im Internet findest du viele Abhandlungen darüber. Als Einstieg dienten mir die folgenden Webseiten.

https://www.mikrocontroller.net/topic/201479\\
https://www.mikrocontroller.net/articles/Entprellung\\
https://praktische-elektronik.dr-k.de/Praktikum/Digital/Dynamik/Le-Entprellter-Taster-Reset.html\\
https://de.wikipedia.org/wiki/Prellen

===== Hilfsmittel für die Experimente =====

PC, LinuxMint. Digital Oscilloscop (XEAST XE-702S). Logic Analyzer (24Mhz 8CH [noname] Saleae Logic compatible) und PulsView (sigrok.org). Texas Instruments MSP430G2553 Launchpad und [[https://home.hccnet.nl/anij/nof/noforth.html|noForth]] bedient mit dem [[projects:e4thcom|e4thcom]] Terminal.

(Alle folgenden Abbildungen wurden vom Autor selbst erzeugt.) 

===== Prellen erzeugt auch hochfrequente Schwinungen =====

Hier geht es um sehr kleine Lasten und kurze Leitungen. Wie z.B. ein Taster direkt an einer MCU oder ein Bedienfeld aus mehreren Tastern oder ein Keyboard. Also Spannungen im 5V Bereich und Ströme um die 1mA. Dennoch hat das schon Leitungsinduktivität und -kapazitäten,  so etwa bei 1µH und 200pF bei 1m Kabellänge. Das gibt tatsächlich schon Schwingungen an der Umschaltflanke um 10MHz. Sowas zu wissen kann bei der Fehlersuche helfen.

{{:pfw:prellen-am-osci-hochfrequenz.jpg?400|Nach der fallende Flanke ist HF zwischen den Prellpegeln.}}



===== Prellen des logischen Pegels =====

Prellen tritt durch die Elastizität der Kontakte und die Federkraft auf. Typische Prellzeiten liegen im Bereich von 100 µs bis 10 ms (KI). Hier im Test waren zwei kleine Kippschalter, ein blauer und ein silbriger. 

{{:pfw:zweikleineschalter.jpg?100|Die alten Kippschalter}} 

<code>
Schaltung für den Test am Logicanalyser (L)

+VCC ---R---+---S_S---GND
            |
            L
</code>

{{:pfw:blauerschalteroff.png|Prellt ca. 200 µs.}}

{{:pfw:silberschalteroff.png|Prellt ca. 120 µs.}}


Die verschiedenen Schaltertypen hatten deutliche  Unterschiede beim öffnen und schließen der Schalter. Es waren alte Schalter, lagen seit über zehn Jahren in einer Schachtel. 

===== Folgen für die Software =====

In digitale Schaltungen und Programmen, die schnell genug sind um die Pegelwechsel zu erkennen,  führt das zu unerwünschten Ereignissen.
  * Bei einem Zähler könnte ein einzelner Tastendruck mehrere Zählschritte auslösen.
  * Bei einer Tastatur könnte ein einzelner Tastendruck als mehrere Drücke registriert werden.

==== Beispiele in Forth ====

Dieser [[pfw:prellstudieinforthquellcode|Forth Quellcode]] läd einige kleine Routinen in das Launchpad.((Du kannst die auch an andere MCUs anpassen.)) Im Folgenden steht was diese Routinen machen.((Ich gehe mal davon aus du weißt schon etwas von Forth und wie man damit interaktiv arbeitet.)) 

=== Pulse machen ===

''pulse ( n -- )'' erzeugt eine Pulsfolge damit abgschätzt werden kann wie schnell simpel programmiertes noForth ist. 
  
  hex
  outP16  10 pulse <ret>
  
Kann man so das Prellen "sehen"? Ja, man kann. noForth kann in der Prellzeit den Pin mehrfach abfragen. 

{{:pfw:pulsinnoforthhighlevel.png?400|Der Puls dauert nur 7 µs.}}

=== Portpin beobachten ===

''tt ( --- )'' fragt den Schalter kontinuierlich ab. Abbruch durch irgendeinen Tastendruck auf der Tastatur. In der Endlosschleife  mittelt ''t? ( -- x )'' aus 8 Abfragen den Pegel am Input-Pin. ''x=0'' wäre ein stetiges ''Low'', ''x=$400'' ein stetiges ''High''. Werte im Breich ''0<x<$400'' bedeuten: Prellen wurde erfasst. Die Abfrage ist schnell genug dafür.
  
Die Beobachtung zeigte, dass //jeder// Tastendruck ein Prellen verursacht.
Es lag immer ein Wert ''<$400'' vor, wenn die Taste gedrückt wurde,
und in der Regel auch beim Loslassen. Probiere selbst ...

=== Versuch, nur die Wechsel zu zeigen ===

''dtt ( --- )'' entprellt noch weiter und zeigt nur noch "beruhigte" Pegel an. Also Zonen in denen die gemittelte Portpin-Abfrage komplett H oder L gewesen ist. Eigentlich müsste dabei zwischen jedem Punkt nur 1x ein L und danach 1x ein H erscheinen. Also sowas: ''L.H.L.H.L.'' 

Doch es kommt das Folgende:
<code>
@)dtt 
LHL.H.LHL.H.LHL.H.LHL.H.LHL.H.LHL.H.LHL.H.L.H.LHL.H.LHL.H.LHL.H.L.H.LHL.H OK.0
@)
</code>

Man sieht, dass die Pegelwechel auch hierbei immer noch nicht ganz ohne Prellen sttfinden. Insbesondere bei den Wechseln von H -> L
wird beim Tastendruck immer noch ein zusätzlicher Wechsel erkannt. Die Routine ist also immer noch zu schnell und "erkennt" das Ende des Prellens nicht wirklich.
Ein Tastendruckzähler H->L würde daher meist falsch, d.h. doppelt zählen.
Von L -> H scheint es schon ohne Prellen zu funktionieren.

Das menschliche Auge kann einem Pegel auch nicht ansehen, ob der schon jenseits vom Prellen liegt. Dazu brauchen wir auch den Vergleich mit der zuvor verstrichenen Prellzeit. Erst wenn wir eine Phase sehen die 2x oder 3x so lang ganz ohne Pegelwechsel ist, wie das, was wir als "prellen" abschätzen, sind wir bereit anzunehmen, dass das Prellen nun wirklich vorbei ist.

Das gilt es in Software nachzubilden.

====== Entprellen ======


Entprellen mittels Hardware, wie RC-Glieder oder ein RS-Flip-Flop will ich hier nicht behandeln. Darüber findest du viel im Internet. Entprellen per Software kennt einige gängigen Methoden. 

===== Flanken-Interrupt =====

Schmitt-Trigger sind in den I/O-Ports einer MCU schon integriert, zumindest beim MSP430 war es so. [[en:pfw:clavis|CLAVIS?]] nutzt das ja bereits. Aber auch nach solch einer Abfrage braucht es noch Zeit bis eine erneute Pin-Abfrage erfolgen darf, will man nicht ins prellen hinein abfragen, wie im vorherigen Abschnitt klar geworden ist.

===== Getaktete Abfrage mit Zeitstempel am Zustand =====



(folgt)

===== Pegelwechsel mitzählen bis ein stabiler Zustand ereicht ist. =====


(folgt)

===== Methode "Schieberegister" =====

Beim ablesen des digitalen Inputs am Port wird der Bit-Wert in ein Register geschoben. Macht man 16x die Abfrage, gibt es entweder eine 0000 oder eine FFFF im Register, beides "gültige" Rückgabewerte. Oder es resultiert was dazwischen und ist dann die Ausnahme.

(folgt)