Hallo,
ich versuche mich mal in der ATMega/AVR Welt und schaue mir die
Möglichkeiten der Tasteneingabe an.
Generell wird ja digitalRead() genutzt um den Wert eines Pin x
abzufragen.
Bei "billigen" Tastern hat man ja ein Prellen. Diese Prellen könnte man
mit einer HW-Entprellung loswerden, aber auch in Software. Im Netz sehe
ich da viele sehr umfangreiche Codebeispiele und Lösungen. Wäre aber
nicht auch einfach eine Entprellung per pulseIn/pulseInlong möglich? Man
liest das damit zum Beispiel die Laufzeiten von IR oder
Ultraschall-Impulse gemessen werden. Zeitdauer zw. 10us bis 3 Minuten
und länger.
Im Prinzip wäre es doch zur Entprellung eines Tasters nur nötig die
Pulslängen mit pulseIn zu messen und dann zu entscheiden ob der
Tastendruck nach loslassen des Taster lang genug war das es ein
"richtiger" Tastendruck war oder ein Störsignal?
Gruß Tom
Tom schrieb:> Bei "billigen" Tastern hat man ja ein Prellen.
Das Problem des Prellens hat ausnahmslos jeder mechanische Taster, das
hat nichts mit 'billig' zu tun.
Eine Lösung beschreibe ich Dir nicht, Google spuckt zu der Frage
beliebig viele Softwarelösungen aus.
Deutsche Sprache schwere Sprache: Lass mir guggeln, lass mich guggeln -
nee, beides falsch: Lass' Andere googlen!
Manfred schrieb:> Eine Lösung beschreibe ich Dir nicht, Google spuckt zu der Frage> beliebig viele Softwarelösungen aus.
Eine Lösung wollte ich von Dir auch nicht haben, denn wie Du richtig
sagst spuckt Google massenhaft aus, allerdings wird das das Rad auch
immer tausendmal neu erfunden. Ich frage mich allerdings warum soviel
Codeaufwand getrieben wird, wenn es doch eigentlich zwei Funktionen
gibt, mit den man das Entprellen doch auch handhaben kann oder verstehe
ich die Funktionen pulseIn/pulseInlong falsch?
Dort lässt sich doch auch das Entprellen bzw. Störeinstrahlungen auf die
Tastenleitung aussieben?!
Tom schrieb:> ich versuche mich mal in der ATMega/AVR Welt
Du meinst du versuchst dich in der Arduino Welt ;)
Tom schrieb:> Bei "billigen" Tastern hat man ja ein Prellen
Das hast du bei so ziehmlich jedem mechanischen Taster egal ob billig
oder teuer.
Mit pulseIn ist das glaube ich nicht so wirklich schön, ich würde da
eher mit millis() arbeiten das ist im gegensatz zu pulseIn nicht
blocking. "debounce" kannst du dann irgendwie 150 oder 250 (ms) wählen
das sollte normal reichen.
[c]
if(millis() > prell){
prell = millis()+debounce;
state = digitalRead(pin);
}
]/c]
foobar schrieb:>> oder verstehe ich die Funktionen pulseIn/pulseInlong falsch?>> Ja. Ein kurzer Blick in die Doku:> Please also note that if the pin is already high when the function> is called, it will wait for the pin to go LOW and then HIGH before> it starts counting.>> Nun überleg mal, was bei einer kurz prellenden Taste passiert.
Wenn der Eingang immer auf Low gehalten wird, die Taste ihn gegen High
zieht, dann wird er nach seinen Prellen (mit vielen kurzen
Rückgabewerten der Funktion) immer von LOW auf HIGH gehen und es wird
gezählt.
Lässt man den Taster dann los, hat man auf jedenfall mindestens einmal
einen gültigen Tastendruck erkannt und die vielen kurzen Preller werden
nicht beachtet. Also genau das was erreicht werden soll. Die vielen
kleinen Werte der pulseIn (bei Prellen oder Störsignal) fallen unter den
Tisch, ab einem genügend großen Rückgabewert wurde die Taste gedrückt.
Tom schrieb:> Im Netz sehe> ich da viele sehr umfangreiche Codebeispiele und Lösungen. Wäre aber> nicht auch einfach eine Entprellung per pulseIn/pulseInlong möglich?
Das ist gar nicht so kompliziert, wie du es darstellst.
Auch solltest du, als selbst ernannter Anfänger, vorsichtig sein, mit
"Verbesserungen", denn vermutlich kommen da zwar witzige Ideen bei rum,
aber kein Erfolg.
Tipp:
Wenn es den einen "Königsweg" geben sollte, dann hätte sich die
Arduinowelt schon darauf geeinigt. Aber bisher heißt die Einigung nur
"Entprellen ist notwendig"
Hier ein Beispiel, wie einfach entprellen in der Anwendung sein kann:
Beitrag "Re: einfache und übersichtliche Flanken erkennung"
Und hier die zugehörigen Libs:
Beitrag "Re: einfache und übersichtliche Flanken erkennung"
Die ganze "Komplexität" wird weg gekapselt, steckt in den Libs und ist
in der Anwendung kaum zu sehen.
>> Please also note that if the pin is already high when the function>> is called, it will wait for the pin to go LOW and then HIGH before>> it starts counting.> Wenn der Eingang immer auf Low gehalten wird, die Taste ihn gegen High> zieht, dann wird er nach seinen Prellen (mit vielen kurzen> Rückgabewerten der Funktion) immer von LOW auf HIGH gehen und es wird> gezählt.
Nicht zuverlässig: wenn die finale steigende Flanke kommt, während das
Programm gerade den vorherigen prell-pulseIn bearbeitet, bekommt es
diesen Tastendruck nicht mit - der pulseIn wartet erstmal, dass die
Taste wieder losgelassen wird. Das sind dann diese Module, bei denen
jeder dritte Tastendruck nichts macht ...
PS: Reaktion erst beim Loslassen find ich außerdem ziemlich bescheiden.
> Wenn es den einen "Königsweg" geben sollte, dann hätte sich die> Arduinowelt schon darauf geeinigt.
Na ja, ist aber schon ein Armutszeugnis, dass sie gar keine API dafür
haben - muß ja nicht gleich mit repeat und long-press pipapo sein.
foobar schrieb:> dass sie gar keine API
Ach...
Welche Erwartungshaltung du hast....
Es gibt ja delay() ;-)
Und eine Library Schnittstelle, zum einfügen von eigenen und fremden
Libraries
Recht beliebt ist in dem Zusammenhang: Bounce2
https://github.com/thomasfredericks/Bounce2
Das reicht doch... damit lassen sich 99,9% aller Entprellungen
erschlagen.
foobar schrieb:> Armutszeugnis
Urteilen, ohne zu wissen, das stellt dir ein ein Armutszeugnis aus.
Arduino Fanboy D. schrieb:> Auch solltest du, als selbst ernannter Anfänger, vorsichtig sein, mit> "Verbesserungen", denn vermutlich kommen da zwar witzige Ideen bei rum,> aber kein Erfolg.
Warum nicht? Man stellt dabei fest, daß es einfach nicht wirklich
funktioniert. Dann erfindet man etwas Neues, bis man genau das erfunden
hat, was andere schon seit Ewigkeiten predigen. Mit dem Erfolg, daß man
jetzt auch genau weiß, warum genau diese Möglichkeit die einzig
sinnvolle ist. Oder eine von maximal drei sinnvollen. Spasseshalber
erfindet man die anderen beiden dann auch noch mal. Finde ich durchaus
erfolgreicher als nur zu wissen, wo man die passende Lib findet.
Tom schrieb:> Im Prinzip wäre es doch zur Entprellung eines Tasters nur nötig die> Pulslängen mit pulseIn zu messen und dann zu entscheiden ob der> Tastendruck nach loslassen des Taster lang genug war das es ein> "richtiger" Tastendruck war oder ein Störsignal?
Warum sollte man so einen riesen Aufwand betreiben und viele Resourcen
verbraten?
Genaues Messen ist überhaupt nicht nötig. Es reicht, wenn man das Signal
mehrfach abtastet, ob es sich geändert hat. Bekannte Lösungen machen das
deshalb ganz nebenbei im Timerinterrupt für beliebig viele Tasten
parallel mit kaum Codeaufwand und wenig CPU-Last.
Du kannst ja gerne mal eine Funktion schreiben, die mit pulseIn 4 Tasten
entprellt und die gedrückt-Flanke zurück liefert.
Und dann vergleichen wir mal, welch riesen Code das wird und ob sie
überhaupt zuverlässig entprellt, keine Drücke verliert und die Mainloop
nicht blockiert.
Thomas E. schrieb:> Warum nicht?
Ihm fragt im Eingangsposting, ob seine pulseIn() Idee sinnvoll ist.
Ist sie nicht.
Dann sage ich ihm das.
Peter D. schrieb:> Bekannte Lösungen machen das> deshalb ganz nebenbei im Timerinterrupt für beliebig viele Tasten> parallel mit kaum Codeaufwand und wenig CPU-Last.
Durchaus!
Im Arduino Umfeld ist die Einstiegshürde etwas niedriger, wenn man
millis() verwendet. Auch funktioniert das dann mit jedem von Arduino
unterstütztem µC.
foobar schrieb:> ein Armutszeugnis
Die IDE liefert ein Beispiel mit.
https://github.com/arduino-org/brackets-arduino/blob/master/examples/02.Digital/Debounce/Debounce.ino
Samt zugehörigem Tutorial:
https://www.arduino.cc/en/tutorial/debounce
Vielleicht nicht das Ressourcen Sparwunder, aber nutzbar.
Wie auch immer....
Ich kann nicht erkennen, wie man mit mit der blockierenden Funktion
pulsIn() eine schönere Entprellung hin bekommen sollte.
Lasse mich aber gerne überraschen.
Im Grunde läufts immer auf das gleiche heraus:
Einfacher endlicher Automat + Zeitabhandlung
Arten, das in Software zu implementieren, gibt es mehrere.
Alle sehen kompliziert aus, wenn man das Prinzip dahinter noch nicht
begriffen hat.
Verstanden, und gekapselt in einer Library, ist die Verwendung dann ein
Klacks.
Zeno schrieb:> Und wenn der Taster mal weniger prellt?
Dann ist er es nicht wert ausgewertet zu werden ;)
Ich persönlich bin ja immernoch ein Freund von entprellen in Hardware.
RC und Schmitt Trigger Eingang mit Interrupt.
Guest schrieb:> Ich persönlich bin ja immernoch ein Freund von entprellen in Hardware.> RC und Schmitt Trigger Eingang mit Interrupt.
benötigt nur mehr Bauteile, ab einem gewissen Alter mag man nicht mehr
verdrahten und löten :) wenn SW reicht.
Guest schrieb:> Ich persönlich bin ja immernoch ein Freund von entprellen in Hardware.> RC und Schmitt Trigger Eingang mit Interrupt.
Solche Interrupts sind ganz praktisch, wenn man AVRs aus dem Tiefschlaf
holen möchte.
Joachim B. schrieb:> benötigt nur mehr Bauteile, ab einem gewissen Alter mag man nicht mehr> verdrahten und löten :) wenn SW reicht.
2 Widerstände zu platzieren ist jetzt nicht wirklich aufwendig und löten
tut der reflow für mich :D
Arduino Fanboy D. schrieb:> Solche Interrupts sind ganz praktisch, wenn man AVRs aus dem Tiefschlaf> holen möchte.
Die sind auch so praktisch weil sie dein Programm nur dann unterbrechen
wenn der Taster wirklich betätigt wurde. Ich mein einen Taster ab zu
fragen kostet nicht wirklich Zeit, aber so muss man sich nicht wirklich
gedanken über die Abfrage und das Entprellen machen das erledigt die
Hardware im Controller für einen ( und natürlich das gute RC).
Aber das ist vermutlich Geschmackssache.
