www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Wie lange prellt ein Taster in der Regel?


Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Morgen zusammen.

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

Reichen 10ms?

Danke!

Autor: Guest (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kommt immer auf den Taster an, aber dafür gibts ja gute 
Entprellroutinen.
Einfach mal die Forensuche anschmeißen :-)

Autor: M. B. (reisender)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja sollte auf jeden Fall reichen. Ist eher ne grosse Entprellzeit.

Autor: Thorsten ... (tms320)
Datum:

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

Autor: Mr. Debounce (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier die "Bibel zum Thema 'Prellen/Entprellen'", wo die Frage nach der 
Prelldauer ausführlich behandelt wird: 
http://www.ganssle.com/debouncing.pdf

Autor: Ausrufer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Zitiere daraus:
The short answer: sometimes a lot, sometimes not at all.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter Dannegger schrieb:
> Stures Warten ist kein Entprellen!

Ist mir klar, deshalb ja:

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

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich danke euch! Mir gings nur um die Zeit. Aber stimmt schon, mit Peters 
Methode ist auch der Alterungsprozess / Mülltaster quasi abgefangen.

Autor: STK500-Besitzer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das Einfachste ist do, erst gar keine Taster zu verwenden.
SCNR

Autor: Paul Baumann (paul_baumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> aber dafür gibts ja gute Entprellroutinen.

Eben, und dazu braucht man Kenntnis übe die maximel Prellzeit.

10ms ist für die üblichen Taster (Sprungkontakt) gut.

Man kann auch umgekehrt fragen: Wie langsam darf ich abtasten, bevor der 
Benutzer die Verzögerung störend bemerkt.

100ms.

> Sicheres Entprellen macht man mit Mehrfachabtastung.

Nö. Damit demonstriert man nur, daß man das Problem nicht verstanden 
hat.

Autor: Stefan (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Paul,

Super! Vielen Dank für die Aufheiterung!

Viele Grüße, Stefan

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also wenn ich zyklisch den Taster abfrage, dann kann der Timer ja 
permanent laufen.

Ich kann ja aber auch nach einem Port-Interrupt den Timer starten und 
danach zyklisch abfragen.

Was ist besser?

Autor: EntprellterGast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>> Sicheres Entprellen macht man mit Mehrfachabtastung.

>Nö.

Wie machst Du es?

Autor: Lalala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Horst schrieb:
> Was ist besser?

Da man in vielen Fällen sowieso einen System-Timer für irgendwelches 
Gekruschel braucht, einfach den Timer als System_Timer mitlaufen lassen.

Einen Taster an einem Interrupt-Eingang lohnt wenn der IRQ dem MCU aus 
einem Sleep aufweckt, aber nicht für die Entprellung.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lalala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
EntprellterGast schrieb:
> Wie machst Du es?

Ich wette er loopt und findet es cool.

Für den Rest der Welt tut es die Unterabtastung mit einer 1-Bit 
Quantisierung und Analyse von ca. vier aufeinander folgenden 
Abtastwerten (ein digitales Filter) wunderbar.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Lalala (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kopfkratz ...

Hmm, das Spektrum der Schaltflanken enthält doch weit über der 
Abtastfrequenz liegende Frequenzanteile. Also liegt man mit der 
Abtastung auf der falschen Seite von Onkel Nyquist. Für mich ist das 
eine Unterabtastung.

Was übersehe ich da?

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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).

Meist bietet sich im Programmcode schon ein zeitbasierter Task an, auf 
den man synchronisieren kann, z.B. Multiplex bei Anzeigen.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jadeclaw (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der gute MaWin kennt wohl noch nicht die Taster, die in meinem 
Radiowecker verbaut sind. Knackfroschblechteil auf Platine. Diese Dinger 
knallen, krachen und kratzen, daß es eine helle Freude ist. Hält man den 
Finger nicht absolut ruhig, dann ist die Uhr mal eben 3 Stunden weiter. 
Sowas zu entprellen, ist mit einfachen Mitteln nicht mehr möglich, nur 
Routinen, die sich dem Gekrache anpassen, kommen damit noch klar.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Standardlösungen benutzen Schleifen und Vergleiche,

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

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.

Daher sind Lösungen, die nur alle Bruchteile von Sekunden mal nachgucken 
wie der Tastenzustand ist, die besseren Lösungen, als jeder Versuch des 
"Entprellens". Vergleiche das übrigens it den hunderteln unsäglicher 
Lösungsversuche (auch hier im Forum) zu Inkrementaldecodern. Auch dort 
funktioniert nur das sampeln in festen Zeitintervallen, und jedes 
Experiment, Flanken zu erkennen "jetzt hat er losgelassen", ist zum 
Scheitern verurteilt.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
lol, MaWin wie er  leibt und lebt...

Leute die bisherigen Beiträge von MaWin sollten euch doch schon gelehrt 
haben, dass ihr ihn besser ignorieren solltet. Dann langweilt er sich 
irgendwann und geht wieder zurück in seine Sandkiste...

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe es jetzt so gemacht:
TBCCR2 += 327; // Ad ~10ms Offset to TBR
      
if (!(P1IN & T1))
{
  key1cnt += 1;
        
  if (key1cnt >= 4)
  {
    key1stat |= 0x01;
  }
  if (key1cnt >= 100)
  {
    key1stat |= 0x02;
  }
  if (key1cnt >= 200)
  {
    key1stat |= 0x04;
  }
}

Der Timer läuft im Intervall von 10ms (Continous Mode bei 32khz quarz).
Wenn die Taste gedrückt ist, dann wird der Zähler für die Taste 
hochgezählt - wenn beim nächsten mal die Taste immernoch gedrückt ist, 
dann wird weiter hochgezählt, wenn nicht mehr, bzw. wenn er prellt, dann 
wird der Zähler turückgesetzt.

Wenn 4x ein gedrückter Taster detektiert wurde, dann wird Bit0 von 
keystatus gesetzt und kann in der main ausgewertet werden.

Bleibt die Taste gedrückt, so wird der Zähler weiter erhöht und 
entsprechend noch Bit1 und 2 gesetzt, was ich dann als gedrückt und 
lange gedrückt auswerten kann, um z.b schneller irgendwas hochzuzählen.

Ist das OK so, oder wie seht ihr das?

Autor: Horst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na toll, den Teil mit dem zurücksetzen hab ich natürlich nicht kopiert, 
aber was soll da groß stehen :)
else
{
  key1cnt = 0;
  key1stat = 0;
}

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Leser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Paul Baumann schrieb:
> In diesem Sinne:
> Immer schön elastisch bleiben
>
> MfG Paul

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

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Mir scheint du kennst die PeDa Lösung gar nicht.

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

Mit Verwendung von delay-Funktionen und seitemlangem Code, die meinst du 
wohl. Bringt undefinerbare Wartezeit und CPU Last und hilft eben NICHT 
wenn die Zeit die der Zustandswechsel eines Tasters über 25msec geht, 
weil sie sich nicht an der schnellsten zu erfassenden Benutzeraktion 
orientiert, sondern glaubt, Taster mit festen Zeiten begegnen zu können.

Für die Funktion ist es prellen, wenn ein Taster 24msec zu und 24msec 
offen ist (wiederholt) und kein prellen wenn er 26msec zu und 26msec 
geschlossen ist, mit wie man sieht einer wahlfrei erfundenen Zahl von 
25msec.

Das Makro beginnt mit der Annahme, die Taste wäre nicht gedrückt 
(flag=0) und wartet dann auf drücken. Dann merkst sich das Makro zwar 
mit flasg=1 daß die Taste gedrückt wurde, doch bei der nächsten 
Verwendung des Makros:
    if( debounce( PINB, PB1 ) )
      PORTB = 1
    :
    : (irgendwelcher sinnvoller code, der das nachfolgende erlaubt:)
    :
    if( !debounce( PINB, PB1 ) )
      PORTB = 0
verwendet die Funktion eine neue flag Variable die nicht weiß, daß die 
Taste schon gedrückt ist, sondern von der nun falschen Annahme ausgeht, 
sie wäre nicht gedrückt. So eine Funktion ist Murks. Es dürfte im ganzen 
Programm pro externer Taste nur 1 mal verwendet werden.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/Entprellun...


Der Rest ist nicht von mir!


Peter

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Paul Baumann (paul_baumann)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Micha H. (mlh) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: puffel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
> lol, MaWin wie er  leibt und lebt...

Er hat aber vollkommen Recht. Irgendwelche Routinen, die den Taster 
zigmal abfragen, sind auch in meinen Augen nicht sinnvoll und am Problem 
vorbeiprogrammiert. Seine Lösung, den Taster mit einem bestimmten 
Zeitraster regelmäßig abzufragen, ist dem Problem völlig angemessen und 
in der Regel fällt das bei Timer-Interrupts einfach mit ab.
Ich mache das zum Beispiel mit etwa 30 ms und hatte damit nie Probleme.

Autor: Micha H. (mlh) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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:

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

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.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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 ;)

__interrupt void PCINT1_ISR(void)
{
  unsigned int delay=2857;             // 7 cycles per count, 20 ms @ 1 
MHz
  unsigned char column;

  GIMSK &= ~(1 << PCIE1);             // disable pin change int for 
de-bounce
  do
  {}
  while(delay--);                     // de-bounce: allow inputs to 
settle
  GIMSK |= (1 << PCIE1);              // enable pin change ints

#ifdef DEBUGWIRE
  column = (~PINB) & 0x07;
#else
  column = (~PINB) & 0x0F;
#endif

  switch (column)
  {
    case  0x00: KPD_KeyDown = 0;
                break;
    case  0x01: KPD_LastKey = KPD_Array[KPD_ScanRow][0];
                if (!KPD_KeyDown)
                  KPD_KeyPressed = 1;               // must release key 
before press recorded
                KPD_KeyDown = 1;
                break;
    case  0x02: KPD_LastKey = KPD_Array[KPD_ScanRow][1];
                if (!KPD_KeyDown)
                  KPD_KeyPressed = 1;               // must release key 
before press recorded
                KPD_KeyDown = 1;
                break;
    case  0x04: KPD_LastKey = KPD_Array[KPD_ScanRow][2];
                if (!KPD_KeyDown)
                  KPD_KeyPressed = 1;               // must release key 
before press recorded
                KPD_KeyDown = 1;
                break;
    case  0x08: KPD_LastKey = KPD_Array[KPD_ScanRow][3];
                if (!KPD_KeyDown)
                  KPD_KeyPressed = 1;               // must release key 
before press recorded
                KPD_KeyDown = 1;
                break;
    default:    KPD_LastKey = 0;
                KPD_KeyPressed = 0;
  }
}

Autor: ... ... ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...
Wie heißt die (von Atmel) denn? Ich kann sie nicht finden...

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;)
>
> __interrupt void PCINT1_ISR(void)
> {
>   unsigned int delay=2857;             // 7 cycles per count, 20 ms @ 1
>   do
>   {}
>   while(delay--);                     // de-bounce: allow inputs to settle
>
>   (...)
>
> }
> 

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

Gruß,
Bernd

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :-)

Autor: Knut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hier gehts ja ab...
Hat schonmal einer über Hardware-Entprellen gedacht? Mit nem Tiefpass?
Funktioniert auch, WENN man etwa weiss mit welcher Frequenz das Ding 
prellt.


Gruß

Knut

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut schrieb:
> Hat schonmal einer über Hardware-Entprellen gedacht? Mit nem Tiefpass?
> Funktioniert auch, WENN man etwa weiss mit welcher Frequenz das Ding
> prellt.

Tiefpaß alleine reicht nicht, du brauchst schon noch einen Schmitt 
Trigger danach zur Signalaufbereitung.

Gruß Anja

Autor: Anja (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> 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.

Ich hoffe du schreibst niemals im Leben sicherheitskritische Software. 
Es gibt im realen Leben nicht nur Tastenprellen sondern auch noch so 
schöne Dinge wie ESD-Impulse, Wackelkontakte in Leitungen usw.

Gruß Anja

Autor: ... ... ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut schrieb:
> Hat schonmal einer über Hardware-Entprellen gedacht? Mit nem Tiefpass?
> Funktioniert auch, WENN man etwa weiss mit welcher Frequenz das Ding
> prellt.
Hardware entwickelst du einmal und musst sie jedes mal kaufen.
Software entwickelst du einmal und kannst sie quasi kostenlos einbauen.
Das klingt jetzt nach nicht viel, aber in der heutigen Zeit zählen 2 
Cent sehr viel und die µCs sind heute groß genug für das bisschen 
Software.

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Tiefpaß alleine reicht nicht, du brauchst schon noch einen Schmitt
> Trigger danach zur Signalaufbereitung.

Wenn man bedenkt, dass heutzutage in fast allen uC Schmitt-Trigger 
enthalten sind, braucht man diese sogar nicht unbedinkt hinzuzukaufen.

Ein einfaches RC-Glied reicht für eine effektive Entprellung aus.
Ob man diese 2 Cent tazächlich investieren möchte, um gleichzeitig 
seinen Port zu Schützen (Widerstand), oder dass Ganze doch per Software 
lösen möchte, dass bleibt den Entwickler selbst überlassen.

Autor: Lukas K. (carrotindustries)
Datum:

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

Autor: Marc (Gast)
Datum:

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

Das stimmt ja auch...
Nur habe ich bislang keine Platine gesehen, welche größer als eine 
Checkkarte war und gleichzeitig keinen Platz mehr für einen 
entsprechenden SMD-RC-Tiefpass-Filter hat.
Bei bereits gerouteten Platinen sollte man vieleicht auf einen 
nachträglichen Einbau verzichten, aber bei neuen währe eine Überlegung 
durchaus währt.

Ich sage ja nur:
Beides hat seine Vor- und EBEN AUCH seine Nachteile.

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So jetzt geb ich auch noch meinen Senf dazu. Wenn man schon 
Hardwareentprellung macht dann aber bitte richtig. Man nimmt als Taster 
einen Umschalter und setzt den an ein RS Flipflop. Und nicht so ein Mist 
wie Tiefpass oder RC Glied. Die funktioniern in 90% und in 10% nicht!
Aber ansonsten ist der Thread ne toller Abendzeitvertreib. Bier hab ich 
hier wenns noch weitergeht muß ich mir noch nen Whisky und Schokolade 
holen :-))

Autor: HildeK (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Wenn nicht Störungen auf den Tastenleitungen durch SW unterbunden werden 
sollen (und das ist m.E. HW-Designsache), dann sollte doch der erste 
erkannten Wechsel bereits als Ereignis interpretiert werden. So wie bei 
einem RS-FF. Erst danach wäre eine Schutzzeit sinnvoll, die sich jetzt 
nach der minimal möglichen Wiederholrate (beim Menschen sollte dies 
unter 10Hz liegen können) für weitere Tastendrücke orientiert. Ansonsten 
wird bereits ein 'Warten' auf mehrere weitere gleiche Zustände zu einer 
Verzögerung führen, die nicht (immer) sein muss und einen sehr kurzen 
Impuls völlig unterdrückt - in manchen Anwendungen auch ungewollt.
Mit der Methode kann durchaus ein FF-Clk über einen Taster ohne Probleme 
bedient werden.

Aber meine Betrachtung zeigt vielleicht auch, dass es wohl keine 
allumfassende Entprellroutine geben wird - man muss auch die gewünschte 
Anwendung im Auge haben.

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also mal eine Routine zum anschauen

byte oldkey=0,newkey,changed,pressed; // bit = 0 wenn Taste losgelassen, 
1 wenn gedrückt

alle 10msec durch Interrupt oder Hauptschleife:
 newkey=input(keyport); // an welchem Port die Tasten auch immer hängen
 changed=oldkey^newkey;
 pressed=changed&newkey;
 // released=changed&~newkey; // falls loslassen interessiert
 if(pressed&1) // Taste 1 runtergedrückt, passende Aktion ausführen
 if(pressed&2) // Taste 2 runtergedrückt  oder zumindest Aktion flaggen
 oldkey=newkey;

Kurz klar und deutlich bei praktisch keiner Rechenzeit.


Wenn, wie Anja korrekt bemerkt, zu kurze ESD Impulse etc. unterdrückt 
werden sollen:

byte oldkey=0,newkey=0,next2key=0,next1key,changed,pressed;

alle 10msec durch Interrupt oder Hauptschleife:
 next1key=input(keyport);
 newkey^=~(next1key^next2key)&(next1key^newkey); // Filtern
 changed=newkey^oldkey;
 pressed=changed&newkey;
 if(pressed&1) // Taste 1 runtergedrückt
 if(pressed&2) // Taste 2 runtergedrückt
 oldkey=newkey;
 next2key=next1key;

nicht wirklich komplizierter.

Autor: Bernd O. (bitshifter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Michael Roek (mexman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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

Autor: Knut (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anja schrieb:
> Tiefpaß alleine reicht nicht, du brauchst schon noch einen Schmitt
> Trigger danach zur Signalaufbereitung.

Nö, klappt auch ohne.

Marc schrieb:
> Ein einfaches RC-Glied reicht für eine effektive Entprellung aus.
> Ob man diese 2 Cent tazächlich investieren möchte, um gleichzeitig
> seinen Port zu Schützen (Widerstand), oder dass Ganze doch per Software
> lösen möchte, dass bleibt den Entwickler selbst überlassen.

So is es.

U.R. Schmitt schrieb:
> Und nicht so ein Mist
> wie Tiefpass oder RC Glied. Die funktioniern in 90% und in 10% nicht!

Wieso sollte das nicht funktionieren?


Gruß Knut

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Knut schrieb:
> Wieso sollte das nicht funktionieren?

Schade, jetzt gehts weiter, aber jetzt muss ich arbeiten und habe kein 
Bier und Popcorn mehr da stehen :-)
Na ja für den Bastelbereich geht das: Du machst ein RC Glied, probierst 
noch ein bischen mit Werten rum und es geht.
Aber wenn das Teil 1000 mal gebaut werden soll, und das über 2 Jahre 
hinweg und auch noch preiswerte Bauteile und keine Super Duper 
Schalter/Taster mit langzeitstabilen und genau spezifizierten 
Prellzeiten, dann funktioniert Dein RC Gleid vieleicht bei der ersten 
Charge, vieleicht funktioniert das Gerät auch noch nach 2 Jahren 
Gebrauch, aber technisch gesehen ist ein einfaches RC Glied so ziemlich 
das ungenaueste und schlechteste Entprellen, zumal ohne Schmitttrigger 
da Du nicht immer davon ausgehen kannst daß digitale Eingänge immer 
Schmitt-Trigger Funktionalität haben.
Softwareseitig gibt es keinen Königsweg, ich denke aber daß die Funktion 
von PeDa (ohne Sie zu kennen) recht gut funktioniert, sonst hätte Sie 
nicht so viele Fürsprecher zumal vom Personen deren Kompetenz sich in 
Ihren Beiträgen hier eindeutig manifestiert.
Alle 100 mS abzutasten ist auf jeden Fall zu langsam, das führt dann zu 
den erwähnten Geräten wo ein kurzer Knopfdruck nur jeder 2. Mal erkannt 
wird.
Schönen Tag noch

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> ... technisch gesehen ist ein einfaches RC Glied so ziemlich
> das ungenaueste
UND GENAU DAS macht ein RC-Glied so pledisziniert in diesen Bereich.
Ein RC-Glied macht keinen Unterschied zwischen verschiedenen Prellungen,
es glättet sie ALLE.
Eine Softwarelösung kann dies bei weitem nicht so gut, vorallem da jeder 
Prell anders aussieht.

> ... schlechteste Entprellen ...
NEIN...

> ... zumal ohne Schmitttrigger ...
Das ist ein Punkt, aber selbst wenn man keinen Schmitt-Trigger
hat, sollte man durch Erhöhung der Konstante Tow ein komplettes Prellen 
vor einer Flankenerkennung am uC einstellen.
Ein Schmitt-Trigger ist also tazächlich nicht immer erforderlich (auch 
wenns besser währe)

Sicherheit bei einer Flankenerkennung erfolgt durch Zeit...
Umso kürzer die Zeit ist, in der du einzelne Flanken erkennen möchtest, 
desto warscheinlicher ist eine Fehlerkennung.
Ob man diese Zeit mit dem Prellen einbezieht, oder in der Form eines 
Timers der nach einer Flanke startet, dass ist egal.

Du begründest deine Aussage damit, dass Taster nicht unbedinkt 
langzeitstabil und genaueste spedifikationen haben...
Wenn du Wirklich eine sooo effektive Entrellung haben möchtest, dann 
Wähle die dritte Variante, welche sowohl Hardware- als auch 
Software-Entprellung beinhaltet. Dann bist du gut bedient.

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... kleine Korrektur

"Slow rising or noisy inputs may cause oscillation to occur while the 
slow rising input signal crosses through the input treshold"
Zitat aus Xilinx-Datenblatt:
http://www.xilinx.com/support/documentation/applic...

Mit anderen Worten:
Ein Schmitt-Trigger ist bei RC-Glättung auf jeden Fall erforderlich.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn sich ... doch wenigstens
Ja gut...

Dafür kriegen wir hier so weitere Quellen rein !

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: screwdriver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich bin kein Studierter. Ich mache hin und wieder kleine Projekte mit 
Bascom. Ich finde auch, die timergetriggerte Tasterabfrage ist der 
richtige Weg zur Entprellung. Peters Minimallösung habe ich im Groben 
verstanden, konnte sie aber noch nicht in Bascom umsetzen. Vielleicht in 
einer Mußestunde mal...

Aber was ich eigentlich nicht verstehe bzw. mich doch sehr wundern läßt: 
Tastenentprellung sollte doch nun wirklich zu den elementarsten Dingen 
gehören, die ein Softwareentwickler lernen und beherrschen muß. Da 
werden die tollsten Gerätschaften heutzutage realisiert und über banale 
Sachen wie Tastenentprellung streiten sich die (sogenannten) Experten. 
Ich verstehe das nicht.

screwdriver

Autor: Di Pi (drpepper) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Di Pi (drpepper) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Nur muss man es richtig machen.

Das steht natürlich außer Frage ;)

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Kondensator ist in der Zeit von 5 Tow fast vollständig geladen.
Setzt man fürs Laden des Kondensators 20 ms als Tow vorraus, kommt man 
für Komplette Laden + Entladen auf 100 ms.

Ich weiß ja nicht, wie oft du es schaft in der Sekunde auf deine 
Maustaste zu drücken aber gänzlich ungeeignet ist diese Methode 
sicherlich nicht ^_^


Viele Wege führen zum Ziel !
Welchen man bestreitet ist die andere Frage ;-)

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc schrieb:
> Tow

WTF?!?

Autor: Di Pi (drpepper) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Klaus schrieb:
> Marc schrieb:
>> Tow
>
> WTF?!?

Er meint die Zeitkonstante Tau

Autor: screwdriver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Btw: Sollten oder müssen nicht im Zeitalter von EMV sowieso alle 
Eingänge über irgendwelche Tiefpässe verfügen?

Manchmal habe ich den Eindruck, in diesem Forum sind nur Theoretiker 
vorhanden. Entweder amüsieren sich die Praktiker stillschweigend oder 
können unsere Sprache nicht, da chinesisch. ;-)

screwdriver

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie schnell ist ein Mensch in der Lage, kurz nach dem drücken eines 
Tasters, seine Muskeln zu entspannen um diesen Wieder loszulassen...

Das Drücken eines Tasters...
Es steckt viel mehr dahinter, als man denkt xD

... ich lass es sein ...

Autor: puffel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Anja schrieb:
> Ich hoffe du schreibst niemals im Leben sicherheitskritische Software.
> 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?

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Marc, dann messe doch mal mit einem Speicheroszi wie lange ein Taster 
(Microschalter) geschlossen ist, den Du nur mal kurz antippst. Ich wette 
mit Dir Du kannst ohne daß Du dich spezifisch anstrengst auf unter 100mS 
kommen. Und das ist dann schon der Bereich in den Du mit einer RC 
Entprellung gehen musst. Das gibt dann genau die Geräte die nur jeden 2. 
kurzen Tastenantipper nicht erkennen.
Es besteht physiologisch ein wesentlicher Unterschied ob Du einen Taster 
nur kurz antippst oder ob Du den Taster mehrfach antippen willst. Und 
dann schau Dir mal Gameboyspielende Kids an. Je nach Spiel kommen die 
locher auf eine Tippfrequenz von 8 - 10 Hz wenn nicht mehr.
Auch klar ist daß bei den meisten Geräten mit trägen Tasten nicht die 
eine RC Entprellung sondern eine träge Software (schlecht programmiert, 
unterdimensionierter Prozessor, miese SW-Entprellung) ursächlich ist.
Und bzgl meiner Formulierung ungenau meinte ich eben die Tatsache daß 
der C vor Beginn entladen/ geladen ist und die Notwendigkeit auf ca. 3 - 
5 tau der eigentlichen Prellzeit zu gehen, während die Mehrfachabtastung 
spätestens kurz nach der Prellzeit einen eindeutigen Befund hat und sich 
an die Prellzeit anpasst.
Ich bleib dabei wenns schnell und sicher hardwaremäßig entprellt werden 
soll Umschatkontakte und RS-Flipflop ansonsten SW-Entprellung. Die 2 
Bauteile kann ich mir dann sparen und bin schneller.

Autor: Marcus Harnisch (mharnisch) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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_%28vide...

Autor: puffel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> No, Ich würde mich schön bedanken, wenn sich meine Geräte selbst
> verstellen, nur weil sie sich einen Puls eingefangen haben.

Das machen sie auch mit der 4fach-Abtast-Entprellroutine, wenn der Puls 
lang genug ist. Ebenso wie die 1fach-Abtastung mit ähnlich langen 
Zeitfenstern. Es ist schon so, dass eine mehrfache Abtastung die 
Sicherheit, eine korrekte Flanke zu erkennen, noch ein wenig erhöht. 
Allerdings würde ich so was nicht als Teil eines Sicherheitskonzeptes 
sehen. Wenn ein einzelner (fehlerhafter) Tastendruck schon katastrophale 
Folgen haben kann, sollte man sein HMI grundsätzlich überdenken.
Und für das Thema Komfort reicht eine 1fach-Entprellung aus.
Und man sollte auch nie vergessen, dass gerade wenig oder nicht 
verstandene oder unnötig komplizierte Software-Elemente latente 
Fehlerquellen sind, die Software auch nicht unbedingt immer sicherer 
machen.

> 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.

Ist da nicht das Problem eher bei der Schwelle des Empfängers und der 
Qualität des Protokolls (Fehlererkennung usw.)?

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mein Gott... da hab ich ja ne Diskusion angezettelt....

Das mit dem Morsen war nicht schlecht...
Laut Weltrecord liegt das Dit da bis an die 16ms und drunter (selbst für 
den MAX6818 zu schnell)

Meine Meinung bleibt aber auch nach-wie-vor:
Es kommt auf die Gegebenheiten an, welche Methode man verwenden kann.
Ob Richtig oder Falsch kann man generel nicht beantworten.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

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

Allerdings nicht mit einer Handtaste.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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... ;-)

...

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das "Debounce-Makro" ist durch ihr Delay und die nicht mehrfache 
Verwendbarkeit schon grottig, die "Komfortroutine" ist einfach viel zu 
aufwändig. Ein Teil davon geht in Key-Repeat, ist also ok wenn man's 
braucht, aber der Rest ist unnötig. 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...
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. Falls du also 
fragst, was Maxim anders macht...

Autor: Bernd (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

Ihr macht ein Theater
Ich komme aus dem SPS Bereich und nutze wenn nötig ein Flip-Flop. Dies 
wird mit dem Taster Impuls gesetzt und erst rückgesetzt wenn meine 
Maschine einen neuen Impuls erwartet. Dabei stört mich kein Prellen, da 
die Zwischenzeit bis zum neuen Betätigen locker ausreicht den Schalter 
zu beruhigen.

Gruss Bernd

Autor: Εrnst B✶ (ernst)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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...

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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:
Tastenabfrage:  ;Entprell-Algorithmus geklaut bei Peter Dannegger...
 in tmp,tap         ;Tastenport einlesen (gedrückt=L)
 com tmp            ;invertieren (gedrückt=H)
 andi tmp,alltast   ;ungenutzte Bits ausblenden
 eor tmp,tas        ;nur Änderungen werden H
 and tz0,tmp        ;Prellzähler unveränderter Tasten löschen (Bit0)
 and tz1,tmp        ;Prellzähler unveränderter Tasten löschen (Bit1)
 com tz0            ;L-Bit zählen 0,2,->1, 1,3,->0
 eor tz1,tz0        ;H-Bit zählen 0,2,->tz1 toggeln
 and tmp,tz0        ;Änderungen nur dann erhalten, wenn im Prellzähler
 and tmp,tz1        ;beide Bits gesetzt sind (Zählerstand 3)
 eor tas,tmp        ;erhaltene Änderungen toggeln alten (gültigen) Tastenstatus
 and tmp,tas        ;nur (neu) gedrückte Tastenbits bleiben erhalten
 or tfl,tmp         ;und zugehörige Bits setzen (gelöscht wird nach Abarbeitung)
 ;in "tas" steht jetzt der gültige Tastenzustand,
 ;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:
 ;in "tas" steht jetzt der gültige Tastenzustand,
 ;in "tfl" die Flags der neu gedrückten, noch nicht abgearbeiteten Tasten...
Tastendauer:
 mov tmp,tas        ;Tastenzustand kopieren
 andi tmp,wietast   ;nur Tasten mit Wiederholfunktion stehen lassen
 tst tmp            ;ist eine Taste betätigt?
 breq Tastendauer0  ;nein, Dauer auf Startwert...
 dec twz            ;ja, Zähler runter
 brne Tastenabfrage_e   ;Dauer abgelaufen? - nein...
 or tfl,tmp         ;ja, noch aktive Tasten übernehmen (alternativ)
; or twf,tmp         ;ja, noch aktive Tasten übernehmen (alternativ)
 ldi twz,twz1       ;und Zähler auf Wiederholwert setzen
Tastenabfrage_e:
 ret                ;fertig...
 ;in "tfl" stehen jetzt wieder die Flags der länger betätigten Tasten
 ;sie werden nach Abarbeitung gelöscht
Tastendauer0:       ;Reset Dauerzähler
 ldi twz,twz0           ;Tastendauerzähler auf Startwert
 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.

...

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Bernd schrieb:
> Ihr macht ein Theater
Dafür ist es ja auch ein Forum !

> Ich komme aus dem SPS Bereich und nutze wenn nötig ein Flip-Flop. Dies
> wird mit dem Taster Impuls gesetzt und erst rückgesetzt wenn meine
> Maschine einen neuen Impuls erwartet. Dabei stört mich kein Prellen, da
> die Zwischenzeit bis zum neuen Betätigen locker ausreicht den Schalter
> zu beruhigen.

... das hab ich mich auch schon was gefragt:
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 ...

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.)

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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).

...

Autor: U.R. Schmitt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Softwareseitig ist aber bequemer.

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
U.R. Schmitt schrieb:
> 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.

Ja gut... schlag mich...
hast ja Recht, nur dass ich hier nen "kleinen" Nachteil sehe, wenn man 
seinen Finger auf den Taster belässt...

Möchte keine Diskusion mehr anfangen ;-)

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jadeclaw Dinosaur (jadeclaw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Ich komme aus dem SPS Bereich und nutze wenn nötig ein Flip-Flop. Dies
>wird mit dem Taster Impuls gesetzt und erst rückgesetzt wenn meine
>Maschine einen neuen Impuls erwartet.
Und wenn die Maschine DANN einen neuen Impuls erwartet, wenn der Taster 
losgelassen wird ???

>Hab ich doch schon zwei mal gesagt. Ein Taster mit Umschaltkontakt und
>dann ein RS Flipflop.
Viel zu aufwendig.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
 next1key=input(keyport);
 newkey^=~(next1key^next2key)&(next1key^newkey); // Filtern
 changed=newkey^oldkey;
 pressed=changed&newkey;
 if(pressed&1) // Taste 1 runtergedrückt
 if(pressed&2) // Taste 2 runtergedrückt
 oldkey=newkey;
 next2key=next1key;

in Gedanken 1:1 in Assembler übersetze (ca. 13 Befehle ohne die beiden
Ifs zur Einzeltastenabfrage) und ihn mit dem von Peter
      mov    iwr0, key_old
      in     key_old, key_port
      eor    iwr0, key_old
      com    key_old
      mov    iwr1, key_state
      or     key_state, iwr0
      and    iwr0, key_old
      eor    key_state, iwr0
      and    iwr1, iwr0
      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.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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!

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: spess53 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi

Dumme Frage: Warum muss man einen Taster entprellen? Nicht gedrückt hat 
er ein definiertes Potential. Beim Drücken ändert sich das. Also reicht 
das Erkennen dieser Änderung aus. Ob das davor oder danach noch prellt 
ist uninteressant.

MfG Spess

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Das, was du hier vorschlägst, ist Mehrfachabtastung,

Sag mal. Hast du eine Leseschwäche?

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.

Du selbst bist nicht so mäkelig wie Anja sondern "kann das erste 
Geschlossensignal sofort und eindeutig als Tastendruck gewertet werden" 
filterst nicht.

Daher ist der übliche Code zum entprellten Einlesen mein erstes 
Programmbeispiel, und hier noch mal für dich in Assembler

  IN  a,KEY_PORT
  MOV key_new,a
  EOR a,key_old   ; changed
  AND a,key_new   ; pressed
  :
  :  a enthält gesetztes bit für jede gerade runtergedrückte Taste
  :
  MOV key_old,key_new

Kurz und verständlich, das ist die Standardlösung, keine 10 Befehle 
lang.



Die Komfortlösung von Peter ist besser als die Macro-Lösung, aber halt 
unnötig lang.

Es gibt also nichts zum schmunzeln, sondern nur die traurige 
Feststellung, daß manche beim Lesen nicht wahrnehmen, was dort steht.


Ja, auch ich war faul, und hab auf der Seite
http://www.mikrocontroller.net/articles/Entprellung
nur bis zum Ersten Auftreten von Author: Peter Dannegger
runtergescrollt und nicht nach weiteren Lösungen von ihm gesucht.
Aber immerhin habe ich nachgeschalgen, was gefunden und gelesen.
Viele andere hier haben bloss eine arrogant vorgefasste Meinung
und bis heute nciht verstanden, wie man ausreichend entprellt.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Also reicht das Erkennen dieser Änderung aus.
Ja, aber in BEIDE Richtungen.
...und dadurch wird es automatisch entprellt.

Autor: MCUA (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>... sondern "kann das erste Geschlossensignal sofort und eindeutig als 
Tastendruck gewertet werden" filterst nicht.
Durch das pure Einlesen (ohne "Filter") wird es trotzdem automatisch 
gefiltert, nämlich von der Integrat.dauer des uC-In-ports. (nur diese 
Zeit (einige ns) ist viel zu kurz)

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Marc (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sagt mal,
Wieso unterhalten wir uns eigendlich mit hunderten Posts über 
Entprellung, wenn darüber bereits ein übersichtlicher Article 
geschrieben ist ?

Nochmal der Link:
http://www.mikrocontroller.net/articles/Entprellung

... hab mich schon gewundert, warum hier einige so Schmunzeln :-)

Autor: screwdriver (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> 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.

In der Tat sieht es zumindest bei den 8bit-AVR so aus, als ob alle 
Eingänge mit Schmitt-Trigger versehen sind, er ist sogar im 
Funktions-Schaltbild eingezeichnet. Die Hysterese ist dann in den 
DC-Characteristics angegeben und beträgt 40% Vcc. Die angehängten Bilder 
sind dem Datenblatt eines mega16 entnommen.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Marc schrieb:
> Sagt mal,
> Wieso unterhalten wir uns eigendlich mit hunderten Posts über
> Entprellung,

Naja, hauptsächlich eigentlich, weil ein gewisser MaWin meint hier 
rumtrollen zu müssen...

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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? Oder habe ich in 
der 5-Zeilen-Lösung, die für all meine Programme bisher ihren Zweck 
erfüllte, etwas übersehen?


#define RELEASE_DELAY 5

volatile uint8_t TasteGedrueckt = 0;

ISR(irgendein_10_ms_timer_interrupt)
{
  if (!(PINA & _BV(PA0)))
    TasteGedrueckt = RELEASE_DELAY;
  else
    if (TasteGedrueckt > 0)
      TasteGedrueckt--;
}

int main(void)
{
  if (TasteGedrueckt) {
    machWas();
  } else {
    machWasAnderes();
  }
}


Tobi

Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na Klaus, inhaltlich überfordert hast du nix beizutragen, also kommt nur 
persönliches Gegeifere von dir ? Das sind die größten Helden.

Autor: Klaus (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
MaWin schrieb:
> inhaltlich [...] hast du nix beizutragen

In diesem Thread ist bereits alles (und das mehr als einmal) gesagt 
worden.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pothead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Peter Dannegger schrieb:
> Und wenn die nen Chip (MAX6818) herstellen

Schönes Teil - kann ich nur empfehlen! Optimal wäre noch ein 
eingegossenes Shiftregister für die 8er-Variante (welches sich 
kaskadieren ließe).

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Tobi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> 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.

Das ist schon klar. Ich wollte auch nur das grundlegende Prinzip 
darstellen. Wenn mehrere Taster und wenig RAM in's Spiel kommen, geht's 
effizienter.

> 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?

Ist ebenfalls klar. Im Beispiel ging's auch nur um's reine Entprellen. 
Was mit dem entprellten Tastenstatus geschieht, ist ein anderes Kapitel.

Worüber sich aber hier seitenweise gezofft wird ist ja schon das 
Entprellen als solches.

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pothead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Simon K. schrieb:
> 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.

Natürlich über den gleichen Pin! Zum entladen kann man den eingebauten 
Pulldown vom Portpin nehmen - wenn man unbedingt Bauteile sparen will.

Simon K. schrieb:
> 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...

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). Hält der Benutzer die 
Taste gedrückt so kann man das mit diesem (wie auch mit anderen) 
Verfahren detektieren. Ob der Nutzer die Taste nun gedrückt halt oder 
nicht ist egal, kaputt gehen kann nichts. Die Idee:

                          __µC______
                         |
Taste >---- R1 ---+------o--+-->
                  |      |  |
                  |      |   /
                  |      |  |
                  C      |  R2
                  |      |  |
                 ---     | ---

mit R2 << R1.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Pothead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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). 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. Ein Timer läuft 
los um das Tau (R2*C) zu generieren. Keine große Sache. Wenn man sich 
den Timer sparen will kann man das auch im Heartbeat unterbringen, falls 
dieser eine geeignete Periodendauer hat. Weiterer Vorteil: Es passiert 
nur dann (und nur dann) etwas, wenn eine Taste gedrückt wird.

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pothead (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Karl heinz Buchegger schrieb:
> Äh nein.
> Entladen kannst du erst anfangen, wenn der Benutzer wieder losgelassen
> hat. Aber ok, ist jetzt ein Detail

Nein, wieso?

Karl heinz Buchegger schrieb:
> Wenn man auf die letzten paar Prozentpunkte Rechenkapazität
> angewiesen ist, ist das natürlich ein Argument.

...oder ums verrecken Strom sparen will.

Simon K. schrieb:
> 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.

Na und, was ist so schlecht daran? Du kannst die Frequenz auch 
wesentlich kleiner (also die Periodendauer länger) machen als die 
Zeitkonstante. So vermeidest du die von dir wohl befürchtete 
Mehrfacherkennung. Die kann aber sehr nützlich sein: Stell dir ein Menü 
vor in dem du einen Parameter ändern willst - einfach die Taste gedrückt 
halten.

Simon K. schrieb:
> 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.

Ich hatte ja bereits beschrieben wie ich das machen würde. Der Aufwand 
ist imho sehr gering.

Autor: screwdriver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Yalu X. schrieb:
> 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.

Danke für den Hinweis, Yalu. Ich werd mich da noch reinlesen. Laut 
Suchfunktikon gibts da ja schon einiges hier im Forum.

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Paul Baumann (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Peter schrob:
>Das Bascom-Debounce wartet immer die vollen 25ms.

Jain. ;-)
Wenn man nichts angibt, werden 25ms benutzt.
Man kann aber mit "Config Debounce= xx" auch andere Zeiten einstellen.

MfG Paul

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.