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!
Horst schrieb:> Mal ne Frage, wenn ich nen Taster entprellen will, wie lang sollte ich> in der egel warten, bis ich den nächsten Zustand abfrage?
Garnicht.
Stures Warten ist kein Entprellen!
Und kostet außerdem wertvolle CPU-Zeit.
Sicheres Entprellen macht man mit Mehrfachabtastung.
Und besonders wichtig, auch beim Loslassen!
In der Regel reicht eine 4-fach Abtastung aus.
Das Abtastintervall ist unkritisch, 5..50ms sind o.k.
Am besten läßt sich das mit einem Timerinterrupt machen.
Peter
Ausrufer schrieb:> Zitiere daraus:> The short answer: sometimes a lot, sometimes not at all.
Toss out those two samples and the other 16 switches exhibited an
average 1557 µsec of bouncing, with, as I said, a max of 6200 µsec. Not
bad at all.
Horst schrieb:> Horst schrieb:>> bis ich den nächsten Zustand abfrage?
Der springende Punkt ist wohl, dass diese Zeit nicht so kritisch ist.
Erst durch das Zusammenspiel mit der Forderung, dass du bei x
Abtastungen mit einem zeitlichen Versatz von y ms jedesmal den gleichen
Wert bekommen musst, entsteht die rock-solid Entprellung. Wenn die dann
auch noch versagt, dann ist der Taster schon lange jenseits von Gut und
Böse und muss getauscht werden.
Forderst du zb dass du 4 mal hintereinander denselben Wert vom Port
bekommen musst, so beginnen mit jedem Preller die Zeit wieder neu zu
laufen und es wieder erneut auf 4 hintereinanderliegende gleiche
Zustände gewartet.
In diesem Sinne passt sich diese Funktionalität, die in der 'PeDa'
Entprellung implementiert ist, automatisch auch in gewissen Grenzen an
die Qualität des Tasters an.
Macht doch nicht so große Wellen
wegen ein wenig Taster-Prellen.
Nehmt doch einfach Gummimatten,
die noch nie ein Prellen hatten!
...oder die Kapazität der Hand,
(hier irgendwo ein Quelltext stand)
Drück ich mit den dicken Pfoten
auf den Taster (auf den roten)
dann wird im Timer-Interupt
dessen Zustand aufgeschnappt
Nach 10 kleinen Millisekunden
wird er dann für gut befunden
4 mal wird das dann durchlaufen,
dann kann man diesen Pegel kaufen.
Damit bin ich immer gut gefahren,
auch bei bösem Prell-Gebaren
In diesem Sinne:
Immer schön elastisch bleiben
MfG Paul
> 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.
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?
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.
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
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.
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
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?
> 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.
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
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.
> 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.
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.
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...
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?
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.
> 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.
MaWin schrieb:> Mit Verwendung von delay-Funktionen und seitemlangem Code, die meinst du> wohl.
Scroll weiter nach unten.
Dort wo "Komfortroutinen" steht.
Das diese _delay Entprellung Müll ist, brauchst du hier niemandem
erzählen.
Stefan schrob:
>Super! Vielen Dank für die Aufheiterung!
Leser schrob:
>Sehr schön Paul. Immer wieder gerne genommen deine Reime :-)
Ich freue mich, daß ihr Euch freut.
;-)
MfG Paul
MaWin schrieb:>> Wie machst Du es?>> So wie alle vernünftigen Lösungen in praktisch allen kommerziellen> Geräte mit uC es machen:>>> Den Tastenzustand nur in so langsamen Zeitabständen erfassen (samplen> per IN am Port), die über der maximalen Prellzeit liegen. Wenn also das> Datenblatt des Herstellers sagt: Prellen 10msec, dann reicht eine> Abtastung im 20msec Abstand, um garantiert keinen "doppelten> Tastendruck" auf Grund des Prellens der Kontakte zu erfassen.>> Es ist Humbug, eine Taste 4 mal oder sonstwie erfassen zu wollen, kostet> nur unnötig Programmcode und Rechenzeit. Aber so ein Murks-Code mit> "Filtern" kommt zu Stande, wenn der Programmierer Prinzip, Ursache und> Auswirkung des Prellens nicht verstanden hat.>> In der Praxis muss man nicht mal ins Datenblatt des Tastenherstellers> gucken, denn man kann die Zeit so lang machen, wie der Benutzer noch> keine Verzögerung bemerkt, so 100msec sind einerseits akzeptabel,> erlauben andererseits noch schnelles Durchklackern wenn der Nutzer> schneller als 1 mal pro Sekunde auf den Knopf drückt, bis 5 Tastendrücke> pro Sekunde wären möglich (bei 100msec Abtastzeit).
Eben nicht. 100ms sind unergonomisch. Das sind dann Geräte, bei denen
man extra lange auf die Taste drücken muß, bis der Tastendrück überhaupt
erkannt wird. Mal eben schnell 5 mal gedrückt und es sind nur drei
Tastendrücke erkannt worden. Furchtbare Ergonomie - wie man sie
beispielsweise von 2,99 € LCD-Geräten aus dem Supermarkt kennt.
Schau' Dir mal die PeDa-Lösung an. Ist wirklich genial!
Gruß,
Bernd
P.S.:
Ich hab dann noch die Macroversion geschrieben, weil Anfänger oftmals
Angst vor Interrupts haben.
Steht aber auch da, daß sie nicht so gut ist.
Sie wartet bei jedem Wechsel 25ms, damit kann man in vielen einfachen
Programmen leben.
Die 25ms müssen prellfrei sein, d.h. aber nicht, daß Preller >25ms
durchkommen. Es wird darin 255 mal abgetastet, also muß eine einzelne
Prellschwingung <25ms sein, die gesamte Prelldauer kann ruhig erheblich
>25ms sein.
Es ist eben ein Kompromiß zwischen Funktion und einfacher Anwendung.
Und das Macro darf auch nur genau einmal pro Taste expandiert werden.
Für komplexere Programme ist sie nicht geeignet, da gebe ich Dir Recht.
Aber dann weiß man auch, wie man die bessere Version mit Timerinterrupt
verwenden muß.
Peter
Peter Dannegger schrieb:> Ich hab dann noch die Macroversion geschrieben, weil Anfänger oftmals> Angst vor Interrupts haben.
Ich würde mich nicht als Anfänger bezeichnen, höchstens etwas
eingerostet, da C-Programmieren bei mir etwa 10 Jahre zurückliegt.
Der Grund warum ich Deine fraglos gute Entprellung nicht benutze ist
nicht Angst vor Interrupts ;-) sondern ganz einfach weil ich sie nicht
nachvollziehen kann, ich verstehe den Code nicht, es fehlt mir wohl an
Abstraktionsvermögen.
Das geht natürlich garnicht, wenn debuggt werden muß (für mich)
unverständlichen Code zu haben.
Kurz vor dem schreiben einer eigenen Routine habe ich deshalb in meinen
Projekten den Ganssle-Debouncer eingesetzt, den kann ich nachvollziehen
und verstehen. Funktioniert auch toll.
Allgemein gesprochen: es ist sehr schön wenn man fertigen Code für sein
Projekt nutzen kann, aber er muß verstehbar und für einen selbst
nachvollziehbar sein. Dein Code ist dafür zu elitär.
Disclaimer: Wie immer ohne Schießgewehr, ich habe nur für mich selbst
gesprochen.
Micha H. schrieb:> Der Grund warum ich Deine fraglos gute Entprellung nicht benutze ist> nicht Angst vor Interrupts ;-) sondern ganz einfach weil ich sie nicht> nachvollziehen kann, ich verstehe den Code nicht, es fehlt mir wohl an> Abstraktionsvermögen.
Sieh diese Funktionalität als Baustein an.
So wie du einen printf() oder einen sprintf() oder einen sin() oder was
auch immer du willst, benutzt.
> Das geht natürlich garnicht, wenn debuggt werden muß (für mich)> unverständlichen Code zu haben.
Das schöne ist:
Den musst du nicht debuggen. Das Teil funktioniert einfach.
Solange die ISR regelmässig aufgerufen wird, ungefähr im Zeitraster von
10 Millisekunden (ist absolut unkritisch), und die #define stimmen,
funktioniert der Code.
Ich gebe zu, dass der Code ziemlich trickreich ist und nicht leicht zu
verstehen. Aber wie gesagt: Ich verstehe auch nicht, welche Klimmzüge
gemacht werden um einen ln schnell zu berechnen. Das hindert mich aber
nicht die Funktion log() ganz einfach zu benutzen, wenn ich sie brauche.
Bei dieser Entprellung rück sogar ich von der Prämisse ab, dass man Code
den man verwenden möchte wenigstens in Grundzügen verstehen sollte. Und
ja, ich habe den Code schon analysiert und verstehe auch wie und warum
er funktioniert.
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.
Karl heinz Buchegger schrieb:> Den musst du nicht debuggen. Das Teil funktioniert einfach.
Glaube ich unbesehen, aber...
Ich hatte in meinem Projekt genau den Fall, daß etwas nicht korrekt
funktionierte und auf einen Bug in der Tastenabfrage hindeutete.
Am Ende stellte sich zwar raus daß der Fehler von ganz woanders herkam,
aber ich war doch froh daß ich die Entprellung verstand und dadurch
schließlich als Fehlerursache ausschließen konnte.
> Bei dieser Entprellung rück sogar ich von der Prämisse ab, dass man Code> den man verwenden möchte wenigstens in Grundzügen verstehen sollte.
Genau das meine ich. Im Sinne von Produktivität mag es sinnvoll sein,
fertige und unverstandene Codeteile zu übernehmen, sofern sie "proven"
sind. Ich muß jedoch nicht für den neuen Ferrari des Chefs hacken,
sondern tu das aus Spass und Freude nur für mich selbst. Und für meine
Hobbyprojekte will und muß ich alles verstehen, was ich an Code
schreibe.
Ich bin kein Chinese ;-)
puffel schrieb:> Seine Lösung, den Taster mit einem bestimmten> Zeitraster regelmäßig abzufragen
Was anderes macht Peters Lösung ja am Ende auch nicht. Sie enthält
(in der im Artikel geschriebenen Form) nur gleich noch dem Timer
selbst (der leider in klassischer 8051-Manier neu geladen wird, statt
den mittlerweile bei allen AVRs vorhandenen CTC-Modus zu nutzen).
Jörg Wunsch schrieb:> selbst (der leider in klassischer 8051-Manier neu geladen wird,
Ich will PeDa da nicht ins Handwerk pfuschen, aber diesen Reload hätt
ich rausgeworfen. Denn ob die ISR alle 10 Millisekunden oder alle 5 oder
alle 15 oder ... aufgerufen wird, spielt absolut keine Rolle.
Dieser Reload betont in meinen Augen diese 10ms viel zu sehr. Ein
Kommentar bei der Timer Initialisierung, dass man sich bemühen soll, in
etwa auf 10 Millisekunden für den Overflow zu kommen, hätte komplett
ausgereicht.
Leider gibt es keine einfache Möglichkeit den Prescaler aus F_CPU und
gewünschter Zeit zu bestimmen, die auf allen AVR funktioniert.
> 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.
MaWin schrieb:> und wenn man die auseinandernimmt, kommt die übernächste Lösung,> und PeDa sagt selbst:>>> Für komplexere Programme ist sie nicht geeignet, da gebe ich>> Dir Recht.
Du zitierst (mit Absicht?) unvollständig.
Das obige hat PeDa ausschließlich auf die Macro-Version bezogen, nicht
auf die Timer-Version.
Hier das vollständige Zitat:
| Für komplexere Programme ist sie nicht geeignet, da gebe ich Dir Recht.
| Aber dann weiß man auch, wie man die bessere Version mit Timerinterrupt
| verwenden muß.
> statt es einfach ein mal und richtig zu machen,
hat er doch - nämlich in der Timerversion.
Ist das wirklich MaWin oder ein Troll? Von dem "echten" MaWin hätte ich
bessere Argumente erwartet.
MaWin schrieb:>> Schau' Dir mal die PeDa-Lösung an. Ist wirklich genial!>> Habe ich, Karl heinz Buchegger erwähnt nicht ohne Grund daß sie> mit ihrem delay Müll sind und verweist auf die nächste> angeblich nun endgültige Lösung,> und wenn man die auseinandernimmt, kommt die übernächste Lösung,> und PeDa sagt selbst:
Sag mal. Hast du eine Leseschwäche?
Die PeDa Lösung ist diejenige, die im Artikel Entprellung unter
Komfortlösung angegeben ist. Und bei der gibt es nichts zum
auseinandernehmen.
Ich dachte eigentlich, dass das mehr als deutlich rüber gekommen ist.
>> Für komplexere Programme ist sie nicht geeignet, da gebe ich>> Dir Recht.
PeDa sprach von einer Alternativ-Einfach-Lösung, die für Programmierer
gedacht ist, die mit Timer und Interrupts auf Kriegsfuss stehen. Aber
auch das ist in seinem Beitrag deutlich ausgesprochen worden.
... 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;
}
}
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...
Martin schrieb:> ... statt es einfach ein mal und richtig zu machen, gibt ja schliesslich> genug AppNotes "Display und Keyboard" von Microchip und Atmel die zeigen> wie's geht ...>> Hier ein Beispiel von Atmel. So ist "richtig" gut ;)>
1
> __interrupt void PCINT1_ISR(void)
2
> {
3
> unsigned int delay=2857; // 7 cycles per count, 20 ms @ 1
4
> do
5
> {}
6
> while(delay--); // de-bounce: allow inputs to settle
7
>
8
> (...)
9
>
10
> }
11
>
Das ist allerdings wirklich eine "geniale" Lösung. Mal eben in der ISR
20ms Pause einzulegen. Das ist normalerweise ein Kündigungsgrund.
Gruß,
Bernd
Bernd O. schrieb:> Das ist allerdings wirklich eine "geniale" Lösung. Mal eben in der ISR> 20ms Pause einzulegen. Das ist normalerweise ein Kündigungsgrund.
Kündigungsgrund ist höchstens wenn man nicht erkennt, dass das (einen
halbwegs intelligenten Compiler vorausgesetzt) zu exakt 0ms Wartezeit
führt und damit die ganze Systematik ad absurdum führt.
Und wenn man das dann so umbaut, das dieses Problem nicht mehr besteht,
wird auch gleich noch die Arbeitslose gestrichen :-)
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
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
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
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.
> 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.
> 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.
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 :-))
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.
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.
HildeK schrieb:> Zugegeben, ich habe den Thread nur oberflächlich durchgescrollt und ich> habe auch Peter Dannegers Entprellroutine nicht in allen Einzelheiten> verstanden, aber manche real existierende Entprellroutine, wie z.B. im> Aufzug in unserem Bürogebäude, haben den Namen nicht verdient. Es darf> nicht vorkommen, dass auch ein sehr kurzer Tastendruck einfach ignoriert> wird.
So einen Aufzug kenne ich auch:
Man drückt die Taste kurz, die Glühbirne dahinter leuchtet sogar kurz
auf - aber die Entprellung hat die Taste noch nicht akzeptiert. Hat
vermutlich so ein Schlaumeier implementiert, der meint 100 ms Abtastung
und dann 5 Ereignisse in Folge seien eine gute Entprellung.
Andererseits ist es ganz lustig. Es steigen immer wieder Leute in den
Aufzug, die ihr Stockwerk nur vermeintlich anwählen - so komme ich dann
schneller da hin wo ich hin will und das dumme Gesicht, wenn der Aufzug
am Ziel vorbeifährt ist auch nicht zu verachten...
Gruß,
Bernd
> Nehmt doch einfach Gummimatten,> die noch nie ein Prellen hatten!
@Paul: Diese Sc/%§$! Carbon Kontakte prellen am schlimmsten.
Im Automotivebereivch verwenden wir i.A: 20..30mS. In dieser Zeit wir
der Eingang n mal abgefragt.
Die Strategie is unterschiedlich:
1. Messe Pegel bei Signalaenderung, warte 20ms, messe Pegel. Wenn gleich
dann loese Aktion aus (Interrupt on change)
2. Messe Pegel alle 2mS. Wenn 8 mal der gleiche Wert, dann loese Aktion
aus (Polling)
Und ein RC Glied ist am EIngang sowieso noch vorhanden (ESD Schutz) aber
ein Entprellen darueber ist zu langsam!
Gruss
Michael
PS.: Alle mechanischen Schalter prellen mehr oder weniger. Der Hinweis
auf Lebensdauer war sehr wichtig!
Und es haengt vom Strom und der Spannung ab.
Vieles dazu findet man unter Reialsdaten. Die Daten fuer Schalter sind
spaerlicher.
Gruss
Michael
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
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
> ... 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.
... 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/application_notes/xapp382.pdf
Mit anderen Worten:
Ein Schmitt-Trigger ist bei RC-Glättung auf jeden Fall erforderlich.
Marc schrieb:> Ein Schmitt-Trigger ist bei RC-Glättung auf jeden Fall erforderlich.
Wenn sich die Leute doch wenigstens mal das ganssle.com-Paper da
oben durchlesen würden...
Das Prellen ist ein stochastischer Vorgang, d.h. die Prellzeit kann
stark variieren.
Will man also nur einmal abtasten, muß man die maximale Prellzeit
abwarten und erhält eine deutlich verzögerte Reaktion.
Tut man dies nicht, kann er 999-mal funktionieren und einmal prellen.
Der Mensch ärgert sich dann genau über dieses eine Mal
Nichtfunktionieren.
Die Mehrfachabtastung würde dann nur dieses eine Mal länger brauchen,
aber die anderen Male deutlich eher reagieren.
Und wenn man sich den geradezu lächerlich geringen Codeaufwand ansieht,
gibt es überhaupt keinen Grund, die Vorteile der Mehrfachabtastung nicht
zu nutzen.
Ein RC-Glied ist deshalb ungeeignet, weil seine Funktion stark variiert.
Wurde lange nicht gedrückt, ist der Kondensator entladen und braucht
lange, um zu reagieren. Der erste Tastendruck wird also lange verzögert.
Unmittelbar nach dem Drücken ist der Kondensator aber nahe der
Schaltschwelle geladen und damit seine Entprellwirkung gering bis
garnicht.
Deshalb benutzen HW-Entprell-ICs einen Taktgenerator und tasten den
Eingang mehrmals ab (z.B. MAX6818, Seite 4, Figure 1).
Also exakt genauso, wir man es in SW machen würe.
Ob man nun 10 Zeilen Code includiert oder lieber 9,35€ (Farnell)
bezahlt, muß jeder für sich entscheiden.
Peter
Marc schrieb:>> Wenn sich ... doch wenigstens> Ja gut...>> Dafür kriegen wir hier so weitere Quellen rein !
Ist schön, aber gerade die Grundlagen der Entprellung mit RC-Filter
sind dort schon gut aufbereitet.
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
Bei der ganzen Diskussion wird völlig außer Acht gelassen, dass man in
Hardware mittels eines RC-Gliedes auch sehr wirksam entprellen kann.
Wenn dieser Hardware-Aufwand im Design kein Problem darstellt (Platz,
Kosten), kann man durch hohe Dimensionierung von R das Prellen der
allermeisten Taster nahezu ganz verhindern.
Di Pi schrieb:> Bei der ganzen Diskussion wird völlig außer Acht gelassen, dass man in> Hardware mittels eines RC-Gliedes auch sehr wirksam entprellen kann.> Wenn dieser Hardware-Aufwand im Design kein Problem darstellt (Platz,> Kosten), kann man durch hohe Dimensionierung von R das Prellen der> allermeisten Taster nahezu ganz verhindern.
Kann man.
Nur muss man es richtig machen.
Das Pollin Board macht es nicht richtig. Die ganzen R und C bringen den
µC regelmässig zum Absturz.
Hardware-Entprellung stilllegen und auf Software umsteigen und der Spuk
hat ein Ende.
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 ;-)
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
Marc schrieb:> Ein Kondensator ist in der Zeit von 5 Tow fast vollständig geladen.
Es heißt Tau, und du hast Peters Post nicht gelesen, denn der
Kondensator ist nur in 5-Tau geladen, wenn er vorher leer war. War er
das nicht (wegen einem vorangegangenen Tastendruck, dann ist er in einer
anderen Zeit geladen. Und das ist eben nicht "reproduzierbar". Also die
Anfangsbedingungen sind nicht immer gleich.
Der Code den MaWin oben übrigens gepostet hat, ist von der Funktion fast
identisch mit Peters Code. Nur, dass Peter eine 4 fach Abtastung noch
durchführt, was, wie er auch schon gesagt hat, in Anbetracht der wenigen
zusätzlichen Rechenpower (Das sind echt nur 3 oder 4 Zyklen) sich
absolut lohnt.
screwdriver schrieb:> Bei einer Hardware-Entprellung sollte dann aber der µC-Eingang über> einen Schmitt-Trigger verfügen. Sonst geht der Schuß doch nach hinten> los, oder?
Gibt es überhaupt (noch) Mikrocontroller ohne Schmitt-Trigger Eingänge?
Schmitt-Trigger ist immer son tolles Wort, das vermutlich nicht
unbedingt im Datenblatt stehen muss. Es ist ja auch einfach nur die
Bezeichnung für eine kleine (definierte) Hysterese an den Eingängen. Und
das hat eigentlich (fast) jeder Mikrocontroller.
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 ...
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?
puffel schrieb:>> Es gibt im realen Leben nicht nur Tastenprellen sondern auch noch so>> schöne Dinge wie ESD-Impulse, Wackelkontakte in Leitungen usw.>> Was bitte hat denn Entprellung von Tasten mit sicherheitskritischer> Software und Schutz gegen ESD-Impulse usw. zu tun?
No, Ich würde mich schön bedanken, wenn sich meine Geräte selbst
verstellen, nur weil sie sich einen Puls eingefangen haben.
Zb mein Fernseher.
Das nervt tierisch, wenn der sich Abends ein paar Infrarot Impulse
einfängt und die dann als 'OSD anzeigen' interpretiert. Gott sei Dank
holt sich der immer nur das OSD und nicht 'Lautstärke volle Pulle'. So
ist dann wenigstens der Fernsehschlaf gesichert.
Marc schrieb:> Wie schnell ist ein Mensch in der Lage, kurz nach dem drücken eines> Tasters, seine Muskeln zu entspannen um diesen Wieder loszulassen...
Ziemlich schnell. Eine Wiederholrate von 10 Hz (also rund 50 ms
"ein" / 50 ms "aus") konnte man bereits problemlos mit dem
ergonomisch sicher völlig ungeeigneten Gabelkontakt eines analogen
Telefons erreichen, um auf diese Weise eine Impulswahl durchzuführen.
Wenn du den Kontakt ergonomisch günstiger aufbaust, dann kannst du
dir mal angucken, was die Leute so aus einer Morsetaste rausholen...
15 Hz und mehr sind da durchaus drin.
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.
Jörg Wunsch schrieb:> Marc schrieb:>> Wie schnell ist ein Mensch in der Lage, kurz nach dem drücken eines>> Tasters, seine Muskeln zu entspannen um diesen Wieder loszulassen...>> dann kannst du dir mal angucken, was die Leute so aus einer Morsetaste> rausholen... 15 Hz und mehr sind da durchaus drin.
Oder aus einem Spielautomaten
http://en.wikipedia.org/wiki/Track_&_Field_%28video_game%29
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.)?
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.
Also Maxim ist ja nicht irgendeine kleine Frickelbude.
Und wenn die nen Chip (MAX6818) herstellen, dann werden die sich dabei
was gedacht haben und dessen Funktion auf Herz und Nieren geprüft haben.
Und die Maxim-Entwicklungsingenieure werden auch nicht alles
Berufsanfänger sein.
Und wenn dann meine Routine haargenau so funktioniert, wie es die
Maxim-Profis in Hardware gegossen haben, dann kann ich ja wohl nicht
alles total falsch gemacht haben.
Peter
Peter Dannegger schrieb:> Also Maxim ist ja nicht irgendeine kleine Frickelbude.>> Und wenn die nen Chip (MAX6818) herstellen, dann werden die sich dabei> was gedacht haben und dessen Funktion auf Herz und Nieren geprüft haben.> Und die Maxim-Entwicklungsingenieure werden auch nicht alles> Berufsanfänger sein.>> Und wenn dann meine Routine haargenau so funktioniert, wie es die> Maxim-Profis in Hardware gegossen haben, dann kann ich ja wohl nicht> alles total falsch gemacht haben.>>> Peter
Nein, Peter, Du hast da nichts falsch gemacht.
Trotzdem muss man sich schon konzentrieren, Deinen Code zu verstehen.
Die ASM-Version nutze ich in verschiedenen Varianten und ich bin sehr
froh, dass es diesen Algorithmus gibt. Die C-Version ist mir zu
kryptisch, die verstehe ich nicht, muss ich aber auch nicht, denn meine
Programme sind meist so klein, dass sie in ASM noch überschaubar sind.
Ansonsten kann ich nur sagen, dass dieser Thread recht amysant war/ist,
er zeigt ein bissel, wie Einige hier so ticken... ;-)
...
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...
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
@MaWin:
Schau dir dochmal den Peter-Code (den guten) nochmal an, da ist nix
aufwändiges dabei (ein paar XORs &co).
Und wie du zu deiner anderen Aussage kommst, ist mir auch
schleierhaft...
Jede Taste hat dort ihren eigenen Zähler, und beeinflusst die anderen
nicht.
Das Zauberwort ist "SIMD", jeder Befehl wirkt gleichzeitig auf alle 8
Einzel-Tasten-Datenstrukturen...
MaWin schrieb:> Also das "Debounce-Makro" ist durch ihr Delay und die nicht mehrfache> Verwendbarkeit schon grottig
Das steht ausser Frage.
Um die gehts hier nicht. Du brauchst daher darauf nicht länger weiter
rumzureiten. Wir alle geben dir Recht, dass diese Simpellösung für
professionellen Einsatz nichts taugt.
>, die "Komfortroutine" ist einfach viel zu> aufwändig.
Wenn man die paar Takzyklen nicht mehr hat.
Und vieel zu aufwändig liegt im Auge des Betrachters.
> Ein Teil davon geht in Key-Repeat, ist also ok wenn man's> braucht, aber der Rest ist unnötig.
Der Rest besteht aus 2 Variablen und einem vertikalen Zähler der mit
einem UND und einem XOR realisiert ist.
> Da jammert dann wieder jemand, daß> ihm der Controllerspeicher ausgeht, weil er ohne Sinn und Verstand> massenhaft Code schreibt,
Lass die Kirche im Dorf. Das ist doch nicht massenhaft.
> Zudem hat sie das Problem, daß die Schleifen, die die Prellzeit beheben> sollen, von allen Tasten gleichzeitig verwendet werden, also nicht jede> Taste einzeln entprellt wird, sonden so lange eine Taste prellt,> verhindert sie daß die anderen Tasten erkannt werden.
Das einzige was hier fehlerhaft ist, ist deine Analyse.
Nichts davon ist wahr.
Was ist so schwer daran, einfach zuzugeben, dass du dich geirrt hast?
Passiert jedem mal. Wahre Größe besteht darin nicht auf Biegen und
Brechen sich selbst als den Allwissenden feiern zu lassen sondern auch
mal zuzugeben, dass man falsch lag.
MaWin schrieb:> Also das "Debounce-Makro" ist durch ihr Delay und die nicht mehrfache> Verwendbarkeit schon grottig,
Das wurde, wie gesagt, für (Timer-)Interrupt-Muffel geschrieben.
> die "Komfortroutine" ist einfach viel zu> aufwändig.
Also Manfred, da verstehe ich Dich nicht. Was ist hierdran aufwendig?
Der Aufruf erfolgt zyklisch im Zeitabstand von etwa 10ms:
1
Tastenabfrage: ;Entprell-Algorithmus geklaut bei Peter Dannegger...
2
in tmp,tap ;Tastenport einlesen (gedrückt=L)
3
com tmp ;invertieren (gedrückt=H)
4
andi tmp,alltast ;ungenutzte Bits ausblenden
5
eor tmp,tas ;nur Änderungen werden H
6
and tz0,tmp ;Prellzähler unveränderter Tasten löschen (Bit0)
7
and tz1,tmp ;Prellzähler unveränderter Tasten löschen (Bit1)
8
com tz0 ;L-Bit zählen 0,2,->1, 1,3,->0
9
eor tz1,tz0 ;H-Bit zählen 0,2,->tz1 toggeln
10
and tmp,tz0 ;Änderungen nur dann erhalten, wenn im Prellzähler
11
and tmp,tz1 ;beide Bits gesetzt sind (Zählerstand 3)
12
eor tas,tmp ;erhaltene Änderungen toggeln alten (gültigen) Tastenstatus
13
and tmp,tas ;nur (neu) gedrückte Tastenbits bleiben erhalten
14
or tfl,tmp ;und zugehörige Bits setzen (gelöscht wird nach Abarbeitung)
15
;in "tas" steht jetzt der gültige Tastenzustand,
16
;in "tfl" die Flags der neu gedrückten, noch nicht abgearbeiteten Tasten...
Das ist die "Grundroutine" also Abfrage, vierfach-Entprellung und
Flankenerkennung von bis zu 8 Tasten eines Ports gleichzeitig. Die
Routine kostet 4 Register und braucht alle 20 ms 13 Takte Rechenzeit (+
ein paar Takte für Aufruf und Verwaltung). Was bitte ist daran
aufwendig? Dafür bekomme ich für 8 Tasten gleichzeitig den Zustand
(nutzbar für Shift-Tasten) und die Information, ob eine oder mehrere der
8 Tasten seit der letzten Auswertung erneut (losgelassen und) gedrückt
wurde. Mehr Komfort bei weniger Rechenleistungsverbrauch kann ich mir
nicht vorstellen.
> Ein Teil davon geht in Key-Repeat, ist also ok wenn man's> braucht,
Das wäre dann dieser Teil, ich baue es nur ein, wenn ich es brauche:
1
;in "tas" steht jetzt der gültige Tastenzustand,
2
;in "tfl" die Flags der neu gedrückten, noch nicht abgearbeiteten Tasten...
3
Tastendauer:
4
mov tmp,tas ;Tastenzustand kopieren
5
andi tmp,wietast ;nur Tasten mit Wiederholfunktion stehen lassen
6
tst tmp ;ist eine Taste betätigt?
7
breq Tastendauer0 ;nein, Dauer auf Startwert...
8
dec twz ;ja, Zähler runter
9
brne Tastenabfrage_e ;Dauer abgelaufen? - nein...
10
or tfl,tmp ;ja, noch aktive Tasten übernehmen (alternativ)
11
; or twf,tmp ;ja, noch aktive Tasten übernehmen (alternativ)
12
ldi twz,twz1 ;und Zähler auf Wiederholwert setzen
13
Tastenabfrage_e:
14
ret ;fertig...
15
;in "tfl" stehen jetzt wieder die Flags der länger betätigten Tasten
16
;sie werden nach Abarbeitung gelöscht
17
Tastendauer0: ;Reset Dauerzähler
18
ldi twz,twz0 ;Tastendauerzähler auf Startwert
19
rjmp Tastenabfrage_e ;fertig...
Und diese Routine macht den Kohl auch nicht fett, sie braucht lediglich
noch einen Zähler für die Repeat-Zeit und ein paar Takte Rechenzeit.
Dafür bekommt man Autorepeat bei längeren Tastendrücken, dessen
Erstaufruf und Wieredholzeit separat (durch Konstanten) eingestellt
werden kann.
Ich finde, dass das verdammt viel Funktionalität für verdammt wenig
Ressourcenverbrauch ist und das lasse ich mir von Dir und Deinen
Diskussionsbeiträgen nicht kaputt reden.
> aber der Rest ist unnötig.
Welcher Rest? Das war es schon. Gut, wenn man es in C formuliert braucht
es etwas mehr Ressourcen, da C ja die Variablen im SRAM hält, trotzdem
meine ich, dass das Aufwand-Nutzen-Verhältnis auch in C unübertroffen
ist.
> Da jammert dann wieder jemand, daß> ihm der Controllerspeicher ausgeht, weil er ohne Sinn und Verstand> massenhaft Code schreibt, und der nächste mit dem Projekt befasste> jammert, weil er nicht versteht, warum sein Vorgänger da so massenhaft> merkwürden Code geschrieben hat...
Nööö, jede andere Variante, bis zu 8 Tasten gleichzeitig zu entprellen
und deren Flanken (erneutes Drücken) separat zu signalisieren braucht
mehr Ressourcen.
> Zudem hat sie das Problem, daß die Schleifen, die die Prellzeit beheben> sollen,
Hier gibt es keine Schleifen, die Prellzeit beheben sollen.
> von allen Tasten gleichzeitig verwendet werden, also nicht jede> Taste einzeln entprellt wird, sonden so lange eine Taste prellt,> verhindert sie daß die anderen Tasten erkannt werden.
Nein, die Tasten werden separat entprellt. Nur die Taste, die 4
Abfragerunden hintereinander mit (zum bisher gültigen) entgegengesetztem
Status eingelesen wird, schafft es, ihren 2-Bit-Prellzähler (je 1 Bit
jeder Taste in einem Register, das andere Bit jeder Taste im anderen
Register) hochzuzählen und den (als entprellt geltenden) Status zu
toggeln. Dies erfolgt beim Drücken genauso wie beim Loslassen.
> Falls du also> fragst, was Maxim anders macht...
Was MAXIM macht, weiß ich nicht, aber auf Peters Entprellalgorithmus in
ASM lasse ich nichts kommen. Einfacher und effizienter geht es nicht.
...
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 ...
Peter, hast du den Algorithmus eigentlich auch schon mal für eine
Matrixtastatur umgebaut? Das habe ich demnächst vor. Im Prinzip
müsste man doch nur den Prellzähler N-mal aufbauen und dann an die
gerade abgefragte Reihe binden, oder? (Mehrere gleichzeitig
gedrückte Tasten würden mich erstmal nicht interessieren.)
Hannes Lux schrieb:> Was MAXIM macht, weiß ich nicht, aber auf Peters Entprellalgorithmus in> ASM lasse ich nichts kommen. Einfacher und effizienter geht es nicht.
Und ich lass mir die C Lösung nicht madig reden.
Das ist eine echte "Plug&Play, einbauen und funktioniert" Lösung.
Selten etwas so problemlos zu verwendendes gesehen.
@Jörg: Das sollte problemlos gehen.
Für eine Matrix habe ich es noch nicht gemacht, aber für 40 Tasten, von
denen 32 per Schieberegister eingelesen werden. Ich habe dazu die
Variablen im SRAM liegen, organisiert wie 4 Arrays je 5 Elemente. Denn
jeder 8er-Block braucht ja 4 Bytes (Status, Flanke, Prellzähler L und
H).
...
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.
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 ;-)
U.R. Schmitt schrieb:> Marc schrieb:>> Das Prellen ist doch meistens nur ein Vorzeichen für einen Pegelwechsel.>> Ein unvorhergesehendes Prellen, ohne das der Finger auf dem Taster ist,>> ist also so gut wie unmöglich.>> Vorsichtig betrachtet kann man also das erste Prellanzeichen direkt ohne>> Timer als Flanke wahrnehmen oder was meint ihr...>> (ich spreche jetzt nicht vom Halten oder wieder Loslassen des Tasters)>> ... Resultat: Schnellste Reaktionszeit ...>> Hab ich doch schon zwei mal gesagt. Ein Taster mit Umschaltkontakt und> dann ein RS Flipflop. Der Ein Kontakt an den S Eingang und der Aus> Kontakt an den R Eingang. Es sollte nur kein Taster sein der im Übergang> kurz alle 3 Kontakte brückt und die Eingänge brauchen einen> entsprechenden Pullup. Das war das erste was ich ca. 1980 zum Thema> Digitaltechnik gelernt habe.
Die Methode habe sogar ich noch in der Berufsschule gelernt (2007). Aber
in der heutigen Zeit ist die (außerhalb vom Hobbybereich) nicht machbar,
da
a) Umschalter idR teurer sind, als einfache "Omron" Switches (Diese
Klick-Taster)
b) Besondere Anforderungen an den Umschalter gelegt werden (nicht
überlappend)
c) Es die Flip-Flop nicht gerade in Miniaturbauweise gibt
d) Die Kosten für die Hardware demnach viel größer sind als die für die
Software Entprellung (Denn hier kann man ggf. auf existierende, GUT
funktionierende Bibliotheken zurückgreifen. Hobbybastler zum Beispiel
auf Danneggers Variante)
EDIT: Ach so, danke an Hannes für diesen (hoffentlich) aufklärenden
Beitrag mit Codeschnipseln.
Simon K. schrieb:> Gibt es überhaupt (noch) Mikrocontroller ohne Schmitt-Trigger Eingänge?
Leider Ja. Z.B. diverse PIC16F/18F. Da gibt's den Schmitt-Trigger nur
für wenige Spezialfunktionen (Timer-Eingang, Interrupt,
Programmiereingänge), der Rest der I/O-Funktionen/Leitungen hat ganz
normale, auf TTL-Verhalten ausgelegte Eingänge.
Atmel ist da konsequenter, AVRs haben Schmitt-Trigger rundrum. Einzelne
Taster bekommt man problemlos mit einem Parallelkondensator und internem
PullUp recht gut entprellt, wenn der Taster von brauchbarer bis guter
Qualität ist. Richtig schlechte oder verdreckte Drücker bekommt damit
natürlich nicht in den Griff, da muß man dann zusätzlich mit Software
ran.
>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.
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
in Gedanken 1:1 in Assembler übersetze (ca. 13 Befehle ohne die beiden
Ifs zur Einzeltastenabfrage) und ihn mit dem von Peter
1
mov iwr0, key_old
2
in key_old, key_port
3
eor iwr0, key_old
4
com key_old
5
mov iwr1, key_state
6
or key_state, iwr0
7
and iwr0, key_old
8
eor key_state, iwr0
9
and iwr1, iwr0
10
or key_press, iwr1
vergleiche (10 Befehle), dann ist es deine Lösung, die den unnötigen
Programmcode enthält und entsprechend mehr Rechenzeit braucht (wobei
über diese paar Bytes und Taktzyklen zu diskutieren an Erbsenzählerei
grenzt). Die Anzahl der benötigten Variablen bzw. Register ist bei
beiden Lösungen gleich. Peter hat es halt geschafft, mit 2 Bits bis 4
statt nur bis 2 zu zählen und die enstehenden Logikterme so zu
umzustellen, dass sie ein AVR mit der minimalen Anzahl von Befehlen
auswerten kann. Warum soll man diesen Vorteil nicht nutzen?
Schmunzel 4:
Karl Heinz, der auf mich an dieser Stelle völlig untypischerweise einen
leicht genervten Eindruck gemacht hat :), hat es schon in wenigen Worten
zusammmengefasst:
> Sag mal. Hast du eine Leseschwäche?
Jetzt aber wieder todernst:
MaWin schrieb:> denn man kann die Zeit so lang machen, wie der Benutzer noch keine> Verzögerung bemerkt, so 100msec sind einerseits akzeptabel,
100ms sind in meinen Augen nicht akzeptabel. Ein kurzes Antippen der
Tasten, wie beispielsweise beim Wählen einer Telefonnummer oder beim
Schreiben auf der Computertastatur, dauert bei mir lt. Oszi nur etwa
30-40ms, und das ist nicht noch lange nicht der worst Case (der liegt
deutlich unter 10ms). Die Pause zwischen zwei Betätigungen derselben
Taste ist aber wesentlich länger, nämlich etwa 80-100ms.
Für eine zuverlässige Tastenentprellung reicht es normalerweise aus, die
Mehrfachabtastung nur beim Öffnen des Tasters zu machen. Da sich ein
offener Taster nach der Prellzeit nicht einfach von selbst schließt (nur
der umgekehrte Fall ist möglich), kann das erste Geschlossensignal
sofort und eindeutig als Tastendruck gewertet werden. Dadurch wird bei
Interruptsteuerung oder entsprechend hoher Abtastrate auch der
8ms-Tippser zuverlässig erfasst. Bevor auf den nächsten Tastendruck
gewartet wird, muss natürlich sichergestellt werden, dass die Taste
zwischenzeitlich losgelassen wurde. Das geht am besten mit Mehrfach-
abtastung, bspw. vierfach im 10ms-Takt. Wegen der relativ langen
Betätigungspausen macht sich die hierfür benötigte Zeit nicht bemerkbar.
Der Benutzer hat also das volle "Echtzeitfeeling", ohne dass die
Zuverlässigkeit leidet.
>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!
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 ;-)
>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.
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
> 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.
>... 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)
MCUA schrieb:>>Richtig. Deswegen muss man hardwareseitig dafür sorgen, dass diese>>On-Spikes gar nicht erst auftreten.> womit dadurch automatisch eine hardw-Entprellung vorhanden ist, was evtl> eine Softw-Entrellung überflüssig macht.
Nicht automatisch. Um das Prellen hardwareseitig zu bekämpfen, ist meist
mehr Aufwand erforderlich. Gegen elektromagnetische Störungen muss oft
gar nichts getan werden, weil der Störabstand an den Digitaleingängen
schon ausreichend ist. Und sonst gelten halt die üblichen Regeln:
"Antennen" vermeiden, saubere Spannungsversorgung usw. Die meisten
dieser Regeln müssen aber sowieso befolgt werden, egal ob die Schaltung
Taster enthält oder nicht. Für die Taster fällt also kaum zusätzlicher
Aufwand an.
Ich kann mich an keinen Fall erinnern, wo durch äußere Störungen fälsch-
licherweise ein Tastendruck erkannt worden ist, nicht einmal bei ganz
billigen Geräten.
MaWin schrieb:> Das was du vorliest, ist nicht der zum entprellten Einlesen notwendige> Algorithmus, der stand drüber, das hättest du schon sehen können, und er> war deutlich kürzer.>> Das was du nun herbeiziehst, ist die zweite Programmvariante, die> einzelne ESD-Störungen die von Anja hereingebracht wurden, filtert. Ja,> die filtert durch Mehrfachabtastung.
Die Mehrfachabtastung macht man ja nicht nur wegen der ESD-Störungen.
Auch ein Reiben der Kontakte aneinander im gedrückten Zustand kann zu
kurzzeitigen Unterbrechungen führen, die deine erste Variante als
Loslassen und erneutes Drücken des Tasters interpretieren würde.
Deswegen muss zumindest für die zuverlässige Erkennung des Öffnens ein
ganz klein wenig mehr Aufwand getrieben werden.
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 :-)
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.
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...
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?
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.
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).
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...
> 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.
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.
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.
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?
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.
Ich verstehs nicht. Angenommen ein Tastendruck wird erkannt, dann wird
der Kondensator kurzgeschlossen und der Kondensator ist für den nächsten
Tastendruck bereit.
Aber was ist denn, wenn der Nutzer den Taster gedrückt hält? Das ist gar
nicht zu unterscheiden davon, als würde der Nutzer den Taster immer
wieder drücken. Man muss also das "Auto Repeat" (dessen Frequenz von
der Zeitkonstante abhängt) benutzen.
Außerdem ist der Programmaufwand nicht zu unterschätzen (Im vergleich
zur Entprellung direkt in Software). Irgendwann muss der Pin auch wieder
auf Eingang gesetzt werden. Also entweder Warteschleife oder
"Merkervariable".
Wie Karl Heinz schon sagt, das ist doch im Prinzip ein Mehraufwand.
ESD kann man AFAIK auch einfacher abhalten.
Pothead schrieb:> Karl heinz Buchegger schrieb:>> Wenn ich bei deiner Lösung sowieso wieder eine spezielle>> programmtechnische Bearbeitung benötige, was ist dann der Vorteil>> gegenüber einer reinen Softwarelösung, die ohne externe Komponenten>> auskommt?>> Mindestens ein Vorteil hat dieses Verfahren. Du hast mit dieser> Schaltung automatisch einen sehr wirkungsvollen ESD Schutz, da man mit> R1 ein (sehr) hochohmiges Längsglied hat (R1 sollte entsprechend> ausgewiesen sein).
Gut, das kann ich so auch machen.
> Außerdem ist es programtechnisch simpelst zu> realisieren - das RC-Glied geht auf einen Portpin mit> Interruptfunktionalität, sobald ein Interrupt kommt kann man das> Ereignis registrieren und gleichzeitig das C entladen.
Äh nein.
Entladen kannst du erst anfangen, wenn der Benutzer wieder losgelassen
hat. Aber ok, ist jetzt ein Detail
> dieser eine geeignete Periodendauer hat. Weiterer Vorteil: Es passiert> nur dann (und nur dann) etwas, wenn eine Taste gedrückt wird.
OK.
Seh ich ein. Wenn man auf die letzten paar Prozentpunkte Rechenkapazität
angewiesen ist, ist das natürlich ein Argument.
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.
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.
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
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
Thread beobachten
Seitenaufteilung abschalten