Entprellen von Tasten mit dem Candidate-Pattern
-----------------------------------------------
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:
1. Rohzustand der Tasten lesen (rawMask)
2. Prüfen, ob sich der Kandidat geändert hat
3. Wenn ja → neuen Kandidaten setzen und Zähler zurücksetzen
4. Wenn nein → Zähler erhöhen
5. 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
--------------------------
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.
RC-Filter (Hardware)
- Prinzip: Analogfilter glättet das Signal
- Vorteile: sehr einfach, keine CPU-Last
- Nachteile: zusätzliche Bauteile, feste Zeitkonstante
Timer-Debounce
- 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.
Vorteile:
- plattformunabhängig
- geringer Rechenaufwand
- funktioniert mit beliebig vielen Tasten
- keine Timer pro Taste notwendig
- saubere Event-Erzeugung
Andreas T. schrieb:> Ich möchte die Idee mit diesem Artikel teilen.
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.
LG, Andy
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.
G. K. schrieb:> 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.
Norbert schrieb:> 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...
> 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.
Rene K. schrieb:> Sag mir das du Latenz nicht verstanden hast ohne mir zu sagen das du> Latenz nicht verstanden hast...
Unsinn!
Nicht nur die Worte ansehen, auch die Bedeutung erkennen!
Bei 20 Tastendrücken pro Sekunde kann die Latenz wohl kaum größer als
50ms sein.
Andreas T. schrieb:> 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).> (ich) nenne sie Candidate-Pattern.
Oh wow! Danke für den neuen Namen.
(Raider heißt jetzt Twix, und Twitter heißt X)
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
Oliver S. schrieb:> 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. ;)
Falk B. schrieb:> 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.
Arduino F. schrieb:> Und meine Variante ist die Beste.> (Nur eben nicht für jeden)
Konkreter: für genau einen, nämlich dich.
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.
Nemopuk schrieb:> 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.
Johannes F. schrieb:> 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!?
Ich finde im Forum sollten klare Verhältnisse herrschen.
KI-generierte Inhalte sind als solche deutlich zu kennzeichnen. Inhalte
die sich nicht daran halten bitte rigoros löschen!
Alexander schrieb:> 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.
Andreas T. schrieb:> (Neu): Candidate-Pattern>> Prinzip: neuer Zustand wird erst nach stabiler Dauer akzeptiert> Vorteile: flexibel, effizient> Nachteile: benötigt zyklischen Aufruf
Nicht wirklich neu, aber ungünstig programmiert.
Peter Danneggers code macht das besser.
Dein AI code betrachtet alle Tasten auf ein Mal, nicht jede einzeln.
Ein Betätigung einer Taste blockiert bis zum DEBOUNCE_COUNT auch die
Flankenerkennung der anderen, schon lange stabilen Tasten.
Andreas T. schrieb:> - 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.
Das gilt auch für den Fall der fallenden Flanke.
Andreas T. schrieb:> nenne sie Candidate-Pattern
Toller Name! Muss jetzt das gang-of-four-Buch umgeschrieben werden?
Bradward B. schrieb:> 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.
Johannes F. schrieb:> Leider ist der KI-Ursprung aber nicht immer so offensichtlich und> eindeutig erkennbar wie hier,
Deswegen die Pflicht des Veröffentlichers.
Alexander schrieb:> Johannes F. schrieb:>> Leider ist der KI-Ursprung aber nicht immer so offensichtlich und>> eindeutig erkennbar wie hier,>> Deswegen die Pflicht des Veröffentlichers.
Die Forderung ist ein bisschen naiv. Es wird genug geben die sich nicht
dran halten werden.
Andreas T. schrieb:> Die folgende Idee habe ich
nicht bedacht
"Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang"
kann ich dir die Rechnung schicken für mein Scrollrad?
Hannes J. schrieb:> 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.
Norbert schrieb:> 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.
Andreas T. schrieb:> RC-Filter (Hardware)> ...
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.
Andreas T. schrieb:> (Neu): Candidate-Pattern
Genau betrachtet: alter Wein in neuen Schläuchen.
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.
Andreas T. schrieb:> 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.
Rainer W. schrieb:> 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.
Nemopuk schrieb:> 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.
Michael B. schrieb:> Vor allem ist deine Besserwisserei komplett unrelevant, wenn es> funktioniert.
Naja, wer sich an besseren Wissen stösst, sollte Foren zum Wissenstausch
und -erweiterung fernbleiben.
>> 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.
Hallo Andreas.
Andreas T. schrieb:> Entprellen von Tasten mit dem Candidate-Pattern> ----------------------------------------------->> 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
Mit freundlichem Gruß
Bernd Wiebus alias dl1eic
http://www.dl0dg.de
Norbert schrieb:> 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.
Bernd W. schrieb:> 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.
Rainer W. schrieb:> 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.
Rainer W. schrieb:> 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.
Hallo Rainer W.
Rainer W. schrieb:>> 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.
Mit freundlichem Gruß:
Bernd Wiebus alias dl1eic
http://www.dl0dg.de
Bernd W. schrieb:> 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:
- https://www.lothar-miller.de/s9y/categories/5-Entprellung
-
https://www.lothar-miller.de/s9y/archives/18-Flinke-Flankenerkennung.html
Als Tipp: diese Ansätze mit den Schieberegistern lassen sich auch
einfach in Software packen...
Bernd W. schrieb:> Rainer W. schrieb:>> 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.
Bradward B. schrieb:> das ein RC-Glied sehr wohl das prellende Signal eines Schalter/Taster> glättet.
Aber eben nicht entprellt, sondern bestenfalls "entstört".
Bernd W. schrieb:> 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.
Rainer W. schrieb:> 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.
Alexander schrieb:> 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.
Alexander schrieb:> Warten oder reagieren. Ersteres ist Entprellen, letzteres nicht.
man kann vor dem Reagieren warten oder erst reagieren und dann warten.
Beides ist entprellen. Ersteres ist auch noch entstören
Alexander schrieb:> 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.
Alexander schrieb:> Warten oder reagieren. Ersteres ist Entprellen, letzteres nicht.
Worauf willst du warten, wenn doch völlig klar ist, dass ein
Energieeintrag stattgefunden hat.
Rainer W. schrieb:> Aber er fängt nicht aus heiterem> Himmel an zu schwingen.
Bei Alexander weiß man das nie.
R. L. schrieb:> man kann vor dem Reagieren warten oder erst reagieren und dann warten.> Beides ist entprellen. Ersteres ist auch noch entstörenRainer W. schrieb:> schwingt es eben und kann in Folge dessen> mehrere Kontaktereignisse auslösen.
So hatte ich es gemeint.
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)
Hallo Rainer.
Rainer W. schrieb:> 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......
Mit freundlichem Gruß:
Bernd Wiebus alias dl1eic
http://www.dl0dg.de
Bradward B. schrieb:> Michael B. schrieb:>> Vor allem ist deine Besserwisserei komplett unrelevant, wenn es>> funktioniert.
Du hast vergessen den Namen aus dem Zitat zu löschen, jetzt weiß man ja,
wen du gemeint hast.
Bradward B. schrieb:> Naja, wer sich an besseren Wissen stösst, sollte Foren zum Wissenstausch> und -erweiterung fernbleiben.
Besseres (im Sinne von "gut, guter, gutesten ;-) ) Wissen !=
Besserwisserei.
Warum muss man dir eigentlich immer die einfachsten Grundlagen des
Lebens erklären?
Alexander schrieb:> Rainer W. schrieb:>> 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.
Quatsch.
Alexander schrieb:> reicht nicht zum Entprellen, das wäre reines Triggern.
Nochmal Quatsch.
Halte dich doch einfach bei Fachgebieten raus, von denen du keine Ahnung
hast. SCNR.
Rahul D. schrieb:> Was soll der Controller dann machen?
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.
Johannes F. schrieb:> Fachgebiete
Mag sein dass ich Entstören mit Entprellen verwechsele, vielleicht ist
das zu oberflächlich betrachtet.
Ich überlasse das spannende Fachgebiet den Fachmännern, woohoo
Alexander schrieb:> Mag sein, dass ich Entstören mit Entprellen verwechsele, vielleicht ist> das zu oberflächlich betrachtet.
Du kostest anderer Leute Lebenszeit.
Alexander schrieb:> 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.
Alexander schrieb:> Ich überlasse das spannende Fachgebiet
Überhaupt nicht spannend, sondern absoluter MC-Urschleim, den man
normalerweise als absoluter Neueinsteiger lernt.
Johannes F. schrieb:> Es geht beim Entprellen darum, das "Triggern" eben so lange zu sperren,> bis das Prellen beendet ist.
Alles nach dem Triggern (also auch das Sperren) gehört für mich schon
zur Aktion:
Nemopuk schrieb:> Weil z.B der Tastendruck eine Ausgabe bewirkt, die bereits länger> dauert, als das Prellen.
Alexander schrieb:> 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.
https://github.com/aIecxs/Lime_Gen3_IoT_Replacement/blob/9a69d2f/LimeIoT/loop.ino#L48
Alexander schrieb:> Erzähle mir wie Du entprellen willst mit einer Latenz von = 0. Das ist> das was ich kritisiert habe.
Das haben bereits andere zuvor in diesem Thread hinreichend beschrieben.
Was genau verstehst du daran nicht?
Ich verstehe nur das womit ich schon mal zu tun hatte. Ich habe jetzt
zwei Beispiele genannt bei denen es nicht ohne Latenz geht.
Gib mir doch mal ein echtes Beispiel aus der Praxis. Ich lese hier nur
einen unausgegorenen Vorschlag von G. K. (zumsel)
Oder beziehst Du Dich auf den KI-Slop vom TE - den hab ich nicht
gelesen.
Alexander schrieb:> Gib mir doch mal ein echtes Beispiel aus der Praxis.
Siehe Artikel Entprellung. Das erste Diagramm in der Einleitung sagt
eigentlich schon alles.
Alexander schrieb:> Oder beziehst Du Dich auf den KI-Slop vom TE - den hab ich nicht> gelesen.
Nein.
Alexander schrieb:> reicht nicht zum Entprellen, das wäre reines Triggern.
Das Entprellen findet HINTERHER statt, d.h. in der Zeit, während der das
schwingende System seine Energie abbaut.
Was willst du jetzt mit dem gezeigten Neigungsschalter sagen?
p.s.
Auf englisch heißt das Ding übrigens "tilt switch". Mit Kacheln hat das
Ding nun so gar nichts zu tun.
Johannes F. schrieb:> Siehe Artikel Entprellung.
Ich habe nach einem Beispiel aus der Praxis gefragt. Das Wiki kenne ich.
Welches ist die Variante ohne Latenz?
Alexander schrieb:> 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.
Alexander schrieb:> Welches ist die Variante ohne 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.
Rolf schrieb:> Dass man diese Zeit praktisch zu null machen kann, hat man dir> inzwischen mehrfach erklärt.
Jo. Dazu braucht es nicht mal einen Mikrocontroller.
Alexander schrieb:> 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.
Alexander schrieb:> Beim anderen Szenario Auslösen bei erster Flanke erschließt sich mir der> Sinn von Entprellen nicht, die Aktion wurde bereits ausgelöst.
Um z.B. zu verhinder, dass ein Zähler für Werkstücke zu einem Zähler für
Prellimpulse wird.
Aber jetzt, nach über 80 Beträgen, sollte die Prellzeit vorüber sein.
Also der TO hat den Anspruch eine grundsätzliche
"Lösungsschablone"/Entwurfsmethode aka "pattern" vorzustellen.
* https://de.wikipedia.org/wiki/Entwurfsmuster
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".
https://www.dwds.de/wb/Relaxation
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.
Nick schrieb:> 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.
Alexander schrieb:> 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.
Alexander schrieb:> 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.
Rainer W. schrieb:> 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.
Alexander schrieb:> Warum sollten sie das? Die Aktion hat eine Laufzeit (mit eigener> Sperrzeit)
Wenn deine Applikation, nur ca. alle 20ms zeit hat, um sich um Tasten
oä. zu kümmern, hast du ganz andere Probleme, als Prellende Kontakte!³
PS: Ich kanns nicht glauben! Ich glaubs einfach nicht! ... Ich muss es
glauben. 8´(
Alexander schrieb:> 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.
Und wie unterscheidest Du echtes von falschem Zählen? Richtig, indem man
nur stabile Flanken auswertet. Das impliziert eine Latenz.
Wenn Du nicht Willens bist die Sperrzeit korrekt in Deine Aktion
einzubauen ist das Deine Entscheidung.
Ändert aber nichts an der Wartezeit die sich ergibt bis dein Taster
entprellt ist.
Alexander schrieb:> stabile
bedeutet, es ändert sich nichts.
Alexander schrieb:> Flanken
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.
Alexander schrieb:> Wenn Du nicht Willens bist die Sperrzeit korrekt in Deine Aktion> einzubauen ist das Deine Entscheidung.>> Ändert aber nichts an der Wartezeit die sich ergibt bis dein Taster> entprellt ist.
Da muss doch nicht die "Aktion" warten, es reicht doch wenn man die
Tastenabfrage, bzw. deren Ergebnis ignoriert.
Alexander schrieb:> 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.
Oliver
Alexander schrieb:> Und ist das jetzt entstören oder entprellen?
Das ist fürchterlich!
Die statischen Variablen machen die sorgenfreie Wiederverwendug kaputt.
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)
Alexander schrieb:> 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.
Alexander schrieb:> analogReadMilliVolts() ist ja an sich schon.
Zunächst einmal ist analogReadMilliVolts() keine Standard Arduino
Funktion und kann daher sonstetwas machen.
Bruno V. schrieb:> Aber es müssen schon sehr spezielle Anforderungen gewesen sein. Oder> einer Deiner ersten Versuche.
In der Tat beides. Aufruf ist in Post #71 verlinkt. Es läuft in der
loop() ohne delay, keine Ahnung wieviel Millionen mal das aufgerufen
wird.
Alexander schrieb:> 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".
J. T. schrieb:> 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.
Ist aber nur meine persönliche Sicht.
Hippelhaxe schrieb:> Auch wenn das nicht exakt zum Thema passt: Ich wünsche allen> Pfuschern wie Dir eine intensive Behandlung mit dem Therac-25.
Solang man sich beim Eingeben Zeit lässt, war das Teil doch toootal
zuverlässig ;-) :D
Alexander schrieb:> 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...
Hippelhaxe schrieb:> Ironischerweise stimmt das -- nur gibt es für diese> Wartezeit zwei Verschaltungsmöglichkeiten:Alexander schrieb:> Warten oder reagieren.Alexander schrieb:> Rahul D. schrieb:>> Was soll der Controller dann machen?>> 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)
Alexander schrieb:> (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.
Alexander schrieb:> 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!
Hippelhaxe schrieb:> "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.
Hippelhaxe schrieb:> 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.
Alexander schrieb:> Alexander schrieb:>> Selbst wenn bei der PC-Tastatur die erste Flanke die Aktion auslöst,>> übernimmt die Aktion mit ihrer Sperrzeit doch die Anschlagsverzögerung.
Und welche "Aktion" mit welcher "Sperrzeit" soll das bei einer Tastatur
bitte sein?
Johannes F. schrieb:> Hippelhaxe schrieb:>> 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.
Hippelhaxe schrieb:> 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.
Hippelhaxe schrieb:> "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.
Hippelhaxe schrieb:> https://de.wikipedia.org/wiki/Fragezeichen
Ich habe geschrieben:
Alexander schrieb:> Versuchen wir es anders. Die beiden Möglichkeiten sind in erster und> letzter Variante abgebildet.>> + Varianten aus Lothar's 8-Bit flinken Flankenerkennung (Schaltempfindlichkeit)
Deine Antwort dazu war:
Hippelhaxe schrieb:> Deine Signale enthalten keine Fehlimpulse, sondern nur> eine saubere Flanke. Es ist kein Entprellen notwendig.
Alexander schrieb:> Johannes F. schrieb:>> Und welche "Aktion" mit welcher "Sperrzeit" soll das bei einer Tastatur>> bitte sein?>> Alexander schrieb:>> Anschlagsverzögerung>> keine Ahnung vielleicht 5 ms
Kein Kommentar.
Alexander schrieb:> Ich habe geschrieben:>> Alexander schrieb:>> Versuchen wir es anders. Die beiden Möglichkeiten sind>> in erster und letzter Variante abgebildet.>>>> + Varianten aus Lothar's 8-Bit flinken Flankenerkennung>> (Schaltempfindlichkeit)
Ähhh... was wird das jetzt?
Beweis durch verwirrende Verweise?
Der relevante Abschnitt aus Beitrag #8020870 ist:
1
Versuchen wir es anders. Die beiden Möglichkeiten sind in
2
erster und letzter Variante abgebildet.
3
4
if (sr="11111110")... << sofort beim Wechsel 1->0
5
if (sr="11110000")... << bei "sauberer Flanke" 1->0 (kritisch)
6
if (sr="10000000")... << wenn Wechsel 1->0, und 0 liegt stabil
7
8
Welche ist jetzt Entprellen und welche Entstören? In welchem
9
konkreten Beispiel soll es vorteilhaft sein Ersteres dem letzten
10
vorzuziehen? Ändert sich die Totzeit/Latenz (z.b. Drehgeber?)
Keins der abgebildeten Signale weist irgend eine Form von
PRELLEN auf.
Was haben diese Beispielsignale in einer Diskussion über
ENTPRELLUNG zu suchen?
> Deine Antwort dazu war:>> Hippelhaxe schrieb:>> 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...
Johannes F. schrieb:> Hippelhaxe schrieb:>> 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...
> Hippelhaxe schrieb:>> "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...
Hippelhaxe schrieb:> Ähhh... was wird das jetzt?> Beweis durch verwirrende Verweise?
Kannst selbst nach Hinweis nicht erkennen dass das keine Signale sind,
sondern Filter 1:1 copy-paste aus Lothar's Link!?
Hippelhaxe schrieb:> 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.
Hippelhaxe schrieb:> 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.
Johannes F. schrieb:> Hippelhaxe schrieb:>> 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.
Das hat nichts mit "Schlampigkeit" zu tun.
> sind zwei verschiedene Dinge.
... die sich beeinflussen (können).
Alexander schrieb:> 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.
Die Diskussion wird immer unterirdischer!
Alexander schrieb:> Hippelhaxe schrieb:>> Ähhh... was wird das jetzt?>> Beweis durch verwirrende Verweise?>> Kannst selbst nach Hinweis nicht erkennen
Das Thema lautet "Entprellung", nicht "Die Blödheit
von Hippelhaxe".
Äußere Dich in klaren Worten mit klarem Bezug zum
Thema, und wir können weiterdiskutieren.
Wenn nicht, dann nicht.
J. T. schrieb:> 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.
Alexander schrieb:> für diejenigen die keine Fantasie haben
Die scheint mir für deinen Code zu fehlen.
Auch bin ich kein Fän von if, je komplizierter die Bedingungen, oder
auch Verschachtelungen, desto unbeliebter bei mir.
Viel weiter vorn im Thread habe ich ja schon gezeigt, wie man meine
Zeitglieder in der Arduino Praxis einsetzen könnte.
OK, ist nicht gut angekommen...
Muss ja auch nicht...
Aber ich machs mal in den Anhang, vielleicht regt es ja deine Fantasie
an.
...ich habe dafür einfach eine kleine c-datei, darin sind vier
Funktionen:
1.) bnt_init()
2.) btn_pushed(btn_nr)
3.) btn_release(btn_nr)
4.) btn_is_pused(btn_nr)
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:
1.) Entprelltes Tastenbit (kurzer Druck)
2.) Entprelltes Tastenbit (langer Druck)
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.
Rainer W. schrieb:> Als Störungen werden gewöhnlich Signale bezeichnet,
Bei Alecxs haben wir es aber möglicherweise nicht mit einem gewöhnlichen
User zu tun.
J. T. schrieb:> Rainer W. schrieb:>> Als Störungen werden gewöhnlich Signale bezeichnet,>> Bei Alecxs haben wir es aber möglicherweise nicht mit einem gewöhnlichen> User zu tun.
Möglicherweise keine gewöhnliche Störung.
Arduino F. schrieb:> 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.
Alexander schrieb:> Ich versteh> die Sprache nicht.
Das kannst nur du ändern.
Es ist C++ in der Variante C++11.
Der Standard für AVR Arduino.
Läuft auch unter C++23
Alexander schrieb:> 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.
Alexander schrieb:> Das kann jeder behaupten. Das ist kein C++ mehr. Das ist OOP in C++ das> geht weit über die C++ Grundlagen hinaus.
Jetzt wird dein denken wirklich absurd.
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.
Florian S. schrieb:> die Samplingrate dicht an> die Grenze der Prellzeit anpassen
Die kann auch gerne weit darunterliegen.
Florian S. schrieb:> Zähle ich nebenbei> noch die Hi-Zyklen mit
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
Florian S. schrieb:> ich ab einer bestimmten Zahl problemlos ein> Flag setzen
Wozu? Bleib flexibel und werte es aus, da wo es benötigt wird.
Arduino F. schrieb:> Jetzt wird dein denken wirklich absurd.
Na schauen wir mal was eine KI dazu sagt :D
#### Es ist Framework‑Design auf Profi‑Niveau, nicht das C++ aus
Arduino‑Beispielen.
#### Ich steigere das in mehreren Stufen – jede Stufe ist *noch
unnötiger* als die vorherige.
---
## 🟩 **Level 1: Normale Funktion (vernünftig)**
---
## 🟪 **Level 10: Debounce als „Compile‑Time State Machine“**
1
constexprautodebounce=make_state_machine(
2
state<Idle>,
3
state<Waiting>,
4
transition<Idle,Waiting>(on_change),
5
transition<Waiting,Idle>(after<20ms>)
6
);
---
## 🟥 **Level 11: Debounce als „Metaprogrammierung“ (C++20 Concepts)**
1
template<ClockC,DurationD>
2
conceptDebounceable=requires(Cclock,Ddur){...};
---
## 🟫 **Level 12: Debounce als „Domain‑Specific Language“**
1
debounceinputevery20msunlessstable;
---
## 🟦 **Level 13: Debounce als „KI‑gestützter Prädikatsfilter“**
1
boolclean=neuralDebounce.predict(raw);
---
## 🟩 **Level 14: Debounce als „Quanten‑Superpositions‑Filter“**
1
autostate=collapse(input⊗debounce_interval);
---
## 🟧 **Level 15: Debounce als „Philosophisches Konzept“**
> „Ein Zustand ist erst dann wahr, wenn er lange genug wahr war, um wahr zu sein.“
---
## 🟨 **Level 16: Debounce als „Bürokratisches Formular“**
Bitte warten Sie 20 ms, bevor Ihr Antrag auf Zustandsänderung bearbeitet
wird.
---
## 🟦 **Level 17: Debounce als „Gedicht“**
1
Ein Taster prellt,
2
die Zeit hält still,
3
erst wenn er schweigt,
4
weiß ich, was er will.
---
## 🟩 Fazit
**Man kann Abstraktion** so weit treiben, dass sie komplett lächerlich
wird.
Und genau das zeigt:
👉 **Manchmal ist die einfachste Lösung die beste.**
Alexander schrieb:> ## 🟨 **Level 16: Debounce als „Bürokratisches Formular“**>> Bitte warten Sie 20 ms, bevor Ihr Antrag auf Zustandsänderung bearbeitet> wird.
Falsch, zurück auf Anfang. Gehe nicht über Los...
Alexander schrieb:> Na schauen wir mal was eine KI dazu sagt :D
Das Gehirn am Eingang abgegeben und den Rest mit dem Löffel
rausgekratzt.
Lass' das doch einfach bleiben. Denn ein "Argument" ist so ein
Jaucheschwall erst recht nicht, sondern nur ein stinkender
Jaucheschwall.
Alexander schrieb:> Na schauen wir mal was eine KI dazu sagt :D
Is klar..
Da habe ich keine Fragen mehr.
Ich verstehe, dass einem, z.B. dir, die C++ Sprachmittel befremdlich
vorkommen.
Frei nach dem Motto:
Was der Bauer nicht kennt, das frisst er nicht.
Was aber unfair ist, deine selbst gebauten Einschränkungen auf andere zu
projizieren.
Merke:
OOP ist nicht böse, nur weil du sie nicht verstehst.
Abstraktion ist nicht böse, nur weil du dazu nicht in der Lage bist.
Selbst für deine Argumentation musst du eine Gehirnprothese verwenden.
Das ist ganz schwach.
Arduino F. schrieb:> Merke:> OOP ist nicht böse, nur weil du sie nicht verstehst.> Abstraktion ist nicht böse, nur weil du dazu nicht in der Lage bist.
Du hast eine seltsame Art Komplimente anzunehmen.
Alexander schrieb:> Du hast eine seltsame Art Komplimente anzunehmen.
Wenn du irgendwo im Thread Komplimente verteilt haben solltest, hast du
eine seltsame Art, Komplimente zu machen.
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.
HAllo,
Arduino F. schrieb:> Is klar..> Da habe ich keine Fragen mehr.
:-))
Arduino F. schrieb:> Abstraktion ist nicht böse.
Stimmt. Aber nicht jede Abstraktion führt automatisch zu mehr Klarheit
und Vereinfachung.
rhf
Roland F. schrieb:> 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.
Hans W. schrieb:> OOP ist der Kern von C++. Dafür wurde die Sprache gemacht.
Das ging mir auch durch den Kopf, aber ich wollt unseren
thread-kapernden Alecxs nicht mit Fakten belasten :D
Harald K. schrieb:> 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
Alexander schrieb:> Arduino F. schrieb:>> Es ist C++>> 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.
Veit D. schrieb:> Du nutzt doch bspw. Serial.print()
Dort leuchtet Virtualisierung und Überladung ja auch ein. Jeder nutzt
print, niemand erwartet es zu verstehen.
Veit D. schrieb:> Da kann niemand behaupten das wäre kein C++.
Hat niemand. Ich kann's nur nicht lesen. Und die meisten hier wohl auch
nicht. Einfaches C hingegen jeder.
Veit D. schrieb:> Der Unterschied den es gibt ist nur der, dass es Programmierer gibt die> die Möglichkeiten des Sprachstandards mehr oder weniger nutzen.
Zugunsten höherer Platformunabhängigkeit und Portabilität in andere
Sprachen.
Veit D. schrieb:> Solange er alles mit Sprachstandard C++11 erschlagen kann, solange kann> das jeder Arduino User 1:1 verwenden.
Nur mit Dokumentation. Dich ausgenommen.
J. T. schrieb:> Das ging mir auch durch den Kopf, aber ich wollt unseren> thread-kapernden Alecxs nicht mit Fakten belasten :D
Du verstehst ja nicht mal meine Sprache!
Alexander schrieb:> Hat niemand.
Doch!
Genau das hast du getan.
Alexander schrieb:> Ich kann's nur nicht lesen.
Schade eigentlich.
Tipp:
Warte mit urteilen, bis du das Fundament dazu hast.
Ich möchte dir da ein schönes dickes modernes C++ Grundlagenbuch
empfehlen.
Alexander schrieb:> Zugunsten höherer Platformunabhängigkeit und Portabilität in andere> Sprachen.
Was ein Unfug...
---------
Im Moment trägst du dein Unwissen und deine Unfähigkeit wie ein
Schutzschild vor dir her. Benutzt es als Basis für deine Argumentation.
Alexander schrieb:> C++ in 21 Tagen
Das ist doch ein Witz!
Um C++ zu lernen, selbst mit C Grundlagenwissen, würde ich eher ein Jahr
ansetzen. Auch dann hat man noch nicht jede Tiefe, jedes Pattern,
erreicht.
Hier mal ein Nachschlagewerk: https://cppreference.com/
Arduino F. schrieb:> Das ist doch ein Witz!
KEIN Witz!
Er hat sich das Buch vorlesen lassen, während der Schlaftherapie.
Da wäre ein Computer zum Üben doch nur hinderlich.
Alexander schrieb:> Du verstehst ja nicht mal meine Sprache!
Ja wie soll ich auch? Du selbst verstehst ja deine eigene Sprache nicht.
Oder wie erklärst du dir sowas:
Alexander schrieb:> Veit D. schrieb:>> Da kann niemand behaupten das wäre kein C++.>> Hat niemand. Ich kann's nur nicht lesen. Und die meisten hier wohl auch> nicht. Einfaches C hingegen jeder
weiter oben hattest du aber behauptet OOP und C++ hätten nichts
miteinander zu tun.
Harald K. schrieb:> Denn ein "Argument" ist so ein Jaucheschwall erst recht nicht, sondern> nur ein stinkender Jaucheschwall.
Wenn die KI mehr Humor hat als das Forum. Dabei hab ich mir doch Mühe
gegeben es extra bunt zu gestalten.
Alexander schrieb:> 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.
Alexander schrieb:> J. T. schrieb:>> was wird denn in meinem nächsten Beitrag stehen?>> Ist Luisa hier?
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.
Thread beobachten
Seitenaufteilung abschalten