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
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.
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.
> 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).
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
> 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).
@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
@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
"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
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.
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
> 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. ...
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...
>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.
> 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).
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...
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).
> 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.
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.
Der Nachteil bei softwaremäßigem Entprellen ist halt einfach das es Zeit braucht ... Rechenzeit ...
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!
> > 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).
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.
> 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. ...
@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
@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
>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
@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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.