mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik muss man unbedingt entprellen?


Autor: Rolf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe ein ein- und ausschaltbares Lauflicht programmiert. Zunaechst
habe ich das Programm nur im Simulator des AVR-Studios laufen lassen.
Dabei musste ich mir wegen der idealen Bedingungen keine Gedanken ueber
Entprellung machen.

Gestern habe ich nun meinen Atmega16 zugeschickt bekommen. Also habe
ich das Programm auf dem STK500 mit dem Atmega16 laufen lassen.

Erstaunlicherweise habe ich keine Probleme mit einem prellenden
Ein/Aus-Taster, obwohl ich keine Entprellung programmiert habe. Warum
ist das so?

Wann muss man unbedingt eine Entprellung programmieren?

Rolf

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die Tasten vom STK könnten ja entprellt sein ?¿

Wenn Du aber ne eigen Platine entwirfst und den Taster auf die
INT Eingänge hängst und dein Progrämmchen auch mit Interruptroutinen
läuft kannste ohne Entprellung ziemlich in den Schlamassel geraten.

Es ist wirklich anzuraten wenn mechanische Taster verwendet werden.

Autor: AntonWert (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie lange dauert eigentlich ein Prellvorgang?
Ich meine (wenn nicht's zeitkritisches ansteht) dann könnte man das
Programm doch einfach für diese Zeit anhalten.

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wie lange dauert eigentlich ein Prellvorgang?
0..50 oder 100ms - je nach Taster. Manche sogar noch länger.

> Ich meine (wenn nicht's zeitkritisches ansteht) dann könnte man das
> Programm doch einfach für diese Zeit anhalten.
So machen's die, die es nicht besser wissen und sich mit jeder
Programmerweiterung Probleme einfangen wollen.
Die anderen entprellen ihre Eingänge einmal gescheit und haben dann
keine Probleme mehr.

----, (QuadDash).

Autor: Christoph Söllner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das ist mal wieder so eine typische /dev/null Antwort, wie sie auch
Schlaubi-Schlumpf nicht besser hätte geben können. Für Anfänger, benutz
doch mal Deinen richtigen Namen (ich nehme mal an, Du hast einen und er
ist nicht gleich quaddash).
Dann hättest Du ihm eine generelle Idee geben können, wie man denn
entprellt:
1.  irgendein Register (zb r16) auf 0 setzen
    ---LOOP START---
2.  if ((!PINx.y)&(r16==0)):
      //REMEMBER, PRESSED BUTTON MEANS "!PINx.y"
      //BEIM ERSTEN MAL SCHON SPERREN, DIESES
      // IF STATEMENT WIRD NUR EINMAL PRO DRUCK AUSGEFÜHRT!
      r16++
      //DO SOMETHING
3.  if ((PINx.y)&(++r16>100)):
      //OK, TASTE WAR LANGE GENUG LOSGELASSEN.
      r16=0;
    ---LOOP END---
Ja, der Syntax ist Python und C gemischt, aber ASM kann ich nicht ^^
Hoffe, es ist kein Denkfehler drin...
Oh und btw, den Prellvorgang zeigst mir mal, der 100ms (=0,1s!) dauert,
ich habe mit INT0 Betrieb und einem Zählerwert grade mal 20(!)
(fosc=16M) Wechsel feststellen können, bevor sich der PORT Wert nicht
mehr änderte.
In diesem Sinne, Christoph

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Dann hättest Du ihm eine generelle Idee geben können, wie man denn
> entprellt:
Die Fragestellung(en) haben nicht ansatzweise erkennen lassen, daß
dieses hier gefragt ist! Ich habe AntonWerts Fragen beantwortet und
kommentiert.
Christoph, ich bin nicht darauf aus, mich mit dir zu streiten.

Noch kurz zu deiner "generellen Idee": So glaubt deine Software, auch
bei nur kurzen Spikes/Störungen, einen vollwertigen Tastendruck erkannt
zu haben.

----, (QuadDash).

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Rolf

"Erstaunlicherweise habe ich keine Probleme mit einem prellenden
Ein/Aus-Taster, obwohl ich keine Entprellung programmiert habe. Warum
ist das so?"

Es kann sein, daß sich durch die restliche Programmlaufzeit zufällig
eine Entprellung ergibt.



"Wann muss man unbedingt eine Entprellung programmieren?"

Müssen muß niemand, es macht die Programmierung nur einfacher und
sicherer.

Man macht einmal die Entprellung und kann sie fürderhin vergessen.
D.h. Änderungen im Programm (Laufzeit) haben nun keinen Einfluß mehr.
Auch hat die Entprellung bei der gedrückt Erkennung den Vorteil, daß
sie Störungen unterdrückt (elektrostatische Entladunden beim Berühren
des Gerätes).


Peter

Autor: Christoph Söllner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@quaddash:
> Noch kurz zu deiner "generellen Idee": So glaubt deine
> Software, auch bei nur kurzen Spikes/Störungen, einen
> vollwertigen Tastendruck erkannt zu haben.

Erinnern wir uns: Der AVR hat seinen Pullup an, also liegt
sein Eingang immer an Vcc. Die Spike/Störung müßte somit ei-
ne gegen Masse sein, und damit die Schutzdioden des AVR das
als 0V erkennen, muss die Spannung < 0,5V sein (Vcc=5V).

Wenn man die Taster wirklich nur zwischen Masse und das AVR Bein-
chen stöpselt, ist mir kein physikalischer Umstand bekannt (
außer Wegfall der Versorgungsspannung natürlich), der zu einer
Fehlfunktion beim Entprellen führen würde. Das AVR-Beinchen
liegt ja schon auf +Vcc, mehr Spannung (="Spike") tötet höch-
stens die Schutzdioden da drinnen, aber die Entprellung läuft.

Aber da kann ich ja auch einen Denkfehler drinnen haben.

Christoph

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Das AVR-Beinchen liegt ja schon auf +Vcc, mehr Spannung (="Spike")
tötet höch- stens die Schutzdioden da drinnen, aber die Entprellung
läuft."


Wie bringst Du aber dem Störimpuls bei, daß er nur positiv sein darf ?


Eine elektrostatische Entladung ist HF, d.h. an parasitären
Induktivitäten und Kapazitäten entsteht eine gedämpfte Schwingung, die
negative und positive Halbwellen hat.


Peter

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mit den Schutzdioden ist da auch eine Fehlannahme drin. Die halten die
Eingangsspannung etwa zwischen VCC+0.7V...-0.7 V und nicht auf 0.5V.

Ansonsten: Klar, ein Spike kann auch negativ sein, wie Peter schon
schreibt.

Autor: Der Elektrische Reiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Man darf Entprellen nicht mit Störfestigkeit in einen Topf werfen.

Wenn man Tasten nur selten abfragt, so ca. alle 200ms, und es nicht auf
den exakten Zeitpunkt des Tastens ankommt, spielt das Prellen praktisch
keine Rolle. Da muss dann nix entprellt werden. Wender per Hard- noch
per Software.

Störfestigkeit lässt sich nur in sehr geringen Masse alleine durch
Software in den Griff bekommen. Egal welche Polarität die Spikes auch
ahben. Da ist schon ein weinig Hardware nötig.

cu

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Wenn man Tasten nur selten abfragt...

Das ist ja schon die erste Stufe der Entprellung.
Taster legt man nicht an externe Interrupts, sondern fragt sie in
regelmäßigen Abständen ab.

Richtig sicher wird es aber erst, wenn man einen Pegelwechsel erst dann
übernimmt, wenn er mehrere Abfragen hintereinander stabil aufgetreten
ist. Eine sehr sparsame Umsetzung eines solchen Entprellalgorithmus ist
die Bulletproof-Entprellung, die Peter Dannegger in der Codesammlung
veröffentlicht hat. Links auf Diskussionen zu dieser Routine findet man
in der Artikelsammlung.
http://www.mikrocontroller.net/articles/Entprellung

Ein weiterer, nicht zu vernachlässigender Vorteil dieser Routine(n)
besteht darin, dass jeder Taste zwei Flags zugeordnet sind, von denen
eines den (entprellten) Tastenzustand anzeigt, das andere einen
Tastendruck signalisiert, der noch nicht abgearbeitet wurde (auch wenn
die Taste bereits wieder losgelassen wurde).

Anschaun lohnt sich.

...

Autor: Christoph Söllner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hm, also mal das ESD-Argument vernachlässigt, das, wie ich meine,
sowieso wenig Bedeutung hat, wenn meine Taster aus Plastik bestehen und
ich nicht neben Tesla-Generatoren arbeite (wo bitte sonst sollte eine
wie auch immer gepolte Ladung herkommen, wenn das MCU Beinchen
praktisch in der Luft hängt und intern gepull-upt ist?!?), habe hier
mal einen C-Code, der sogar dafür geeignet ist, längeren Tastendruck
(etwa wie FastForward) zu realisieren:

unsigned char up_btn = 0;
---LOOP START POLLING EVERY 1ms---
if ((up_btn==1)&(dmx_address_ch1 < 513)) {
  //^          ^^^^^^^^^^^^^^^^^^^^^^^^^
  //DAS IST EIGNETLICH ÜBERFLÜSSIG...

  //CODE FÜR EINFACHEN TASTENDRUCK,
  //WIRD IMMER ZUERST AUSGEFÜHRT!
  dmx_address_ch1++; //NUR BEISPIEL!
}
if (up_btn==10) {
  up_btn--;
  //CODE FÜR FASTFORWARD TASTENDRUCK,
  //WIRD NUR AUSGEFÜHRT, WENN TASTE GEHALTEN.
  //MIT "up_btn==y" EINSTELLEN, WIE LANGE GE-
  //WARTET WIRD BIS ZUM FF-MODE.
  if (dmx_address_ch1 < 513) { dmx_address_ch1++; } //NUR BEISPIEL!
}
// WENN PIN == 0 RESET, SONST GUCKEN, WIE LANGE SCHON GEDRÜCKT
if (PIND.5) { up_btn=0; } else { up_btn++; }
---LOOP END---
In diesem Sinne...

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Störfestigkeit lässt sich nur in sehr geringen Masse alleine durch
Software in den Griff bekommen. Egal welche Polarität die Spikes auch
ahben. Da ist schon ein weinig Hardware nötig.

Also Spikes sind rein durch Software wunderbar in den Griff zu
bekommen, insofern sie nicht so leistungsstark sind, dass sie einem was
kaputt hauen. Spikes sind nämlich immer von kurzer Dauer, während ein
Tastendruck längere Zeit einen Eingang auf einem Potenzial hält.

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> also mal das ESD-Argument vernachlässigt, das, wie ich meine,
> sowieso wenig Bedeutung hat,
Ich will dich da von deiner festgefahrenen Meinung nicht abbringen. Wie
ich oben schon schrieb: "So machen's die, die es nicht besser
wissen...".

> Also Spikes sind rein durch Software wunderbar in den Griff zu
> bekommen,
Genau und eine Zeile Code kostet nix.

> if ((up_btn==1)&(dmx_address_ch1 < 513))
dein bitweises "&" funktioniert hier auch nur rein zufällig.

Dein Code hängt sehr, von nicht sofort sichtbaren Nebenläufigkeiten ab.
Z.B. läuft dein up_btn von 0 beginnend hoch auf 10 und pendelt dann
zwischen 9 und 10 hin und her, bis die Taste losgelassen wird... ist
dir das auch noch in zwei Wochen noch so klar, wenn du das nächste Mal
da dran was änderst?
Wozu wird eigentlich dmx_address_ch1 inkrementiert und im Vergleich
eingangs mitausgewertet? (Muss wohl irgendwie mit dem restlichen
Programmfluss zusammenhängen?!).
Wenigstens könnte dein "FASTFORWARD TASTENDRUCK" jetzt
"spikesicher" sein. Wobei ich mich frage, wie der Benutzer einen
langen Tastendruck von >=10ms oder einem Tastendruck <10ms definiert
eingeben können soll.

Schlaubi-Schlumpf würde sagen: "Aus zusammenhanglos dahingeworfenen
Brocken Code kann der Anfänger ja am besten lernen und sich für ihn das
Relevante rausziehen".

----, (QuadDash).

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich bin immer wieder fasziniert über die ESD Störimpuls Diskussionen in
diesen "Entprell"-Threads :-)

Für mich ist das ganz einfach....

a) Es gibt Tasten, da braucht man das...
b) Es gibt Tasten, da braucht man das nicht...

Beispiel für a) sind alle Tasten, wo es einen Weg von aussen bis zum
Kontakt der Taste oder PCB (Auch VSS!) gibt. Ein solcher Weg wird
garantiert vom ESD Puls gefunden... (wenn es nicht mehr als ein paar
Zentimeter sind)

Beispiel für b) sind von der Umgebung galvanisch isolierte Tasten, z.B.
Folientastaturen, Gummi-Matten, wasserdichte Tasten etc.

Im Fall von a) reicht eine reine Software Entprellung absolut nicht
aus! Man muss auch durch entsprechende Hardware-Massnahmen die
Elektronik schützen. Z.B. wenn die Potentiale nicht gleichmässig
angehoben werden kann sich der µC "verlaufen" oder abstürzen. Für
Konsumer-Geräte werden für ESD z.T. schon 16kV HBM gefordert. Also: ->
Hardware & Software Massnahmen erforderlich.

only my 10 cents...

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Kann sich im Falle B. nicht auch eine Störung über eine andere
Schnittstelle ins Gerät einfinden und dann auf den Tastereingang
einkoppeln? Oder das ganze spielt sich direkt im Prozessor selbst ab?
Oder die (Peripherie)Elektronik stört sich selbst, weil auch an anderer
Stelle sparsam gedacht wurde. Beispiel: nichtentstörte Relais usw..
Naja, die ganze Bandbreite der EMV-Problemchen halt.
Nur weil der Taster aus Plastik ist, reichts IMHO nicht, auf solche
kostenlosen "Einzeiler" zu verzichten. Eine tatsächlich gedrückte
Taste unterscheidet sich von einem kurzen Störimpuls deutlich in der
Dauer für die das Signal anliegt - das läßt sich leicht durch die SW
filtern.

----, (QuadDash).

Autor: Christoph Söllner (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Bitweises "&"
Das darf der faule C-Programmierer, der Compiler kapiert anhand
des Statements in den Klammern, ob das ein bitweises UND ist oder
wirklich ein Bedingungs-UND.
für bitweises "&":
 //DIREKT 2 REGISTER VER-UND-EN
 if ((status & FRAMING_ERROR) != 0) {}

> Dein Code hängt sehr, von nicht sofort sichtbaren Nebenläufig-
> keiten ab. Z.B. läuft dein up_btn von 0 beginnend hoch auf 10
> und pendelt dann zwischen 9 und 10 hin und her, bis die Taste
> losgelassen wird... ist dir das auch noch in zwei Wochen noch
> so klar, wenn du das nächste Mal da dran was änderst?
Den Bedenken kapier ich nicht. Aber ja, das ist mir in 2 Wochen
auch noch klar. btw, das ist die schnellste (C) Methode, um den
FF-Code mit maximaler Geschwindigkeit ausführen zu lassen, ohne
Delays zwischendrin. Genial, nicht ^^?

> Wozu wird eigentlich dmx_address_ch1 inkrementiert und im
> Vergleich eingangs mitausgewertet? (Muss wohl irgendwie mit
> dem restlichen Programmfluss zusammenhängen?!).
Richtig, und wie im Kommentar drunter geschrieben, ist das
für die Funktion nicht relevant.

Zum Thema 1ms: Also die 10 ist ein Probierwert, theoretisch
sollte meine Schleife alle 1ms aufgerufen werden (16M/16k),
scheint aber deutlich langsamer zu sein wegen TimerINT und
Displayroutinen.

Und nochmal ESD:

Vcc-10k-+       ^
        |      ---
MCU.PD7 +------+ +----------------GND
        ^^^^^^^^
Wo bitte kommt an dieses Stück Leitung eine ausreichend
große negative Ladung, um die gesamte Leitung runterzuziehen?
Nein, auch ein gestörtes Relais reicht nicht aus, weil die
"Antenne" MCU PIN und Leiterbahn bei weitem nicht soviel Strom
aus so einer Entladung umsetzen kann, dass es für einen LOW-
Pegel reicht. Und auch die Frequenzen für eine Energieüber-
tragung nicht ausreichend hoch sind (wo genau arbeitet nochmal
ein Tesla Generator?). Und zum Thema HF: Richtig, je steiler
die Flanke, desto mehr f nach oben hin, aber die Energiever-
teilung wird auch entsprechend aufgespreizt.

Und der RC-Schwingkreis <MCU-Pin Leiterbahn> hat nun mal Bandpaß
Charakter. Und wers trotzdem ESD-sicher haben will, der ändere
meinen C-Source einfach in der zweiten Zeile auf "(up_btn==2)"
oder auch 3, und dann muss die Spike schon 3ms lang sein. (Und
das heißt dann Tastendruck).

In diesem Sinne.

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Da lob ich mir bascom, da gibts den
DEBOUNCE,

den man sogar über CONFIG DEBOUNCE einstellen kann ;o)

Was bei mir auch schon mal ganz gut geklappt hat
war einfach die Signalleiterbahn per SMD-Kapazität
gegen die Massefläche und schon war das Prellen
OK, wenn auch nicht perfekt, so doch VIEL besser.

Autor: Marko (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Nachteil bei softwaremäßigem Entprellen
ist halt einfach das es Zeit braucht ... Rechenzeit ...

Autor: TravelRec. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Na jetz´ hör aber auf: die Rechenzeit, die bei einer Tastenabfrage per
kurzer ISR verbraucht wird, die Timer-gesteuert Flags setzt und löscht,
ist nun wirklich nicht die Bremse - die paar Taktzyklen kann man ja wohl
in fast jedem Fall opfern. Und wenn der Prozi gerade keine Zeit zu haben
hat, läßt man die Tastenabfrage eben mal ein paar Male ausfallen - merkt
doch keiner!

Autor: ---- (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> > Bitweises "&"
> Das darf der faule C-Programmierer, der Compiler kapiert anhand
> des Statements in den Klammern, ob das ein bitweises UND ist oder
> wirklich ein Bedingungs-UND.
Nein. Für ein logisches UND wurde "&&" erfunden und für bitweises UND
gibt's das "&". Der Compiler kann nichts erraten, da beide Operatoren
richtig sein könnten!

> Zum Thema 1ms: Also die 10 ist ein Probierwert, theoretisch
> sollte meine Schleife alle 1ms aufgerufen werden (16M/16k),
> scheint aber deutlich langsamer zu sein wegen TimerINT und
> Displayroutinen.
Das spricht für sich.

Der Rest ist ausreichend diskutiert und führt hier nicht weiter.

----, (QuadDash).

Autor: Winfried (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Praxisbeispiel: Hatte für meinen Vater eine Zeitschaltuhr umgebaut,
diese normalen für die Steckdose. Da kam ein Kurzzeittimer mit AVR
rein, der diese 2 Minuten einschaltete. Eine kleine Platine und ein
Taster mit vielleicht 5 cm Kabel angeschlossen im Gehäuse. Getestet mit
einer Glühlampe und alles war bestens. In der Praxis wurde jedoch eine
Pumpe geschaltet (=induktive Last). Dabei schaltete die Uhr nach 2
Minuten ab, dann aber sofort wieder ein, weil ein Glitch/Spike beim
Abschalten den Schaltereingang gleich wieder triggerte.

Wollte damit mal kundtun, EMV Themen sind nicht nur was, um
irgendwelche Normen einzuhalten, sondern betreffen einen auch ganz
praktisch.

Autor: Hannes Lux (hannes)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> Der Nachteil bei softwaremäßigem Entprellen
> ist halt einfach das es Zeit braucht ... Rechenzeit ...

Muss ich das jetzt verstehen???
Was sind denn 12 Prozessortakte in einer Timer-ISR (alle 4...20ms), die
nebenbei noch andere Aufgaben hat, für verschwendete Rechenzeit???

Tastenabfrage:     ;Entprellroutine (geklaut bei Peter Dannegger...)
 in scan,tap       ;Tastenport einlesen (gedrückt=L)
 com scan          ;invertieren (gedrückt=H)
 eor scan,tas      ;nur Änderungen werden H
 and tz0,scan      ;Prellzähler unveränderter Tasten löschen (Bit0)
 and tz1,scan      ;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 scan,tz0      ;Änderungen nur dann erhalten, wenn im Prellzähler
 and scan,tz1      ;beide Bits gesetzt sind (Zählerstand 3)
 eor tas,scan      ;Änderungen toggeln (gültigen) Tastenstatus
 and scan,tas      ;nur (neu) gedrückte Tastenbits bleiben erhalten
 or tfl,scan       ;und zugehörige Bits setzen

 ;in "tas" steht jetzt der gültige Tastenzustand,
 ;in "tfl" die Flags der neu gedrückten, noch nicht abgearbeiteten
 ;Tasten...

Es sind ganze 12 ASM-Befehle, von denen jeder nur einen Prozessortakt
benötigt. Ich kann mir nicht vorstellen, dass eine Entprellung mit
Vierfachüberprüfung anders billiger realisierbar ist.

...

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Christoph Söllner

> hm, also mal das ESD-Argument vernachlässigt, das, wie ich meine,
> sowieso wenig Bedeutung hat, wenn meine Taster aus Plastik bestehen
> und ich nicht neben Tesla-Generatoren arbeite (wo bitte sonst sollte
> eine wie auch immer gepolte Ladung herkommen, wenn das MCU Beinchen
> praktisch in der Luft hängt und intern gepull-upt ist?!?)


Aha, Du bist also immer in Räumen mit hoher Luftfeuchtigkeit und trägst
keinerlei isolierende Kleidung und hast keinen isolierenden
Fußbodenbelag ?

Oder hast Du ständig ein Erdungsarmband am Handgelenk, bevor Du ein
Gerät bedienst ?

Du brauchst keinen Tesla-Generator, um Dich auf 100kV aufzuladen.
Und der Plastikknopf bildet einen prima Kondensator (Kontakt auf der
einen Seite, Fingerkuppe auf der anderen), durch den dann ein kurzer
Ladestromstoß fließt.


Solchen Unsinn machen sogar große Hersteller, die eigentlich ihr Fach
verstehen sollten:

In unserer Firma ist z.B. ein Thyssen-Fahrstuhl. Wenn man über den
Teppich läuft und betätigt die Runter-Taste, geht gleichzeitig die
Hoch-Taste mit an.
Nur wenn man sich vor dem Drücken an der Fahrstuhltür erdet, geht auch
nur die gewünschte Taste an.


Soviel zum Thema, ESD interessiert mich nicht !


Peter

Autor: Der Elektrische Reiter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@peter dannegger

In Eurem Aufzug stecke bestimmt ein AVR nur mit internen Pullups und
reiner "Software-STörfstigkeit" ;-)

Im Ernst: Wie hat dann euere Aufzug die CE gepackt? Oder brauchen
Fahrstühle keine CE?

.. da läuft mir eiskalt den Rücken runter, wenn ich mir weitere
Fehlfunktionen ausmale.

cu

Autor: SuperUser (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Kann sich im Falle B. nicht auch eine Störung über eine andere
>Schnittstelle ins Gerät einfinden und dann auf den Tastereingang
>einkoppeln?

Na in diesem Fall hast du aber ein ganz anderes Problem als eine
Tastenentprellung... Genauso hat der Mann mit der Pumpe vermutlich die
Wirkung unterbunden, aber nicht die Ursache - Glück gehabt?

Plastik-Tasten schützen überhaupt nicht vor ESD, siehe mein voherigen
Post.

Um noch ein wenig Öl aufs Feuer zu schütten...

Es gibt Applikationen, da kann man sich die Software-Spike
Unterdrückung nicht leisten. Beispiele:

I) Musikinstrumente
Gute Musiker stören schon 1-2ms delay auf Tastendrücke, und man muss
die gesamte Kette (mit signal processing) beachten

II) Stoppuhr
Macht zwar keinen Sinn aber Nutzer wollen die 1/100 sec. stoppen
können

III) Langsames Pollen
Verzögerungen >100ms werden für MMIs (man machine interfaces) als
störend empfunden, d.h. ein zweites Abfragen kommt nicht in Frage

Und nochmal: Wenn Software Entprellung notwendig ist, ist auch immer
Hardware ESD Schutz notwendig (beides!!). Sonst kann man die Software
auch gleich bleiben lassen. (Ich vermute, dass das in vielen Hobby
Projecten nicht beachtet wird)

my another 10 cents

Autor: Peter Dannegger (peda)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@SuperUser

das ist ja gerade der Vorteil der Softwareentprellung, ihre
Universalität.
Du kannst doch die Timerinterruptrate genau Deinen Erfordernissen
anpassen.

Wenn Du also bessere Tasten hast, die kürzer prellen, nimmt z.B. 1ms
Intervalle.

100ms sind nur für absolute Billigtaster erforderlich.


Und für hochwertige Musikinstrumente nimmt man eh keine Kontakttasten,
sondern optische oder magnetische, die dadurch prellfrei und
verzögerungsfrei sind.


Peter

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.