> 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.
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ß
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?!
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.
> 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
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...
> 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 ?
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)?
> Naja, bei einem handbetätigten Schalter kann man von einm längeren> Signal ausgehen.
000000001000101111111111111.......111111111111011000100000000
Blöde Ausrede, dein Programm bleibt falsch.
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.
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
> 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.
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 :-)
Auch an Karl Heinz Buchegger noch ein Danke schön.
Die Portpins werden drei mal abgefragt.
Was ist mit:
1
inti=0;
2
while(taste_gedrueckt==false)
3
{
4
if(taste_gedrueckt==true)
5
{
6
i++;
7
warte(0.001s);
8
if(taste_gedrueckt==true)
9
i++;
10
if(i==2)
11
break;
12
else
13
i=0;
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.
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.
> 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.
: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
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?
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.
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.
...
> 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.
> 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.
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
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.
> 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.
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
> 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 :-( )
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
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...
...
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
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.
> 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.
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.
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.
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.
Thread beobachten
Seitenaufteilung abschalten