Taster entprellen: µC oder Schaltung
Hans-Paul Hoppel
bei meinem Testaufbau mit einem AtMega32 prellen die Taster deutlich.
Im WWW habe ich verschiedene einfache bis recht komplexe Vorschläge
gefunden, was man dagegen tun kann.
Was haltet Ihr von "Softwarelösungen"? Der µC wird sich in meiner
Anwendung sowieso total langweilen, Performance ist also gegeben.
Was wäre eine einfache Lösung als Schaltung?
Vielen Dank und viele Grüße
HaPa
Udo Piechottka
> Hallo Elektronik-Gurus,
>
> bei meinem Testaufbau mit einem AtMega32 prellen die Taster deutlich.
>
> Im WWW habe ich verschiedene einfache bis recht komplexe Vorschläge
> gefunden, was man dagegen tun kann.
>
> Was haltet Ihr von "Softwarelösungen"? Der µC wird sich in meiner
> Anwendung sowieso total langweilen, Performance ist also gegeben.
Funtioniert ganz gut wenn man's richtig macht. Keine Matrixtastatur hat
m.W. irgendeine Entprellung per Hardware und funktioniert bestens.
Du musst eben prüfen, ob, der Zustand mindestens für x msec stabil ist.
Wie Du das genau machst, ist eigentlich egal. Man sollte es möglichst in
definiertem Zeitraster ablaufen lassen, damit z.B. ein verkürzter Umlauf
der Hauptprogramms nicht zu Fehlinterpretationen führt.
>
> Was wäre eine einfache Lösung als Schaltung?
Widerstand + Taster (+EMV-Beschaltung bei entferntem Kontakt oder
kritischem Umfeld)
- Udo
Rafael Deliano
Benötigt typisch
* Speicher, typisch 1 Byte RAM pro Taste ( soweit es keine Matrix ist )
* eine Zeitsteuerung ( "Tick" ) die dafür sorgt daß die Routine
alle 1msec oder 100usec durchlaufen wird.
Prellzeit ist für schlechte Knachfrösche ca. 40msec max.
Für ein Seriengerät wird das immer die übliche Lösung sein.
Bei sehr simpler Software kanns auch einfacher gehen.
Für ein Einzelgerät kann ansonsten der schon genannten
RC-Tiefpaß angemessen sein.
MfG JRD
Hergen Lehmann
> Was haltet Ihr von "Softwarelösungen"? Der µC wird sich in meiner
Wenn sowieso schon ein Microcontroller vorhanden ist, spricht praktisch
NICHTS für eine Hardwarelösung...
Hergen
Thomas Kindler
> bei meinem Testaufbau mit einem AtMega32 prellen die Taster deutlich.
>
> Im WWW habe ich verschiedene einfache bis recht komplexe Vorschläge
> gefunden, was man dagegen tun kann.
>
> Was haltet Ihr von "Softwarelösungen"? Der µC wird sich in meiner
> Anwendung sowieso total langweilen, Performance ist also gegeben.
Ich hab' noch nie Verstanden, warum die Leute überhaupt aufwändige
Entprell-Lösungen basteln..
Wenn man die Taster in einem vernünftigen Zeitabstand (z.B. alle 50ms im
Timer-Interrupt) abfragt, kann man den Zustand direkt verarbeiten, ohne
irgendwelche Probleme zu haben. Schneller kann man einen Taster ohnehin
nicht betätigen, und 50ms sind noch keine merkbare Verzögerung..
--
Thomas Kindler <mail...@t-kindler.de>
Uwe Hercksen
Thomas Kindler schrieb:
> Ich hab' noch nie Verstanden, warum die Leute überhaupt aufwändige
> Entprell-Lösungen basteln..
>
> Wenn man die Taster in einem vernünftigen Zeitabstand (z.B. alle 50ms im
> Timer-Interrupt) abfragt, kann man den Zustand direkt verarbeiten, ohne
> irgendwelche Probleme zu haben. Schneller kann man einen Taster ohnehin
> nicht betätigen, und 50ms sind noch keine merkbare Verzögerung..
Hallo,
und wenn man sich so etliche Geräte anschaut die mit Software die Tasten
entprellen und die dann nach einiger Zeit doch prellen weil die Kontakte
korrodiert und schon etwas abgenutzt sind und die Software mit der
längeren Prellzeit nicht mehr sicher zurechtkommt wünscht man sich doch
Entprell-Lösungen die über die gesamte Lebensdauer des Gerätes sicher
funktionieren. Besonders nett wird es wenn durch ein bis 4-maliges
Drücken der Zifferntasten Zahlen und Buchstaben halbwegs fehlerfrei
eingegeben werden sollen.
Bye
Bernd Laengerich
> funktionieren. Besonders nett wird es wenn durch ein bis 4-maliges
> Drücken der Zifferntasten Zahlen und Buchstaben halbwegs fehlerfrei
> eingegeben werden sollen.
Der TI-30 war so ein tolles Gerät :)
Bernd
Dirk Ruth
"
>Hallo Elektronik-Gurus,
>
>bei meinem Testaufbau mit einem AtMega32 prellen die Taster deutlich.
>
>Im WWW habe ich verschiedene einfache bis recht komplexe Vorschläge
>gefunden, was man dagegen tun kann.
>
>Was haltet Ihr von "Softwarelösungen"? Der µC wird sich in meiner
>Anwendung sowieso total langweilen, Performance ist also gegeben.
>
Funktioniert sehr gut, wenn es richtig gemacht ist.
>Was wäre eine einfache Lösung als Schaltung?
>
Widerstand und Kondensator. Anstiegs- und Abfallzeiten beachten! Evtl.
Schmittrigger verwenden.
Dirk
ingo....@web.de
> Hallo Elektronik-Gurus,
>
> bei meinem Testaufbau mit einem AtMega32 prellen die Taster deutlich.
> Was w�re eine einfache L�sung als Schaltung?
Taster mit Umschaltkontakten.
*duck*
Ingo
Udo Piechottka
> Widerstand und Kondensator. Anstiegs- und Abfallzeiten beachten! Evtl.
> Schmittrigger verwenden.
Wie sollen R,C und Taster verschaltet sein?
UP
walter
> Hallo Elektronik-Gurus,
>
> bei meinem Testaufbau mit einem AtMega32 prellen die Taster deutlich.
Einfach nur selten genug abfragen, dann kriegst Du das Prellen nicht mit.
Alle 50-100ms reicht immer.
> Im WWW habe ich verschiedene einfache bis recht komplexe Vorschläge
> gefunden, was man dagegen tun kann.
Was wird denn so vorgeschlagen?
> Was haltet Ihr von "Softwarelösungen"? Der µC wird sich in meiner
> Anwendung sowieso total langweilen, Performance ist also gegeben.
>
> Was wäre eine einfache Lösung als Schaltung?
Du hast doch einen Prozessor. Also benutz ihn auch.
Kai-Martin Knaak
>> Widerstand und Kondensator. Anstiegs- und Abfallzeiten beachten! Evtl.
>> Schmittrigger verwenden.
>
> Wie sollen R,C und Taster verschaltet sein?
R,C als Tiefpass hinter dem Taster.
http://de.wikipedia.org/wiki/Tiefpass
Schmitt-Trigger kennt Wikipedia natürlich auch:
http://de.wikipedia.org/wiki/Schmitt-Trigger
---<(kaimartin)>---
Heiko Nocon
>> "Softwarelösungen"?
>Benötigt typisch
>* Speicher, typisch 1 Byte RAM pro Taste ( soweit es keine Matrix ist )
Intelligente Lösungen benötigen zwei Bits pro Taste.
>* eine Zeitsteuerung ( "Tick" ) die dafür sorgt daß die Routine
> alle 1msec oder 100usec durchlaufen wird.
Jepp, eine "Zeitkonstante" in irgendeiner Form braucht man schon, da
führt kein Weg dran vorbei. Das gilt natürlich auch für eine
Hardwarelösung. Bei der Softwarelösung kommt man allerdings mit einer
einzigen "Zeitkonstante" für alle Taster aus und kann diese obendrein
oft mit anderen Anwendungsteilen "sharen".
Display-Mux z.B. paßt oft sehr gut mit Tastaturabfragen zusammen,
teilweise (mit Matrix-Tastaturen) lassen sich sogar Ports sharen und
nicht nur der Timer.
Udo Piechottka
> On Fri, 27 Feb 2009 16:13:22 +0100, Udo Piechottka wrote:
>
>>> Widerstand und Kondensator. Anstiegs- und Abfallzeiten beachten! Evtl.
>>> Schmittrigger verwenden.
>> Wie sollen R,C und Taster verschaltet sein?
>
> R,C als Tiefpass hinter dem Taster.
Der Taster kann ja dann nur plusseitig liegen und über den Widerstand
den Kondensator aufladen. Wer entlädt den Kondensator wieder? Oder
braucht man dafür jetzt eine Umtaster?
UP
walter
> Hallo Elektronik-Gurus,
>
> bei meinem Testaufbau mit einem AtMega32 prellen die Taster deutlich.
>
> Im WWW habe ich verschiedene einfache bis recht komplexe Vorschläge
> gefunden, was man dagegen tun kann.
Die bisherigen Antworten auf Deine Anfrage sind Unsinn. RC-Glied,
komplizierte Software, etc ist alles Unfug.
Ein simpler Taster mit Pull-Up und Abfrage weit seltener als die
Prellzeit reicht immer aus. Kein Taster prellt länger als 50ms und das
ist dann die minimale Zeit zwischen Abfragen. Nimm einfach einen Input-
Port und lies das Bit direkt ein. Tastenmatrix funktioniert ebenfalls
nach dem Prinzip langsam abfragen.
Rafael Deliano
> braucht man dafür jetzt eine Umtaster?
-+- 5V
|
R1
|
+---R2----+---
| |
Switch C1
| |
GND GND
Die Zeitkonstante ist halt etwas unsymmetrisch weil
R1 und der Taster ( 0 Ohm wenn geschaltet ) unterschiedlichen
Widerstand haben.
MfG JRD
Rafael Deliano
> Intelligente Lösungen benötigen zwei Bits pro Taste.
http://www.embeddedFORTH.de/temp/y.pdf
( stammt aus Heft 2 der Zeitschrift, kostenpflichtig )
TASTE# ist die Variable im RAM, THRES ist die Sättigungskonstante <FF
die passend dazu festgelegt wird in welchem zeitlichen Abstand
die Routine durchlaufen wird.
Was manchmal einfacher ist, ist ein Schieberegister TASTE#
das mit 0 oder 1 gefüttert wird, je nach Tasterpegel. Da kann
man dann auf 7F bzw. 80 triggern.
> Bei der Softwarelösung
Die oben dargestellte Lösung ist für eine Zeitsteuerung
der ganzen Applikation wie sie in dem Heft ausführlich dargestellt
ist: die Unterprogramme werden häufig durchlaufen und sie sollen
deshalb kurz sein. Und sie sollen standardisiert und isoliert sein
um die Erstellung der Software zu vereinfachen.
Es hängt also wohl auch von den Randbedingungen ab wie die
Entprellung von Tasten in einer Applikation erfolgt.
MfG JRD
Dirk Ruth
Im einfachsten Fall:
.-.-.-.-.-.-.
|
.
| /|\
. |
| .-.
. | |
| | | .---------.
. '-' | |
___ | | | -- |
.----|___|-----o--------.------o-------+ // |
| | | | -- |
-\--o --- . | |
\ --- | | |
\. | . | |
o | | '---------'
| | .
| | .-.-.-.-.-.-.
=== ===
GND GND
(created by AACircuit v1.28.6 beta 04/19/05 www.tech-chat.de)
Gibt aber verschiedene Möglichkeiten. Hängt davon ab, ob man eher in
Richtung eigensicher, oder Strom sparend usw. gehen möchte.
Dirk
Dirk Ruth
Hängt sicher vom Anwendunsfall ab. Bei 50ms-Abfragen, muss die Taste
schon 100ms gedrückt sein. Für eine Maustaste, oder für jemanden, der
600 Anschläge auf einer Tastatur macht, ist das schon sehr knapp.
Dirk
Rafael Deliano
Da fehlt der Realname.
>> Die bisherigen Antworten auf Deine Anfrage sind Unsinn.
Höflichkeit und Sachverstand korrelieren häufig.
>> Kein Taster prellt länger als 50ms
> Dirk Ruth schrieb:
> Hängt sicher vom Anwendunsfall ab. Bei 50ms-Abfragen, muss die Taste
> schon 100ms gedrückt sein. Für eine Maustaste, oder für jemanden, der
> 600 Anschläge auf einer Tastatur macht, ist das schon sehr knapp.
Ja, hat zwei Macken:
* die von mir im pdf angegebenen Werte
Prellzeit 10msec für typische Taste und 40msec für schlechte Taste
sind Datenblattangaben. Da ist keine Alterung und keine veränderten
Testbedingungen ( andere Andruckkraft, Geschwindigkeit des
Tastendrucks, anderer Winkel ) berücksichtigt. Literaturangaben
zur Dauer Tastendruck sind 100 - 1000msec. D.h. beide Werte variieren
stark und liegen nicht weit auseinander.
* wenn man langsam abtastet hat man entsprechend verzögerte Reaktion auf
Tastendruck was oft unerwünscht ist.
MfG JRD
Michael Schwingen
> * wenn man langsam abtastet hat man entsprechend verzögerte Reaktion auf
> Tastendruck was oft unerwünscht ist.
Wenn man in Software mehrere Taster entprellen will, ist hier:
http://www.ganssle.com/tem/tem112.pdf
eine interessante Lösung angegeben.
cu
Michael
Horst-D.Winzler
Man sollte auch den Querstrom nicht unterschätzen. Eine Mindestgröße
sollte schon eigehalten werden. Datenblatt sollte Auskunft geben.
--
mfg hdw
Heiko Nocon
>Die bisherigen Antworten auf Deine Anfrage sind Unsinn. RC-Glied,
>komplizierte Software, etc ist alles Unfug.
Nein, Unfug ist deine Meinung. Du bist nur schlicht nicht in der Lage,
das Problem abstrakt genug zu sehen. Ein Bastler halt.
>Ein simpler Taster mit Pull-Up und Abfrage weit seltener als die
>Prellzeit reicht immer aus.
Nein, genau das ist nicht der Fall. Der Status eines Tasters allein
nützt nämlich garnix (außer für Sachen wie Reset). Um einen Taster
sinnvoll benutzen zu können, muß man auf ÄNDERUNGEN seines Status
reagieren. Das bedeutet implizit, daß man sich den zuletzt "gesehenen"
Status merken muß, um erkennen zu können, daß sich etwas geändert hat.
Damit ist ein Bit verbraucht. Es mag sein, daß du dieses Bit nicht
explizit in deiner Abfrageroutine untergebracht hast, aber es muß
irgendwo sein. Wenn nicht in der Abfrageroutine, dann in der
eigentlichen Applikation. Die Grundgesetze der Informatik erzwingen das
einfach. Also, falls du es nicht glaubst: Zeig' mir deinen Code, und ich
zeige dir, wo dieses Bit steckt.
Heiko Nocon
> Es hängt also wohl auch von den Randbedingungen ab wie die
>Entprellung von Tasten in einer Applikation erfolgt.
Natürlich.
Es bleibt aber die Tatsache, daß man exakt zwei "Merker"-Bits pro Taste
zwingend benötigt, nicht mehr und nicht weniger. Schlechtere Lösungen
(im Sinne von: Lösungen mit höherem Speicherplatzverbrauch) sind
natürlich immer möglich, bessere hingegen nur dann, wenn man auf
Funktionalität verzichten kann (oder Teilinformationen bereits anderswo
stecken)
Konkret bedeutet der Verzicht auf ein Bit, daß man nur noch einmalig
definiert auf eine Flanke (oder den Pegel danach) reagieren kann, der
Verzicht auf beide Merker bedeutet, daß man nur noch auf den Pegel
reagieren kann. (In diesem Fall steckt z.B. die Information eines der
Merkerbits in der Annahme eines definierten Startpegels).
>Meine "dumme" Lösung sieht so aus:
>http://www.embeddedFORTH.de/temp/y.pdf
Vielleicht solltest du, statt dich in dem total veralteten Forth-Zeugs
zu suhlen (und frecherweise auch noch kommerzielle Werbung zu betreiben)
einfach mal deine Informatik-Grundlagenkenntnisse auffrischen.
Das hilft gelegentlich, Scheuklappen zu entfernen. Übrigens ganz
unabhängig von der verwendeten Programmiersprache, betrifft also mich
selber genauso. Auch ich neige dazu, die Fähigkeiten meiner bevorzugten
Programmiersprachen oder der Zielhardware als primäres Kriterium zu
betrachten, statt das Problem abstrakt zu analysieren und mir erst
hinterher über die Implementierung Gedanken zu machen und die passende
Programmiersprache dafür zu wählen.
Udo Piechottka
Wollte eigentlich nur darauf hinaus, ob der Taster direkt parallel zum
Ko liegen soll.
Udo
Rafael Deliano
> zu suhlen (und frecherweise auch noch kommerzielle Werbung zu betreiben)
Der Hinweis auf weiterführende Information ( die auch kostenpflichtig
sein darf ) war thema- und sachbezogen.
Jeder ist hier im Sinne einer konstruktiven Diskussion
eingeladen andere Varianten konkret, nachvollziehbar
darzustellen ( und da bin ich dank meiner Zeitschrift wohl
im Vorteil weil ich eben Zugriff auf mehr aufgearbeitetes
Material habe ).
MfG JRD
Horst-D.Winzler
> Rafael Deliano schrieb:
>>> Wer entlädt den Kondensator wieder? Oder
>>> braucht man dafür jetzt eine Umtaster?
>>
>> -+- 5V
>> |
>> R1
>> |
>> +---R2----+---
>> | |
>> Switch C1
>> | |
>> GND GND
>>
>> Die Zeitkonstante ist halt etwas unsymmetrisch weil
>> R1 und der Taster ( 0 Ohm wenn geschaltet ) unterschiedlichen
>> Widerstand haben.
>
> Wollte eigentlich nur darauf hinaus, ob der Taster direkt parallel zum
> Ko liegen soll.
>
> Udo
Noch ein Hinweis. Obige Schaltung ist günstig wenn mit HF verseuchter
Umgebung zu rechnen ist.
--
mfg hdw
Michael Eggert
Moin!
>> Ein simpler Taster mit Pull-Up und Abfrage weit seltener als die
>> Prellzeit reicht immer aus.
Zum Entprellen reicht das.
> Nein, genau das ist nicht der Fall. Der Status eines Tasters allein
> nützt nämlich garnix (außer für Sachen wie Reset). Um einen Taster
> sinnvoll benutzen zu können, muß man auf ÄNDERUNGEN seines Status
> reagieren. Das bedeutet implizit, daß man sich den zuletzt "gesehenen"
> Status merken muß, um erkennen zu können, daß sich etwas geändert hat.
Das hat aber nichts mit der Entprellung zu tun, ist schließlich bei
Hardware-Entprellung noch genauso nötig um auf Änderungen zu reagieren.
Gruß,
Michael.
Michael Eggert
Moin!
Besser nicht ohne R2. 100n direkt parallel zu einem Digitast sind ein
zuverlässiger Absturzgenerator.
Gruß,
Michael.
Marte Schwarz
>> Vielleicht solltest du, statt dich in dem total veralteten Forth-Zeugs
>> zu suhlen (und frecherweise auch noch kommerzielle Werbung zu betreiben)
Schierer Neid, nicht Wert, sich darüber aufzuregen
Marte
walter
> walter wrote:
>
>>Die bisherigen Antworten auf Deine Anfrage sind Unsinn. RC-Glied,
>>komplizierte Software, etc ist alles Unfug.
>
> Nein, Unfug ist deine Meinung. Du bist nur schlicht nicht in der Lage,
> das Problem abstrakt genug zu sehen. Ein Bastler halt.
>
>>Ein simpler Taster mit Pull-Up und Abfrage weit seltener als die
>>Prellzeit reicht immer aus.
>
> Nein, genau das ist nicht der Fall. Der Status eines Tasters allein
> nützt nämlich garnix (außer für Sachen wie Reset). Um einen Taster
> sinnvoll benutzen zu können, muß man auf ÄNDERUNGEN seines Status
> reagieren. Das bedeutet implizit, daß man sich den zuletzt "gesehenen"
> Status merken muß, um erkennen zu können, daß sich etwas geändert hat.
Es ging ums Entprellen. Dafür reicht Abfrage alle 100ms aus.
> Damit ist ein Bit verbraucht. Es mag sein, daß du dieses Bit nicht
> explizit in deiner Abfrageroutine untergebracht hast, aber es muß
> irgendwo sein. Wenn nicht in der Abfrageroutine, dann in der
> eigentlichen Applikation. Die Grundgesetze der Informatik erzwingen das
> einfach. Also, falls du es nicht glaubst: Zeig' mir deinen Code, und ich
> zeige dir, wo dieses Bit steckt.
Na klar muß die Software den letzten Status halten um auf die positive
oder negative Flanke zu reagieren. Das ist ein Bit pro Taster.
OK?
walter
> walterschrieb:
>>Ein simpler Taster mit Pull-Up und Abfrage weit seltener als die
>>Prellzeit reicht immer aus. Kein Taster prellt länger als 50ms und das
>>ist dann die minimale Zeit zwischen Abfragen. Nimm einfach einen Input-
>>Port und lies das Bit direkt ein. Tastenmatrix funktioniert ebenfalls
>>nach dem Prinzip langsam abfragen.
>
>
> Hängt sicher vom Anwendunsfall ab. Bei 50ms-Abfragen, muss die Taste
> schon 100ms gedrückt sein. Für eine Maustaste, oder für jemanden, der
> 600 Anschläge auf einer Tastatur macht, ist das schon sehr knapp.
Bei 50ms Abfrage reichen 50ms+Prellzeit um den Tastendruck sicher zu
erkennen. Für manuelle Betätigung sollte das immer schnell genug sein.
Gibts Menschen, die eine Taste schneller drücken können?
Bei 600 Anschlägen pro Minute muß sowieso N-Key-Rollover implementiert
werden - da fließen die einzelnen Tastendrücke ineinander über. Probiers
mal an Deiner Tastatur aus. Ohne Rollover sind 600 APM nicht machbar.
Dirk Ruth
Das hat mit Rollover erstmal nichts zu tun.
Wie ich gelesen habe, kann man wohl 1200 Anschläge pro Minute - also
20 pro Sekunde schaffen. Nehmen wir mal eine Matrix von 12x8 für eine
Tastatur (weiß jetzt nicht, ob es 12x8 ist), dann müssen die
Spalten(8) also mindestens alle 4ms eingelesen, und jeweils eine
andere Reihe(12) aktiviert werden. 2ms (2ms + Prellzeit) ist schon
eine sehr kleine Prellzeit und es mag vielleicht auch sein, dass
solche "Weltmeister-Tastaturen" von besonders guter Qualität sind, es
zeigt aber, dass die Aussage - man müsse nur die Scan-Intervalle
genügend lang machen - so nicht allgemeingültig sein kann.
Dirk
Hergen Lehmann
> zeigt aber, dass die Aussage - man müsse nur die Scan-Intervalle
> genügend lang machen - so nicht allgemeingültig sein kann.
In 95% der Fälle ist das Konzept "ausreichend grosses Scan-Intervall"
vollkommen ausreichend. In einem typischen, Microcontroller-gesteuerten
Gerät muss man weder mit 1000 Anschlägen pro Minute rechnen, noch treten
übermässig grosse Tastenmatrizen auf. Kritisch kann allenfalls die
Alterung werden, wenn man bei der Qualität der Tasten allzu geizig war.
Bei den wenigen Sonderfällen kann man dann ja immer noch mehr
Gehirnschmalz bzw. Speicherplatz investieren, Software ist geduldig...
Hergen
Frank Buss
> Na klar muß die Software den letzten Status halten um auf die positive
> oder negative Flanke zu reagieren. Das ist ein Bit pro Taster.
Kommt auf die Anwendung drauf an. Nehmen wir an, ich wollte einen Motor
ansteuern und zwar genau dann, wenn eine Taste gedrückt gehalten wird. Dann
reicht es, die Taste z.B. alle 200 ms abzufragen und dann die Abfrage des
Pins direkt an den Motorsteuerungspin auszugeben. Dadurch würde man
vermeiden, daß ein Prellen den Motor schnell hintereinander an-/auschaltet.
Dafür wäre dann keine Flankendetektierung notwendig und auch kein
Status-Bit notwendig, nur ein Ausgabe-Bit :-)
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Lutz Schulze
>> Na klar muß die Software den letzten Status halten um auf die positive
>> oder negative Flanke zu reagieren. Das ist ein Bit pro Taster.
>
> Kommt auf die Anwendung drauf an. Nehmen wir an, ich wollte einen Motor
> ansteuern und zwar genau dann, wenn eine Taste gedrückt gehalten wird. Dann
> reicht es, die Taste z.B. alle 200 ms abzufragen und dann die Abfrage des
> Pins direkt an den Motorsteuerungspin auszugeben. Dadurch würde man
> vermeiden, daß ein Prellen den Motor schnell hintereinander an-/auschaltet.
> Dafür wäre dann keine Flankendetektierung notwendig und auch kein
> Status-Bit notwendig, nur ein Ausgabe-Bit :-)
Mit etwas mehr Aufwand kann man aber auch das prellen analysieren und
regelmässig den Verschleiss der Taster protokollieren ;-)
Lutz
--
Mit unseren Sensoren ist der Administrator informiert, bevor es Probleme im
Serverraum gibt: preiswerte Monitoring Hard- und Software-kostenloses Plugin
auch für Nagios - Nachricht per e-mail,SMS und SNMP: http://www.messpc.de
Neu: Ethernetbox jetzt auch im 19 Zoll Gehäuse mit 12 Ports für Sensoren
walter
> walter wrote:
>
>> Na klar muß die Software den letzten Status halten um auf die positive
>> oder negative Flanke zu reagieren. Das ist ein Bit pro Taster.
>
> Kommt auf die Anwendung drauf an. Nehmen wir an, ich wollte einen Motor
> ansteuern und zwar genau dann, wenn eine Taste gedrückt gehalten wird.
> Dann reicht es, die Taste z.B. alle 200 ms abzufragen und dann die
> Abfrage des Pins direkt an den Motorsteuerungspin auszugeben. Dadurch
> würde man vermeiden, daß ein Prellen den Motor schnell hintereinander
> an-/auschaltet. Dafür wäre dann keine Flankendetektierung notwendig und
> auch kein Status-Bit notwendig, nur ein Ausgabe-Bit :-)
Ist ja gut. Da ich nicht weiß was der OP mit seiner Taste machen will hab
ich auch keinen Vorschlag zur weiteren Verarbeitung gemacht. Zum
Entprellen reichts jedenfalls und mehr ist dafür auch nicht nötig.
walter
> walterschrieb:
> "
>>On Fri, 27 Feb 2009 19:37:27 +0100, Dirk Ruth wrote:
>>
>>> walterschrieb:
>>>>Ein simpler Taster mit Pull-Up und Abfrage weit seltener als die
>>> Hängt sicher vom Anwendunsfall ab. Bei 50ms-Abfragen, muss die Taste
>>> schon 100ms gedrückt sein. Für eine Maustaste, oder für jemanden, der
>>> 600 Anschläge auf einer Tastatur macht, ist das schon sehr knapp.
>>
>>Bei 50ms Abfrage reichen 50ms+Prellzeit um den Tastendruck sicher zu
>>erkennen. Für manuelle Betätigung sollte das immer schnell genug sein.
>>Gibts Menschen, die eine Taste schneller drücken können?
>>
>>Bei 600 Anschlägen pro Minute muß sowieso N-Key-Rollover implementiert
>>werden - da fließen die einzelnen Tastendrücke ineinander über. Probiers
>>mal an Deiner Tastatur aus. Ohne Rollover sind 600 APM nicht machbar.
>
>
> Das hat mit Rollover erstmal nichts zu tun. Wie ich gelesen habe, kann
> man wohl 1200 Anschläge pro Minute - also 20 pro Sekunde schaffen.
> Dirk
Na klar hat das mit Rollover zu tun. Die einzelne Taste ist auch bei 1200
Anschlägen pro Minute längere Zeit gedrückt.
Im Übrigen war die Frage des OP nach dem Entprellen einer einzelnen
Taste. Abfrage mit Zykluszeit größer als der maximalen Prellzeit löst
dieses Problem zuverlässig.
Johannes Bauer
> Es bleibt aber die Tatsache, daß man exakt zwei "Merker"-Bits pro Taste
> zwingend benötigt, nicht mehr und nicht weniger. Schlechtere Lösungen
> (im Sinne von: Lösungen mit höherem Speicherplatzverbrauch) sind
> natürlich immer möglich, bessere hingegen nur dann, wenn man auf
> Funktionalität verzichten kann (oder Teilinformationen bereits anderswo
> stecken)
Ahja, das Kriterium für Optimum ist also laut dir einzig und alleine der
RAM-Verbrauch. Über den Mehrverbrauch im ROM, den deine Lösung
sicherlich mitbringen würde, schweigst du dich aus.
>> Meine "dumme" Lösung sieht so aus:
>> http://www.embeddedFORTH.de/temp/y.pdf
>
> Vielleicht solltest du, statt dich in dem total veralteten Forth-Zeugs
> zu suhlen (und frecherweise auch noch kommerzielle Werbung zu betreiben)
> einfach mal deine Informatik-Grundlagenkenntnisse auffrischen.
Wenn du Informatik-Grundkenntnisse besitzen würdest, wäre dir der
Begriff der Pareto-Optimalität ein Begriff. Dann hättest du auch die
Klappe gehalten statt hier so großkotzig rumzukläffen.
Viele Grüße,
Johannes
--
"Meine Gegenklage gegen dich lautet dann auf bewusste Verlogenheit,
verlästerung von Gott, Bibel und mir und bewusster Blasphemie."
-- Prophet und Visionär Hans Joss aka HJP in de.sci.physik
<48d8bf1d$0$7510$5402...@news.sunrise.ch>
Raimund Nisius
> Dirk Ruth wrote:
> > zeigt aber, dass die Aussage - man müsse nur die Scan-Intervalle
> > genügend lang machen - so nicht allgemeingültig sein kann.
>
> In 95% der Fälle ist das Konzept "ausreichend grosses Scan-Intervall"
> vollkommen ausreichend. In einem typischen, Microcontroller-gesteuerten
> Gerät muss man weder mit 1000 Anschlägen pro Minute rechnen, noch treten
> übermässig grosse Tastenmatrizen auf. Kritisch kann allenfalls die
> Alterung werden, wenn man bei der Qualität der Tasten allzu geizig war.
Das dachte ich auch. Kleines Prüftool mit genau 1 Taste. Die Prüfung
dauert viele Sekunden und braucht bloß einen Trigger. Wenn aber dem
Prüfling eine bestimmte Komponente fehlt bekomme ich gleich 5 bis 10
fehlgeschlagene Tests auf einen Tastendruck. Das macht sich im Logfile
nicht gut.
> Bei den wenigen Sonderfällen kann man dann ja immer noch mehr
> Gehirnschmalz bzw. Speicherplatz investieren, Software ist geduldig...
Wenn der Platz schon für so elementare Software zu knapp ist, hat man
die falsche Hardware ausgesucht. Gegen Ende der Entwicklung, wenn das
schon mal vorgeführt wird, fressen die Begehrlichkeiten des Kunden viel
mehr Speicherplatz.
Vor 20 Jahren war Speicherplatz noch ein ernstes Thema. Heute muß das
nicht sein.
--
Gruß, Raimund
Mein Pfotoalbum <http://www.raimund.in-berlin.de>
Mail ohne Anhang an <Reply-To:> wird gelesen. Im Impressum der Homepage
findet sich immer eine länger gültige Adresse.
Michael Eggert
Moin!
>>> Bei 600 Anschlägen pro Minute muß sowieso N-Key-Rollover implementiert
>>> werden - da fließen die einzelnen Tastendrücke ineinander über. Probiers
>>> mal an Deiner Tastatur aus. Ohne Rollover sind 600 APM nicht machbar.
>>
>>
>> Das hat mit Rollover erstmal nichts zu tun. Wie ich gelesen habe, kann
>> man wohl 1200 Anschläge pro Minute - also 20 pro Sekunde schaffen.
>> Dirk
> Na klar hat das mit Rollover zu tun. Die einzelne Taste ist auch bei 1200
> Anschlägen pro Minute längere Zeit gedrückt.
Trotzdem muss man natürlich oft genug abfragen, um entscheiden zu
können, welche Taste zuerst gedrückt wurde. Und bei im Schnitt 20
Anschlägen pro Sekunde - also im Mittel alle 50ms einer - dürften auch
teilweise welche in nur 20ms oder weniger aufeinander folgen.
Gruß,
Micahel.
Thomas Kindler
>
> Thomas Kindler schrieb:
>
>> Ich hab' noch nie Verstanden, warum die Leute überhaupt aufwändige
>> Entprell-Lösungen basteln..
>>
>> Wenn man die Taster in einem vernünftigen Zeitabstand (z.B. alle 50ms im
>> Timer-Interrupt) abfragt, kann man den Zustand direkt verarbeiten, ohne
>> irgendwelche Probleme zu haben. Schneller kann man einen Taster ohnehin
>> nicht betätigen, und 50ms sind noch keine merkbare Verzögerung..
>
> Hallo,
>
> und wenn man sich so etliche Geräte anschaut die mit Software die Tasten
> entprellen und die dann nach einiger Zeit doch prellen weil die Kontakte
> korrodiert und schon etwas abgenutzt sind [..]
Gab es nicht mal selbstreinigende Taster, bei denen ein mindeststrom im
Datenblatt stand?! AFAIR sorgte ein kleiner Kondensator parallel zum
Taster für's freibrennen von Ablagerungen..
--
Thomas Kindler <ma...@t-kindler.de>
Gerrit Heitsch
> Hans-Paul Hoppel wrote:
>
>> Was haltet Ihr von "Softwarelösungen"? Der µC wird sich in meiner
>
> Wenn sowieso schon ein Microcontroller vorhanden ist, spricht praktisch
> NICHTS für eine Hardwarelösung...
Wobei die bei den Platinen von Pollin aus genau einem Widerstand und
einen Kondensator besteht. Warum sich einen mit der Software abbrechen
wenn es die Hardware auch kann? Setzt natuerlich Einzeltasten voraus.
Gerrit
Gerrit Heitsch
> Dirk Ruth schrieb:
>> Widerstand und Kondensator. Anstiegs- und Abfallzeiten beachten! Evtl.
>> Schmittrigger verwenden.
>
> Wie sollen R,C und Taster verschaltet sein?
Bei der Eval-Platine von Pollin:
- Taster zwischen Vcc und Eingang
- Widerstand (33KOhm) und Kondensator (330nF) parallel
zwischen Eingang und GND.
Funktioniert, bei meinen Experimenten benutze ich keine Entprellung in
Software.
Gerrit
MaWin
news:gobt30$7gl$4...@news.bawue.net...
>
> Funktioniert, bei meinen Experimenten benutze ich keine Entprellung in
> Software.
Funktioniert nur gut, wenn der Digitaleingang eine Schmitt-Trigger Funktion
hat, und der Taster wird dem Kurzschlusstrom des Kondensators ausgesetzt,
das kann ein Vorteil sein (brennt Oxidation weg) oder ein Nachteil (rauht die
Oberflaeche auf, die korridiert leichter, irgendwann dann kein Kontakt mehr),
muss man Tasterhersteller fragen.
Alles zur richtigen Entprellung in
de.sci.electronics FAQ: http://dse-faq.elektronik-kompendium.de/
F.29.1. Entprellen von Tastern
--
Manfred Winterhoff, reply-to invalid, use mawin at gmx dot net
homepage: http://www.geocities.com/mwinterhoff/
Read 'Art of Electronics' Horowitz/Hill before you ask.
Lese 'Hohe Schule der Elektronik 1+2' bevor du fragst.
Gerrit Heitsch
>
> Vor 20 Jahren war Speicherplatz noch ein ernstes Thema. Heute muß das
> nicht sein.
Trotzdem sollte man in Hardware erledigen was in Hardware mit kleinem
Aufwand zu machen ist. Entprellung gehoert dazu.
Gerrit
Lutz Schulze
>> Vor 20 Jahren war Speicherplatz noch ein ernstes Thema. Heute muß das
>> nicht sein.
>
> Trotzdem sollte man in Hardware erledigen was in Hardware mit kleinem
> Aufwand zu machen ist. Entprellung gehoert dazu.
Das sehe ich nicht unbedingt so. Die schnellen Flankenwechsel schaden dem MC
ja nicht, das kann man IMHO ebensogut in Software erledigen und ist damit
auch noch flexibler.
Gerrit Heitsch
> Am Sat, 28 Feb 2009 18:52:43 +0100 schrieb Gerrit Heitsch:
>
>>> Vor 20 Jahren war Speicherplatz noch ein ernstes Thema. Heute muß das
>>> nicht sein.
>> Trotzdem sollte man in Hardware erledigen was in Hardware mit kleinem
>> Aufwand zu machen ist. Entprellung gehoert dazu.
>
> Das sehe ich nicht unbedingt so. Die schnellen Flankenwechsel schaden dem MC
> ja nicht, das kann man IMHO ebensogut in Software erledigen und ist damit
> auch noch flexibler.
Mit dem gleichen Argument koennte man sich den Multiplikator in Hardware
sparen. Eine Sequenz von ADD in einer Schleife tuts schliesslich auch.
Ebenso den UART oder SPI, geht alles in Software wenn man will.
Gerrit
Lutz Schulze
>>> Trotzdem sollte man in Hardware erledigen was in Hardware mit kleinem
>>> Aufwand zu machen ist. Entprellung gehoert dazu.
>>
>> Das sehe ich nicht unbedingt so. Die schnellen Flankenwechsel schaden dem MC
>> ja nicht, das kann man IMHO ebensogut in Software erledigen und ist damit
>> auch noch flexibler.
>
> Mit dem gleichen Argument koennte man sich den Multiplikator in Hardware
> sparen. Eine Sequenz von ADD in einer Schleife tuts schliesslich auch.
> Ebenso den UART oder SPI, geht alles in Software wenn man will.
Das ist dann schon ein wenig komplexer, wie immer sollte die Lösung zum
Problem passen.
Ich kenne auch Controller mit internem UART oder SPI (da scheint Harware in
der Tat einige Vorteile zu haben), Tastenentprellung in Hardware wurde
ausser dem in der Nähe anzusiedelnden Schmitt Trigger meines Wissens bisher
nicht angeboten.
Raimund Nisius
Der kleine HW-Aufwand besteht aus 2 bis 3 Bauteilen, Leiterplattenplatz,
Testpunkten, Logistik.
Der Softwareaufwand besteht aus 1 oder 2 boolschen Variablen und 1
Nobrain- Task im Scheduler, also ein paar (µm)^2 auf einem Chip, der
sowieso verbaut wird.
Gerrit Heitsch
> Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>
>> Raimund Nisius wrote:
>>> Vor 20 Jahren war Speicherplatz noch ein ernstes Thema. Heute muß das
>>> nicht sein.
>> Trotzdem sollte man in Hardware erledigen was in Hardware mit kleinem
>> Aufwand zu machen ist. Entprellung gehoert dazu.
>
> Der kleine HW-Aufwand besteht aus 2 bis 3 Bauteilen, Leiterplattenplatz,
> Testpunkten, Logistik.
>
> Der Softwareaufwand besteht aus 1 oder 2 boolschen Variablen und 1
> Nobrain- Task im Scheduler, also ein paar (µm)^2 auf einem Chip, der
> sowieso verbaut wird.
Ja... und irgendwie einem Test der garantiert, dass diese
Software-Entprellung auch nach Alterung des Tasters noch problemlos
funktioniert. Mein Radiowecker ist von 1984, seit ein paar Jahren
prellen die Tasten dann doch wieder, ist ziemlich laestig.
Gerrit
Frank Buss
> Ja... und irgendwie einem Test der garantiert, dass diese
> Software-Entprellung auch nach Alterung des Tasters noch problemlos
> funktioniert. Mein Radiowecker ist von 1984, seit ein paar Jahren
> prellen die Tasten dann doch wieder, ist ziemlich laestig.
da wäre aber zumindest die Hardware-Lösung nicht im Vorteil, da die genauso
prellen würde, wenn die Tasten altern. In Software könnte man das sogar
noch mit berücksichtigen, sodaß man die Tasten nur länger drücken müsste.
Oder den Pin mal kurz auf Ausgang schalten und die Kontakte freibrennen :-)
Raimund Nisius
20 Jahre Haltbarkeit ist für Konsumartikel viel zu viel...
Und hart entprellt würde heute noch funktionieren? Nicht zwangsläufig,
oder?
Gerrit Heitsch
> Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>
>> Raimund Nisius wrote:
>>> Gerrit Heitsch <ger...@laosinh.s.bawue.de> wrote:
>>>
>>>> Raimund Nisius wrote:
>>>>> Vor 20 Jahren war Speicherplatz noch ein ernstes Thema. Heute muß das
>>>>> nicht sein.
>>>> Trotzdem sollte man in Hardware erledigen was in Hardware mit kleinem
>>>> Aufwand zu machen ist. Entprellung gehoert dazu.
>>> Der kleine HW-Aufwand besteht aus 2 bis 3 Bauteilen, Leiterplattenplatz,
>>> Testpunkten, Logistik.
>>>
>>> Der Softwareaufwand besteht aus 1 oder 2 boolschen Variablen und 1
>>> Nobrain- Task im Scheduler, also ein paar (µm)^2 auf einem Chip, der
>>> sowieso verbaut wird.
>> Ja... und irgendwie einem Test der garantiert, dass diese
>> Software-Entprellung auch nach Alterung des Tasters noch problemlos
>> funktioniert. Mein Radiowecker ist von 1984, seit ein paar Jahren
>> prellen die Tasten dann doch wieder, ist ziemlich laestig.
>
> 20 Jahre Haltbarkeit ist für Konsumartikel viel zu viel...
Bei einem Geraet ohne bewegliche Teile sollte das kein Problem sein.
Roehrenradios hielten teilweise laenger.
Die Tastatur auf der ich das hier tippe duerfte Softwareentprellung
benutzen und ist seit 1996 in Gebrauch. Koennte also gehen, so man will
und passend programmiert. Cherry tat das damals wohl.
> Und hart entprellt würde heute noch funktionieren? Nicht zwangsläufig,
> oder?
Grob ueberdimensionieren oder die Standard-Loesung mit 2 NAND-Gattern
verwenden. Da sehe ich nicht, wie das durch Alterung driften koennte.
Bedingt allerdings einen Wechsel-Taster.
Gerrit
Hans-Paul Hoppel
> Trotzdem sollte man in Hardware erledigen was in Hardware mit kleinem
> Aufwand zu machen ist. Entprellung gehoert dazu.
Als jemand, der sich im Programmieren durchaus auskennt, wenn auch nicht in
der "Fachrichtung" µC, experimentiere ich definitive lieber mit Software
als mit Hardware. Da kann ich einfach weniger Scheiße bauen.
HaPa
Joerg
Das hatten diese Jungs auch mal gedacht:
http://en.wikipedia.org/wiki/Therac-25
--
Gruesse, Joerg
http://www.analogconsultants.com/
"gmail" domain blocked because of excessive spam.
Use another domain or send PM.
Raimund Nisius
Nur, wenn das Softwareprodukt für nichts teures nütze ist.
Experimentiere doch mal im SAP eines größeren Konzerns. Etwa so, daß
Versandkosten als Einnahme gebucht werden wobei das erst bei der
Wirtschaftsprüfung im nächsten Jahr auffallen wird..
Oder mit der Steuerung einer richtigen Hardware. Eine kleine
unscheinbare Koordinate auf Null zu setzen hat meinen Arbeitgeber im
Januar locker 4-stellig gekostet. Angenehmer Nebeneffekt: Das dem
"Softwareexperiment" zu Grunde liegende Problem konnte bei der
Schadenbehebung gleich richtig mitgelöst werden. Sonst wäre da bloß
wieder einmal rumgepfuscht worden.
S.Urban
> Oder mit der Steuerung einer richtigen Hardware. Eine kleine
> unscheinbare Koordinate auf Null zu setzen hat meinen Arbeitgeber im
> Januar locker 4-stellig gekostet.
Oder den falschen Pin als "Output Push-Pull" zu deklarieren. Hat aus
einem 10 kEUR-Muster einen netten Briefbeschwerer gemacht...
--
Gruesse
Stephan
Ralph A. Schmid, dk5ras
>Als jemand, der sich im Programmieren durchaus auskennt, wenn auch nicht in
>der "Fachrichtung" µC, experimentiere ich definitive lieber mit Software
>als mit Hardware. Da kann ich einfach weniger Scheiße bauen.
Und bei mir als hardware-Spezi ist das genau umgekehrt :-)
-ras
--
Ralph A. Schmid
http://www.dk5ras.de/ http://www.db0fue.de/
http://www.bclog.de/