Hallo liebe Gemeinde,
kann mir jemand erklären, warum die Hardware-Entprellung (quasi mit dem
Kondensator zu glätten) für einen Taster an dem uC keine gute
Alternative ist? Irgendwie habe ich was über einen kurzzeitigen enormen
leistungsverbrauch, Spannungszusammenbruch gehört, dass der uC sich
reseten kann. Wie genau ist das gemeint?
Ich finde sonst Software-Entprellung viel aufwendiger
(Interrupt-Routinen schreiben usw) als nur einfach einen Kondi zwischen
Taster und GND zu stecken=)
Ich bitte um eine Aufklärung ;) Danke
@Manja (Gast)
>kann mir jemand erklären, warum die Hardware-Entprellung (quasi mit dem>Kondensator zu glätten) für einen Taster an dem uC keine gute>Alternative ist?
sie ist schon gut, aber einige Leute sehen es als Kostentreiber für ein
paar Cent für R und C an ;-)
>Irgendwie habe ich was über einen kurzzeitigen enormen>leistungsverbrauch, Spannungszusammenbruch gehört, dass der uC sich>reseten kann. Wie genau ist das gemeint?
Da hst du was falsch verstanden. Wenn man Entprellung in Hardware
RICHTIG macht, passiert da gar nichts. Bei einem nicht häher genannten
Evaluationboard einer nicht näher genannten Elektronikverwertungsfirma
mit P gab es einen Bug, der den Controller abstürzen lies. Das ist aber
nicht der Normalfall.
>Ich finde sonst Software-Entprellung viel aufwendiger>(Interrupt-Routinen schreiben usw)
Das macht man EINMAL und dann is gut, in neuen Projekten kopiert man es
einfach.
> als nur einfach einen Kondi zwischen>Taster und GND zu stecken=)
DAS ist KEINE solide Entprellung, da fehlt ein Widerstand. Wie man
es richtig macht, siehe Artikel Entprellung
>Warum Software-Entprellung besser?
Weil man Software einfach ändern kann. Und ne Routine die im Takt von x
ms aufgerufen wird brauchst du eh bei jedem nur etwas groesseren
Projekt, da kannst du gleich die Tastenabfrage inkl. Entprellung
einbauen.
Ok, danke. Das mit den Kosten ist echt bisschen lächerlich.. OK, vllt
wenn man 100 Taster hat, dann ja=)
Und natürlich ist der Widerstand bei mir dran=)
Aber macht die Software-Lösung nicht den uC (vllt minimal) langsamer?
Manja schrieb:> Aber macht die Software-Lösung nicht den uC (vllt minimal) langsamer?
Ja, aber: Wenn die paar Promille mehr an Rechenzeit wirklich ins Gewicht
fallen, hast du ein ganz anderes Problem.
Deine SW Entprellroutine schreibst du einmal und verwendest sie immer
wieder.
Zu den Kosten:
Klar fallen Centbeträge für einen Bastler nicht ins Gewicht, aber wenn
eine Firma eine Stückzahl von 500000 Boards oder mehr (wir sprechen hier
nicht von 100, denn auch das ist lächerlich) hat, ist das sehr wohl
relevant.
Klar, die Kosten an sich sind nicht wirklich für uns Bastler relevant.
Was bei uns aber schon wieder mehr ins Gewicht fällt: Eine Hardware
Entprellung braucht ja auch Platinenplatz. Irgendwo müssen die Bauteile
ja hin.
Die Hardware-Entprellung hat den gravierenden Nachteil, dass die
Zeikonstante durch R und C vorgegeben sind. Wählt man sie zu lang, hat
der Anwender das Problem, dass Tastendrücke verloren gehen, weil die
Schaltung gegenüber dem Anwender einfach zu lahm ist. Wählt man die
Konstante zu kurz, können gerade bei gealterten Tasten wieder Preller
durchkommen. Eine gut geschriebene Routine kann sowohl schnell sein, als
auch anständig filtern, so dass jeder Tastendruck ein Erfolg wird.
Früher oder später kehrt man der Hardwarevariante den Rücken zu.
Ganz speziell die PeDa Entprellung hat dann noch ein paar Zuckerl, auf
Grund derer der Gedanke nach einer Hardware Entprellung noch nie
aufgekommen ist. Denn mit der Hardware-Entprellungt kriege ich eben
nicht zb einen Autorepeat oder eine Unterscheidung zwischen kurzen und
langen Tastendrücken frei Haus geliefert.
Gut, kurz/lang verwende ich nie. Aber das Autorepeat ist schon Klasse,
zb bei Up/Down Zahleneingaben. Auf Up-Taster drücken und die Zahl wird
um 1 größer. Bleib ich drauf, dann setzt nach kurzer Zeit der Autoreapat
ein und die Zahl wird im (konfigurierbar) 1/10 Sekunden Takt um 1 größer
(oder auch um 10, je nachdem was ich programmiere und welchen Bereich
ich abdecken muss). Und das ganze mit einem simplen
1
...
2
3
while(1){
4
5
if(get_keypress(1<<KEY_UP))
6
value++;
7
8
if(get_keyrepeat(1<<KEY_UP))
9
value+=10;
10
11
if(get_keypress(1<<KEY_DOWN))
12
value--;
13
14
if(get_keyrepeat(1<<KEY_DOWN))
15
value-=10;
16
17
...
mach das mal mit Hardware-Entprellung so angenehm in der Programmierung
UND in der Benutzerbedienung :-)
Manja schrieb:> Aber macht die Software-Lösung nicht den uC (vllt minimal) langsamer?
Es zeigt sich, dass praktisch jedes ernstzunehmende Programm sowieso
intern sowas wie einen Basistakt in Form von ISR-Aufrufen alle paar
Millisekunden hat bzw. braucht. Du paar zusätzlichen Anweisungen da
drinnen, die die Entprellung von maximal 8 Tastern gleichzeitig
erledigen, fallen allesamt unter 'ferner liefen'.
Es gibt auch noch einen Zwitter, der die Hardwareentprellung mit
Software unterstüzt. Entgegen der reinen Softwareentprellung, eledigt
ein RC-Glied die schnelle Filterung und die Software sorgt für
definierte Pegel am Eingang. Aber lies selber, wie dies die Gemüter
erregt:
Beitrag "EIN-AUS mit Taster per Interrupt, ATtiny25 o.ä."
Wenn Du mehrere Taster und/oder Schalter entprellen mußt, ist auf jeden
Fall die Lösung per Software sinnvoll. Vielleicht hilft Dir dies weiter.
Beitrag "Entprellung von Tastern"
Aus EMV-Sicht sind RC-Filter bisweilen unerläßlich. Auch kann man
deutlich schnellere Signale als nur Tasten nur per Hardware sinnvoll
filtern. Last but not least braucht jedes abtastende System eine analoge
Bandbegrenzung am Eingang. ;-)
Falk Brunner schrieb:> Last but not least braucht jedes abtastende System eine analoge> Bandbegrenzung am Eingang.
Einen Vorfilter für jede Taste? Das ist barer Unsinn. Es geht ja nicht
um einen Sinuseingang, sondern um das Erkennen stabiler 0 oder 1
Zustände. Völlig abwegiges Theorieverständnis.
Die Softwareentprellung funktioniert seit rund 40 Jahren problemlos, da
sollte sie doch allmählich verstanden sein. Die benötigte Rechenzeit war
damals schon unerheblich. Das einzige was eine Taste braucht ist ein
Überspannungsschutz, wenn sie entsprechend exponiert ist.
Gruss Reinhard
Reinhard Kern schrieb:> Einen Vorfilter für jede Taste? Das ist barer Unsinn. Es geht ja nicht> um einen Sinuseingang, sondern um das Erkennen stabiler 0 oder 1> Zustände. Völlig abwegiges Theorieverständnis.
Völlig abwegiges Ironieverständnis ;)
