Ich habe ein sehr einfaches Projekt, bei dem ich eine Taste (in Software) entprellen musste. Logischerweise ist mein Denkprozess:
Wenn der Zustand für eine Weile stabil war und sich ändert, dann signalisiere sofort ein Ereignis.
Stellen Sie sicher, dass der nächste Zustand stabil ist, bevor Sie eine weitere Zustandsänderung zulassen.
Wenn also eine Taste nicht gedrückt wird und schon eine Weile so war, aber plötzlich eine geänderte Eingabe lese, muss ich nicht warten, um zu bestätigen, dass die geänderte Eingabe stabil war (ich weiß dass eine tatsächliche physische Änderung des Tastenzustands stattgefunden hat). Ich kann ein Ereignis einfach signalisieren, aber neue Ereignisse für einen bestimmten Zeitraum nicht zulassen, um zu verhindern, dass falsche Tastensprünge Ereignisse signalisieren.
Hier ist Arduino-Code für eine Funktion getAction() auf diese Weise:
static int buttonBounceState = BUTTON_STATE_UP; // "Bouncing" state
static int buttonState = BUTTON_STATE_UP; // Debounced state
static unsigned long lastChangeMillis = 0; // Time of last state transition
unsigned long currentMillis;
buttonBounceState = digitalRead(BUTTON_PIN);
if (buttonBounceState != buttonState) {
// Only allow state change if it's been 20 millis since last
currentMillis = millis()
if (currentMillis >= lastChangeMillis + 20) {
buttonState = buttonBounceState; // Change state
lastChangeMillis = currentMillis; // Only update timings at state transition
// Button state has changed, so return an action
if (buttonState == BUTTON_STATE_DOWN) return ACT_PRESS;
else return ACT_RELEASE;
}
}
// No button state change. Return no action.
return ACT_NONE;
Es scheint jedoch, dass überall, wo ich hinschaue, die Art und Weise, wie das Entprellen durchgeführt wird, darin besteht, dass der anfängliche Zustandsübergang stabil werden muss, bevor tatsächlich eine Software-Zustandsänderung / Ereignissignalisierung durchgeführt wird. Zum Beispiel das untere Bild hier: https://www.baldengineer.com/arduino-de-bounce-a-button-with-micros.html
Meine Frage: Ist es besser, auf diese Weise zu entprellen? Gibt es etwas an meiner Methode, das fehlschlagen könnte, an das ich nicht denke – dh irgendeine Art von Geräusch, während der Knopf Stable-Open oder Stable-Closed ist? Wenn nicht, scheint meine Methode genauere Zeitangaben zu machen; und ich vermisse keine sehr schnellen Tastendrücke (aber verzögern, bis es stabil ist). Wie hängen diese beiden Softwaremethoden auch mit dem Hardware-Entprellen zusammen? Wie würde ein Hardware-Entpreller implementiert, der ähnliche Dinge wie meine Methode zeitlich festlegen kann?
Wenn Sie entprellen, indem Sie sofort reagieren und die Taste ausblenden (das Ignorieren nachfolgender Stufenänderungen für eine vorab festgelegte Zeit), ist der Vorteil eine geringe Latenz. Der Nachteil ist die Anfälligkeit für induziertes Rauschen, das einige Systeme verursachen oder beschädigen kann.
Die Leute reagieren nicht schnell genug, um eine Latenz von 10 ms zu bemerken, daher denke ich, dass es normalerweise am besten ist, zu entprellen, indem überprüft wird, ob eine Zustandsänderung einige ms lang stabil ist, bevor sie reagiert. Auf diese Weise können Sie unerwarteten Rauschproblemen vorbeugen.
Der Hauptgrund, warum ich manchmal mit „reagiere sofort und dann leer“ entprelle, ist, wenn ich etwas schnellen und schmutzigen Testcode schreibe, der letztendlich entfernt wird. Ich finde, dass es normalerweise einfacher und weniger invasiv ist, die Entprellung auf diese Weise zu codieren, sodass sie schneller geschrieben und leichter aus dem endgültigen Code entfernt werden kann.
Einige Hardware-Entpreller wie der MAX6816 verwenden fest verdrahtete Timer und Zähler. Insbesondere der MAX6816 wartet eine gewisse Zeit darauf, dass der Zustand stabil ist, bevor er ihn durchläuft.
Auf einem FPGA ist es auch in dem Sinne fest verdrahtet, dass Zeitgeber, Zähler und Abtastregister verwendet werden. Sie können es sofort reagieren lassen und dann leer sein oder warten, bis sich der Schalter stabilisiert hat, bevor Sie das Signal durchlassen.
JK-Flip-Flop-Entpreller wechseln sofort den Zustand und sind dann "leer". Ich habe Leerzeichen in Anführungszeichen gesetzt, weil sie kein Zeitintervall verwenden, um nachfolgende Änderungen zu ignorieren. Vielmehr beruht es auf etwas, das eher einer mechanischen Hysterese ähnelt. Es ändert sofort seinen Zustand, wenn und nur wenn ein positiver elektrischer Kontakt hergestellt wird. Es reagiert nicht, wenn lediglich der Kontakt verloren geht. Wenn also der Kontakt im Schalter verloren geht (z. B. aufgrund eines Prellens), aber kein neuer positiver Kontakt hergestellt wird, ändern sie ihren Zustand nicht. Der Schalter sollte niemals so stark abprallen können, dass er weit genug in die entgegengesetzte Richtung fliegt, um den anderen Kontakt zu treffen. Dies ähnelt der Energieeinsparung, bei der ein fallengelassener Ball niemals wieder auf die Höhe zurückprallen sollte, aus der er fallen gelassen wurde.
Es gibt auch andere Entprellmethoden wie die Verwendung von Tiefpassfiltern und Komparatoren, die sich darauf verlassen, dass der Schalter lange genug stabil ist, aber auch fälschlicherweise ausgelöst werden können, wenn der Schalter zu oft prellt und die Zeitkonstante so gewählt wird zu kurz, da sich der Kondensator weiterhin auflädt oder entlädt, wenn der Schalter bei jedem Aufprall Kontakt herstellt.
Es ist absolut nichts Falsches daran, "Leading Edge"-Entprellen zu machen, wie Sie es beschreiben - tatsächlich ist es die Methode, die ich in meinen eigenen Projekten bevorzuge.
Wie Sie sagen, wissen Sie, sobald Sie die erste Kante sehen, dass der Benutzer eine Aktion initiiert hat, also gibt es keinen Grund, die Aktion zu verzögern. Das System "fühlt" sich reaktionsschneller auf den Benutzer an.
Der einzige Grund für die Verwendung der "Hinterkanten" -Entprellung (die Art, die Sie gefunden haben) wäre, wenn es einen Grund (EMI, ESD usw.) gibt, dass ein Eingang fehlerhaft sein könnte, der nicht wirklich durch eine Benutzeraktion verursacht wird.
Es gibt keinen besseren Weg, da jeder Fall unterschiedliche Switches, unterschiedliche Umgebungen oder unterschiedliche Anforderungen haben kann. Ihre Lösung wird gut funktionieren, wenn aus irgendeinem Grund keine falschen Impulse auftreten. Ein Beispiel wäre eine normalerweise geschlossene Verbindung, aber unter mechanischen Vibrationen könnte sie sich öffnen und gelegentlich falsche Trigger verursachen, und das Reagieren auf jede Kante würde das Problem nur verstärken. Es ist ein empfindliches Gleichgewicht zwischen ausreichendem Entprellen, um unerwünschtes Rauschen fernzuhalten, und nicht zu viel Zeit zu verbringen, wie z.
Wenn Sie intensiv genug suchen, finden Sie viele komplizierte Systeme zum Entprellen.
Nur wenige von ihnen übertreffen die sehr einfachen, warten Sie einfach .
Ihr System hat eine Reaktionszeitanforderung, Sie müssen schneller arbeiten als oder auf Impulse reagieren, die kürzer als eine bestimmte Schwellenzeit sind . Der Just-Wait-Algorithmus fragt den Switch etwas schneller ab und ignoriert ihn zwischendurch völlig.
Wenn Ihr Switch tatsächlich länger als diese Zeit springt, ist Ihr Switch nicht gut genug, um Ihre Systemanforderungen zu erfüllen. Kein willkürlich kompliziertes Entprellschema kann einen kurzen Impuls, auf den das System reagieren sollte, von einem langen Prellen unterscheiden.
In der einfachsten Version fragen wir den Switch einfach alle ab . Es wird eine variable Latenz geben, die davon abhängt, wann genau der Schalter gedrückt wurde, was sich bemerkbar und störend auswirken könnte war größer als 100 ms oder so.
In einer reaktionsschnelleren und kaum komplizierteren Version fragen wir viel häufiger ab und reagieren auf eine Zustandsänderung des Schalters. Sobald sich der Zustand geändert hat, warten wir ab bevor Sie den Switch erneut abfragen.
Phil g
jonk