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]
> oder verstehe ich die Funktionen pulseIn/pulseInlong falsch?
Ja. Ein kurzer Blick in die Doku:
1 | Please also note that if the pin is already high when the function |
2 | is called, it will wait for the pin to go LOW and then HIGH before |
3 | it starts counting. |
Nun überleg mal, was bei einer kurz prellenden Taste passiert.
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.
Tom schrieb: > ab einem genügend großen Rückgabewert wurde die Taste gedrückt. Und wenn der Taster mal weniger prellt?
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.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.