Wie lange prellt ein Taster in der Regel?

Ja sollte auf jeden Fall reichen. Ist eher ne grosse Entprellzeit.

Man sollte auch berücksichtigen, dass mit zunehmendem Alter die 
Prellzeit ebenfalls zunimmt. Die kann dann bis zu mehreren 100 ms 
betragen.

Horst schrieb:
> Mal ne Frage, wenn ich nen Taster entprellen will, wie lang sollte ich
> in der egel warten, bis ich den nächsten Zustand abfrage?

Garnicht.
Stures Warten ist kein Entprellen!
Und kostet außerdem wertvolle CPU-Zeit.

Sicheres Entprellen macht man mit Mehrfachabtastung.
Und besonders wichtig, auch beim Loslassen!

In der Regel reicht eine 4-fach Abtastung aus.
Das Abtastintervall ist unkritisch, 5..50ms sind o.k.
Am besten läßt sich das mit einem Timerinterrupt machen.


Peter

Ausrufer schrieb:
> Zitiere daraus:
> The short answer: sometimes a lot, sometimes not at all.

Toss out those two samples and the other 16 switches exhibited an 
average 1557 µsec of bouncing, with, as I said, a max of 6200 µsec. Not 
bad at all.

Horst schrieb:

> Horst schrieb:
>> bis ich den nächsten Zustand abfrage?

Der springende Punkt ist wohl, dass diese Zeit nicht so kritisch ist. 
Erst durch das Zusammenspiel mit der Forderung, dass du bei x 
Abtastungen mit einem zeitlichen Versatz von y ms jedesmal den gleichen 
Wert bekommen musst, entsteht die rock-solid Entprellung. Wenn die dann 
auch noch versagt, dann ist der Taster schon lange jenseits von Gut und 
Böse und muss getauscht werden.

Forderst du zb dass du 4 mal hintereinander denselben Wert vom Port 
bekommen musst, so beginnen mit jedem Preller die Zeit wieder neu zu 
laufen und es wieder erneut auf 4 hintereinanderliegende gleiche 
Zustände gewartet.
In diesem Sinne passt sich diese Funktionalität, die in der 'PeDa' 
Entprellung implementiert ist, automatisch auch in gewissen Grenzen an 
die Qualität des Tasters an.

Macht doch nicht so große Wellen
wegen ein wenig Taster-Prellen.

Nehmt doch einfach Gummimatten,
die noch nie ein Prellen hatten!

...oder die Kapazität der Hand,
(hier irgendwo ein Quelltext stand)

Drück ich mit den dicken Pfoten
auf den Taster (auf den roten)

dann wird im Timer-Interupt
dessen Zustand aufgeschnappt

Nach 10 kleinen Millisekunden
wird er dann für gut befunden

4 mal wird das dann durchlaufen,
dann kann man diesen Pegel kaufen.

Damit bin ich immer gut gefahren,
auch bei bösem Prell-Gebaren



In diesem Sinne:
Immer schön elastisch bleiben

MfG Paul

MaWin schrieb:
>> Sicheres Entprellen macht man mit Mehrfachabtastung.
>
> Nö. Damit demonstriert man nur, daß man das Problem nicht verstanden
> hat.

Super! Vielen Dank für die Aufheiterung!

Du kennst also meine Lösung noch nicht.

Prellen ist eine abklingende Schwingung. Wenn man mehrfach abtastet, muß 
man nur unter der Periode bleiben, nicht unter der Gesamtzeit der 
Schwingungen.
D.h. man kann schlechtere Tasten oder in kürzerer Zeit entprellen.

Und als Dreingabe bis zu 8 Tasten entprellen ohne höhere CPU-Last, ist 
auch ganz nett.


Peter

P.S.:
Edit: Tausche "unter" gegen "über":

"Prellen ist eine abklingende Schwingung. Wenn man mehrfach abtastet, 
muß man nur über der Periode bleiben, nicht über der Gesamtzeit der 
Schwingungen."


Peter

MaWin schrieb:
> So wie alle vernünftigen Lösungen in praktisch allen kommerziellen
> Geräte mit uC es machen:

Ja leider, da muß man sich viel zu oft über prellende Tasten ärgern.


> Wenn also das
> Datenblatt des Herstellers sagt: Prellen 10msec, dann reicht eine
> Abtastung im 20msec Abstand, um garantiert keinen "doppelten
> Tastendruck" auf Grund des Prellens der Kontakte zu erfassen.

Träum weiter, das ist pures Wunschdenken. Oder Absicht, um Geräte 
schnell altern zu lassen, damit der Kunde wieder neue kaufen muß.

Garantierte Prellzeiten hat man nur bei neuen und extrem teuren Tasten.
Aber in der Regel wird immer das billigste verbaut.

Daher muß dann die Software ran. Meine Entprellroutione wäre längst 
nicht so populär, wenn sich ihre Notwendigkeit nicht erwiesen hätte.


> Es ist Humbug, eine Taste 4 mal oder sonstwie erfassen zu wollen, kostet
> nur unnötig Programmcode und Rechenzeit.

Großer Irrtum Deinerseits. Sie kostet nicht mehr Rechenzeit und 
Speicher, sondern sie spart sogar ein, gegenüber Standardlösungen.
Der Trick sind Bitoperationen, die immer über die volle Breite der CPU 
arbeiten (8, 16 bzw. 32 Bit).
Standardlösungen benutzen Schleifen und Vergleiche, was erheblich 
aufwendiger ist.


> Aber so ein Murks-Code mit
> "Filtern" kommt zu Stande, wenn der Programmierer Prinzip, Ursache und
> Auswirkung des Prellens nicht verstanden hat.

Nö, weil der Programmierer die realen Anforderungen verstanden hat, die 
reale Bauteile stellen.


Kontaktprellen kommt nicht nur durch die Federwirkung zustande, sondern 
auch Verschmutzung kann kurzzeitige Unterbrechungen bewirken.
Wenn dann nicht das Loslassen entprellt ist, merkt der Nutzer das auch 
als Prellen.


Peter

MaWin schrieb:

> Nein, sicher nicht, aber du hast schon ausreichend dargelegt, daß du
> keine blasse Ahnung hast, wie die Standardlösung aussieht.

Mag sein.
Er hat aber eine sehr gut funktionierende Lösung.

> Ihr beide, Jadeclaw und Du, habt offensichtlich nicht begriffen, daß
> z.B. ein Taster, der auf Grund von unruhigem Finger, oder Dreck oder was
> ihr noch alles über Knackfrösche und Gummitaster geschrieben habt,
> schnelle Wechsel zwischen geschlossen und offen ausführt, nicht
> unterscheidbar von absichtlicher oder unabsichtlicher Kontaktgabe ist,
> auch mit euren Algorithmen nicht.

Ich denke, das ist ihnen schon klar.

> Daher sind Lösungen, die nur alle Bruchteile von Sekunden mal nachgucken
> wie der Tastenzustand ist, die besseren Lösungen,

Genau das macht die PeDa-Standard-Entprellung.

Der einzige Unterschied zu deiner Lösung:
Man braucht keine Herstellerangabe über die maximale Prellzeit. Die 
Funktion registriert einen Tastendruck so schnell wie möglich aber so 
langsam wie notwendig. Und sie passt sich an schlechter werdende Taster 
von alleine an.
Zusätzlich 'entprellen' diese 9 Zeilen Code (ich hab jetzt nicht 
nachgezählt) maximal 8 Tasten gleichzeitig und machen auch noch einen 
Autoreapeat wenns gewünscht wird.

Mir scheint du kennst die PeDa Lösung gar nicht.

Klaus schrieb:
> Leute die bisherigen Beiträge von MaWin sollten euch doch schon gelehrt
> haben, dass ihr ihn besser ignorieren solltet.

Nein.  Er mag manchmal eigenwillige Ansichten haben (die man wohl
am besten ignoriert), ich habe aber auch schon so viel schnelle und
kompetente Hilfe von ihm gesehen, dass man das "immer ignorieren"
keineswegs unterschreiben kann.

MaWin schrieb:
> Ich kenne die Seite http://www.mikrocontroller.net/articles/Entprellung
> und darin ist Peter Danneggers Lösung die grausamste von allen.

Die, wo mein Name als Kommentar drübersteht:

http://www.mikrocontroller.net/articles/Entprellung#Komfortroutine_.28C_f.C3.BCr_AVR.29


Der Rest ist nicht von mir!


Peter

MaWin schrieb:

> Mit Verwendung von delay-Funktionen und seitemlangem Code, die meinst du
> wohl.

Scroll weiter nach unten.
Dort wo "Komfortroutinen" steht.

Das diese _delay Entprellung Müll ist, brauchst du hier niemandem 
erzählen.

Stefan schrob:
>Super! Vielen Dank für die Aufheiterung!

Leser schrob:
>Sehr schön Paul. Immer wieder gerne genommen deine Reime :-)

Ich freue mich, daß ihr Euch freut.
;-)

MfG Paul

MaWin schrieb:
>> Wie machst Du es?
>
> So wie alle vernünftigen Lösungen in praktisch allen kommerziellen
> Geräte mit uC es machen:
>
>
> Den Tastenzustand nur in so langsamen Zeitabständen erfassen (samplen
> per IN am Port), die über der maximalen Prellzeit liegen. Wenn also das
> Datenblatt des Herstellers sagt: Prellen 10msec, dann reicht eine
> Abtastung im 20msec Abstand, um garantiert keinen "doppelten
> Tastendruck" auf Grund des Prellens der Kontakte zu erfassen.
>
> Es ist Humbug, eine Taste 4 mal oder sonstwie erfassen zu wollen, kostet
> nur unnötig Programmcode und Rechenzeit. Aber so ein Murks-Code mit
> "Filtern" kommt zu Stande, wenn der Programmierer Prinzip, Ursache und
> Auswirkung des Prellens nicht verstanden hat.
>
> In der Praxis muss man nicht mal ins Datenblatt des Tastenherstellers
> gucken, denn man kann die Zeit so lang machen, wie der Benutzer noch
> keine Verzögerung bemerkt, so 100msec sind einerseits akzeptabel,
> erlauben andererseits noch schnelles Durchklackern wenn der Nutzer
> schneller als 1 mal pro Sekunde auf den Knopf drückt, bis 5 Tastendrücke
> pro Sekunde wären möglich (bei 100msec Abtastzeit).
Eben nicht. 100ms sind unergonomisch. Das sind dann Geräte, bei denen 
man extra lange auf die Taste drücken muß, bis der Tastendrück überhaupt 
erkannt wird. Mal eben schnell 5 mal gedrückt und es sind nur drei 
Tastendrücke erkannt worden. Furchtbare Ergonomie - wie man sie 
beispielsweise von 2,99 € LCD-Geräten aus dem Supermarkt kennt.

Schau' Dir mal die PeDa-Lösung an. Ist wirklich genial!

Gruß,
Bernd

P.S.:

Ich hab dann noch die Macroversion geschrieben, weil Anfänger oftmals 
Angst vor Interrupts haben.
Steht aber auch da, daß sie nicht so gut ist.

Sie wartet bei jedem Wechsel 25ms, damit kann man in vielen einfachen 
Programmen leben.
Die 25ms müssen prellfrei sein, d.h. aber nicht, daß Preller >25ms 
durchkommen. Es wird darin 255 mal abgetastet, also muß eine einzelne 
Prellschwingung <25ms sein, die gesamte Prelldauer kann ruhig erheblich 
>25ms sein.
Es ist eben ein Kompromiß zwischen Funktion und einfacher Anwendung.
Und das Macro darf auch nur genau einmal pro Taste expandiert werden.


Für komplexere Programme ist sie nicht geeignet, da gebe ich Dir Recht.
Aber dann weiß man auch, wie man die bessere Version mit Timerinterrupt 
verwenden muß.


Peter

Peter Dannegger schrieb:
> Ich hab dann noch die Macroversion geschrieben, weil Anfänger oftmals
> Angst vor Interrupts haben.

Ich würde mich nicht als Anfänger bezeichnen, höchstens etwas 
eingerostet, da C-Programmieren bei mir etwa 10 Jahre zurückliegt.
Der Grund warum ich Deine fraglos gute Entprellung nicht benutze ist 
nicht Angst vor Interrupts ;-) sondern ganz einfach weil ich sie nicht 
nachvollziehen kann, ich verstehe den Code nicht, es fehlt mir wohl an 
Abstraktionsvermögen.
Das geht natürlich garnicht, wenn debuggt werden muß (für mich) 
unverständlichen Code zu haben.
Kurz vor dem schreiben einer eigenen Routine habe ich deshalb in meinen 
Projekten den Ganssle-Debouncer eingesetzt, den kann ich nachvollziehen 
und verstehen. Funktioniert auch toll.

Allgemein gesprochen: es ist sehr schön wenn man fertigen Code für sein 
Projekt nutzen kann, aber er muß verstehbar und für einen selbst 
nachvollziehbar sein. Dein Code ist dafür zu elitär.



Disclaimer: Wie immer ohne Schießgewehr, ich habe nur für mich selbst 
gesprochen.

Micha H. schrieb:

> Der Grund warum ich Deine fraglos gute Entprellung nicht benutze ist
> nicht Angst vor Interrupts ;-) sondern ganz einfach weil ich sie nicht
> nachvollziehen kann, ich verstehe den Code nicht, es fehlt mir wohl an
> Abstraktionsvermögen.

Sieh diese Funktionalität als Baustein an.
So wie du einen printf() oder einen sprintf() oder einen sin() oder was 
auch immer du willst, benutzt.

> Das geht natürlich garnicht, wenn debuggt werden muß (für mich)
> unverständlichen Code zu haben.

Das schöne ist:
Den musst du nicht debuggen. Das Teil funktioniert einfach.

Solange die ISR regelmässig aufgerufen wird, ungefähr im Zeitraster von 
10 Millisekunden (ist absolut unkritisch), und die #define stimmen, 
funktioniert der Code.

Ich gebe zu, dass der Code ziemlich trickreich ist und nicht leicht zu 
verstehen. Aber wie gesagt: Ich verstehe auch nicht, welche Klimmzüge 
gemacht werden um einen ln schnell zu berechnen. Das hindert mich aber 
nicht die Funktion log() ganz einfach zu benutzen, wenn ich sie brauche.

Bei dieser Entprellung rück sogar ich von der Prämisse ab, dass man Code 
den man verwenden möchte wenigstens in Grundzügen verstehen sollte. Und 
ja, ich habe den Code schon analysiert und verstehe auch wie und warum 
er funktioniert.

Karl heinz Buchegger schrieb:
> Den musst du nicht debuggen. Das Teil funktioniert einfach.

Glaube ich unbesehen, aber...
Ich hatte in meinem Projekt genau den Fall, daß etwas nicht korrekt 
funktionierte und auf einen Bug in der Tastenabfrage hindeutete.
Am Ende stellte sich zwar raus daß der Fehler von ganz woanders herkam, 
aber ich war doch froh daß ich die Entprellung verstand und dadurch 
schließlich als Fehlerursache ausschließen konnte.

> Bei dieser Entprellung rück sogar ich von der Prämisse ab, dass man Code
> den man verwenden möchte wenigstens in Grundzügen verstehen sollte.

Genau das meine ich. Im Sinne von Produktivität mag es sinnvoll sein, 
fertige und unverstandene Codeteile zu übernehmen, sofern sie "proven" 
sind. Ich muß jedoch nicht für den neuen Ferrari des Chefs hacken, 
sondern tu das aus Spass und Freude nur für mich selbst. Und für meine 
Hobbyprojekte will und muß ich alles verstehen, was ich an Code 
schreibe.
Ich bin kein Chinese ;-)

puffel schrieb:
> Seine Lösung, den Taster mit einem bestimmten
> Zeitraster regelmäßig abzufragen

Was anderes macht Peters Lösung ja am Ende auch nicht.  Sie enthält
(in der im Artikel geschriebenen Form) nur gleich noch dem Timer
selbst (der leider in klassischer 8051-Manier neu geladen wird, statt
den mittlerweile bei allen AVRs vorhandenen CTC-Modus zu nutzen).

Jörg Wunsch schrieb:

> selbst (der leider in klassischer 8051-Manier neu geladen wird,

Ich will PeDa da nicht ins Handwerk pfuschen, aber diesen Reload hätt 
ich rausgeworfen. Denn ob die ISR alle 10 Millisekunden oder alle 5 oder 
alle 15 oder ... aufgerufen wird, spielt absolut keine Rolle.
Dieser Reload betont in meinen Augen diese 10ms viel zu sehr. Ein 
Kommentar bei der Timer Initialisierung, dass man sich bemühen soll, in 
etwa auf 10 Millisekunden für den Overflow zu kommen, hätte komplett 
ausgereicht.

Leider gibt es keine einfache Möglichkeit den Prescaler aus F_CPU und 
gewünschter Zeit zu bestimmen, die auf allen AVR funktioniert.

MaWin schrieb:
> und wenn man die auseinandernimmt, kommt die übernächste Lösung,
> und PeDa sagt selbst:
>
>> Für komplexere Programme ist sie nicht geeignet, da gebe ich
>> Dir Recht.

Du zitierst (mit Absicht?) unvollständig.

Das obige hat PeDa ausschließlich auf die Macro-Version bezogen, nicht 
auf die Timer-Version.

Hier das vollständige Zitat:

| Für komplexere Programme ist sie nicht geeignet, da gebe ich Dir Recht.
| Aber dann weiß man auch, wie man die bessere Version mit Timerinterrupt
| verwenden muß.

> statt es einfach ein mal und richtig zu machen,

hat er doch - nämlich in der Timerversion.

Ist das wirklich MaWin oder ein Troll? Von dem "echten" MaWin hätte ich 
bessere Argumente erwartet.

MaWin schrieb:
>> Schau' Dir mal die PeDa-Lösung an. Ist wirklich genial!
>
> Habe ich, Karl heinz Buchegger erwähnt nicht ohne Grund daß sie
> mit ihrem delay Müll sind und verweist auf die nächste
> angeblich nun endgültige Lösung,
> und wenn man die auseinandernimmt, kommt die übernächste Lösung,
> und PeDa sagt selbst:

Sag mal. Hast du eine Leseschwäche?

Die PeDa Lösung ist diejenige, die im Artikel Entprellung unter 
Komfortlösung angegeben ist. Und bei der gibt es nichts zum 
auseinandernehmen.

Ich dachte eigentlich, dass das mehr als deutlich rüber gekommen ist.


>> Für komplexere Programme ist sie nicht geeignet, da gebe ich
>> Dir Recht.

PeDa sprach von einer Alternativ-Einfach-Lösung, die für Programmierer 
gedacht ist, die mit Timer und Interrupts auf Kriegsfuss stehen. Aber 
auch das ist in seinem Beitrag deutlich ausgesprochen worden.

Martin schrieb:
> ... statt es einfach ein mal und richtig zu machen, gibt ja schliesslich
> genug AppNotes "Display und Keyboard" von Microchip und Atmel die zeigen
> wie's geht ...
>
> Hier ein Beispiel von Atmel. So ist "richtig" gut ;)
>

1

> __interrupt void PCINT1_ISR(void)

2

> {

3

>   unsigned int delay=2857;             // 7 cycles per count, 20 ms @ 1

4

>   do

5

>   {}

6

>   while(delay--);                     // de-bounce: allow inputs to settle

7

>

8

>   (...)

9

>

10

> }

11

>

Das ist allerdings wirklich eine "geniale" Lösung. Mal eben in der ISR 
20ms Pause einzulegen. Das ist normalerweise ein Kündigungsgrund.

Gruß,
Bernd

Bernd O. schrieb:

> Das ist allerdings wirklich eine "geniale" Lösung. Mal eben in der ISR
> 20ms Pause einzulegen. Das ist normalerweise ein Kündigungsgrund.

Kündigungsgrund ist höchstens wenn man nicht erkennt, dass das (einen 
halbwegs intelligenten Compiler vorausgesetzt) zu exakt 0ms Wartezeit 
führt und damit die ganze Systematik ad absurdum führt.

Und wenn man das dann so umbaut, das dieses Problem nicht mehr besteht, 
wird auch gleich noch die Arbeitslose gestrichen :-)

Ein Tiefpass kostet wieder auch Board-Fläche, Software nur nen paar 
Bytes mehr im Flash des µCs.

HildeK schrieb:
> Zugegeben, ich habe den Thread nur oberflächlich durchgescrollt und ich
> habe auch Peter Dannegers Entprellroutine nicht in allen Einzelheiten
> verstanden, aber manche real existierende Entprellroutine, wie z.B. im
> Aufzug in unserem Bürogebäude, haben den Namen nicht verdient. Es darf
> nicht vorkommen, dass auch ein sehr kurzer Tastendruck einfach ignoriert
> wird.
So einen Aufzug kenne ich auch:
Man drückt die Taste kurz, die Glühbirne dahinter leuchtet sogar kurz 
auf - aber die Entprellung hat die Taste noch nicht akzeptiert. Hat 
vermutlich so ein Schlaumeier implementiert, der meint 100 ms Abtastung 
und dann 5 Ereignisse in Folge seien eine gute Entprellung.

Andererseits ist es ganz lustig. Es steigen immer wieder Leute in den 
Aufzug, die ihr Stockwerk nur vermeintlich anwählen - so komme ich dann 
schneller da hin wo ich hin will und das dumme Gesicht, wenn der Aufzug 
am Ziel vorbeifährt ist auch nicht zu verachten...

Gruß,
Bernd

> Nehmt doch einfach Gummimatten,
> die noch nie ein Prellen hatten!

@Paul: Diese Sc/%§$! Carbon Kontakte prellen am schlimmsten.

Im Automotivebereivch verwenden wir i.A: 20..30mS. In dieser Zeit wir 
der Eingang n mal abgefragt.
Die Strategie is unterschiedlich:
1. Messe Pegel bei Signalaenderung, warte 20ms, messe Pegel. Wenn gleich 
dann loese Aktion aus (Interrupt on change)
2. Messe Pegel alle 2mS. Wenn 8 mal der gleiche Wert, dann loese Aktion 
aus (Polling)

Und ein RC Glied ist am EIngang sowieso noch vorhanden (ESD Schutz) aber 
ein Entprellen darueber ist zu langsam!


Gruss

Michael

PS.: Alle mechanischen Schalter prellen mehr oder weniger. Der Hinweis 
auf Lebensdauer war sehr wichtig!
Und es haengt vom Strom und der Spannung ab.
Vieles dazu findet man unter Reialsdaten. Die Daten fuer Schalter sind 
spaerlicher.


Gruss

Michael

Marc schrieb:
> Ein Schmitt-Trigger ist bei RC-Glättung auf jeden Fall erforderlich.

Wenn sich die Leute doch wenigstens mal das ganssle.com-Paper da
oben durchlesen würden...

Das Prellen ist ein stochastischer Vorgang, d.h. die Prellzeit kann 
stark variieren.
Will man also nur einmal abtasten, muß man die maximale Prellzeit 
abwarten und erhält eine deutlich verzögerte Reaktion.
Tut man dies nicht, kann er 999-mal funktionieren und einmal prellen.
Der Mensch ärgert sich dann genau über dieses eine Mal 
Nichtfunktionieren.

Die Mehrfachabtastung würde dann nur dieses eine Mal länger brauchen, 
aber die anderen Male deutlich eher reagieren.
Und wenn man sich den geradezu lächerlich geringen Codeaufwand ansieht, 
gibt es überhaupt keinen Grund, die Vorteile der Mehrfachabtastung nicht 
zu nutzen.


Ein RC-Glied ist deshalb ungeeignet, weil seine Funktion stark variiert.
Wurde lange nicht gedrückt, ist der Kondensator entladen und braucht 
lange, um zu reagieren. Der erste Tastendruck wird also lange verzögert.
Unmittelbar nach dem Drücken ist der Kondensator aber nahe der 
Schaltschwelle geladen und damit seine Entprellwirkung gering bis 
garnicht.

Deshalb benutzen HW-Entprell-ICs einen Taktgenerator und tasten den 
Eingang mehrmals ab (z.B. MAX6818, Seite 4, Figure 1).
Also exakt genauso, wir man es in SW machen würe.

Ob man nun 10 Zeilen Code includiert oder lieber 9,35€ (Farnell) 
bezahlt, muß jeder für sich entscheiden.



Peter

Marc schrieb:
>> Wenn sich ... doch wenigstens
> Ja gut...
>
> Dafür kriegen wir hier so weitere Quellen rein !

Ist schön, aber gerade die Grundlagen der Entprellung mit RC-Filter
sind dort schon gut aufbereitet.

Bei der ganzen Diskussion wird völlig außer Acht gelassen, dass man in 
Hardware mittels eines RC-Gliedes auch sehr wirksam entprellen kann.
Wenn dieser Hardware-Aufwand im Design kein Problem darstellt (Platz, 
Kosten), kann man durch hohe Dimensionierung von R das Prellen der 
allermeisten Taster nahezu ganz verhindern.

Di Pi schrieb:
> Bei der ganzen Diskussion wird völlig außer Acht gelassen, dass man in
> Hardware mittels eines RC-Gliedes auch sehr wirksam entprellen kann.
> Wenn dieser Hardware-Aufwand im Design kein Problem darstellt (Platz,
> Kosten), kann man durch hohe Dimensionierung von R das Prellen der
> allermeisten Taster nahezu ganz verhindern.

Kann man.
Nur muss man es richtig machen.
Das Pollin Board macht es nicht richtig. Die ganzen R und C bringen den 
µC regelmässig zum Absturz.
Hardware-Entprellung stilllegen und auf Software umsteigen und der Spuk 
hat ein Ende.

Karl heinz Buchegger schrieb:
> Nur muss man es richtig machen.

Das steht natürlich außer Frage ;)

Klaus schrieb:
> Marc schrieb:
>> Tow
>
> WTF?!?

Er meint die Zeitkonstante Tau

Marc schrieb:
> Ein Kondensator ist in der Zeit von 5 Tow fast vollständig geladen.
Es heißt Tau, und du hast Peters Post nicht gelesen, denn der 
Kondensator ist nur in 5-Tau geladen, wenn er vorher leer war. War er 
das nicht (wegen einem vorangegangenen Tastendruck, dann ist er in einer 
anderen Zeit geladen. Und das ist eben nicht "reproduzierbar". Also die 
Anfangsbedingungen sind nicht immer gleich.

Der Code den MaWin oben übrigens gepostet hat, ist von der Funktion fast 
identisch mit Peters Code. Nur, dass Peter eine 4 fach Abtastung noch 
durchführt, was, wie er auch schon gesagt hat, in Anbetracht der wenigen 
zusätzlichen Rechenpower (Das sind echt nur 3 oder 4 Zyklen) sich 
absolut lohnt.

screwdriver schrieb:
> Bei einer Hardware-Entprellung sollte dann aber der µC-Eingang über
> einen Schmitt-Trigger verfügen. Sonst geht der Schuß doch nach hinten
> los, oder?

Gibt es überhaupt (noch) Mikrocontroller ohne Schmitt-Trigger Eingänge? 
Schmitt-Trigger ist immer son tolles Wort, das vermutlich nicht 
unbedingt im Datenblatt stehen muss. Es ist ja auch einfach nur die 
Bezeichnung für eine kleine (definierte) Hysterese an den Eingängen. Und 
das hat eigentlich (fast) jeder Mikrocontroller.

puffel schrieb:

>> Es gibt im realen Leben nicht nur Tastenprellen sondern auch noch so
>> schöne Dinge wie ESD-Impulse, Wackelkontakte in Leitungen usw.
>
> Was bitte hat denn Entprellung von Tasten mit sicherheitskritischer
> Software und Schutz gegen ESD-Impulse usw. zu tun?

No, Ich würde mich schön bedanken, wenn sich meine Geräte selbst 
verstellen, nur weil sie sich einen Puls eingefangen haben.

Zb mein Fernseher.
Das nervt tierisch, wenn der sich Abends ein paar Infrarot Impulse 
einfängt und die dann als 'OSD anzeigen' interpretiert. Gott sei Dank 
holt sich der immer nur das OSD und nicht 'Lautstärke volle Pulle'. So 
ist dann wenigstens der Fernsehschlaf gesichert.

Marc schrieb:
> Wie schnell ist ein Mensch in der Lage, kurz nach dem drücken eines
> Tasters, seine Muskeln zu entspannen um diesen Wieder loszulassen...

Ziemlich schnell.  Eine Wiederholrate von 10 Hz (also rund 50 ms
"ein" / 50 ms "aus") konnte man bereits problemlos mit dem
ergonomisch sicher völlig ungeeigneten Gabelkontakt eines analogen
Telefons erreichen, um auf diese Weise eine Impulswahl durchzuführen.
Wenn du den Kontakt ergonomisch günstiger aufbaust, dann kannst du
dir mal angucken, was die Leute so aus einer Morsetaste rausholen...
15 Hz und mehr sind da durchaus drin.

Jörg Wunsch schrieb:
> Marc schrieb:
>> Wie schnell ist ein Mensch in der Lage, kurz nach dem drücken eines
>> Tasters, seine Muskeln zu entspannen um diesen Wieder loszulassen...
>
> dann kannst du dir mal angucken, was die Leute so aus einer Morsetaste
> rausholen... 15 Hz und mehr sind da durchaus drin.

Oder aus einem Spielautomaten
http://en.wikipedia.org/wiki/Track_&_Field_%28video_game%29

Marc schrieb:
> Laut Weltrecord liegt das Dit da bis an die 16ms und drunter

Allerdings nicht mit einer Handtaste.

Also Maxim ist ja nicht irgendeine kleine Frickelbude.

Und wenn die nen Chip (MAX6818) herstellen, dann werden die sich dabei 
was gedacht haben und dessen Funktion auf Herz und Nieren geprüft haben.
Und die Maxim-Entwicklungsingenieure werden auch nicht alles 
Berufsanfänger sein.

Und wenn dann meine Routine haargenau so funktioniert, wie es die 
Maxim-Profis in Hardware gegossen haben, dann kann ich ja wohl nicht 
alles total falsch gemacht haben.


Peter

Peter Dannegger schrieb:
> Also Maxim ist ja nicht irgendeine kleine Frickelbude.
>
> Und wenn die nen Chip (MAX6818) herstellen, dann werden die sich dabei
> was gedacht haben und dessen Funktion auf Herz und Nieren geprüft haben.
> Und die Maxim-Entwicklungsingenieure werden auch nicht alles
> Berufsanfänger sein.
>
> Und wenn dann meine Routine haargenau so funktioniert, wie es die
> Maxim-Profis in Hardware gegossen haben, dann kann ich ja wohl nicht
> alles total falsch gemacht haben.
>
>
> Peter

Nein, Peter, Du hast da nichts falsch gemacht.

Trotzdem muss man sich schon konzentrieren, Deinen Code zu verstehen. 
Die ASM-Version nutze ich in verschiedenen Varianten und ich bin sehr 
froh, dass es diesen Algorithmus gibt. Die C-Version ist mir zu 
kryptisch, die verstehe ich nicht, muss ich aber auch nicht, denn meine 
Programme sind meist so klein, dass sie in ASM noch überschaubar sind.

Ansonsten kann ich nur sagen, dass dieser Thread recht amysant war/ist, 
er zeigt ein bissel, wie Einige hier so ticken... ;-)

...

@MaWin:

Schau dir dochmal den Peter-Code (den guten) nochmal an, da ist nix 
aufwändiges dabei (ein paar XORs &co).
Und wie du zu deiner anderen Aussage kommst, ist mir auch 
schleierhaft...
Jede Taste hat dort ihren eigenen Zähler, und beeinflusst die anderen 
nicht.

Das Zauberwort ist "SIMD", jeder Befehl wirkt gleichzeitig auf alle 8 
Einzel-Tasten-Datenstrukturen...

MaWin schrieb:
> Also das "Debounce-Makro" ist durch ihr Delay und die nicht mehrfache
> Verwendbarkeit schon grottig

Das steht ausser Frage.
Um die gehts hier nicht. Du brauchst daher darauf nicht länger weiter 
rumzureiten. Wir alle geben dir Recht, dass diese Simpellösung für 
professionellen Einsatz nichts taugt.

>, die "Komfortroutine" ist einfach viel zu
> aufwändig.

Wenn man die paar Takzyklen nicht mehr hat.
Und vieel zu aufwändig liegt im Auge des Betrachters.

> Ein Teil davon geht in Key-Repeat, ist also ok wenn man's
> braucht, aber der Rest ist unnötig.

Der Rest besteht aus 2 Variablen und einem vertikalen Zähler der mit 
einem UND und einem XOR realisiert ist.

> Da jammert dann wieder jemand, daß
> ihm der Controllerspeicher ausgeht, weil er ohne Sinn und Verstand
> massenhaft Code schreibt,

Lass die Kirche im Dorf. Das ist doch nicht massenhaft.

> Zudem hat sie das Problem, daß die Schleifen, die die Prellzeit beheben
> sollen, von allen Tasten gleichzeitig verwendet werden, also nicht jede
> Taste einzeln entprellt wird, sonden so lange eine Taste prellt,
> verhindert sie daß die anderen Tasten erkannt werden.

Das einzige was hier fehlerhaft ist, ist deine Analyse.
Nichts davon ist wahr.

Was ist so schwer daran, einfach zuzugeben, dass du dich geirrt hast?
Passiert jedem mal. Wahre Größe besteht darin nicht auf Biegen und 
Brechen sich selbst als den Allwissenden feiern zu lassen sondern auch 
mal zuzugeben, dass man falsch lag.

MaWin schrieb:
> Also das "Debounce-Makro" ist durch ihr Delay und die nicht mehrfache
> Verwendbarkeit schon grottig,

Das wurde, wie gesagt, für (Timer-)Interrupt-Muffel geschrieben.

> die "Komfortroutine" ist einfach viel zu
> aufwändig.

Also Manfred, da verstehe ich Dich nicht. Was ist hierdran aufwendig?
Der Aufruf erfolgt zyklisch im Zeitabstand von etwa 10ms:

1

Tastenabfrage:  ;Entprell-Algorithmus geklaut bei Peter Dannegger...

2

 in tmp,tap         ;Tastenport einlesen (gedrückt=L)

3

 com tmp            ;invertieren (gedrückt=H)

4

 andi tmp,alltast   ;ungenutzte Bits ausblenden

5

 eor tmp,tas        ;nur Änderungen werden H

6

 and tz0,tmp        ;Prellzähler unveränderter Tasten löschen (Bit0)

7

 and tz1,tmp        ;Prellzähler unveränderter Tasten löschen (Bit1)

8

 com tz0            ;L-Bit zählen 0,2,->1, 1,3,->0

9

 eor tz1,tz0        ;H-Bit zählen 0,2,->tz1 toggeln

10

 and tmp,tz0        ;Änderungen nur dann erhalten, wenn im Prellzähler

11

 and tmp,tz1        ;beide Bits gesetzt sind (Zählerstand 3)

12

 eor tas,tmp        ;erhaltene Änderungen toggeln alten (gültigen) Tastenstatus

13

 and tmp,tas        ;nur (neu) gedrückte Tastenbits bleiben erhalten

14

 or tfl,tmp         ;und zugehörige Bits setzen (gelöscht wird nach Abarbeitung)

15

 ;in "tas" steht jetzt der gültige Tastenzustand,

16

 ;in "tfl" die Flags der neu gedrückten, noch nicht abgearbeiteten Tasten...

Das ist die "Grundroutine" also Abfrage, vierfach-Entprellung und 
Flankenerkennung von bis zu 8 Tasten eines Ports gleichzeitig. Die 
Routine kostet 4 Register und braucht alle 20 ms 13 Takte Rechenzeit (+ 
ein paar Takte für Aufruf und Verwaltung). Was bitte ist daran 
aufwendig? Dafür bekomme ich für 8 Tasten gleichzeitig den Zustand 
(nutzbar für Shift-Tasten) und die Information, ob eine oder mehrere der 
8 Tasten seit der letzten Auswertung erneut (losgelassen und) gedrückt 
wurde. Mehr Komfort bei weniger Rechenleistungsverbrauch kann ich mir 
nicht vorstellen.


> Ein Teil davon geht in Key-Repeat, ist also ok wenn man's
> braucht,

Das wäre dann dieser Teil, ich baue es nur ein, wenn ich es brauche:

1

 ;in "tas" steht jetzt der gültige Tastenzustand,

2

 ;in "tfl" die Flags der neu gedrückten, noch nicht abgearbeiteten Tasten...

3

Tastendauer:

4

 mov tmp,tas        ;Tastenzustand kopieren

5

 andi tmp,wietast   ;nur Tasten mit Wiederholfunktion stehen lassen

6

 tst tmp            ;ist eine Taste betätigt?

7

 breq Tastendauer0  ;nein, Dauer auf Startwert...

8

 dec twz            ;ja, Zähler runter

9

 brne Tastenabfrage_e   ;Dauer abgelaufen? - nein...

10

 or tfl,tmp         ;ja, noch aktive Tasten übernehmen (alternativ)

11

; or twf,tmp         ;ja, noch aktive Tasten übernehmen (alternativ)

12

 ldi twz,twz1       ;und Zähler auf Wiederholwert setzen

13

Tastenabfrage_e:

14

 ret                ;fertig...

15

 ;in "tfl" stehen jetzt wieder die Flags der länger betätigten Tasten

16

 ;sie werden nach Abarbeitung gelöscht

17

Tastendauer0:       ;Reset Dauerzähler

18

 ldi twz,twz0           ;Tastendauerzähler auf Startwert

19

 rjmp Tastenabfrage_e   ;fertig...

Und diese Routine macht den Kohl auch nicht fett, sie braucht lediglich 
noch einen Zähler für die Repeat-Zeit und ein paar Takte Rechenzeit. 
Dafür bekommt man Autorepeat bei längeren Tastendrücken, dessen 
Erstaufruf und Wieredholzeit separat (durch Konstanten) eingestellt 
werden kann.

Ich finde, dass das verdammt viel Funktionalität für verdammt wenig 
Ressourcenverbrauch ist und das lasse ich mir von Dir und Deinen 
Diskussionsbeiträgen nicht kaputt reden.

> aber der Rest ist unnötig.

Welcher Rest? Das war es schon. Gut, wenn man es in C formuliert braucht 
es etwas mehr Ressourcen, da C ja die Variablen im SRAM hält, trotzdem 
meine ich, dass das Aufwand-Nutzen-Verhältnis auch in C unübertroffen 
ist.

> Da jammert dann wieder jemand, daß
> ihm der Controllerspeicher ausgeht, weil er ohne Sinn und Verstand
> massenhaft Code schreibt, und der nächste mit dem Projekt befasste
> jammert, weil er nicht versteht, warum sein Vorgänger da so massenhaft
> merkwürden Code geschrieben hat...

Nööö, jede andere Variante, bis zu 8 Tasten gleichzeitig zu entprellen 
und deren Flanken (erneutes Drücken) separat zu signalisieren braucht 
mehr Ressourcen.

> Zudem hat sie das Problem, daß die Schleifen, die die Prellzeit beheben
> sollen,

Hier gibt es keine Schleifen, die Prellzeit beheben sollen.

> von allen Tasten gleichzeitig verwendet werden, also nicht jede
> Taste einzeln entprellt wird, sonden so lange eine Taste prellt,
> verhindert sie daß die anderen Tasten erkannt werden.

Nein, die Tasten werden separat entprellt. Nur die Taste, die 4 
Abfragerunden hintereinander mit (zum bisher gültigen) entgegengesetztem 
Status eingelesen wird, schafft es, ihren 2-Bit-Prellzähler (je 1 Bit 
jeder Taste in einem Register, das andere Bit jeder Taste im anderen 
Register) hochzuzählen und den (als entprellt geltenden) Status zu 
toggeln. Dies erfolgt beim Drücken genauso wie beim Loslassen.

> Falls du also
> fragst, was Maxim anders macht...

Was MAXIM macht, weiß ich nicht, aber auf Peters Entprellalgorithmus in 
ASM lasse ich nichts kommen. Einfacher und effizienter geht es nicht.

...

Peter, hast du den Algorithmus eigentlich auch schon mal für eine
Matrixtastatur umgebaut?  Das habe ich demnächst vor.  Im Prinzip
müsste man doch nur den Prellzähler N-mal aufbauen und dann an die
gerade abgefragte Reihe binden, oder?  (Mehrere gleichzeitig
gedrückte Tasten würden mich erstmal nicht interessieren.)

Hannes Lux schrieb:

> Was MAXIM macht, weiß ich nicht, aber auf Peters Entprellalgorithmus in
> ASM lasse ich nichts kommen. Einfacher und effizienter geht es nicht.

Und ich lass mir die C Lösung nicht madig reden.
Das ist eine echte "Plug&Play, einbauen und funktioniert" Lösung.
Selten etwas so problemlos zu verwendendes gesehen.

@Jörg: Das sollte problemlos gehen.

Für eine Matrix habe ich es noch nicht gemacht, aber für 40 Tasten, von 
denen 32 per Schieberegister eingelesen werden. Ich habe dazu die 
Variablen im SRAM liegen, organisiert wie 4 Arrays je 5 Elemente. Denn 
jeder 8er-Block braucht ja 4 Bytes (Status, Flanke, Prellzähler L und 
H).

...

U.R. Schmitt schrieb:
> Marc schrieb:
>> Das Prellen ist doch meistens nur ein Vorzeichen für einen Pegelwechsel.
>> Ein unvorhergesehendes Prellen, ohne das der Finger auf dem Taster ist,
>> ist also so gut wie unmöglich.
>> Vorsichtig betrachtet kann man also das erste Prellanzeichen direkt ohne
>> Timer als Flanke wahrnehmen oder was meint ihr...
>> (ich spreche jetzt nicht vom Halten oder wieder Loslassen des Tasters)
>> ... Resultat: Schnellste Reaktionszeit ...
>
> Hab ich doch schon zwei mal gesagt. Ein Taster mit Umschaltkontakt und
> dann ein RS Flipflop. Der Ein Kontakt an den S Eingang und der Aus
> Kontakt an den R Eingang. Es sollte nur kein Taster sein der im Übergang
> kurz alle 3 Kontakte brückt und die Eingänge brauchen einen
> entsprechenden Pullup. Das war das erste was ich ca. 1980 zum Thema
> Digitaltechnik gelernt habe.

Die Methode habe sogar ich noch in der Berufsschule gelernt (2007). Aber 
in der heutigen Zeit ist die (außerhalb vom Hobbybereich) nicht machbar, 
da
a) Umschalter idR teurer sind, als einfache "Omron" Switches (Diese 
Klick-Taster)
b) Besondere Anforderungen an den Umschalter gelegt werden (nicht 
überlappend)
c) Es die Flip-Flop nicht gerade in Miniaturbauweise gibt
d) Die Kosten für die Hardware demnach viel größer sind als die für die 
Software Entprellung (Denn hier kann man ggf. auf existierende, GUT 
funktionierende Bibliotheken zurückgreifen. Hobbybastler zum Beispiel 
auf Danneggers Variante)

EDIT: Ach so, danke an Hannes für diesen (hoffentlich) aufklärenden 
Beitrag mit Codeschnipseln.

Simon K. schrieb:
> Gibt es überhaupt (noch) Mikrocontroller ohne Schmitt-Trigger Eingänge?
Leider Ja. Z.B. diverse PIC16F/18F. Da gibt's den Schmitt-Trigger nur 
für wenige Spezialfunktionen (Timer-Eingang, Interrupt, 
Programmiereingänge), der Rest der I/O-Funktionen/Leitungen hat ganz 
normale, auf TTL-Verhalten ausgelegte Eingänge.
Atmel ist da konsequenter, AVRs haben Schmitt-Trigger rundrum. Einzelne 
Taster bekommt man problemlos mit einem Parallelkondensator und internem 
PullUp recht gut entprellt, wenn der Taster von brauchbarer bis guter 
Qualität ist. Richtig schlechte oder verdreckte Drücker bekommt damit 
natürlich nicht in den Griff, da muß man dann zusätzlich mit Software 
ran.

Amüsanter Thread Schmunzel

MaWin, ich schätze dich als alten Hasen, der bei technischen Problemen
meist sofort aus Erfahrung weiß, wo es lang geht. Wenn man allerdings
wie du keinen Rückwärtsgang hat, sollte man trotz der vielen Erfahrung
erst überlegen, wohin man fährt und dann nicht zu viel Gas geben ;-)

Schmunzel 1:

Peter Dannegger schrieb:
> Sicheres Entprellen macht man mit Mehrfachabtastung.
> Und besonders wichtig, auch beim Loslassen!

MaWin schrieb:
> Nö. Damit demonstriert man nur, daß man das Problem nicht verstanden
> hat.

MaWin schrieb:
> next1key=input(keyport);
>  newkey^=~(next1key^next2key)&(next1key^newkey); // Filtern
>  ...
>  next2key=next1key;

Das, was du hier vorschlägst, ist Mehrfachabtastung, zwar nicht vier-
fach wie bei Peter, aber immerhin zweifach. Du liegst also mit Peter
voll auf einer Schiene :)

Schmunzel 2:

MaWin schrieb:
> Aber so ein Murks-Code mit "Filtern" kommt zu Stande, wenn der
> Programmierer Prinzip, Ursache und Auswirkung des Prellens nicht
> verstanden hat.

MaWin schrieb:
>  newkey^=~(next1key^next2key)&(next1key^newkey); // Filtern
                                                      ^^^^^^^
Ja was jetzt, filtern oder nicht filtern?

Schmunzel 3:

MaWin schrieb:
> Es ist Humbug, eine Taste 4 mal oder sonstwie erfassen zu wollen, kostet
> nur unnötig Programmcode und Rechenzeit.

Also wenn ich deinen Code

1

 next1key=input(keyport);

2

 newkey^=~(next1key^next2key)&(next1key^newkey); // Filtern

3

 changed=newkey^oldkey;

4

 pressed=changed&newkey;

5

 if(pressed&1) // Taste 1 runtergedrückt

6

 if(pressed&2) // Taste 2 runtergedrückt

7

 oldkey=newkey;

8

 next2key=next1key;

in Gedanken 1:1 in Assembler übersetze (ca. 13 Befehle ohne die beiden
Ifs zur Einzeltastenabfrage) und ihn mit dem von Peter

1

      mov    iwr0, key_old

2

      in     key_old, key_port

3

      eor    iwr0, key_old

4

      com    key_old

5

      mov    iwr1, key_state

6

      or     key_state, iwr0

7

      and    iwr0, key_old

8

      eor    key_state, iwr0

9

      and    iwr1, iwr0

10

      or     key_press, iwr1

vergleiche (10 Befehle), dann ist es deine Lösung, die den unnötigen
Programmcode enthält und entsprechend mehr Rechenzeit braucht (wobei
über diese paar Bytes und Taktzyklen zu diskutieren an Erbsenzählerei
grenzt). Die Anzahl der benötigten Variablen bzw. Register ist bei
beiden Lösungen gleich. Peter hat es halt geschafft, mit 2 Bits bis 4
statt nur bis 2 zu zählen und die enstehenden Logikterme so zu
umzustellen, dass sie ein AVR mit der minimalen Anzahl von Befehlen
auswerten kann. Warum soll man diesen Vorteil nicht nutzen?

Schmunzel 4:

Karl Heinz, der auf mich an dieser Stelle völlig untypischerweise einen
leicht genervten Eindruck gemacht hat :), hat es schon in wenigen Worten
zusammmengefasst:

> Sag mal. Hast du eine Leseschwäche?


Jetzt aber wieder todernst:

MaWin schrieb:
> denn man kann die Zeit so lang machen, wie der Benutzer noch keine
> Verzögerung bemerkt, so 100msec sind einerseits akzeptabel,

100ms sind in meinen Augen nicht akzeptabel. Ein kurzes Antippen der
Tasten, wie beispielsweise beim Wählen einer Telefonnummer oder beim
Schreiben auf der Computertastatur, dauert bei mir lt. Oszi nur etwa
30-40ms, und das ist nicht noch lange nicht der worst Case (der liegt
deutlich unter 10ms). Die Pause zwischen zwei Betätigungen derselben
Taste ist aber wesentlich länger, nämlich etwa 80-100ms.

Für eine zuverlässige Tastenentprellung reicht es normalerweise aus, die
Mehrfachabtastung nur beim Öffnen des Tasters zu machen. Da sich ein
offener Taster nach der Prellzeit nicht einfach von selbst schließt (nur
der umgekehrte Fall ist möglich), kann das erste Geschlossensignal
sofort und eindeutig als Tastendruck gewertet werden. Dadurch wird bei
Interruptsteuerung oder entsprechend hoher Abtastrate auch der
8ms-Tippser zuverlässig erfasst. Bevor auf den nächsten Tastendruck
gewartet wird, muss natürlich sichergestellt werden, dass die Taste
zwischenzeitlich losgelassen wurde. Das geht am besten mit Mehrfach-
abtastung, bspw. vierfach im 10ms-Takt. Wegen der relativ langen
Betätigungspausen macht sich die hierfür benötigte Zeit nicht bemerkbar.
Der Benutzer hat also das volle "Echtzeitfeeling", ohne dass die
Zuverlässigkeit leidet.

MCUA schrieb:
>>Für eine zuverlässige Tastenentprellung reicht es normalerweise aus, die
>>Mehrfachabtastung nur beim Öffnen des Tasters zu machen.
> Da würdest du ein (evtl auf der Leitung vorhandenes) On-Spike als
> "Ein"-Taste erkennen!

Richtig. Deswegen muss man hardwareseitig dafür sorgen, dass diese
On-Spikes gar nicht erst auftreten. Das ist aber gerade bei Tastern an
Digitaleingängen nicht sonderlich schwer und muss auch bei allen anderen
I/O-Anschlüssen des Controllers getan werden. Wäre es schwer, dann würde
kein Computer zuverlässig funktionieren, weil bspw. keine der vielen
Busleitungen softwaremäßig gegen Spikes geschützt ist ;-)

MCUA schrieb:
>>Richtig. Deswegen muss man hardwareseitig dafür sorgen, dass diese
>>On-Spikes gar nicht erst auftreten.
> womit dadurch automatisch eine hardw-Entprellung vorhanden ist, was evtl
> eine Softw-Entrellung überflüssig macht.

Nicht automatisch. Um das Prellen hardwareseitig zu bekämpfen, ist meist
mehr Aufwand erforderlich. Gegen elektromagnetische Störungen muss oft
gar nichts getan werden, weil der Störabstand an den Digitaleingängen
schon ausreichend ist. Und sonst gelten halt die üblichen Regeln:
"Antennen" vermeiden, saubere Spannungsversorgung usw. Die meisten
dieser Regeln müssen aber sowieso befolgt werden, egal ob die Schaltung
Taster enthält oder nicht. Für die Taster fällt also kaum zusätzlicher
Aufwand an.

Ich kann mich an keinen Fall erinnern, wo durch äußere Störungen fälsch-
licherweise ein Tastendruck erkannt worden ist, nicht einmal bei ganz
billigen Geräten.

MaWin schrieb:
> Das was du vorliest, ist nicht der zum entprellten Einlesen notwendige
> Algorithmus, der stand drüber, das hättest du schon sehen können, und er
> war deutlich kürzer.
>
> Das was du nun herbeiziehst, ist die zweite Programmvariante, die
> einzelne ESD-Störungen die von Anja hereingebracht wurden, filtert. Ja,
> die filtert durch Mehrfachabtastung.

Die Mehrfachabtastung macht man ja nicht nur wegen der ESD-Störungen.
Auch ein Reiben der Kontakte aneinander im gedrückten Zustand kann zu
kurzzeitigen Unterbrechungen führen, die deine erste Variante als
Loslassen und erneutes Drücken des Tasters interpretieren würde.
Deswegen muss zumindest für die zuverlässige Erkennung des Öffnens ein
ganz klein wenig mehr Aufwand getrieben werden.

Tobi schrieb:
> Wuff... Was wird das denn hier? Eine wissenschaftliche Abhandlung über's
> Entprellen? Entschuldigt bitte mein Unverständnis, aber warum wird
> deswegen teilweise so eine Unmenge an Code gebraucht?

Was für eine Unmenge?

Erweitere deine Lösung auf mehrere Taster und deine Lösung wird auch 
größer.

Die PeDa Entprellung funktioniert im Prinzip genau wie deine, nur macht 
sie den Zähler ein wenig cleverer. Um bis 5 zu zählen braucht man keine 
8 Bit. Da die PeDa Lösung aber bis zu 8 Taster entprellen möchte 
(meistens hat man ja mehr als nur 1 Taster in einer Anwendung) und nur 
bis 4 zählt (dafür sind 2 Bits nötig) benötigt man dafür minimal 16 Bit. 
Und genau das macht diese Entprellung: sie kommt mit 16 Bit aus um für 8 
Eingänge jeweils einen Zähler zu implementieren der bis 4 zählen kann.

Der Rest rundherum ist dann Komfort, der nebenbei abfällt, wie zb das 
automatische Löschen einer gedückten Tastenkennung wenn du dir den 
Status holst. Oder hast du bemerkt, dass in deiner Musterlösung ein 
einmal gedrückter Taster ständig erneut als gedrückt erkannt wird, 
solange der Benuter draufdrückt?

Die einen brauchen eben Funktionalität, die abläuft wenn ein Taster 
gedrückt ist versus Funktionalität wenn der Taster nicht gedrückt ist. 
Die anderen benötigen ein Einmalereignis für den Fall das der Taster 
gedrücktr wird (zb für Eingaben) etc. Da gibt es viele Spielarten, die 
mit der PeDa Entprellung alle erschlagen werden.

Pothead schrieb:
> Simon K. schrieb:
>> War er
>> das nicht (wegen einem vorangegangenen Tastendruck, dann ist er in einer
>> anderen Zeit geladen. Und das ist eben nicht "reproduzierbar". Also die
>> Anfangsbedingungen sind nicht immer gleich.
>
> Dafür kann gesorgt werden. Wenn ein gültiger Tastendruck detektiert wird
> entlädt man das C einfach über den Portpin.
Das ist doch wieder nur unnötiger Aufwand. 2 Pins für jeden Taster, den 
man anschließen möchte?! Na gut, man könnte natürlich über den gleichen 
Pin entladen, dann braucht man aber noch einen Widerstand in Reihe -> 
Wieder ein Bauteil mehr. Mehr als 10nF würde ich nicht direkt per 
Portpin kurzschließen.

EDIT: Das geht übrigens gar nicht, denn man darf den Kondensator erst 
kurzschließen, wenn der Taster bereits wieder losgelassen wurde. Aber 
wie will man das Erkennen? Hängt ja die R-C Kombination dran, die das 
verzögert...

screwdriver schrieb:
> Die Hysterese ist dann in den
> DC-Characteristics angegeben und beträgt 40% Vcc.

Das hast du falsch verstanden. In den Fußnoten zu den Tabelleneinträgen
steht, warum.

Die Hysterese ist im Diagramm "I/O Pin Input Hysteresis" dargestellt und
liegt deutlich unter einem MilliVolt.

Um diese geringe Hysterese für eine Entprellung zu nutzen, müsste man
die Zeitkonstante des RC-Glieds so groß machen, dass die Reaktionszeit
beim Öffnen des Tasters evtl. nicht mehr akzeptabel ist.

Pothead schrieb:

> Aber ja. Sobald man einen gültigen Übergang detektiert hat kann man das
> C entladen - was eine gewisse Zeit dauert (Tau, das man so wählen kann,
> dass man eine angemessene Wiederholrate bekommt).

Gleich vorweg: Ich habe eure Diskussion nicht vollständig verfolgt.
Aber ich hab da jetzt eine Frage:

Wenn ich bei deiner Lösung sowieso wieder eine spezielle 
programmtechnische Bearbeitung benötige, was ist dann der Vorteil 
gegenüber einer reinen Softwarelösung, die ohne externe Komponenten 
auskommt?

Ich verstehs nicht. Angenommen ein Tastendruck wird erkannt, dann wird 
der Kondensator kurzgeschlossen und der Kondensator ist für den nächsten 
Tastendruck bereit.
Aber was ist denn, wenn der Nutzer den Taster gedrückt hält? Das ist gar 
nicht zu unterscheiden davon, als würde der Nutzer den Taster immer 
wieder drücken. Man muss also das "Auto Repeat" (dessen Frequenz von 
der Zeitkonstante abhängt) benutzen.

Außerdem ist der Programmaufwand nicht zu unterschätzen (Im vergleich 
zur Entprellung direkt in Software). Irgendwann muss der Pin auch wieder 
auf Eingang gesetzt werden. Also entweder Warteschleife oder 
"Merkervariable".
Wie Karl Heinz schon sagt, das ist doch im Prinzip ein Mehraufwand.

ESD kann man AFAIK auch einfacher abhalten.

Pothead schrieb:
> Karl heinz Buchegger schrieb:
>> Wenn ich bei deiner Lösung sowieso wieder eine spezielle
>> programmtechnische Bearbeitung benötige, was ist dann der Vorteil
>> gegenüber einer reinen Softwarelösung, die ohne externe Komponenten
>> auskommt?
>
> Mindestens ein Vorteil hat dieses Verfahren. Du hast mit dieser
> Schaltung automatisch einen sehr wirkungsvollen ESD Schutz, da man mit
> R1 ein (sehr) hochohmiges Längsglied hat (R1 sollte entsprechend
> ausgewiesen sein).

Gut, das kann ich so auch machen.

> Außerdem ist es programtechnisch simpelst zu
> realisieren - das RC-Glied geht auf einen Portpin mit
> Interruptfunktionalität, sobald ein Interrupt kommt kann man das
> Ereignis registrieren und gleichzeitig das C entladen.

Äh nein.
Entladen kannst du erst anfangen, wenn der Benutzer wieder losgelassen 
hat. Aber ok, ist jetzt ein Detail

> dieser eine geeignete Periodendauer hat. Weiterer Vorteil: Es passiert
> nur dann (und nur dann) etwas, wenn eine Taste gedrückt wird.

OK.
Seh ich ein. Wenn man auf die letzten paar Prozentpunkte Rechenkapazität 
angewiesen ist, ist das natürlich ein Argument.

Noch ne Anmerkung:

Die Macro-Version hat schon ihre Berechtigung.
Sie ist überhaupt nicht so schlecht, wie hier versucht wird, einem 
weiszumachen.

Sie ist popeleinfach anzuwenden (kein Interrupt, kein Timer).
Sie ist vielleicht nicht der Brüller, wenn man riesen Menüsteuerungen 
auf nem ATmega2560 programmiert.

Aber die meisten Anwendungen ala ATmega8 sind recht einfach gestrickt 
mit ner schnellen Mainloop und da ist sie gut.
Sie bestraft allerdings Programmiersünden, wie "delay_ms(1000)".

Sie arbeitet ähnlich wie das Debounce von Bascom und das wird sehr gerne
benutzt. Das Bascom-Debounce wartet immer die vollen 25ms.

Bascom erlaubt, die Routine an mehreren Stellen für die gleiche Taste 
aufzurufen. Das ist mit der C-Syntax nicht möglich.
Ist aber überhaupt kein Beinbruch, dann macht man eben ne echte Funktion 
für diese Taste und die kann man dann beliebig oft aufrufen.


Und wer die Komfortroutine benutzt, der merkt schnell, daß da keine 
einzige Zeile überflüssig ist. Da man sie selbst auf dem winzigen 
ATiny13 einsetzen kann, ist eine Diskussion über Codegröße schlichtweg 
Unsinn.

Sie macht erheblich mehr, als nur ein Entprellen, aber alles Sachen, die 
in der Praxis häufig benötigt werden.
Wer auch nur etwas C kann, wird schnell erkennen, was er weglassen kann, 
z.B. wenn die Repeatfunktion nicht benötigt wird.
Ich hielt es daher unnötig, das extra mit einem "#ifdef" zu kapseln.
Es stört selbst beim winzigen ATtiny13 kaum, wenn man es drinläßt.

Nicht umsonst gehört vor dem effektiven Optimieren erstmal ein 
Profiling. D.h. eine Funktion sollte mindestens einige 100Byte groß 
sein, ehe sich eine Optimierung lohnt.
Ein PC-Programmierer würde darüber nur lachen, der optimiert erst ab 
1MByte aufwärts.


Peter