Gast
#2618906
Servus Warum sind die Beispiele hier (http://www.mikrocontroller.net/articles/Entprellung) so kompliziert? Was ist mit einer einfachen Funktion wie:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
Gast
#2618910
es gibt leute die wollen halt nicht 0.001s in der Main schleife mit warten verbringen sondern etwas sinnvolles tun.
Gast
#2618927
> Was ist mit einer einfachen Funktion wie:
Erstens ist sie nicht einfach, zweitens falsch, drittens prellen die
meisten Taster länger als 1msec, so 3 bis 8.
Einfach ist:
while(1)// die Programm-Hauptschleife
{
tasten=PIND; // 8 Taster auf ein mal
gedrueckt=tasten&~gedrueckt;
if(gedrueckt&1)
{
// Taster 1 wurde gerade runtergedrückt, mach was
}
if(gedrueckt&2)
{
// Taster 2 wurde gerade runtergedrückt, mach was
}
gedrueckt=tasten;
_delay_ms(10);
}
Macht 3 Anweisungen für 8 Taster, das ist so wenig, dafür lohnt
nicht mal eine eigene Funktion.
Gast
#2618930
Möglich, aber für das grundlegende Verständnis und für einfache Anwendungen reicht das aus. Hab inzwischen hier Beitrag "Taster enprellen" meine Antworten bekommen. Thema hat sich damit erledigt. Gruß
Gast
#2618934
1ms ist für einen AVR mit 1MHz mal eben 1000 Takte... Mit 20MHz sind's schon 20000. Warum sollte ich verschenken nur weil ich nicht vernünftig entprellen kann?!
Gast
#2618937
Jupp, vielen Dank MaWin. Aber was ist an meiner Funktion falsch?
Gast
#2618949
Ingo schrieb: > 1ms ist für einen AVR mit 1MHz mal eben 1000 Takte... Mit 20MHz sind's > schon 20000. Warum sollte ich verschenken nur weil ich nicht vernünftig > entprellen kann?! Es ging mir nicht darum etwas "vernünftig" zu tun, sondern zweckmäßig. Das es nicht sehr elegant ist, ist mir auch bewusst.
Gast
#2618956
> Aber was ist an meiner Funktion falsch?
Na sie entprellt nicht.
Beispielsignal bei der digitalen Abtastung eines Tasters,
in Auflösung 0.6 msec:
000000001000101111111111111111111111111011000100000000
Gast
#2618958
Also ich zähl immer wenn ne 1 am Eingang steht hoch. Wenn die Schleife dann 200 mal (nur zum Beispiel) vorbeigekommen ist und es immer 1 war, gilt das als gedrückte Taste. Sobald es einmal 0 ist wird zurückgesetzt. Funktioniert gut, man kann dazwischen beliebig viel machen und man hat auch gleich eine einstellbare Tastenwiederholung drin...
Gast
#2618973
> Funktioniert gut, man kann dazwischen beliebig viel machen Du baust also die Funkuhren, bei denen man immer kräftig und bestimmt und lange auf den Knopf drücken muß, bis was passiert, so daß bald die Platine zerbrochen ist... > und man hat auch gleich eine einstellbare Tastenwiederholung drin Denn Repeat soll normalerweise länger dauern (z.B. 1 sec) als Erkennen (schon so 50msec bemerkt der Mensch als Verzögerung). Allerdings funktioniert die Methode trotzdem, mit einem kleinen Trick, bloss ob du den kennst ?
Gast
#2618974
MaWin schrieb: > Beispielsignal bei der digitalen Abtastung eines Tasters, > in Auflösung 0.6 msec: > 000000001000101111111111111111111111111011000100000000 Naja, bei einem handbetätigten Schalter kann man von einm längeren Signal ausgehen. dfgh schrieb: > Also ich zähl immer wenn ne 1 am Eingang steht hoch. Wenn die Schleife > dann 200 mal (nur zum Beispiel) vorbeigekommen ist und es immer 1 war, > gilt das als gedrückte Taste. Sobald es einmal 0 ist wird zurückgesetzt. Die Variante werd ich mal probieren. Seh ich richtig, dass die Wiederholungen von hier 200 mal hauptsächlich von der Programmlänge abhängig ist (mal von Taktfrequenz abgesehen)?
Gast
#2618991
> Naja, bei einem handbetätigten Schalter kann man von einm längeren > Signal ausgehen. 000000001000101111111111111.......111111111111011000100000000 Blöde Ausrede, dein Programm bleibt falsch.
Gast
#2619006
MaWin schrieb: > Blöde Ausrede, dein Programm bleibt falsch. Es erfüllt seinen Zweck, damit kann es nicht falsch sein. Und auf meine Frage, "Warum so kompliziert?", hab ich bereits von einem anderen eine aufschlussreiche Antwort bekommen. Ich fragte nicht, wie ich es besser machen kann, sondern warum(!) meine Variante zu einfach ist.
Gast
#2619062
Ich nehm immer ein RC-Glied...:-) da verschenkt man auch keine Takte...
Gast
#2619070
Deine Funktion ist zu einfach, weil sie nur zwei sample-punkte hat. Sie betrachtet nur zu zwei unterschiedlichen punkten den Zustand des eingangs. bei einer folge von 1010101010101010101010101 (stark vereinfachtes prellen) kannst du zweimal einen 1ser messen, oder auch nicht. da kannst du, wenn mans genau nimmt, auch gleich warten bis du irgendwann mal einen 1ser misst, den verwenden und den nächsten sample erst nach 100ms zulassen. ist noch einfacher und noch falscher ;) wird aber trotzdem des öfteren funktionieren, ohne dass mans merkt. aja, wenn du nur zwei sample-punkte hast, kannst du auch das Pech haben, dass eine einfache Störung bereits als Eingang gewertet wird, es ist leider nicht alles so einfach wie man es sich gerne wünschen würde. lg Azrael
Gast
#2619192
> Es erfüllt seinen Zweck, damit kann es nicht falsch sein.
Tja, wenn Dummheit siegt, ist der Lernerfolg = 0.
(zumindest sollten die Anderen vor deinem Murks gewarnt werden, da es
bei denen nicht funktionieren muss).
LBubble schrieb: > Jupp, vielen Dank MaWin. > > Aber was ist an meiner Funktion falsch? zb auch dass du die Portpins 3 mal abfrägst. (zumindest hast du in deinem Sample nicht genau markiert, wo denn die eigentliche Pin-Abfrage stattfindet und sie hinter einem "Taster_gedrückt" versteckt). > while(taste_gedrueckt == false) > { > if(taste_gedrueckt == true) > { > warte(0.001s); > if(taste_gedrueckt == true) > break; <-----------> > } > } Drückt dein Benutzer die Taste genau zu dem Zeitpunkt, an dem das Programm an der markierten Stelle ist, dann wird die while Schleife abgebrochen ohne dass irgendeine Form von Entprellung stattfindet. Ja nachdem wie es dann im Code weitergeht wird dann ein und derselbe Tastendruck ein zweites mal registriert bzw. ein kurzer Preller mit einem Tastendruck verwechselt, das Loslassen des Tasters mit einem erneuten Drücken verwechselt etc. etc. Und seien wir uns ehrlich: die PeDa Lösung ist so kompliziert in der Anwendung nun auch wieder nicht. Einen 'langsam' laufenden Timer hat man fast in jeder Anwendung für irgendwelche Zeitsachen. Da kommt dann eben in die ISR noch der 10-Zeiler für die Tasten dazu, und im wesentlichen wars das dann für maximal 8 Tasten. Dafür bin ich sorgenfrei und brauch mich nicht mehr ums Niederdrücken (und Loslassen! denn das hast du in deinem Code geflissentlich ignoriert) kümmern. Ob der Timer alle 5 oder alle 10 oder 15 oder 20ms seine ISR auslöst, ist für das Entprellen völlig irrelevant, so dass man das bischen Code fast immer in einen bereits bestehenden Timer integrieren kann. Von daher ist der Aufwand minimal und funktioniert blendend.
Gast
#2619214
MaWin schrieb: > Tja, wenn Dummheit siegt, ist der Lernerfolg = 0. > (zumindest sollten die Anderen vor deinem Murks gewarnt werden, da es > bei denen nicht funktionieren muss). Warum sollten andere vor meinem "Murks" gewarnt werden? Ich habe eine Frage gestellt, und Antworten bekommen, von denen sicher auch andere Anfänger profitieren. Dein Beitrag dazu hält sich allerdings in Grenzen. Zur Dummheit: Ich habe einen ziemlich knapp bemessen Zeitplan, da kann ich mich mit so etwas wie einem Taster nicht lange rumschlagen. Bis jetzt tut es meine Lösung. Und solange dass der Fall ist, werde ich auch nichts daran ändern. Falls es doch mal Probleme in einem relevanten Bereich gibt, weiß ich woran es liegen könnte. Nicht Dummheit, sondern Verteilung von Prioritäten. Herzlichen Dank an Azrael.
LBubble schrieb: > Bis > jetzt tut es meine Lösung. Das Problem ist halt auch, dass das nicht so bleiben muss, weil Taster auch ganz gerne "verschleißen" - je nach Taster und Alter. Das lässt sich kaum bis gar nicht vorhersagen.
LBubble schrieb: > Zur Dummheit: Ich habe einen ziemlich knapp bemessen Zeitplan, da kann > ich mich mit so etwas wie einem Taster nicht lange rumschlagen. Ein Grund mehr für die PeDa Lösung. Taster einbauen dauert damit 10 bis 15 Minuten und ich hab alles was ich brauche und weiß, dass das auch in Zukunft so bleiben wird. Der Code hat 2 Voraussetzungen * eine ISR Aufrufzeit von 5 bis 20ms * keine exzessiv langen Interruptsperren beide sind relativ einfach zu erfüllende Vorgaben. Dafür hab ich die Garantie, dass * kein einziger Tastendruck übersehen wird * die Tasten sauber entprellt werden * Das Tastenentprellen nicht oder so gut wie nicht mit dem restlichen Code interagiert * Sich die verbrauchte Rechenzeit für das Entprellen in Bereichen bewegt, die völlig irrelevant sind. * Ich nicht laufend irgendwelche delay Konstanten nachjustieren muss, um auf die im Laufe der Zeit sich verändernde Bedingungen in der Mainloop zu reagieren. Und mehr will ich eigentlich auch gar nicht. Eine richtige Copy&Paste&Configure&Forget Lösung.
LBubble schrieb: > if(taste_gedrueckt == true) > break; die "if"-Anweisung (mit break;) kannste auch gleich ganz weglassen, der Effekt ist der gleiche :-)
Gast
#2619263
Auch an Karl Heinz Buchegger noch ein Danke schön. Die Portpins werden drei mal abgefragt. Was ist mit:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
Sicher auch nicht die optimale Lösung, aber das Problem mit dem rausspringen, weil man zufällig die zweite if-Abfrage trifft, sollte damit weg sein. Was die verschwendete Rechenleistung angeht, die spielt hier einfach keine Rolle. Der verschleiß des Tasters auch (noch) nicht. Aber Danke für den Hinweis, Karol Babioch. Werds mir für den Fall notieren.
Gast
#2619271
Andreas W. schrieb: > die "if"-Anweisung (mit break;) kannste auch gleich ganz weglassen, der > > Effekt ist der gleiche :-) Jetzt nicht mehr ;-) Von alleine wäre ich zugegeben aber nicht drauf gekommen. Bin inzwischen schon wieder wo ganz anders. Wenn ich Zeit hab oder auf was anderes keine Lust denk ich mich mal in den PeDa-Code rein. Einen schönen Feierabend an alle.
LBubble schrieb: >
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
> Sicher auch nicht die optimale Lösung, aber das Problem mit dem > rausspringen, weil man zufällig die zweite if-Abfrage trifft, sollte > damit weg sein. Denk nachmal darüber nach. Insbesondere, was wohl diesmal an der markierten Stelle alles passieren kann. (Und schon wird dein Code immer komplizierter, Und wenn wir dir hier dann nach ein paar bisher nicht bedachte Sonderfälle präsentieren wird er noch komplizierter und komplizierter und komplizierter. Und plötzlich ist dann die PeDa Komfortfunktionalität gar nicht mehr kompliziert :-) OK, der Code ist tricky - aber in der Anwendung so simpel wie es nur sein kann while( 1 ) { ... if( get_keypress( 1 << TASTE1 ) ) LED_PORT = LED_PORT ^ ( 1 << RED_LED ); if( get_keypress( 1 << TASTE2 ) ) LED_PORT = LED_PORT ^ ( 1 << GREEN_LED ); ... LED_PORT = LED_PORT ^ ( 1 << BLUE_LED ); _delay_ms( 1000 ); } toggelt die beiden LED bei jedem einzelnen Tastendruck. Und zwar zuverlässig und unabhängig davon * wieviel Code vor bzw. nach dieser Tastenauswertung steht. * in welcher Reihenfolge die Tasten gedrückt werden * lässt genug Rechenzeit übrig, damit das Programm in den ... Bereichen seine eigentliche Arbeit machen kann. * lässt mir sogar den Freiraum, dass ich in der Hauptschleife weiterhin mit _delay_ms arbeiten kann. Die Tastendrücke gehen nicht verloren wohl aber hinkt deren Auswertung hinten nach. Aber das ist immer noch besser als der Benutzer muss mit der Zunge zwischen den Zähnen genau den richtigen Zeitpunkt abpassen an dem der die Taste drücken darf.
Gast
#2619364
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
:D Den PeDa werde ich mir noch zu Gemüte führen. Aber momentan muss das einfach reichen. Zugegeben die Sonderfälle kenne ich nicht, aber wenn es 100 mal gut geht, und das 101. mal nicht, kann ich momentan damit leben. Reset und gut ist, kaputt gehen kann bei mir nichts. Es ist einfach eine Zeitfrage. Dass die Lösung nicht sonderlich gut sein kann, war mir schon vorher klar. Aber jetzt weiß ich warum. Vielen Danke nochmal für die Mühe
LBubble schrieb: > Es ist einfach eine Zeitfrage. Du wurdest ja schon darauf hingewiesen, dass genau deswegen der Einsatz der Lösung von PeDa wohl sinniger sein dürfte.
Karol Babioch schrieb: > Du wurdest ja schon darauf hingewiesen, dass genau deswegen der Einsatz > der Lösung von PeDa wohl sinniger sein dürfte. Das wollte er aber alles nicht hören, bzw. lesen. "Ja deine Lösung ist super einfach, hat zwar ein paar kleine Macken, aber wenn es schnell gehen soll, mache ich das auch so." Hat nur leider keiner geschrieben. mfg.
Thomas Eckmann schrieb: > "Ja deine Lösung ist super einfach, hat zwar ein paar kleine Macken, > aber wenn es schnell gehen soll, mache ich das auch so." > Hat nur leider keiner geschrieben. Yep. Wenn es schnell gehen soll, nehm ich Bewährtes und erfinde nichts Eigenes. Den erstens kommt es immer anders als man zweitens denkt. Und mich da mit Tastenauswertung und Prellen rumschlagen, dazu hab ich nicht den Nerv, wenn ich eh schon unter Zeitdruck stehe. Aber hey. Jetzt sind die Argumente am Tisch, aus unserer Sicht gibt es keinen Grund die PeDa Entprellung nicht zu verwenden (ausser dem Grund: Angst vor Timer) und damit sollten wir es, denk ich, belassen.
Wie kann man nur so lernresistent sein, jetzt wird die eine super lösung echt gut erklärt, und du erzählst hier irgendwas von keine Zeit. Wolltest du einen Strauß Blumen für deine Lösung? Und bist jetzt nicht zufrieden, weil dir alle sagen, das dich deine Lösung auf Dauer nicht glücklich machen wird. Und ganz ehrlich, wenn du schon bei so einem recht einfachen Thema schlampig wirst, will ich nicht deinen restlichen Code sehen, egal was er machen soll. Ich bin selber noch ziemlich am Anfang der Lernphase, und bekomme hier bei einer vernünftigen Fragestellung immer eine ordentliche Antwort, wie du gerade hier auch, die ich mir dann aber auch annehme. Weil eben die Leute, die mir oder dir hier antworten, auch mal größere Projekte im Blick haben, zu denen du über kurz oder lang kommen wirst. Und wenn du dann ein Projekt mit ganz paar kbyte hast, und überall schön verteilt solche kleinen Fehler, dann wünsche ich dir viel Spaß beim suchen, ich bin mir sicher, das du es dann hinwirfst. Also lass den Quatsch hier irgendwie den Großen zu spielen, mit der Meinung, ich lern das grundlegende dann, wenn ich mal Zeit dafür hab, jetzt rette ich erstmal die Welt. Einfach mal so ne Meinung von einem anderen Anfänger, vielleicht denkst du ja mal drüber nach MfG Dennis
Gast
#2620019
Naja, ich hab mal sicher 1 Woche damit verbracht und mir überlegt wie ich am besten entprelle und mir eine Funktion geschrieben. Zu finden unter: http://bascom-forum.de/showthread.php?3807-Taster-Entprellen-mit-einem-Timer-Einfach-Zweifach-Dreifach-Vierfach...-und-Lang allerdings in Bascom geschrieben! Gruß Markus
Gast
#2620021
Markus schrieb: > allerdings in Bascom geschrieben! ich habe mir deine Entprellfunktion nicht angesehen (kann man ja auch nicht, ohne sich bei dem Forum anzumelden), aber hat Bascom nicht schon die Debounce-Funktion?
Gast
#2620027
Ja das ist richtig, die hat Bascom, allerdings blockiert diese den ganzen Programmablauf, und da ich nicht die Zeit verschwenden wollte habe ich eine Entprellfunktion geschrieben die nur über Timerüberläufe funktioniert und alles in einem Aufruf abarbeitet. Man könnte die funkion noch verfeinern das sich der Timer wieder abschaltet wenn langere Zeit keine Taste gedrückt wird, so spart man sich die Timer überläufe, aber das habe ich bis jetzt noch nicht benötigt. Aber ich hab da ganz schön viel Hirnschmalz reinstecken müssen.(Zumindest für mich). Oft sind es die scheinbar einfachen Sachen die einem das Leben schwer machen :-) Gruß Ps: wenn Interesse besteht kann ich den Code hier Posten.
Tasten entprellen ist nicht trivial. Es lohnt sich ein paar Wochen Entwicklungszeit zu sparen und etwas fertiges zu verwenden. Falls man Dannegers Code nicht verwenden kann / möchte gibt es auch noch http://hackaday.com/2010/11/09/debounce-code-one-post-to-rule-them-all/ Gerade wenn es schnell gehen soll würde ich mir keine Fallstricke mit doppelten oder nicht erkannten Tastendrücken bauen.
Also da wir hier eh schon am diskutieren sind, möchte ich auch gleich noch eine Frage zur Entprellung stellen:
1 | |
2 | |
3 | |
4 | |
5 | |
6 | |
7 | |
8 | |
9 | |
10 | |
11 | |
12 | |
13 | |
14 | |
15 | |
16 | |
17 | |
18 | |
19 | |
20 | |
21 | |
22 | |
23 | |
24 | |
25 | |
26 | |
27 | |
28 | |
29 | |
30 | |
31 | |
Habe dieses Beispiel im Artikel gesehen, so was nennt sich eine
State-Maschine oder?
Auf jeden Fall meine 2 Fragen:
Muss ich diese Funktion für jeden Taster machen?
Und muss ich einfach jedes mal, wenn ich einen Taster abfragen will,
diese Funktion aufrufen?
also quasi
int main ()
{
while (1)
{
taster();
if (rw)
{
/*Mach was*/
}
}
}
MFG
Dave
Karl Heinz Buchegger schrieb: > Und seien wir uns ehrlich: die PeDa Lösung ist so kompliziert in der > Anwendung nun auch wieder nicht. Hier liest man immer wieder von Leuten, die die PeDa-Lösung(en) zwar kennen, sich aber mit Händen und Füßen dagegen wehren, sie anzuwenden. Warum ist das so? Ich habe den Eindruck, dass sie einfach ein mentales Problem damit haben: Sie verstehen den Source nicht. Peter macht es den Leuten auch nicht gerade leicht mit der konsequenten Antwendung des EXOR-Operators '^', wo auch ein OR-Operator '|' gereicht hätte. Manches ist auch sehr kompakt ausgedrückt, wo ein wenig mehr "Geschwätzigkeit" zum Verständnis mehr beitragen würde und der Compiler das schon so hinbiegen würde, dass am Ende derselbe Code rauskommt. Ich kann dieses Problem durchaus nachvollziehen. Ich verwende auch ungern bis gar nicht Code, den ich nicht verstehe. Man möchte halt ungern die Kontrolle über das eigene Programm verlieren. Gruß, Frank
Frank M. schrieb: > Antwendung des > EXOR-Operators '^', wo auch ein OR-Operator '|' gereicht hätte. Das ist ein Irrtum. Um die Veränderung gegenüber dem Old-Zustand in beiden Richtungen zu erkennen, braucht es nunmal EXOR, OR geht da nicht. ...
Gast
#2620158
> Habe dieses Beispiel im Artikel gesehen, so was nennt sich eine > State-Maschine oder? Ja. > Muss ich diese Funktion für jeden Taster machen? Ja. Sie können ja alle zu unterschiedlichen Zeitpunkten gedrückt/losgelasen werden. Allerdings arbeitet die Funktion gerade andersrum: Wenn "gedrückt" geht es um logisch low 0 Signal am Eingang. Dummerweise entprellt die Funktion nicht. Eine Entprellung kommt nur zu Stande, wenn die Funktion nicht zu schnell wiederholt und nicht zu langsam wiederholt aufgerufen wird, also z.B. nicht schneller als alle 10msec und nicht langsamer als alle 100msec. Man braucht also neben der Funktion noch mehr Aufwand, z.B. einen Timer. > PeDa-Lösung(en) zwar kennen, sich aber mit Händen und Füßen > dagegen wehren, sie anzuwenden. Warum ist das so? Im Normalfall ist sie zu aufwändig, im Normalfall tun es die von mir beschriebenen 3 Anweisungen. Zudem muß man Rahmenbedingungen beachten, es ist also keineswegs so, daß man die PeDe-Funktionen einfach so einsetzen kann, ohne verstanden zu haben was in ihnen passiert.
Frank M. schrieb: > Ich kann dieses Problem durchaus nachvollziehen. Ich verwende auch > ungern bis gar nicht Code, den ich nicht verstehe. Man möchte halt > ungern die Kontrolle über das eigene Programm verlieren. Mit Windows, MacOS oder Linux Online-Überweisungen ausführen usw. ist OK, aber bei der Tastenabfrage im Mikrocontroller vertraue ich Keinem! Ja, klar. ;-) Der PeDa-Code ist in seiner Kompaktheit einfach genial und es war für mich ein Genuss, die Funktionsweise nachzuvollziehen. Dafür ein Danke an Peter Dannegger! Das Beste daran ist, dass der Code auch dann funktioniert, wenn man ihn nicht versteht oder man sich die Zeit fürs Verstehenlernen nicht nehmen kann/mag. So, genug der Werbung, genug der Schreckensszenarien. Jetzt gilt das Sprichwort "Du kannst den Ochsen zum Brunnen tragen, aber du kannst ihn nicht zum Saufen zwingen!" ;-)
MaWin schrieb: > Allerdings arbeitet die Funktion gerade andersrum: Wenn "gedrückt" geht > es um logisch low 0 Signal am Eingang. > > Dummerweise entprellt die Funktion nicht. > > Eine Entprellung kommt nur zu Stande, wenn die Funktion nicht zu schnell > wiederholt und nicht zu langsam wiederholt aufgerufen wird, also z.B. > nicht schneller als alle 10msec und nicht langsamer als alle 100msec. > Man braucht also neben der Funktion noch mehr Aufwand, z.B. einen Timer. Ach so, danke für die Erklärung. Dann werde ich wohl auf die von dir beschriebenen Anweisungen zurückgreifen. Warum gibt's eigentlich so was nicht fix im Controller? Oder gibt es solche Controller? So im Sinn von internen Pullup-Widerständen, wenn man sie braucht, kann man sie aktivieren. Würde doch noch Sinn machen? MFG Dave
Dave Chappelle schrieb: > Warum gibt's eigentlich so was nicht fix im Controller? > Oder gibt es solche Controller? > > So im Sinn von internen Pullup-Widerständen, wenn man sie braucht, kann > man sie aktivieren. > Würde doch noch Sinn machen? Weil jeder eine andere Vorstellung davon hat, was noch als Prellen gelten soll und was einfach nur 2 schnelle Pulse hintereinander sind. Zudem kommt dazu, dass sich ein paar Basiswerte mit der Taktfrequenz des µC ändern. Bei Pullup-Widerständen kann man sich auf einen Wert einigen, der über weite Strecken funktioniert, weil das im Regelfall nicht so kritisch ist. Bei den Parametern für eine Entprellung ist das aber nicht so.
Gast
#2620238
> Warum gibt's eigentlich so was nicht fix im Controller?
Gibt's doch, nennt sich Eingangspin.
Alles was man zur entprellten Erfassung eines an ihn angeschlossenen
Tasters machen muß, ist, ihn in halbwegs regelmässigen Zeitabständen
abzufragen, das kostet passend ins Hauptprogramm eingebaut keinen
einzigen Befehl.
Was will man daran noch vereinfachen ?
Die Flexibilität, ob man nun das Niederdrücken, das gedrückt halten, das
Loslassen des nach Masse oder nach Plus schaltenden Tasters erkennen
will, bleibt so oder so an einem selbst hängen, wer wollte sich das
schon von einer vorgefertigen READDEBOUNCEDKEY Befehl vordiktieren
lassen ?
Entprellen ist so superprimitiv, daß es quasi schon erledigt ist. Nur
diejenigen, die irgendwo gelesen haben, es gäbe da ein Problem, man
müsste Taster entprellen, seitenlange unverständliche Funktionen
gefunden haben die trotzdem nicht funktionieren, die glauben es wäre
kompliziert, und damit machen sie es sich erst kompliziert.
Der einzelne Taster am einzelnen Anschluss hat eh Seltenheitswert und
wird nur von extremen Anfängern so verwendet. Normalerweise gibt es
Tastenfelder die im Multiplex abgefragt werden, quasi nebenbei zum
Multiplex einer Anzeige, oder ein Analogeingang erfasst 4 Taster oder
so, oder ein Taster hängt an Pins die eigentlich ein Ausgang sind, man
will ja Pins sparen.
Dave Chappelle schrieb: > Würde doch noch Sinn machen? Warum? Der µC hat doch alles nötige schon an Bord: Timer und die Fähigkeit zu rechnen. Und wenn das einbinden von Fremdroutinen in C zu kompliziert ist, nim z.B. Bascom, da gibts einen "DEBOUNCE"-Befehl, iirc.
Gast
#2620241
Dave Chappelle schrieb: > Warum gibt's eigentlich so was nicht fix im Controller? > Oder gibt es solche Controller? Du kannst auch extern ein RC-Glied verwenden. Das würde einer Hardwarelösung entsprechen. Allerdings braucht sowas Platz, der ja im Chip immer Mangelware ist. ;-)
MaWin schrieb: > Entprellen ist so superprimitiv, daß es quasi schon erledigt ist. Genau so denken viele Entwickler. Und deshalb müssen sich viele Benutzer mit einer grottenschlechten Tastenabfrage rumärgern. Entweder man muß ewig drücken oder es prellt oder die falsche Taste reagiert. Und die nächste Taste wird auch nicht gemerkt, man muß brav warten, bis eine Aktion beendet ist. MaWin schrieb: > Der einzelne Taster am einzelnen Anschluss hat eh Seltenheitswert und > wird nur von extremen Anfängern so verwendet. Eher umgekehrt, eine Tastatur an Geräte ist selten, Tasten kosten nämlich Geld. Viele Geräte haben nur wenige Tasten und da lohnt sich eine Matrix nicht. Zahleneingaben erfolgen oft über 2 Tasten (Up,Down). Meine Entprellung funktioniert natürlich auch mit einer Matrix prima: Beitrag "Tastenmatrix auslesen über nur 2 Leitungen" Die Intention bei meiner Lösung war, daß sie wenig Ressourcen (CPU-Zeit, Flash, RAM) braucht, universell einsetzbar ist, wenig Seiteneffekte hat und wenig empfindlich auf Seiteneffekte (Dauer) anderer Tasks ist. Insbesondere das erstere ist nicht zu toppen ohne gravierende Abstriche an der Funktion. Peter
Gast
#2620333
Was haltet ihr eigentlich von sowas. Brauch IMHO keine Entprellung weil die Ladung während der Schaltzeit immer gehalten wird. Brauch aber einen Umschalter und einen Draht mehr.
Gast
#2620335
Zweiter Versuch, diesmal das jpg
Angehängte Dateien:
-
Draft2.jpg
(53 KB)
Der Rächer der Transistormorde schrieb: > Zweiter Versuch, diesmal das jpg ==> Bildformate
Gast
#2620347
> Was haltet ihr eigentlich von sowas. Wow, du hast es geschafft, einen Taster an einen uC anzuschliessen. > Genau so denken viele Entwickler. Es ist ja auch richtig, sie müssen es danach nur richtig machen, und das habe ich hinlänglich beschrieben. Man darf das also ignorieren weil man sich für superklug hält und schreibt Programme die immer länger werden, oder man folgt dem einfach und hat keine Probleme. Noch mal kurz zum mitschreiben: Man muß bei in passendem Zeitabständen (also langsamer als die machanische Prellzeit, schneller als die gewünschte Reaktionszeit) gesampelten Tastenzustand nicht entprellen. Jede Programfunktion dafür ist überflüssig. Aber spielt ruhig schön weiter und macht Schützengräben auf wo keine sind.
Der Rächer der Transistormorde schrieb: > Was haltet ihr eigentlich von sowas. auf eine persönliche Frage eine persönliche Antwort: nichts. > Brauch IMHO keine Entprellung weil die Ladung während der Schaltzeit > immer gehalten wird. Brauch aber einen Umschalter und einen Draht mehr. Ich versteh eines nicht. Es gibt eine Softwarelösung, die nahezu perfekt ist. Warum versuchen dann immer wieder Leute, statt dessen eine Hardware-Lösung zu propagieren? Ich kann ja verstehen, dass die Funktionsweise der ISR schwer zu durchschauen ist. Ja, sie ist tricky. Aber das kann doch kein Grund sein, sie nicht zu verwenden. Dieselben Leute die hier immer wieder diese Lösung aus genau diesem Grund ablehnen (den ich verstehen kann), hätten überhaupt keine Hemmungen einen malloc zu benutzen obwohl sie auch keine Speicherverwaltung selbst schreiben könnten oder verstehen würden wie dynamische Speicherverwaltung intern funktioniert. Betrachtet das einfach als Black-Box, so wie die genauen Vorgänge beim Parameterpassing in eine Funktion eine Black Box sind - die Werte kommen irgendwie in den Zielvariablen an. Wie das genau funktioniert, darüber haben sich andere den Kopf zerbrochen. Nur weil man hier ein Modul hat, bei dem einen der Source-Code ins Auge springt, heißt das ja nicht, dass man den Code nicht einfach als Block Box sehen kann. Wieviele der Programmierer, die Aussteuerungsanzeigen bauen, haben den wirklich verstanden wie eine FFT funktioniert und wie der Code arbeitet. Ich denke, ich liege nicht allzufalsch, wenn ich sage: weniger als 30%. Die anderen übernehmen den Code, einfach weil er funktioniert. Und das ist ja auch gut so.
Gast
#2620353
Der Rächer der Transistormorde schrieb: > Zweiter Versuch, diesmal das jpg Boah, toll! Und was soll das jetzt? Nimm 'ne anständige Routine und fertig. Habe selbst mal eine geproggt, mit Wiederholfunktion, verschiedenen Geschwindigkeiten in Abhängigkeit der Drückdauer - das war allerdings ein recht komplexer Zustandsautomat - nix 08/15. Nimm Karl Heinz' Vorschlag an, der ist allemal besser als dein komisches Bildchen. Gruß Rächer
MaWin schrieb: > Noch mal kurz zum mitschreiben: Man muß bei in passendem Zeitabständen > (also langsamer als die machanische Prellzeit, schneller als die > gewünschte Reaktionszeit) gesampelten Tastenzustand nicht entprellen. Das ist in der Theorie sicher richtig. In der Praxis kotzt aber manchmal eben doch das Pferd vor die Apotheke. Man hat es ja nicht nur mit Prellen zu tun. Es können auch andere Störungen zufällig zum Zeitpunkt des Abtastens auf den Eingangspin gelangen, zumal der interne Pullup recht hochohmig ist. Daher ergibt sich durch Mehrfachabtastung eine deutlich merkbare Erhöhung der Schaltsicherheit. Und was liegt näher, diese passenden Zeitabstände durch einen Timerinterrupt zu machen? Damit ist man unabhängig von Änderungen der Ausführungszeit in der Mainloop. Es kann also nicht passieren, daß durch Debugcode oder Erweiterungen plötzlich etwas nicht mehr funktioniert, was davor aber noch ging. Dann noch die Flankenerkennung hinzu und schon ist der Aufwand für die Mehrfachabtastung fast Null. Peter
Gast
#2620412
> Das ist in der Theorie sicher richtig. Das ist immer richtig. > In der Praxis kotzt aber manchmal eben doch das Pferd vor die Apotheke. > Man hat es ja nicht nur mit Prellen zu tun. Es können auch andere > Störungen zufällig zum Zeitpunkt des Abtastens auf den Eingangspin > gelangen, zumal der interne Pullup recht hochohmig ist. Störungen lassen sich nicht 'entprellen'. Wenn die Schaltung sich Störungen einfängt, liegt das Problem woanders als in einer mangelhaften Entprellfunktion. Sondern z.B. im für das Umfeld und die Leitungslänge zu hochohmigen PullUps. Dann sollte man das Problem auch dort angehen, wo es entsteht, und nicht versuchen mit einer eigentlich anderen Funktionalität ein wenig dran rumzufummeln (und nur die Störungen durchlassen, die kräftig genug waren, um als Tastendruck durchzugehen :-( )
Gast
#2620431
Hallo MaWin, deine Methode Taster zu entprellen mag für einfache Anwendungen sicher perfekt sein wenn es schnell gehen muss. Aber PeDa's kann noch viel mehr als nur einen Tastendruck sicher zu erkennen, da wären: Repeat-Funktion, langer Tastendruck, kurzer Tastendruck und Tastenkombinationen erkennen. mfg
Gast
#2620436
> Aber PeDa's kann noch viel mehr
Natürlich. Wer Repeat & Co. braucht, kommt mit meinen 3 Zeilen nicht
aus.
Das wurde auch hinlänglich erwähnt.
Gast
#2620483
Ich bin immer wieder ueberrascht, wie viel Leistung darin gesteckt wird die Peda-Loesung zu promoten - ein Bruchteil davon wuerde reichen, den Code mal ordentlich zu gestalten, was der Akzeptanz sicher mehr helfen wuerde.
Marwin schrieb: > ... den > Code mal ordentlich zu gestalten, ... Den C-Quelltext kann und will ich nicht beurteilen, aber der ASM-Quelltext der Bulletproof-Version ist verdammt ordentlich ! ...
Also an Peter Daneggers Stelle würde mich das wenig anheben, wenn jemand den Code nicht nutzen will, weil er ihn in der Schreibweise nicht versteht. Hier wird niemand gezwungen, etwas zu nutzen, was angeboten wird. Ich finde es doch gut, das er den Code in einen Artikel gestellt hat, hätte er nicht tun müssen. Wer ihn nutzen will, darf das gern tun, wer ihn nicht nutzen will, hat das Recht, es eben sein zu lassen und es selbst zu versuchen. MfG Dennis
Dennis H. schrieb: > Wer ihn nutzen will, darf das gern tun, > wer ihn nicht nutzen will, hat das Recht, es eben sein zu lassen und es > selbst zu versuchen. Er soll ihn aber auch nicht schlecht reden... ...
Das stimmt allerdings, das ist nicht ok, da muss ich dir Recht geben. MfG Dennis
MaWin schrieb: > Dann sollte man das Problem auch dort angehen, wo es entsteht Man kann nicht alles und jedes abschirmen oder erden, das wird unverhältnismäßig teuer. Man latscht über den Teppich, d.h. lädt sich auf und schon gibt es einen Impuls beim Annähern an die Taste. Ich kann Dir auch mehrere kommerzielle Geräte zeigen, die dann einen Tastendruck interpretieren. MaWin schrieb: > und nicht > versuchen mit einer eigentlich anderen Funktionalität ein wenig dran > rumzufummeln Wenn ich Hardware durch etwas Software ersetzen kann, dann tue ich das. Ich bin auch immer ganz gut gefahren, grundsätzlich alles, was von außen kommt, zu validieren. Inputs werden mehrfach abgetastet, Spannungen mehrfach gewandelt, UART-Daten per Protokoll geprüft usw. Bei ner Alarmanlage will man ja auch keinen Fehlalarm, nur weil die Putzfrau mit dem trockenen Staubtuch drüberwischt. Letztendlich stellt die Mehrfachabtastung einen Tiefpaß dar und der hilft gegen Prellen und Störungen gleichermaßen. Peter
Gast
#2621691
Dennis H. schrieb: "Wie kann man nur so lernresistent sein, jetzt wird die eine super lösungecht gut erklärt, und du erzählst hier irgendwas von keine Zeit.Wolltest du einen Strauß Blumen für deine Lösung? Und bist jetzt nichtzufrieden, weil dir alle sagen, das dich deine Lösung auf Dauer nichtglücklich machen wird. Und ganz ehrlich, wenn du schon bei so einemrecht einfachen Thema schlampig wirst, will ich nicht deinen restlichenCode sehen, egal was er machen soll. Ich bin selber noch ziemlich amAnfang der Lernphase, und bekomme hier bei einer vernünftigenFragestellung immer eine ordentliche Antwort, wie du gerade hier auch,die ich mir dann aber auch annehme. Weil eben die Leute, die mir oderdir hier antworten, auch mal größere Projekte im Blick haben, zu denendu über kurz oder lang kommen wirst. Und wenn du dann ein Projekt mitganz paar kbyte hast, und überall schön verteilt solche kleinen Fehler,dann wünsche ich dir viel Spaß beim suchen, ich bin mir sicher, das dues dann hinwirfst. Also lass den Quatsch hier irgendwie den Großen zuspielen, mit der Meinung, ich lern das grundlegende dann, wenn ich malZeit dafür hab, jetzt rette ich erstmal die Welt. Einfach mal so neMeinung von einem anderen Anfänger, vielleicht denkst du ja mal drübernachMfG Dennis" Es gab Probleme bei dem langen Zitat. Ich nehem die Lösung sehr gerne an und habe sie abgelehnt. Wenn man sich diesen kurzen Thread durchliest(Beitrag "Taster enprellen"), sieht man auch, dass ich einer sachlichen Antwort nichts entgegen zu setzen habe. Speziell MaWin hat aber größtenteils nur aggressiv kritisiert, anstatt zu sagen, was denn bei meinem Code nicht stimmt. Er war niemals als Verbesserungsvorschlag gedacht, mir ist ja bewusst, dass ich Anfänger bin. Ich wollte nur wissen, warum er es nicht tut. In den PeDa-Code müsste ich mich erstmal reindenken. Mein Taster startet einen einfachen Ablauf, ganz am Anfang des Programms, da kann nichts schief gehn - entweder er staret oder nicht. Bis jetzt tat er es immer. Jeglicher weitere Zeitaufwand betrachte ich im Moment als verschwendete Zeit. Das es auf Dauer nicht gut ist, habe ich nie geleugnet. Das mich andere deshalb dabei "unterstützen", deshalb auch nie erwaret. Was ich aber erwartet habe, war wie oben schon geschrieben, eine sachliche Darstellung der Dinge, was und warum daran nicht passt. Wenn es Fehler gibt, oder wenn ich hinten raus Zeit habe, steht das mit auf meiner Liste der Dinge, die besser zu machen sind. Aber noch kümmere ich mich darum nicht. Jeden weiteren Aufwand, mich zu rechtfertigen, stelle ich hiermit mauch auch ein. Mahlzeit Und Danke an die Leute, die meine Frage beantwortet haben.
Gast
#2621693
LBubble schrieb: > Ich nehem die Lösung sehr gerne an und habe sie abgelehnt "... und habe sie NIE abgelehnt" sollte es heißen. Jetzt aber Schluss.
Gast
#2621716
> Speziell MaWin hat aber größtenteils nur aggressiv kritisiert, > anstatt zu sagen, was denn bei meinem Code nicht stimmt. Blödsinn. Du hast alles bekommen. Den Hinweis daß er nicht funktioniert. Ein Beispiel an dem du das nachvollziehen kannst. Eine Alternativlösung die funktioniert. Du warst so rattenfaul, nicht mal das Beispiel nachzuvollziehen, sondern hast nur Pseudo-Mäkeleien geäussert "längeres Signal". Dafür entfaltest du einen maximalen Zauber wenn es darum geht, von der Unzulänglichkeit deiner Lösung abzulenken. Wahrscheinlich hat mir Mami beigebracht: "Es ist egal ob man was richtig macht, Hauptsache man streitet eigene Fehler ab." Sorry, falsche Lebensweisheit. Ja, die andere Lebensart ist aufwändiger, da muß man Denken und Verstehen. Da wehrst du dich aber mit Händen und Füssen gegen.
Gast
#2621727
MaWin schrieb:
> Dann sollte man das Problem auch dort angehen, wo es entsteht
Es ist leider hier öfters so,dass viele Leute einfach zu faul sind
selber Probleme zu lösen. Meistens auch noch Studenten.
Vielleicht sollte man sich mit dem Thema beschäftigen und nicht einfach
den Thread lesen.
Gast
#2621777
MaWin schrieb: > "Es ist egal ob man was > richtig macht, Hauptsache man streitet eigene Fehler ab." > Sorry, falsche Lebensweisheit. Beste Voraussetzung, in die Politik zu gehen. ;-) In der Zeit, in der man hier diskutiert, hätte er sich auch hinsetzen und den Peter-Code durchspielen können. Hat mich mal ne halbe Stunde gekostet, dann war die Funktion klar und der Code implementiert... Man kann sich das Leben auch schwermachen.
Gast
#2621907
MaWin schrieb: > Noch mal kurz zum mitschreiben: Man muß bei in passendem Zeitabständen > (also langsamer als die machanische Prellzeit, schneller als die > gewünschte Reaktionszeit) gesampelten Tastenzustand nicht entprellen. Ich kann MaWin nur recht geben. Er weiß wovon er spricht. In meiner Software gibt die Main-Schleife oder ein Timer, der die Main-Schleife steuert, den Takt für die Abtastung der Tasten vor. Das kostet nicht mal Programmspeicher. Das takten der Main brauch ich eh. Das mach ich seit mindenstens zwanzig Jahren schon so. In sehr vielen Geräten die professionell genutzt werden, und diese User verzeihen keine Fehler, nicht die kleinsten. Allen die Tasten entprellen wünsch ich viel Spaß mit ihrer Software. Kein Zweifel, sie wird funktionieren. Anerkennung für die Routinen von DePa, die sind ausgefuchst. In meinen Geräten brauch ichs nicht. Abtasten mit der richtigen Frequenz macht das Entprellen entbehrlich.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.