Ein einfacher und robuster Stabilitätsfilter für Mikrocontroller-Eingaben.
Die folgende Idee habe ich für ein ATMega-Projekt (DIY Stream-Deck) entwickelt. Ich möchte die Idee mit diesem Artikel teilen.
Es geht hier mehr um eine Idee als um Code für eine spezielle Platform.
Einleitung
Um mechanische Tasten und Schalter software-seitig zu entprellen,
habe ich folgende Idee entwickelt und nenne sie Candidate-Pattern.
Das Candidate-Pattern ist ein Stabilitätsfilter: Ein neu beobachteter Zustand wird zunächst als möglicher Kandidat betrachtet und erst dann übernommen, wenn er über mehrere Messzyklen hinweg unverändert bleibt.
Der Algorithmus ist bewusst plattformunabhängig:
funktioniert auf praktisch jedem Mikrocontroller oder Mikroprozessor
ist unabhängig davon, wie die Tasten eingelesen werden
funktioniert mit GPIO, Tastaturmatrix, IO-Expander oder anderen Eingabemechanismen
Der Debounce-Algorithmus arbeitet ausschließlich auf dem bereits gelesenen
Rohzustand der Tasten.
Warum Taster entprellt werden müssen
Beispiel eines prellenden Signals:
1
Rohsignal (Bounce)
2
3
HIGH ────────┐ ┌─┐ ┌──┐ ┌─┐
4
│ │ │ │ │ │ │
5
LOW ─────────┴───┘ └─┘ └─┘ └────────
6
7
Zeit →
Der Mikrocontroller würde mehrere Flanken erkennen,
obwohl der Benutzer nur einmal gedrückt hat.
Nach der Entprellung entsteht ein stabiler Zustand:
1
Debounced Signal
2
3
HIGH ────────────────┐
4
│
5
LOW ────────────────┴──────────────
6
7
Zeit →
Grundidee des Candidate-Patterns
Der Algorithmus arbeitet mit drei Zuständen:
1
Variable Bedeutung
2
--------------------------------------------
3
rawMask aktueller Rohzustand der Tasten
4
candidateMask möglicher neuer Zustand
5
stableMask zuletzt bestätigter stabiler Zustand
Zusätzlich existiert ein Zähler:
1
candidateTimer
Ein neuer Zustand wird nicht sofort akzeptiert.
Er wird zunächst als Kandidat gespeichert.
Die gemessenen Eingangswerte (z.b. Tastenmatrix-Scan) sind der Candidate
Erst wenn dieser Kandidat lange genug unverändert bleibt, wird er zum neuen stabilen Zustand.
Ändert sich der gemessene Zustand, gilt dieser als neuer Kandidat und der Zähler wird zurückgesetzt (reset).
Periodischer Aufruf des Algorithmus
Der Algorithmus kann einen Timer verwenden, muss aber nicht.
Er kann beispielsweise durch einen Hardware-Timer regelmäßig aufgerufen werden, funktioniert aber ebenso gut innerhalb einer zyklischen Hauptschleife.
Der interne candidateTimer zählt lediglich, wie viele Update-Zyklen der Kandidat unverändert geblieben ist.
Entscheidend ist nicht der Timer selbst, sondern ein regelmäßiger Aufruf des Debounce-Algorithmus.
Variante 1 – Timer-Interrupt
1
Timer Interrupt (1 ms)
2
-> scanKeys()
3
-> debounceUpdate()
Variante 2 – Hauptschleife
1
while(1)
2
{
3
scanKeys();
4
debounceUpdate();
5
}
Solange der Algorithmus in einem annähernd konstanten
zeitlichen Raster ausgeführt wird, arbeitet er zuverlässig.
Ablauf des Algorithmus
Bei jedem Update passiert Folgendes:
Rohzustand der Tasten lesen (rawMask)
Prüfen, ob sich der Kandidat geändert hat
Wenn ja → neuen Kandidaten setzen und Zähler zurücksetzen
Wenn nein → Zähler erhöhen
Wenn stabil → neuen stabilen Zustand übernehmen und Event setzen
Mehrere Tasten mit Bitmasken
1
Bit 0 -> Taste 0
2
Bit 1 -> Taste 1
3
Bit 2 -> Taste 2
Beispiele (gemessener raw/candidate wert):
1
00000000 keine Taste gedrückt
2
00000001 Taste 0 gedrückt
3
00000101 Taste 0 und Taste 2 gedrückt
Press- und Release-Events
1
pressedMask = newState & ~oldState
2
releasedMask = oldState & ~newState
Damit erhält man
neu gedrückte Tasten
losgelassene Tasten
Event-Semantik
Ein Event ist ein einmaliger Impuls.
Typische Events:
PRESSED
RELEASED
Zusatzinformation im Event
1
typedefstruct
2
{
3
uint32_tpressedMask;
4
uint32_treleasedMask;
5
uint16_tstabilityCount;
6
}ButtonEvent;
Beispielimplementierung (Arduino)
[cpp]
void MatrixKeys::Loop()
{
uint8_t scannedIndex = ScanRow(0);
if (!scannedIndex) scannedIndex = ScanRow(1);
if (!scannedIndex) scannedIndex = ScanRow(2);
1
if (scannedIndex == m_candidateIndex)
2
{
3
if (millis() - m_startMillis > BUTTON_DEBOUNCE_TIME)
4
{
5
if (m_currentKeyIndex != m_candidateIndex)
6
{
7
m_currentKeyIndex = m_candidateIndex;
8
m_eventFlag = 1;
9
}
10
}
11
}
12
else
13
{
14
m_candidateIndex = scannedIndex;
15
m_startMillis = millis();
16
17
if (m_candidateIndex == 0 && m_currentKeyIndex != 0)
18
{
19
m_currentKeyIndex = 0;
20
m_eventFlag = 1;
21
}
22
}
}
[/cpp]
Beispiel-Pseudocode
1
voiddebounceUpdate(uint32_trawMask)
2
{
3
if(rawMask!=candidateMask)
4
{
5
candidateMask=rawMask;
6
candidateTimer=0;
7
}
8
else
9
{
10
candidateTimer++;
11
12
if(candidateTimer>=DEBOUNCE_COUNT)
13
{
14
if(candidateMask!=stableMask)
15
{
16
pressedMask=candidateMask&~stableMask;
17
releasedMask=stableMask&~candidateMask;
18
19
stableMask=candidateMask;
20
}
21
}
22
}
23
}
Typische Parameter
1
Aufrufintervall: 1–5 ms
2
DEBOUNCE_COUNT: 5–20
Zusammenfassung
Das Candidate-Pattern ist eine einfache und robuste Methode zur
Entprellung mechanischer Taster.
Voraussetzung ist, dass das Eingangssignal zu einem stabilen Zustand gelangen kann. Bei mechanischen Tastern und Schaltern ist dies in der Regel der Fall, wenn sie einmal die entsprechende Endlage erreicht haben, während sie beim herunterdrücken/loslassen oft den "Prell-Effekt" haben. Eine fein-Justierung und Glättung kann durch Aufrufhäufigkeit und der minimal erforderlichen Stabilitäts-Zeit eingestellt werden.
Vergleich mit anderen Debounce-Algorithmen
Es existieren verschiedene Methoden, um das Prellen mechanischer Kontakte zu
unterdrücken. Die folgenden Ansätze sind in Mikrocontroller-Projekten besonders
verbreitet.
Prinzip: nach einer Flanke wird eine feste Sperrzeit gestartet
Vorteile: leicht zu implementieren
Nachteile: reagiert träge
Integrator / Counter
Prinzip: Zähler integriert den Eingang über mehrere Zyklen
Vorteile: robust gegen Störungen
Nachteile: etwas komplexer
(Neu): Candidate-Pattern
Prinzip: neuer Zustand wird erst nach stabiler Dauer akzeptiert
Vorteile: flexibel, effizient
Nachteile: benötigt zyklischen Aufruf
Einordnung des Candidate-Patterns
Das Candidate-Pattern lässt sich als Stabilitätsprüfung eines beobachteten
Zustands verstehen.
Im Gegensatz zu einem klassischen Timer-Debounce wird keine feste Sperrzeit
gestartet. Stattdessen wird kontinuierlich geprüft, ob ein neu beobachteter
Zustand lange genug stabil bleibt.
Daraus ergeben sich einige praktische Vorteile:
keine individuellen Timer pro Taste notwendig
funktioniert mit vielen Eingängen gleichzeitig
unterstützt mehrere gleichzeitig gedrückte Tasten
gut geeignet für zyklische Scan-Systeme (z.B. Tastaturmatrizen)
Der Algorithmus eignet sich besonders für Systeme, in denen Eingänge ohnehin
regelmäßig gescannt werden, beispielsweise:
Tastaturmatrizen
GPIO-Scanning
Polling-basierte Eingabeverarbeitung
Wann andere Methoden sinnvoll sein können
Andere Debounce-Methoden können in bestimmten Situationen besser geeignet sein:
RC-Filter bei sehr einfachen Schaltungen ohne Softwarelogik
Timer-Debounce bei einzelnen Tastern mit Interrupts
Integrator-Methoden bei stark verrauschten Signalen
In vielen Mikrocontroller-Anwendungen mit zyklischer Eingabeerfassung stellt
das Candidate-Pattern jedoch eine sehr einfache und flexible Lösung dar.
Dann solltest du mal in der Artikelsammlung nach anderen Lösungen gucken.
Peter Dannegger hat sowas (zwar kryptischer, aber kürzer) schon vor diversen Jahren veröffentlicht
Danke Dir. Das dachte ich mir schon, dass die Idee wahrscheinlich schon uralt ist. Ich schaue mir den Artikel von Peter mal an - vermutlich hab ich den einfach übersehen.
Für die Shooter-Freaks (kurze Latenz) könnte man diskutieren die erste Änderung an die Anwendung weiter zu geben und eine Änderung des von der Anwendung gesehenen Tastenzustands erst nach einer gewissen Zeit wieder zuzulassen.
Also den Zeitfaktor zugunsten kürzerer Latenzen "andersherum" zu bewerten.
Für die Shooter-Freaks (kurze Latenz) könnte man diskutieren die erste
Änderung an die Anwendung weiter zu geben und eine Änderung des von der
Anwendung gesehenen Tastenzustands erst nach einer gewissen Zeit wieder
zuzulassen.
Selbst wenn die den Finger auf der Taste haben und man sie mit einem kräftigen Taser beglückt, werden sie kaum mehr als 20 pro Sekunde schaffen.
Aber es ist natürlich sinnvoll, den EIN-Zustand (bei dem Prellen stattfinden kann) sofort zu vermitteln, den Wechsel in den AUS-Zustand mindestens um den Prell-Zeitraum zu verlängern.
Dafür lässt sich dann allerdings kein LONG/SHORT/DOUBLE Klick vernünftig unterscheiden.
Ein einfacher und robuster Stabilitätsfilter für
Mikrocontroller-Eingaben.
Interessant wie sich die Ansichten über "was einfach" ist, gewandelt haben,
zwanzig Zeilen code bis zur vierten Verschachtelungsebene.
Einen Nachweis der Robustheit findet man jetzt auch nicht ansatzweise, OK Robustheit erklärt sich auch eher aus der Betrachtung des Gesamtsystems, nicht an Detail-Implementierungen.
Aber faszinierende Wortfindungen: "Stabilitätsfilter", "Candidate pattern", "Roh-zustand". Persönlich bevorzuge ich Blockbilder bei der Erklärung der Funktionsweise, ok ist bei einem Forum wie diesem etwas schwierig.
funktioniert mit ... IO-Expander oder anderen
Eingabemechanismen
Die Frage dabei ist, wieviel eine Entprellung in einem nachgeschalteten µC bei einem I²C Portexpander Sinn macht. Die Entprellung, also der Tiefpass ist in dem Fall Bestandteil des IO-Expanders. Oder der des Schaltplans/PCB (RC-Glied).
Jedenfalls ein anregender Beitrag, werd ich wohl als "Hardwarker" eher nicht nutzen, aber für diese war es wohl auch nicht gedacht.
Die gemessenen Eingangswerte (z.b. Tastenmatrix-Scan) sind der Candidate
Erst wenn dieser Kandidat lange genug unverändert bleibt, wird er zum
neuen stabilen Zustand.
Ändert sich der gemessene Zustand, gilt dieser als neuer Kandidat und
der Zähler wird zurückgesetzt (reset).
Wie schon geschrieben wurde, ist das Vorgehen bzgl. gefühlter Verzögerung suboptimal. Wenn die einzigen „Störungen“ im Signal vom Prellen des Schalters stammen, ist es nicht nötig, das Signal erst dann als aktiv zu bezeichnen, wenn der Prellvorgang abgeschlossen ist. Das Signal ist gültig, sobald die erste Änderung erkannt wird. Die Entprellung muß dann nur dafür sorgen, daß alle nachfolgenden Änderungen ignoriert werden, bis das Signal stabil ist.
Anders ist es, wenn es auf der Leitung auch Störungen gibt, die nicht vom Schalter kommen. Dann ist das Abwarten auf einen stabilen Zustand sinnvoll.
Aber wie ja auch schon geschrieben wurde, gibts ja schon unzählige Routinen, für alle möglichen Anforderungen, und es wurde trotzdem noch nicht alles erfunden, und erst recht nicht von jedem.
Aber wie ja auch schon geschrieben wurde, gibts ja schon unzählige
Routinen, für alle möglichen Anforderungen, und es wurde trotzdem noch
nicht alles erfunden, und erst recht nicht von jedem.
Natürlich!
Und meine Variante ist die Beste.
(Nur eben nicht für jeden)
Ja, ich weiß, nicht die sparsamste....
Aber sparsam ist auch nicht immer nötig, schnelle Entwicklung und Zuverlässigkeit ist durchaus wichtig.
Mir scheint beinahe da hat jemand der seit 16 Jahren duscht das Waschen erfunden und mittel ChatGPT einen Buzzwordbingo-Reklametext verfassen lassen, weil das eine Klausur für den Soziologie-LK war. Oder so.
Mein Go-To zur Tastenentprellung sind Vertical Counters, klein, schnell, einfach, sicher, kann mehrere Tasten auf einmal.
Zwei Nachteile: die Entprellzeit ist für alle Tasten zusammen immer 2^x Aufrufe lang (halt je nach Bittiefe der Zähler) und den Code zu verstehen ist nicht so einfach, aber wenn's klickt isses schlau.
Wenig Code zu schreiben, Wenig Zyklen in der Abarbeitung, Wenig RAM (z.B. je Bit Zählertiefe ein Byte, aber nichts weiter für weitere 7 Eingänge; plus In- und Out-Puffer), funktioniert in beide Richtungen gleich lang für alle Eingänge unabhängig.
Einzig um Doppeltipp, Longpress und Autorepeat muss man sich noch kümmern, wenn man das braucht.
Ist übrigens auch ein System aus der Klasse der Candidate-Pattern-Filter. ;)
OMG! Schon wieder ein ChatGPT Experiment? Viel reden und wenig sagen.
Liegt im Trend, wie leben in der Laberkratie.
100% ACK. "profrob" 2.0. Dieses Pamphlet kann nur wieder von einem LLM kommen, wer bitte sonst hat soviel Langeweile, so dermaßen viel Schaum zu schlagen, mit nichts Neuem außer trivialer Heißluft, die bei Nicht-MC-Anfängern nur gääähn hervorruft? Aber hochgestochen und gegliedert mit Fazit und Vergleich etc.
Die Motivation dahinter ist mir schleierhaft. Kann mir nur vorstellen, dass sich jemand mit solchen "Beiträgen" eine Reputation erschleichen will.
Mindestens zwei verlorene Generationen. Freiwillige Lobotomie.
Ob die Menschheit das jemals wieder aufholen kann? Oder ob dann die Würfel total neu gemischt werden, und Menschen aus Ländern, in denen der Zugang zur Totalverblödung nicht so einfach war, dann die führende Rolle übernehmen, weil sie im Gegensatz zur saturierten bisherigen Elite sich nicht das Hirn mit KI-Löffeln rausgekratzt haben?
Das Lustige an den ganzen Debounce Debatten ist, daß es sehr oft einfach überflüssig ist. Weil z.B der Tastendruck eine Ausgabe bewirkt, die bereits länger dauert, als das Prellen.
Richtig spannend wird das Thema für mich erst bei Drehgebern, was hier vor ein paar Wochen ausgiebig diskutiert wurde.
Das Lustige an den ganzen Debounce Debatten ist, daß es sehr oft einfach
überflüssig ist. Weil z.B der Tastendruck eine Ausgabe bewirkt, die
bereits länger dauert, als das Prellen.
Hmmm... Wenn ein Tastendruck aufgrund einer länger dauernden (und das restliche Programm blockierenden) Ausgabe nicht registriert wird, dann riecht das aber verdächtig nach Anfänger-Warteschleifen-Programmierung.
Hmmm... Wenn ein Tastendruck aufgrund einer länger dauernden (und das
restliche Programm blockierenden) Ausgabe nicht registriert wird, dann
riecht das aber verdächtig nach Anfänger-Warteschleifen-Programmierung.
Nicht jede Anwendung soll während dessen auf weitere Eingaben reagieren. Wenn nan es braucht, soll man es natürlich richtig machen.
IBMs Lösung dazu war ein separater Mikrocontroller im PC, nur um die Tastatur zu puffern, die wiederum einen eigenen Mikrocontroller zum Pollen und Entprellen der Tasten hatte. Und das zu Zeiten, als die Dinger viel mehr als 50 Cent kosteten. Wenn das mal kein Overkill ist!?
KI-generierte Inhalte sind als solche deutlich zu kennzeichnen. Inhalte
die sich nicht daran halten bitte rigoros löschen!
Leider ist der KI-Ursprung aber nicht immer so offensichtlich und eindeutig erkennbar wie hier, oder diesem kuriosen Erguss über State Machines (mit "und." am Ende) neulich.
Prinzip: neuer Zustand wird erst nach stabiler Dauer akzeptiert
Die Taste wurde bei der ersten steigenden Flanke gedrückt. Das ist dann der neue Zustand. Das darauf folgende Prellen kann/muss für die Prellzeit ignoriert werden.
Aber faszinierende Wortfindungen: "Stabilitätsfilter", "Candidate
pattern", "Roh-zustand".
Dabei ist es mal wieder nur eine Form der Unterabtastung mit ein bisschen Filtern. Wenn da niemand mit einer grundsätzlich neuen Idee kommt, statt nur mit KI-Bezeichnungen, wird es in 20 Jahren immer noch Unterabtasten und Filtern sein.
Die Forderung ist ein bisschen naiv. Es wird genug geben die sich nicht
dran halten werden.
Deswegen rigorose Löschung von ungekennzeichneten Inhalten. Im Verdachtsfall einfach ein Post mit Hinweis auf KI Slop erstellen, dann das eigene Post melden. Der Moderator entscheidet nach Bauchgefühl und kann den Thread komplett löschen - kein /dev/null oder ähnliches. Bei Spam geht es doch auch.
In Projekte & Code kann man ja seine ganz tollen KI-Codeschnipsel teilen, wenn man findet diese sollten für die Nachwelt erhalten bleiben. Nur eben mit Kennzeichnung dass man selbst nicht der Autor ist, sondern eine KI.
Aber faszinierende Wortfindungen: "Stabilitätsfilter", "Candidate
pattern", "Roh-zustand".
Dabei ist es mal wieder nur eine Form der Unterabtastung mit ein
bisschen Filtern. Wenn da niemand mit einer grundsätzlich neuen Idee
kommt, statt nur mit KI-Bezeichnungen, wird es in 20 Jahren immer noch
Unterabtasten und Filtern sein.
"Filter" ist IMHO eine Wort-Hure, die kann alles mögliche sein, insbesonders in der Informatik. Bei "Roh-Zustand" ist IMHO "Zustand" die falsche Begriffsklasse, es ist wohl eher "Signal" gemeint, also das unveränderte Signal (resp. u(t)-Zeitreihe). Und Stabilität in Zusammenhang mit Filtern ist auch schon anders gebraucht ((Eigen-)Schwingungsneigung, Stabilitätskriterium), gemeint ist hier wohl eher "Trägheit" statt "Stabilität".
"Unterabtastung", hm, da denke ich eher an Nyquist und Anti-Aliasing. Tiefpassfilter mit Grenzfrequenz im kHz-Bereich passt da schon besser, aber das ist wohl einigen dann eine zu eine Betrachtungsweise der Analogtechnik.
Aber ja, das sind alles "alte Begriffe", die gegen die Modeerscheinungen in der Technik stehen.
Bei 20 Tastendrücken pro Sekunde kann die Latenz wohl kaum größer als
50ms sein.
Die ganze Tastendruckfolge kann doch, warum auch immer, mit 100 ms Verzögerung aus einem Filter heraus kommen. Du verwechselst Grenzfrequenz mit Latenz.
Zur Hardwareentprellung braucht man kein RC-Filter. Ein Taster mit Umschaltkontakt und dahinterfolgendem RS-FF liefert ein prellfreies Signal, ohne die Tastfrequenz zu beschränken.
Oder andersrum: das Verfahren ist uralt, du hast dir nur neue Namen ausgedacht.
Sieh es einfach mal so, dass man eine Zeit über eine Timerabfrage oder über einen timergesteuerten zyklischen Aufruf machen kann. Dann ist dein neues Verfahren gar nicht mehr so neu.
Die ganze Tastendruckfolge kann doch, warum auch immer, mit 100 ms
Verzögerung aus einem Filter heraus kommen. Du verwechselst
Grenzfrequenz mit Latenz.
Ja, da hast du recht. Passiert mir ziemlich oft. Montag Abend schalte ich im Wohnzimmer die Beleuchtung an und schon gegen Donnerstag wird es hell.
Diesen Fall hatte ich nicht bedacht.
IBMs Lösung dazu war ein separater Mikrocontroller im PC, nur um die
Tastatur zu puffern, die wiederum einen eigenen Mikrocontroller zum
Pollen und Entprellen der Tasten hatte.
Nein, der separate Microcontroller im PC (genauer: AT und nachfolgenden) diente der kompatiblen Nachbildung der älteren microcontrollerlosen Tastaturschnittstelle des PC und XT aus Sicht der auf dem AT laufenden Software, bei gleichzeitiger Erweiterung des Tastaturprotokolls um Bidirektionalität. Das PC- und XT-Tastaturprotokoll war komplett unidirektional, d.h. die Leuchtdioden für CapsLock etc. konnten, da sie von der Tastatur selbt ansgesteuert wurden, "aus dem Takt" kommen und somit das genaue Gegenteil der Realität ausgeben.
Das AT-Tastaturprotokoll (das auch Grundlage des späteren PS/2-Protokolls war) bietet im Gegensatz dazu die Steuerung der LEDs durch den PC selbst an. Seitdem kann man eine Restfunktion des PCs durch zweimaliges Drücken einer der Lock-Tasten kontrollieren - ändert sich der Zustand der LED, lebt noch irgendwas.
Und als man PS/2 einführte, war der Microcontroller (i.d.R. ein 8042) praktisch, da man ihn um die Unterstützung der Maus erweitern konnte.
RC-Filter (Hardware)
Prinzip: Analogfilter glättet das Signal
Wenn man die Sache wirklich zu Ende gedacht hat, stellt man fest: allein
mit einem RC-Filter kann man einen Eingang prinzipiell nicht entprellen.
Naja, wenn man statt willkürlich "Ende" deklamiert mal das Ganze aufbauen oder bewährte Schaltungen durchmessen würde, könnte man feststellen, das ein RC-Glied sehr wohl das prellende Signal eines Schalter/Taster glättet.
Natürlich muß die Zeitkonstante 𝜏 (Produkt aus Widerstands- und Kondensator-Wert) passen und das Verhalten ist auch (beispielsweise bzgl. der Latenz (Verzögerung)) ein anderes, aber die schnellen Wechsel des einzulesenden Signals zwischen V_iH und V_iL (Schaltschwellen für logisch '1' und '0' der Eingangsstufe) während des Burst-artigen "Prellens" sind entfernt.
Ein einfacher und robuster Stabilitätsfilter für
Mikrocontroller-Eingaben.
Die folgende Idee habe ich für ein ATMega-Projekt (DIY Stream-Deck)
entwickelt. Ich möchte die Idee mit diesem Artikel teilen.
Früher habe ich soetwas gerne mit einem gleitenden Durchschnitt gemacht.
Ein Zähler zählt die steigenden Flanken hoch, und die fallenden herunter.
Wird für eine gewisse Zeit keine Veränderung bemerkt, wird der Zustand als stabil angenommen, und der Zählerstand für High auf z.B. 126 gesetzt, entsprechend der Zählerstand für Low auf Null. Von diesen Werten werden die Flanken entsprechend hinzugezählt bzw. abgezogen, wobei der Zählerstand nie 126 überschreiten oder Null unterschreiten kann, sonst wird er eben wieder zu 126 oder zu Null gesetzt.
Nun kann ich (z.B. nach Erfahrungswerten oder auch Willkürlich) Schwellen definieren, ab wann ein Zählerstand High oder Low zu interpretieren ist. Eine Hysterese ist natürlich auch möglich.
Ein anderer Weg wäre es, ständig zu Pollen, und statt Flanken dann die gepollten Zustände zu verwenden.
Jedenfalls gefühlt einfacher als Deine Methode.
Ok, könnte auch etwas an der Architektur des betrachteten Mikrokontrollers hängen
Ja, da hast du recht. Passiert mir ziemlich oft. Montag Abend schalte
ich im Wohnzimmer die Beleuchtung an und schon gegen Donnerstag wird es
hell.
Diesen Fall hatte ich nicht bedacht.
Auch wenn es dir in deinem Alltag und bei dem von dir gewählten Beispiel völlig befremdlich vorkommt, ist es in anderen Bereichen der Technik gängige Praxis.
Nimm dir bspw. eine Internetverbindung, bei der trotz Ping-Zeiten von etlichen Millisekunden Datenübertragungsraten von 100 MBit/s völlig üblich sind. Oder nimm Raumsonden beim Mars, wo Datenströme mit 1 MBit/s um 1/4 Stunde verzögert eintreffen. Die gleiche Verzögerung gilt für Steuerkommandos.
Ein Zähler zählt die steigenden Flanken hoch, und die fallenden
herunter.
Wird für eine gewisse Zeit keine Veränderung bemerkt, wird der Zustand
als stabil angenommen ...
Bei einem vernünftigen Schalter und einem ausreichenden Störabstand der Signalübertragung kann man bereits beim Erscheinen der ersten Flanke davon ausgehen, dass der Schalter seinen Zustand ändert, d.h. man bekommt sofort mit, wenn sich etwas ändert. Darauf folgende Prellerei kann man sich dann "in Ruhe" angucken und ausblenden, hat aber keine unnötige Verzögerung bei der Erkennung der Statusänderung. Ein Schalter prellt nicht aus heiterem Himmel, sondern nur, wenn man ihn umschaltet. Die Statusänderung ist die Ursache für die erste Flanke, das Prellen ist nur eine Folge davon.
Auch wenn es dir in deinem Alltag und bei dem von dir gewählten Beispiel
völlig befremdlich vorkommt, ist es in anderen Bereichen der Technik
gängige Praxis.
Rainer, ich entwickle Software seit mittlerweile einigen Jahrzehnten. Insofern ist mir der Begriff der Latenz sehr wohl bekannt.
Allerdings ging es in dem Beispiel um einen hastig den Knopf traktierenden Gamer. Käme man dort auf die Idee einen Filter mit der von dir angenommenen, extremen Verzögerung einzusetzen, wäre das ganze System der schnellen Reaktion ad absurdum geführt.
Insofern darf man dann getrost davon ausgehen, dass bei einer angenommenen maximal Wiederholrate (da hatte ich mal vorsorglich übertrieben und 20/Sekunde angesetzt) nur für ca. 25 ms gefiltert wird, falls man eine Ausgangstastrate von 50% erreichen möchte.
Es gibt einen Unterschied zwischen Theoretisieren und Praktizieren.
Bei einem vernünftigen Schalter und einem ausreichenden Störabstand der
Signalübertragung kann man bereits beim Erscheinen der ersten Flanke
Ja Rainer, dass hatte ich bereits gestern angeführt:
Aber es ist natürlich sinnvoll, den EIN-Zustand (bei dem Prellen
stattfinden kann) sofort zu vermitteln, den Wechsel in den AUS-Zustand
mindestens um den Prell-Zeitraum zu verlängern.
Ein Zähler zählt die steigenden Flanken hoch, und die fallenden
herunter.
Wird für eine gewisse Zeit keine Veränderung bemerkt, wird der Zustand
als stabil angenommen ...
Bei einem vernünftigen Schalter und einem ausreichenden Störabstand der
Signalübertragung kann man bereits beim Erscheinen der ersten Flanke
davon ausgehen, dass der Schalter seinen Zustand ändert, d.h. man
bekommt sofort mit, wenn sich etwas ändert.
Sicher? ;O)
Immerhin lieferst Du die Argumente für die Ausnahmen ja selber schon.
Darauf folgende Prellerei
kann man sich dann "in Ruhe" angucken und ausblenden, hat aber keine
unnötige Verzögerung bei der Erkennung der Statusänderung.
Kann man machen. Richtig. Wenn einem mögliche Fehler unwichtiger sind als die Verzögerung.
Ein Schalter
prellt nicht aus heiterem Himmel, sondern nur, wenn man ihn umschaltet.
Ich sah mich in meiner Vergangenheit schon damit konfrontiert, "Entrprellungen" gegen "Spielkinder", die einen Schalter manuell schnell hin- und her Schalten einzusetzten. Die Zeitkonstante der Entprellung lag dann im Minutenbereich. ;O)
Die Statusänderung ist die Ursache für die erste Flanke, das Prellen ist
nur eine Folge davon.
Es gibt, insbesondere im industriellen Umfeld, miese Schalter mit Wackelkontakten bei hartem Erschütterungen (insbesondere wenn sie älter oder stark verschmutzt sind), und starke elektromagnetische Störfelder.
Es gibt Leitungen und Klemmen mit Wackelkontakten, und Cheffe verlangt, dass Du das am Laufen hälst, egal ob Du was für den Wackelkontakt kannst oder nicht. ;O)
In einem Gamer- oder Büroumfeld z.B. mag Deine Annahme aber durchaus hinkommen.
Ein Zähler zählt die steigenden Flanken hoch, und die fallenden
herunter.
Wird für eine gewisse Zeit keine Veränderung bemerkt, wird der Zustand
als stabil angenommen
In der Hardware macht man sowas mit einem Schieberegister. Der Takt für dieses Schieberegister bestimmt die Entprellzeit. Wenn dann dann ein Schiebetakt von 2ms verwendet wird und 5 aufeinanderfolgende Bits im SR gleich sind, dann hat das Signal sicher 10ms nicht mehr gezappelt und der Zustand kann als stabil angenommen werden.
Siehe dort:
Die Statusänderung ist die Ursache für die erste Flanke, das Prellen ist
nur eine Folge davon.
Es gibt, insbesondere im industriellen Umfeld ...
starke elektromagnetische Störfelder.
"Entprellen" und "Störsicherheit" sind zwei Paar Stiefel. Wenn man es geschickt macht, kann man sie mit dem selben Werkzeug erschlagen. Aber Störungen sollten erst gar nicht auf die Leiterplatte kommen, sondern schon direkt am Stecker ausgefiltert werden.
Ich sah mich in meiner Vergangenheit schon damit konfrontiert,
"Entrprellungen" gegen "Spielkinder", die einen Schalter manuell schnell
hin- und her Schalten einzusetzten. Die Zeitkonstante der Entprellung
lag dann im Minutenbereich. ;O)
Ich hasse Fahrstühle, bei denen man die Stockwerkwahltaste für gefühlt 2s drücken muss.
Es kommt also seehr darauf an, wie weit man den Begriff "entprellen" fassen will. Und mir ist nicht bekannt, dass das "debounce" des TO präziser definiert ist. Kurz, die Software muss zur Anwendung und zur Umgebung passen.
Es gibt, insbesondere im industriellen Umfeld, miese Schalter mit
Wackelkontakten bei hartem Erschütterungen (insbesondere wenn sie älter
oder stark verschmutzt sind), und starke elektromagnetische Störfelder.
Es gibt Leitungen und Klemmen mit Wackelkontakten, und Cheffe verlangt,
dass Du das am Laufen hälst, egal ob Du was für den Wackelkontakt kannst
oder nicht. ;O)
Dann gibt es so etwas wie ein stabiles Signal eben nicht und man muss den Schalt-"Zustand" am Tastverhältnis der Wackelei festmachen oder vielleicht doch einmal über geeignete Schalter und vernünftige Wartung nachdenken. Im Automobilbereich sind, nicht ohne Grund, bereits viele Schalter durch mechanische Hebel und Hall-Sensoren ersetzt.
Bei einem vernünftigen Schalter und einem ausreichenden Störabstand der
Signalübertragung kann man bereits beim Erscheinen der ersten Flanke
davon ausgehen, dass der Schalter seinen Zustand ändert
Das führt jedes Entprellen ad absurdum. Geschenkt.
Das führt jedes Entprellen ad absurdum. Geschenkt.
... "Die erste Flanke" ...
Heißt doch, dass Schaltzustand des Schalters längere Zeit nicht geändert wurde. Man reagiret auf die erste Flanke und wartet geichzeitig auf den neuen stabilen Zustand.
Das führt jedes Entprellen ad absurdum. Geschenkt.
Unsinn - ein mechanischer Schalter ist ein schwingfähiges System und wenn das durch Energieeintrag (aka Schaltvorgang) zu einer (gedämpften) Schwingung angeregt wird, schwingt es eben und kann in Folge dessen mehrere Kontaktereignisse auslösen. Aber er fängt nicht aus heiterem Himmel an zu schwingen.
Ja und etwas das bei der ersten Flanke auslösen (reagieren) soll benötigt keine nachfolgende Betrachtung - diese macht nur Sinn wenn man /nicht/ sofort auslöst (reagiert)
Dann gibt es so etwas wie ein stabiles Signal eben nicht und man muss
den Schalt-"Zustand" am Tastverhältnis der Wackelei festmachen
Eben!
oder vielleicht doch einmal über geeignete Schalter und vernünftige
Wartung nachdenken.
Das wäre in der konkreten Situation das möglicherweise sinnvollste gewesen. Aber Cheffe sah das halt anders: "Vielleicht wird die Anlage ja schon nächsten Monat komplett stillgelegt". Das sind halt auch entsprechende Rahmenbedingungen.
Im Automobilbereich sind, nicht ohne Grund, bereits viele
Schalter durch mechanische Hebel und Hall-Sensoren ersetzt.
Das ist in den meisten Situationen sehr sinnvoll. Leider viel Aufwand beim nachrüsten einer alten Anlage. Und eventuell müsste auch noch neu zertifiziert werden......
Bei einem vernünftigen Schalter und einem ausreichenden Störabstand der
Signalübertragung kann man bereits beim Erscheinen der ersten Flanke
davon ausgehen, dass der Schalter seinen Zustand ändert
Dann wann? Wenn er bereits ausgelöst (reagiert) hat - sich mit der ausgelösten Aktion beschäften und sich zum nächsten Auslöser frei melden.
Wenn er noch nicht ausgelöst (nicht reagiert) hat - warten. Beobachten. Entscheiden. Auf einen stabilen Zustand warten der zur Flanke passt. Dann auslösen.
Ja und etwas das bei der ersten Flanke auslösen (reagieren) soll
benötigt keine nachfolgende Betrachtung
Doch. Um zu verhindern, dass nachfolgendes Kontaktprellen (i.e. weitere Flanken im Millisekundenbereich ohne willkürliche erneute Betätigung) nicht /erneute/ "Taster-wurde-gedrückt"-Event-Erkennungen im MC auslösen.
Es geht beim Entprellen darum, das "Triggern" eben so lange zu sperren, bis das Prellen beendet ist. Nicht mehr und nicht weniger.
Alles nach dem Triggern (also auch das Sperren) gehört für mich schon
zur Aktion:
Nun wird es komplett lächerlich. Du willst einfach nicht einsehen, dass du im Unrecht bist und Mist geschrieben hast. Ich werde auf diesen Unsinn nicht weiter eingehen.
Erzähle mir wie Du entprellen willst mit einer Latenz von = 0. Das ist das was ich kritisiert habe.
Ich hab schon entprellen müssen mit einer Latenz von 5 Sekunden. Beim anschließen des Ladegeräts oder regulären Einschalten schaltet ein GPIO mehrmals in 5 Sekunden um bevor er stabil wird.
Ich verstehe nur das womit ich schon mal zu tun hatte.
Wer nicht über das Henne-und-Ei-Problem hinwegkommt, der bleibt ewig wo? Der bleibt auf unterstem Niveau.
Was Prellen ist, sagt dir der erste Absatz bei https://de.wikipedia.org/wiki/Prellen
Entprellen bedeutet in der Fachsprache nicht mehr und nicht weniger als das Verhindern der unerwünschten Auswirkung eines Prellens.
Latenz bedeutet in der Fachsprache Verzögerung, nicht mehr und nicht weniger. Das ist hier die Zeit zwischen dem auslösenden Ereignis und dem gewünschten auszulösenden Ereignis, also zwischen der ersten Signalflanke und dem "Abliefern" einer einschlägigen Meldung.
Dass man diese Zeit praktisch zu null machen kann, hat man dir inzwischen mehrfach erklärt.
Ich habe jetzt zwei Beispiele genannt bei denen es nicht ohne Latenz geht.
Nach den Gesetzen der Logik beweist das allerhöchstens, dass es möglich ist, mit Latenzen >>0 zu arbeiten. Es beweist null Komma nichts hinsichtlich einer Mindest-Latenz.
Ist es dir nicht möglich, das beim Studium des Artikels zu erkennen?
Wir sind hier nicht im Kindergarten und zumindest ich habe keine Lust, irgendwem alles haarklein erklären zu müssen. Scheinbar fehlt dir entweder die Motivation, die Geduld, oder der Intellekt, um zu verstehen, was hier und andernorts schon 1001mal dargelegt wurde. Wenn es an solchen Trivialitäten schon scheitert, dann ist Elektronik das falsche Gebiet.
Jo. Dazu braucht es nicht mal einen Mikrocontroller.
Die erste Flanke braucht kein Entprellen, also auch keinen uC.
Nur die Flanken während des Prellens werden entprellt. Wie genau, hängt vom zu erwartenden Prellen und der maximal geforderten Schaltgeschwindigkeit ab.
Je weiter das auseinander liegt, umso einfacher. Wenn das prellen genau bekannt ist, z.B. max 9ms, kann ich einfach 10ms nach jeder Flanke warten. Wenn es nur beim ein- oder ausschalten auftritt, kann ich noch einfacher auswerten.
Aber für erste Erfahrungen ist es völlig okay, auch die Startflanke zu „entprellen“.
Hauptsache Du sammelst Erfahrung. Ich war z.B. völlig überrascht, wie mir ein Kollege fast 20 Tastendrücke pro s mit knackfröschen zeigt, wenn lange Listen zu scrollen waren. (Eigentlich sind ~10/s das Maximum)
Türklingel, Treppenlichtautomat, Fotokamera, Keyboard, Stefan Raab's Hot Button, mir fallen irgendwie nur Beispiele ein wo man keine Entprellung braucht. Selbst wenn bei der PC-Tastatur die erste Flanke die Aktion auslöst, übernimmt die Aktion mit ihrer Sperrzeit doch die Anschlagsverzögerung. Drehgeber wurde noch genannt, aber da hab ich den Thread dazu nicht gefunden.
Wenn wir von Mikrocontrollern reden, interessiert mich doch nur wann ich eine Aktion auslösen will. Ich kenne nur das Problem "zu früh ausgelöst" welches sich eben durch Festlegen einer Mindestdrückdauer beheben lässt (oder mit anderen genannten Verfahren die den stabilen Zustand abwarten)
Beim anderen Szenario Auslösen bei erster Flanke erschließt sich mir der Sinn von Entprellen nicht, die Aktion wurde bereits ausgelöst.
Gut man kann natürlich Aktion und Auslöser in einen Topf werfen und diese Einheit mit "Entprellen nach erster Flanke" bezeichnen.
Das dem de-bounce und anderen ähnlichen Methoden zugrundeliegende Grundprinzip ist, das man während eines Übergangs zwischen zwei zeitlich stabilen Zuständen das Eingangssignal ignoriert und nicht weiterverarbeitet.
Dieses Prinzip kennt man auch unter den Begriff Relaxation - "Erholphase" englisch auch "recovery time", oder bei Messungen bspw. mit der Tafelwaage als "Austarieren".
Statt "canditate pattern" wären IMHO eine treffendere Bezeichnung "relaxation wait" oder "idle output during recovery" o.ä..
Das wichtige wesentliche "tool" in dieser Methode ist ein Timer oder Verzögerungsglied. Entweder um dem Ablauf der erfahrungsgemäßen Maximalzeit zu ermitteln oder um damit abzuschätzen wie die zunehmende Zeitspanne zwischen den "Preller" das Nahen des nächsten stabilen Zustandes anzeigt.
Für spezielle Anwendungen wie dem Entprellen mechanischer Knöppe könnte man zur Beschleunigung des "Einschwingens" bremsende Eingriffe andenken; manche Laborwaagen haben bspw. Bremsen/Dämpfer, bei manchen µC könnte man die internen Pulls passend zuschalten. Aber das sind m.E. Details, grundprinzip ist, das es eben zeitintervalle in eine Steuerprozedure gibt in der man eben nicht die Eingangsgröße ermittelt bzw. zur Steuerung verwendet.
PS: Rumgekacker über angebliche "Besserwisserei" ist komplett für den Arsch und bringt in der Sache nicht weiter.
Um z.B. zu verhinder, dass ein Zähler für Werkstücke zu einem Zähler für
Prellimpulse wird.
Geldzählmaschine ist ein gutes Beispiel danke. Kann man also auch in dem Fall sagen, der Zähler gehört zur Aktion und fällt nicht in die Zuständigkeit des Auslösers?
Das Entprellen folgt dann wieder indirekt durch die Laufzeit der Aktion.
Geldzählmaschine ist ein gutes Beispiel danke. Kann man also auch in dem
Fall sagen, der Zähler gehört zur Aktion und fällt nicht in die
Zuständigkeit des Auslösers?
Das Entprellen folgt dann wieder indirekt durch die Laufzeit der Aktion.
Dann musste man erstmal klären, ob es eine nebenläufige Architektur ist, in der der debounce-Zähler/timer gleichzeitig/parallel zur Aktion (Zähler der Moneten) läuft/laufen könnte.
Aber der Ansatz soll ja architektur-unabhängig betrachtet werden.
Geldzählmaschine ist ein gutes Beispiel danke. Kann man also auch in dem
Fall sagen, der Zähler gehört zur Aktion und fällt nicht in die
Zuständigkeit des Auslösers?
Das Entprellen folgt dann wieder indirekt durch die Laufzeit der Aktion.
Das ist alles recht vage. Und bringt niemanden weiter. Gehe einfach vom Standardbeispiel aus, das jeder Anfänger irgendwann durchläuft:
ein Taster, eine LED an/aus (oder Motor, Licht, Fernseher, ... )
Naiver Ansatz: Wenn AUS und Flanke, dann EIN. Wenn EIN und Flanke, dann Aus
--> ob der LED-Zustand sich ändert, ist Glücksache
Dann fragt er hier und die Lösung ist entprellen.
Das einfache Entprellen klappt natürlich per Wartezeit oder RC-Glied genauso gut wie mit Peter Dannegers Routine oder irgendeiner beliebigen, z.B. des TO. Meist tritt das Problem gar nicht erst auf, weil die Abfrage in der Loop erfolgt und die > 30ms dauert.
Peters et. al. Routinen braucht man erst, wenn man mehr als einen Impuls zählen muss. Drehgeber, Werkstückzähler oder Bedieneinheiten mit wenigen Tasten. Wo man "blind" 5x "runter" drückt, 2x "rechts" und dann "Enter" und immer die gleiche Aktion erwartet.
Beim anderen Szenario Auslösen bei erster Flanke erschließt sich mir der
Sinn von Entprellen nicht, die Aktion wurde bereits ausgelöst.
Wie phantasielos kann man sein?
Wenn nach der ersten Flanke/Aktion weitere Signalflanken auf Grund von Prellen auftreten, sollen dadurch nicht gleich weitere Aktionen ausgelöst werden, sondern erstmal gewartet werden, bis sich die Schaltermechanik wieder beruhigt hat, d.h. sicher in einen stabilen Zustand gegangen ist.
Wie phantasielos kann man sein?
Wenn nach der ersten Aktion weitere Signalflanken auf Grund von Prellen
auftreten, sollen dadurch nicht gleich weitere Aktionen ausgelöst werden
Warum sollten sie das? Die Aktion hat eine Laufzeit (mit eigener Sperrzeit)
Man kann natürlich auch den Treppenlichtautomat so weit runter drehen dass das Licht schneller aus ist als der Taster fertig mit prellen. Das ist Deine Entscheidung.
Warum sollten sie das? Die Aktion hat eine Laufzeit (mit eigener
Sperrzeit)
Wo steht das?
Die Welt besteht nicht nur aus Treppenlichtautomaten, die auf Grund ihrer Monoflop-Charakteristik selber für sauberes Verhalten sorgen.
Es gibt durchaus Aktionen, die NICHT länger als die Prelldauer eines Schalters dauern, z.B. das Zählen von Tastendruckereignissen.
Ist genau der Moment, in dem die Änderung auftritt.
Deine Aussage ist also:
Wenn es sich im Moment der Änderung nicht ändert.
Na, ist blöd, wenn man auf Krampf missverstanden wird, näch?
Mal wieder n typischer Alecxs, entweder bist du zu blöd, oder du willst es absichtlich nicht verstehen, jedenfalls macht es keinen Sinn, dir da noch irgendwas zu erklären. Erinner dich an die Lichtgeschwindigkeitsthreads.
In letzter Zeit kam mir öfters der Gedanke "Mensch der Alecxs hat sich gemausert" wenn ich was von dir las. Offensichtlich lag ich da falsch und du bist genau wie früher.
Wenn wir von Mikrocontrollern reden, interessiert mich doch nur wann ich
eine Aktion auslösen will. Ich kenne nur das Problem "zu früh ausgelöst"
welches sich eben durch Festlegen einer Mindestdrückdauer beheben lässt
Wie schon geschrieben wurde, ist dein Teller zu klein und zu hoch…
Der Rest ist dein Begriffswirrwar.
Entprellen hat eine Bedeutung, und Enstören eine andere.
Und da wir hier von Mikrocontrollern reden (das lässt zumindest mal der Forumstitel und auch der Ausgangsbeitrag dieses Threads vermuten), ist da der Fall, daß die Aktion schneller fertig ist, als die Schalterprellimpulse eintreffen, durchaus üblich. Dagegen hilft „Entprellen“ - verhindern, daß die zusätzlich kommenden Schaltimpulse nach dem allerersten ungewollte Aktionen auslösen.
Dann gibts auch noch „Entstörung“. Da will man und (auch Du) verhindern, daß Störungen auf der Leitung ungewollt eine Aktion auslösen.
Für beides gibts Lösungen, die sich teilweise auch überschneiden. Trotzdem ist ist weder das gleich noch das selbe.
Ja hab ich auch gemerkt. Wird aber nur an einer einzigen Stelle verwendet. Ist ne Weile her, woanders hab ich das mal in eine Klasse gepackt.
Mir ging es jetzt nicht um Effizienz sondern um die Begrifflichkeit meines Tellers. analogReadMilliVolts() ist ja an sich schon ein "Integrator" (Oversampling und Averaging)
Und ist das jetzt entstören oder entprellen? (eng: debounce)
Das ist vor allem Kanonen auf Spatzen:
Mit ADC nimmt man einfach RC und Hysterese (aka Schmitt-Trigger)
millis ist oft schwergewichtiger und komplexer als sich einmal Gedanken um eine Zykluszeit zu machen (wie oft rufst Du denn das auf? Was passiert dann? Siehst Du!)
irgendwie fehlt da was. Entweder 2 ptr (state und valid) oder keinen und Rückgabewert.
Natürlich wird das für Deinen Fall funktioniert haben. Aber es müssen schon sehr spezielle Anforderungen gewesen sein. Oder einer Deiner ersten Versuche.
Beim anderen Szenario Auslösen bei erster Flanke erschließt
sich mir der Sinn von Entprellen nicht, die Aktion wurde
bereits ausgelöst.
Es ist offensichtlich für Dich undenkbar und jenseits aller
Vorstellungskraft, dass die auszulösende Aktion -- zum
Beispiel das Erhöhen eines Wertes um Eins -- innerhalb
einiger Mikrosekunden erledigt sein könnte.
Gut man kann natürlich Aktion und Auslöser in einen Topf
werfen und diese Einheit mit "Entprellen nach erster
Flanke" bezeichnen.
Das ist aus DEINEM Munde ein besonders origineller Vorwurf --
denn DU bist es ja, der steif und fest behauptet, die Dauer
der ausgelösten AKTION garantiere die Unwirksamkeit falscher
AUSLÖSUNGEN.
Auch wenn das nicht exakt zum Thema passt: Ich wünsche allen
Pfuschern wie Dir eine intensive Behandlung mit dem Therac-25.
Übrigens: Das von Dir vehement kritisierte "Entprellen nach
der ersten Flanke" kennt man bei Oszis unter dem Stichwort
"Holdoff", und dort fand ich auch das passende deutsche Wort
dafür: "Totzeit".
Man könnte es natürlich auch noch so sehen, dass Prellen
eine Art von Störung ist.
Kann man so sehen, finde ich aber unglücklich.
"Störungen" streuen in meinem Universum von außen in das
Mikrocontrollersystem ein -- "Prellen" ist aber etwas,
was der Tiptaster auf dem µC-Board selbst tut. Da ist
niemand anders schuld -- außer dem mechanischen Kontakt
selbst.
Und wie unterscheidest Du echtes von falschem Zählen?
Richtig, indem man nur stabile Flanken auswertet.
Ja, korrekt.
Das impliziert eine Latenz.
Jein.
Latenz bedeutet "Verzögerung", das stimmt schon -- aber
bei weitem nicht jede im Innern eines Systems auftretende
Verzögerung ist eine "Latenz" im üblichen Sinne.
Latenz bezeichnet die Zeitverzögerung zwischen einer
Aktion und DEM Signal, das DIESE Aktion ausgelöst hat.
Die Zeit zwischen Betätigen des Abzuges und Schussabgabe
ist die Latenz; die Zeit zwischen Schussabgabe und erneuter
Schussbereitschaft ist die Nachladezeit.
Deswegen ist das "Holdoff" beim Oszi KEINE Latenz!
Wenn Du nicht Willens bist die Sperrzeit korrekt in
Deine Aktion einzubauen ist das Deine Entscheidung.
HÄH?
Jetzt wirds völlig abstrus. Bei welchem Bastelpfuscher
hast Du denn programmieren gelernt?
Ein EINGABEORGAN liefert (bauartbedingt) Fehlimpulse,
und die Sperrzeit gehört -- angeblich "korrekt" -- in
die ausgelöste AKTION?
Ändert aber nichts an der Wartezeit die sich ergibt
bis dein Taster entprellt ist.
Ironischerweise stimmt das -- nur gibt es für diese
Wartezeit zwei Verschaltungsmöglichkeiten: Man kann
Wartezeit und Aktion in Reihe schalten oder parallel...
Dann wann? Wenn er bereits ausgelöst (reagiert) hat - sich mit der
ausgelösten Aktion beschäften und sich zum nächsten Auslöser frei
melden.
Wenn er noch nicht ausgelöst (nicht reagiert) hat - warten. Beobachten.
Entscheiden. Auf einen stabilen Zustand warten der zur Flanke passt.
Dann auslösen.
Versuchen wir es anders. Die beiden Möglichkeiten sind in erster und letzter Variante abgebildet.
Welche ist jetzt Entprellen und welche Entstören? In welchem konkreten Beispiel soll es vorteilhaft sein Ersteres dem letzten vorzuziehen? Ändert sich die Totzeit/Latenz (z.b. Drehgeber?)
Oder noch einfacher. Für welche Anwendungen bringt es was ggü. der anderen Variante?
1
auslösen, sperren, auslösen, sperren,
2
vs
3
warten, auslösen, warten, auslösen,
(zur Erinnerung, ich hatte nach Beispielen gefragt)
(zur Erinnerung, ich hatte nach Beispielen gefragt)
Mechanische (Gaming-)PC-Tastatur. Verkaufe mal einem Gamer ne Tastatur, die erst 50 oder 100 ms nach dem Drücken das Ereignis an den PC übermittelt. Die wird er dir spätestens nach der ersten LAN-Party um die Ohren hauen. Ebenso schlecht wäre es, wenn die Tastatur jede Prellflanke als separaten Tastendruck an den PC sendet.
Und nun bin ich gespannt, mit welchen haarsträubenden Betrachtungsweisen du dich wieder raus reden willst.
Versuchen wir es anders. Die beiden Möglichkeiten sind
in erster und letzter Variante abgebildet.
Nö, sind nicht.
Deine Signale enthalten keine Fehlimpulse, sondern nur
eine saubere Flanke. Es ist kein Entprellen notwendig.
1.)
"Prellen" bezeichnet die unangenehme Eigenart metallischer
Kontakte, bei EINMALIGER mechanischer Betätigung in kurzer
Zeit eine VIELZAHL elektrischer Impulse zu liefern, an die
sich dann der stabile EIN-Zustand anschließt. Also ungefähr
so:
1
00001000100011010010101101111111111111111111
2.)
"Entprellen" bezeichnet das Beseitigen der Fehlimpulse.
3.)
Eine (verbreitete) Möglichkeit des Entprellens ist
schlicht das Einbauen einer kurzen Wartezeit.
4.)
Ob man die Aktion am Beginn (ähnlich "Holdoff") oder
am Ende ("Latenz") der Wartezeit (einmal) auslöst, ist
in vielen -- aber nicht in allen! -- Fälle egal. Die
Wartezeit hat den Sinn, dass die Aktion nicht MEHRMALS
ausgelöst wird.
5.)
Schlechter Stil ist es, die Aktion selbst so weit zu
verlangsamen, dass Mehrfachauslösungen (auch ohne
explizite "Entprellung") vermieden werden.
Probleme sollten an der Ursache bekämpft werden und
nicht zwanzig Schritte später...
6.)
GANZ schlechter Stil ist es, Entprellung mit dem
Argument einzusparen, die Laufzeit der Aktion sorge ja
von selbst dafür, dass Mehrfachauslösung verhindert
wird. Das kann (und wird irgendwann) gewaltig ins Auge
gehen...
Welche ist jetzt Entprellen und welche Entstören?
Reite doch nicht auf den Worten herum...
Ändert sich die Totzeit/Latenz (z.b. Drehgeber?)
Och menno...
Wenn die Aktion bei der ersten Flanke ausgelöst
wird, ist die Latenz praktisch Null. Ist das nicht
offensichtlich?
Allerdings setzt das Abwesenheit eingestreuter Störungen
voraus...
Oder noch einfacher. Für welche Anwendungen bringt es
was ggü. der anderen Variante?
Die Hauptsache ist, Du verlagerst die Wartezeit nicht
IN DIE AKTION (wo sie nicht hingehört) -- oder sparst
sie gleich ganz ein!
"Prellen" bezeichnet die unangenehme Eigenart metallischer
Kontakte, bei EINMALIGER mechanischer Betätigung in kurzer
Zeit eine VIELZAHL elektrischer Impulse zu liefern, an die
sich dann der stabile EIN-Zustand anschließt.
Ich habe aufgehört zu zählen, wie viele Leute ihm das in diesem Thread bereits versucht haben zu erklären. Es scheint hoffnungslos, weshalb ich es für ratsam halte, ihn in seiner kleinen beschränkten Welt recht haben zu lassen und die eigene Zeit hier nicht weiter mit Gegen-die-Wand-reden zu verschwenden.
Ob man die Aktion am Beginn oder am Ende der Wartezeit
(einmal) auslöst, ist in vielen Fälle egal.
In einigen anspruchslosen Fällen sicher (schnarchlahme Sachen wie Ampelsteuerung). Ob diese aber heutzutage noch die Mehrheit bilden, wage ich zu bezweifeln. Auf jeden Fall ist das ein zimelich sicheres Kriterium, um stümperhafte bzw. schlampige Programmierung zu erkennen.
Ob man die Aktion am Beginn oder am Ende der Wartezeit
(einmal) auslöst, ist in vielen Fälle egal.
In einigen anspruchslosen Fällen sicher (schnarchlahme
Sachen wie Ampelsteuerung). Ob diese aber heutzutage noch
die Mehrheit bilden, wage ich zu bezweifeln.
Nun ja... ich würde diese Logik umdrehen: Ob die extrem
latenzkritischen Anwendungen wie Gamer-Tastaturen die
Mehrheit bilden, wüsste ich nicht mit Sicherheit zu sagen.
Ob eine Lampe mit elektronischem Ein-Aus-Schalter 50ms
später angeht oder nicht, wird ziemlich egal sein.
Das gleiche gilt für die Cursortasten meiner Digitalkamera,
mit denen ich Datum und Uhrzeit einstelle. Wichtig ist,
dass EIN Tastendruck den Wert um genau EINS verändert.
Ob das sofort oder 50ms verzögert passiert, ist mir egal.
Beim AUSLÖSER der Kamera ist das natürlich was anderes...
Auf jeden Fall ist das ein zimelich sicheres Kriterium,
um stümperhafte bzw. schlampige Programmierung zu erkennen.
Das möchte ich bezweifeln.
"Aktion bei der ersten Flanke auslösen" setzt nämlich
vollständiges Fehlen z.B. von eingestreuten Störimpulsen
voraus.
Das gleiche gilt für die Cursortasten meiner Digitalkamera,
mit denen ich Datum und Uhrzeit einstelle. Wichtig ist,
dass EIN Tastendruck den Wert um genau EINS verändert.
Ob das sofort oder 50ms verzögert passiert, ist mir egal.
Mir nicht. 50 ms sind gar nicht so wenig. Eine zwanzigstel Sekunde. Wenn man schnell durch Menüs navigieren will und nicht die Geduld in Person ist, nervt das extrem. Vorallem, weil es einfach unnötig ist.
"Aktion bei der ersten Flanke auslösen" setzt nämlich
vollständiges Fehlen z.B. von eingestreuten Störimpulsen
voraus.
Und woher sollen diese z.B. bei einer Digicam kommen, um mal bei dem Beispiel zu bleiben, wo die Taster einige wenige Zentimeter vom MC auf der Leiterplatte sind? Wenn du da schon Störimpulse hast, dann hast du noch ganz andere Probleme.
Deine Signale enthalten keine Fehlimpulse, sondern nur
eine saubere Flanke. Es ist kein Entprellen notwendig.
Ja -- genau das war meine Antwort.
Ist sie auch immer noch -- erweitert um die Frage, was
Beispielsignale OHNE JEDE FORM VON PRELLEN in einer
Diskussion über ENTPRELLUNG zu suchen haben.
Vielleicht gibt es ja einen guten Grund -- ich sehe ihn
nur im Moment nicht...
Das gleiche gilt für die Cursortasten meiner Digitalkamera,
mit denen ich Datum und Uhrzeit einstelle. Wichtig ist,
dass EIN Tastendruck den Wert um genau EINS verändert.
Ob das sofort oder 50ms verzögert passiert, ist mir egal.
Mir nicht.
Gut; können wir so stehen lassen. Agree to disagree.
50 ms sind gar nicht so wenig. Eine zwanzigstel Sekunde.
Wenn man schnell durch Menüs navigieren will und nicht
die Geduld in Person ist, nervt das extrem.
Kommt auf das Gesamtpaket an. Mit angenehmem Autorepeat
finde ich es nicht nervig.
Viel schlimmer sind prellende Kontakte -- die machen aus
jedem Taster einen Zufallsgenerator. Das nervt nicht nur --
das macht das Gerät schlicht unbrauchbar...
"Aktion bei der ersten Flanke auslösen" setzt nämlich
vollständiges Fehlen z.B. von eingestreuten Störimpulsen
voraus.
Und woher sollen diese z.B. bei einer Digicam kommen, um
mal bei dem Beispiel zu bleiben, wo die Taster einige
wenige Zentimeter vom MC auf der Leiterplatte sind?
Hmm...
Wie war das mit dem "absichtlichen Missverstehen"?
Du hast pauschal -- also ohne einschränkende Bedingung --
behauptet, das Auslösen der "Aktion" NACH Abwarten der
Entprellzeit zeuge von stümperhaften bzw. nachlässiger
Programmierung.
Das sehe ich nicht so; in komplexen Anlagen mit langen
Strippen, Umrichtern etc. halte ich das für nicht
unsinnig.
Dass aber eine Digitalkamera KEIN solches System ist,
steht ja wohl auch außer Zweifel. Entprellung ist aber
nicht auf Digitalkameras und sonstigen Consumer-Krempel
beschränkt...
Hmm...
Wie war das mit dem "absichtlichen Missverstehen"?
Ich rede von "Entprellen", du von "Entstören". Das sind zwei verschiedene Dinge. So weit waren wir auch schonmal, wir drehen uns im Kreis. Aber egal, ich bin jetzt hier endgültig raus.
Du hast pauschal -- also ohne einschränkende Bedingung --
behauptet, das Auslösen der "Aktion" NACH Abwarten der
Entprellzeit zeuge von stümperhaften bzw. nachlässiger
Programmierung.
Das ist so nicht richtig. Er schrieb, dass es ein ziemlich sicheres Kriterium ist. Vor allem auf Deine Aussage hin, es sei in vielen Fällen egal.
Hippelhaxe schrieb:
Ob man die Aktion am Beginn oder am Ende der Wartezeit
(einmal) auslöst, ist in vielen Fälle egal.
In den meisten Fällen ist die Bedienung dann aber einfach schlecht, weil die Rückmeldung dann in Summe eher 200ms dauert als 50 oder 100. Bei den anderen Aktionen wird ja genauso geschludert.
Und dann kommt jedes Mal "aber das braucht niemand". Doch. Man ist einfach nur zu sehr gewohnt, dass elektrische Geräte sehr, sehr langsam sind.
Hmm...
Wie war das mit dem "absichtlichen Missverstehen"?
Ich rede von "Entprellen",
Ich auch.
du von "Entstören".
Nein.
Ich wollte nur darauf aufmerksam machen, dass "Entprellen"
auf einer mit Sicherheit UNGESTÖRTEN Leitung anders gemacht
werden kann als auf einer potenziell GESTÖRTEN.
Und ist das jetzt entstören oder entprellen? (eng: debounce)
Das ist typischer Arduino-Coder-code. würg
Fängt schon damit an, dass die Funktion kein Ergebnis liefert, sondern einen Pointer (auf welchen Wert muss der stehen damit der Krampf funktioniert) ändert.
Man könnte es natürlich auch noch so sehen, dass Prellen eine Art von
Störung ist.
Als Störungen werden gewöhnlich Signale bezeichnet, die nicht mit dem Nutzsignal korreliert sind. Das ist beim Prellen nun so überhaupt nicht der Fall, da das Prellen ursächlich mit dem Schaltvorgang verknüpft ist.
Das war nur Spoon-feeding für diejenigen die keine Fantasie haben die Funktion aufzurufen. Im echten Code ist das Bool nur eines von mehreren Flags für die if Bedingung. ADC für 1V Signal und einstellen der Schaltschwelle, kann man auch auskommentieren.
Funktion zwei und drei werden dort im code eingebaut wo der pin oder die Matrix oder der io Baustein oder was in welcher Form auch immer unentprellt ankommt, bei mir ist es häufig eine Konstellation ca. im 10ms Raster, ich mache das aber grundsätzlich nie im Interrupt.
Im Header kann man festlegen, in Anzahl der Funktionsaufrufe der Funktion zwei:
1.) Entprellzeit
2.) Zeit bis Autorun aktiv wird
3.) Geschwindigkeit des Autorun
4.) Zeit bis lang-drücken aktiv wird
Am "Ausgang" hat man dann zwei Bits/Funktionen die man nutzen kann:
Zur Konfiguration hat man ein Bit pro Taste um Autorun an oder aus zu schalten und eines um "langer Druck" zu aktivieren. Die "Ausgangsbits" kann man dann mit niedriger Frequenz entsprechend abfragen....
Wenn man Autorun aktiviert fängt das (kurzer Druck) Bit nach einer einstellbaren "Zeit" an zu toggeln, wenn man in einem Menü beispielweise Zählerwerte einstellen möchte... o.ä.
Alles in allem habe ich das Zeug schon auf mehreren uc genutzt, es ist einfach gehalten, aber sehr effektiv... natürlich sicher nicht so effektiv wie eine spezifische Assembler Routine, eingebettet in einem timer Interrupt, aber es ist schon sehr einfach gehalten...in c.
Aber ich machs mal in den Anhang, vielleicht regt es ja deine Fantasie
an.
Ich habe versucht es zu verstehen, aber ist mir zu abstrakt. Ich versteh die Sprache nicht. Dein debounce scheint ja auch erstmal den stabilen Zustand mit einem Zeitintervall abzuwarten.
Dein debounce scheint ja auch erstmal den stabilen
Zustand mit einem Zeitintervall abzuwarten.
Ja, das tut es.
Per Default 20ms.
Auch beim loslassen
Diese Reaktionszeit ist kaum fühlbar und reicht um Störungen und prellen zu unterbinden.
In den allermeisten Fällen voll ausreichend.
Herrlich wie bemerkenswert zu lesen, wie sehr man auf einem Thema herumreiten kann.
Ich persönlich würde meinen, dass man die Auswertung von Tasten schlicht an die Anwendung anpasst. Wenn von vornherein klar ist, dass das Abfrageintervall des Zustands Hi-Lo programmbedingt die Prellzeit garantiert(!) überschreitet, kann man theoretisch auf ein Entprellen verzichten und sich nur die erste Flanke anschauen. Praktisch würde ich es dennoch nicht so machen, da ich mich hier von einer Bedingung abhängig mache (Programmlaufzeit), die sich über die Zeit ändern könnte, allein schon, wenn man Optimierungen vornimmt. Klarer und verlässlicher erachte ich, immer eine Entprellung vorzusehen.
Ich für meinen Teil habe es in meinen Hobbyanwendungen immer so realisiert: da ich meistens ohnehin einen Timer am laufen hatte (PIT bei neueren AVR), habe ich den Zustand der Taste(n) per GPIO schlicht alle 1/64 Sekunden (~ 15,6 ms) erfasst. Die durchschnittliche Betätigungsrate eines Menschen (mit einem Finger!) beträgt ~ 5/s, geübte schaffen ~10/s und ganz extreme kurzzeitig ~20/s. Mit 64 Samples pro Sekunde übertreffe ich nun allein diesen Extremwert schon um das 3-fache. Und selbst etwas ältere Tactile Switches hatten immer Prellzeiten von maximal 10 ms. Und ein sehr schneller "Drücker" eines Menschen (also der Geschlossen-Zustand) dauert nach meinen Informationen minimal 30 ms. Aus meiner Sicht also alles im grünen Bereich und die Implementierung hat sich für meine Zwecke im Praktischen auch bewährt. Mit Encodern habe ich nicht gearbeitet, dafür könnte man aber u.a. die Samplingrate dicht an die Grenze der Prellzeit anpassen. Ich würde aber behaupten, dass eine Routine dieser Art für die meisten Anwendungen, die nicht auf extrem schnelle Eingaben angewiesen sind, völlig ausreicht. Zähle ich nebenbei noch die Hi-Zyklen mit, kann ich ab einer bestimmten Zahl problemlos ein Flag setzen das zeigt, ob eine Taste gedrückt gehalten wird. Das Implementiere ich dann einmal und muss nicht darauf achten, wie das eigentliche Programm, das auf die Eingabe reagiert, aufgebaut ist und ob es 1 oder 1000 ms zur Abarbeitung benötigt.
Neben bei? Das ist "alles" was ich tue... Nur halt ohne Obfuscation und vieeel Code, mit dem man sich hier offensichtlich vormacht, die Physik behumpsen zu können. :D
Ich hab mir seine Lib wenigstens mal angesehen, und sogar ernsthaft versucht zu verstehen. Mehr als man vom Rest behaupten kann. Die finden doch nicht mal das Post wieder.
Aber nicht jede Abstraktion führt automatisch zu mehr Klarheit
und Vereinfachung.
Habe ich auch nie behauptet.
Hier ist das innere kompliziert, zugegeben.
Aber die Anwendung ist einfach.
Ausgelegt auf Wiederverwendung.
Mit OOP arbeite ich seit das an turbo pascal geklebt wurde.
Zwischenzeitlich recht viel SPS. Daher auch die konsequente Aufteilung in Funktionsbausteine.
C++ ist mir früher schon mal unter gekommen, verfolge ich aber erst ernsthaft, sein ich 2014 auf Arduino gestoßen bin.
Ach wo wir doch grad schon beim Prellen sind. Ich hab ne neue Maus bestellt. MEINE FRESSE IST DAS NERVIG WENN DIE LINKE MAUSTASTE PRELLT UND DU LAUFEND DOPPELKLICKS MACHST ~keif.
Sorry fürs Geschrei, es ist übrigens das billigste Model von ISY (4468). Nach nem gefühlten Meter Mauspad is die Seriennummer schon halb wegschmiert. Und wie gesagt, die linke Maustaste prellt wohl und ist offensichtlich wenig bis gar nicht entprellt.
Zurückschicken, ist wohl nicht nur billig, sondern Müll.
Dabei hatte ich eigentlich schon gelernt, wer billig kauft, kauft 2mal. Ich dachte wohl "was kann man bei ner Maus schon groß falsch machen...". Die BWLer sind bestimmt schuld :D
Das kann jeder behaupten. Das ist kein C++ mehr. Das ist OOP in C++ das
geht weit über die C++ Grundlagen hinaus.
Mein Senf auch noch. Muss sein. C++ steht für OOP. Es geht um Datenkapslung, ein Kernziel dessen. Das hat nichts mit Grundlagen zu tun. Das sind Grundlagen von C++. Das nutzt jeder schon mehr oder weniger unbewusst mit dem Arduino Framework. Was denkst du was Serial ist? Du nutzt doch bspw. Serial.print(). Dabei ist print eine Methode von der Instanz Serial. Das ist in dem Fall keine Methode von Serial1 oder Serial2. Da sind wir schon beim Thema Datenkapslung. Ich sage einmal so ganz frech. Wer OOP nicht möchte, was sein gutes Recht ist, der bleibt bei C. Nur, alles was C++ zur Verfügung stellt ist und bleibt C++. Da kann niemand behaupten das wäre kein C++. Der Unterschied den es gibt ist nur der, dass es Programmierer gibt die die Möglichkeiten des Sprachstandards mehr oder weniger nutzen. Arduino F. nutzt ihn sehr, was mich freut. Solange er alles mit Sprachstandard C++11 erschlagen kann, solange kann das jeder Arduino User 1:1 verwenden. Warum? Weil C++11 die Standardeinstellung der Arduino IDE ist. Alles andere erfordert paar Klimmzüge.
Bei Dir weiß man immer schon vorher was Du als nächstes schreiben wirst,
Du bist ein schönes Trollfutter mit Deinem Therapeutenkomplex.
Duzt du dich jetzt schon selbst? Von Therapie hast bisher nur du geschwafelt, als du erwähntest dass du entweder in 21 Tagen das Buch "C++ lernen" gelesen hast während deiner Therapie oder du währemd deiner Therapie das Buch "C++ lernen in 21 Tagen" gelesen hast.
Aber ich fühl mich einfach mal angesprochen, was wird denn in meinem nächsten Beitrag stehen? Ich bin gespannt, mein kleiner Hellseher.
Knapp daneben ist auch vorbei. Der Bezug deiner Vorhersage zum tatsächlichen Inhalt meines nächsten Beitrags ist etwa so groß wie dein Verständnis von Debouncing.
Für die Shooter-Freaks (kurze Latenz) könnte man diskutieren die erste
Änderung an die Anwendung weiter zu geben und eine Änderung des von der
Anwendung gesehenen Tastenzustands erst nach einer gewissen Zeit wieder
zuzulassen.
Selbst wenn die den Finger auf der Taste haben und man sie mit einem
kräftigen Taser beglückt, werden sie kaum mehr als 20 pro Sekunde
schaffen.
Aber es ist natürlich sinnvoll, den EIN-Zustand (bei dem Prellen
stattfinden kann) sofort zu vermitteln, den Wechsel in den AUS-Zustand
mindestens um den Prell-Zeitraum zu verlängern.
Dafür lässt sich dann allerdings kein LONG/SHORT/DOUBLE Klick vernünftig
unterscheiden.
Ich glaube ich habe das auch schon irgendwo gemacht.
Damit ein pressed/released-Event ausgelöst werden kann, mit Berücksichtigung von ms und Latenzzeiten, müssen die Zeiten natürlich irgendwo gespeichert werden. Eine Unterscheidung zwischen short/long press/release ist hier schon möglich, allerdings kein DoubleClick. Hier könnte man aber einen weiteren Layer drüber bauen, falls es geht.
Hallo Ihr lieben Mods,
leider hier ist ein priv. Krieg ausgebrochen... :´(
Ich hoffe es wird alles wieder ruhig. Mikrocontroller kenne ich eigentlich gar nicht ohne "krieg" ;.) Irgendwo brennt immer ein Feuer ;-)
Vielleicht ist das für uns normal. Wie viele Drähte und Stecker ich als Kind in die Steckdose gesteckt habe, wie oft es mir eine "gewischt" hat und an den Geruch explodierender ELKOs, schwarze Flecken an der Decke bei Chemie-Experimenten im Kinderzimmer, kann ich mich noch gut erinnern.
Ich bereite gerade einen entspannten Beitrag/Antwort vor, in dem ich einige erklären muss/werde und auch den ein oder anderen Fehler meinerseits zugestehen darf.
Selbst wenn die den Finger auf der Taste haben und man sie mit einem
kräftigen Taser beglückt, werden sie kaum mehr als 20 pro Sekunde
schaffen.
Sag mir das du Latenz nicht verstanden hast ohne mir zu sagen das du
Latenz nicht verstanden hast...
Vielleicht kann man das, was Norbert meint auch als eine Art Latzenz verstehen. Ich glaube man kann das aus verschiedenen Ebenen/Flughöhen betrachten und es ist auch nicht immer relevant.
Ich bin mir aber auch nicht immer sicher, ob es eine Latenz ist oder eine Verzögerung. Letzteres ist für mich absichtlich, deterministisch und in einem gewissen Maß kontrollierbar, vielleicht auch gewollt.
Wenn die Tastenerkennung Timer-gesteuert ist und eine gewisse Zeit vergeht, bis der neue State erkannt wird, ist das für mich eine Latenz.
Wenn ich ein Netzwerk-Paket von A nach B sende, ist die Zeit, die zur Übertragung gebraucht wird für mich auch eine Latenz.
Wenn mein Wasserkocher 3 Minuten braucht ist das für mich keine Latenz, sondern eine Zeitdauer.
Wenn ich jemand anrufe und es 2 Minuten dauert bis der Andere dran geht,
ist das auch eine Zeitdauer (Wartezeit).
Wenn die Audio/Video Übertragung dann langsam ist, würde ich das persönlich wieder Latenz nennen.
Wenn wir ganz ins Klein-Klein gehen, haben vielleicht sogar unsere Nerven eine Latenz. Beispiel: Du Drückst die Taste, der Kontakt schließt sich, das Signal kommt am Micro an und dein Code ruft den State ab und reagiert. Parallel passiert aber glaub ich noch was Anderes: Du drückst Die Taste, deine Nerven im Finger reagieren auf das Druckgefühl. Es wird weitergeleitet über die Synapsen, bis Du im Häuschen den Tastendruck wahr nimmst. Nach meinem Verständnis ist das auch eine Latenz.
Ich weiss nicht, ob ich mit meinem Gefühl da richtig bin.
LG
Bei Dir weiß man immer schon vorher was Du als nächstes schreiben wirst,
Du bist ein schönes Trollfutter mit Deinem Therapeutenkomplex.
Duzt du dich jetzt schon selbst? Von Therapie hast bisher nur du
geschwafelt, als du erwähntest dass du entweder in 21 Tagen das Buch
"C++ lernen" gelesen hast während deiner Therapie oder du währemd deiner
Therapie das Buch "C++ lernen in 21 Tagen" gelesen hast.
Aber ich fühl mich einfach mal angesprochen, was wird denn in meinem
nächsten Beitrag stehen? Ich bin gespannt, mein kleiner Hellseher.
KA um was es geht. Als ich mir ende der 80er ein Turbo Pascal 4 Buch bestellt hatte in der Erwartung, dass IDE und Compiler dabei sind, wurde ich häftig enttäuscht und und bin mit Buch von W/V Kassera 3 Wochen in den Italien Urlaub (ich glaub ich war damals 11 oder 12 Jahre alt). Ohne Compiler - nur das Buch. Ich hatte gerade angefangen mit Programmieren, ein paar Spiele in Computer-Zeitschriften veröffentlicht (QuickBasic 4.5) und wollte auf TP4. Was "Integer" bedeutet konnte mir mein Pa so halbwegs erklären. Zurück aus dem Urlaub habe ich über B. dann auch den Compiler bekommen und konnte fast auf anhieb damit los legen.
Visual C++ in 21 Tagen hab ich auf Therapie gelesen danke. Hatte nur
keinen Computer auf Station.
Ich kann bestätigen, dass das geht und unterstütze die Aussage.
Wie viel man dann damit anfangen kann, steht auf einem anderen Blatt.
Wer noch die "PC Intern" Wälzer von Michael Tischer kennt. Diese habe ich in meiner Freizeit im Internat gelesen, anstatt Hausaufgaben zu machen - auch ohne Computer. Computer gabs nur von Freitag Abend bis Sonntag Mittag. Aber zur der Zeit habe ich alles in mich rein gesaugt.
Auf Therapie war ich auch schon, etwas länger (3 Monate) (wegen den Klassikern) aber habe in meiner Freizeit und aus Langeweile die Planungs-Software für meinen damaligen Arbeitgeber neu geschrieben.
Ich habe mir auf die gleiche Weise Turbo Pascal bei gebracht (nach Quick Basic 4.5) und habe mir des Buch im Urlaub echt wirklich "reingezogen".
Den Compiler und die IDE bekam ich erst nach dem Urlaub. Aber nun konnte ich alles ausprobieren und der Einstieg war echt motivierend.
C++ in 21 Tagen zu lesen ist bestimmt geil. Erstens, wer schätzt heute noch das "Lesen", ein Buch in den Händen zu halten, das Cover, den Einschlag, das Gewicht zu fühlen, es zu riechen, die einzelnen Seiten anzufassen, die mittlere Seite auf zu machen, die Nase rein stecken und ganz tief den Geruch und Smell des frisch gedruckten Papiers einzuatmen, oder auch einen schutz-Einband aus Folie wie in der Schule um das Buch zu machen, weil es einem was Wert ist, zu gucken ob hinten Fotos von den Autoren drauf sind, in Seiten was rein zu kritzeln, den Kugelschreiber währen der Kaffee-Pause als Merker zu machen oder Post-Its rein zu kleben.
Ein Buch hat so viel mehr als nur Seiten mit Text.
Ich werde hier im Forum von J. T. (chaoskind) persönlich betreut. Er versucht seit meiner Anmeldung mir die Welt zu erklären. Leider fruchtet es nicht!
OMG! Schon wieder ein ChatGPT Experiment? Viel reden und wenig sagen.
Liegt im Trend, wie leben in der Laberkratie.
Ich möchte hier kurz ein ein Statement abgeben - vielleicht wird es auch länger ;-)
den Debounce-Algo habe ich für mein DIY-Stream-Deck entwickelt und alles selber raus gefunden. Dass es bestimmt schon coolere und ausgereifter Libs gibt, hatte ich schon im Hinterkopf - aber es hat mir mehr spaß gemacht, selber etwas raus zu finden. Ich finde es immer toll, wenn man eine eigene Lösung findet und nicht fertige Sachen benutzt oder einfach abschreibt -
insbesondere wenn man (also ich) noch einiges dazu lernen darf.
Da ich es noch nicht geschafft habe, das ganze Projekt zu releasen, wollte ich zumindest einen Teil davon veröffentlichen und da kam mir die Idee zu dem Artikel. Ich habe erst mal alles grob in Rohfassung geschrieben und dann tatsächlich ChatGPT darum gebeten es "rund" zu machen und einen Artikel zu schreiben, den ich hier veröffentlichen kann.
Über das Ergebnis habe ich dann noch mal manuell drüber gearbeitet und das wars dann.
Ich möchte mich dafür entschuldigen. Ich habe selber gemerkt, es geht irgenwie die Authentizität verloren. Du hast es ja selber schon gemerkt.
Ich finde es grundsätzlich okay, wenn man KI einsetzt. Noch wichtiger ist es aber, dass man sich selber anstrengt, den Denk-Kasten verwendet und nicht alles abschreibt oder schreiben lässt.
Hier war jetzt genau mein Fehler: es sollte schnell gehen, es sollte sich toll lesen, auch für newbies verständlich sein (z.b. debouncing noch mal erklären), nicht nur ein 3-zeiler sondern etwas mehr.
Den nächsten Artikel (vermutlich das DIY-Stream-Deck) schreibe ich dann einfach wieder selber, auch wenn vielleicht nicht perfekt.
Ein einfacher und robuster Stabilitätsfilter für
Mikrocontroller-Eingaben.
Interessant wie sich die Ansichten über "was einfach" ist, gewandelt
haben,
zwanzig Zeilen code bis zur vierten Verschachtelungsebene.
Einen Nachweis der Robustheit findet man jetzt auch nicht ansatzweise,
OK Robustheit erklärt sich auch eher aus der Betrachtung des
Gesamtsystems, nicht an Detail-Implementierungen.
Aber faszinierende Wortfindungen: "Stabilitätsfilter", "Candidate
pattern", "Roh-zustand". Persönlich bevorzuge ich Blockbilder bei der
Erklärung der Funktionsweise, ok ist bei einem Forum wie diesem etwas
schwierig.
funktioniert mit ... IO-Expander oder anderen
Eingabemechanismen
Die Frage dabei ist, wieviel eine Entprellung in einem nachgeschalteten
µC bei einem I²C Portexpander Sinn macht. Die Entprellung, also der
Tiefpass ist in dem Fall Bestandteil des IO-Expanders. Oder der des
Schaltplans/PCB (RC-Glied).
Jedenfalls ein anregender Beitrag, werd ich wohl als "Hardwarker" eher
nicht nutzen, aber für diese war es wohl auch nicht gedacht.
Hi und danke für das Feedback.
Ehrlich gesagt gibt es in dem Artikel ein paar Wortfindungen, die tatsächlich ChatGPT erfunden hat (dazu habe ich bereits eine Antwort vorhin geschrieben). Ich habe ja heute auch schon einiges geschrieben dazu.
Dass manche Wortfindungen Quatsch sind, gebe ich gerne zu.
mit Stabifilter ist gemeint, dass der gemessene Zustand stabil ist, also eigentlich der Output des Debounce. Das Eingangssignal kann ja instabil sein. Technisch ist das vermutlich ein Quatsch, da ja keine Stabilität gefiltert wird.
Eine Kandidat-Variable gibt es bei mir tatsächlich. Das war so meine ursprüngliche Idee. Anstatt mit timings und delays zu arbeiten,
bin ich auf diese Idee gekommen. Nur wenn ein Kandidat stabil ist, kommt
er ins Team. Ich habe versucht herauszufinden, ob es für diese Vorgehensweise, also S/W-Seitig schon einen Namen gibt, bin aber leider nicht fündig geworden. Deswegen habe ich mich getraut, es mal candidate-pattern zu nennen.
Hardwareseitig halte ich mich jetzt mal raus, da ich hier nur ganz wenig Wissen habe.
Wie schon geschrieben wurde, ist das Vorgehen bzgl. gefühlter
Verzögerung suboptimal. Wenn die einzigen „Störungen“ im Signal vom
Prellen des Schalters stammen, ist es nicht nötig, das Signal erst dann
als aktiv zu bezeichnen, wenn der Prellvorgang abgeschlossen ist. Das
Signal ist gültig, sobald die erste Änderung erkannt wird. Die
Entprellung muß dann nur dafür sorgen, daß alle nachfolgenden Änderungen
ignoriert werden, bis das Signal stabil ist.
Anders ist es, wenn es auf der Leitung auch Störungen gibt, die nicht
vom Schalter kommen. Dann ist das Abwarten auf einen stabilen Zustand
sinnvoll.
Aber wie ja auch schon geschrieben wurde, gibts ja schon unzählige
Routinen, für alle möglichen Anforderungen, und es wurde trotzdem noch
nicht alles erfunden, und erst recht nicht von jedem.
Oliver
Hallo Oliver,
danke für den konstruktiven Beitrag. Da kann ich auch noch was lernen.
Lässt deine Variante auch zu, zwei Tasten gleichzeitig zu drücken ?
Ich versuche mal das ganze Projekt zu veröffentlichen und vielleicht erklärt sich dann einiges.
Eine Kandidat-Variable gibt es bei mir tatsächlich. Das war so meine
ursprüngliche Idee. Anstatt mit timings und delays zu arbeiten,
bin ich auf diese Idee gekommen. Nur wenn ein Kandidat stabil ist, kommt
er ins Team. Ich habe versucht herauszufinden, ob es für diese
Vorgehensweise, also S/W-Seitig schon einen Namen gibt, bin aber leider
nicht fündig geworden. Deswegen habe ich mich getraut, es mal
candidate-pattern zu nennen.
Bei pattern denkt man halt an design pattern der Versuch alles auf ein paar Grundverfahren zu abstrahieren.
In der Signaltheorie könnte man auch einige Filtertypen und verdrahtete Logic wie ein design pattern nutzen.
Und beim Tastenentprellen ist es halt klassischerweise ein Tiefpass, der eben höher frequente aka schnelllebige Änderunge "abblockt" resp. wegfiltert. Eine Pulslängenbewertung durch einen Zähler ist da auch nur eine spezielle Implementierung, da wird eben die zur Frequenz reziproke Periodendauer ermittelt.
