Hallo, ich bin gerade mit einer Studienarbeit beschäftigt und wollte mehrere Entprellmethoden aufzeigen. Um das Prellen für jedermann sichtbar zu machen, wollte ich dies einmal simulieren, um ein anschauliches Diagramm zu bekommen. Ebenso wollte ich dann ein Diagramm mit Entprelltem Taster erstellen, sozusagen als Gegenüberstellung. Wie mache ich das am Besten? Hat das schon jemand gemacht? Vielen Dank für eure Hilfe. Viele Grüße Jörg
Taster + Widerstand + Speicheroszi damit kannste das Prellen gut sichtbar machen
Ich meinte eher jetzt die Simulation am Rechner. Denn ein Speicheroszi steht mir nicht zu Verfügung.
Nun, in erster Näherung ist das Prellen ja auf den elastischen Stoß zwei Körper (nämlich der Kontakte) zurückzuführen. Mal nach "elastischem Stoß" gurgeln. Dann kommt noch die Feder hinzu, welche die beiden Kontakte gegeneinander drückt. Ich sage in erster Näherung, weil ich nicht der Meinung bin das Problem gründlich durchdacht zu haben. Also ohne Gewähr für Vollständigkeit. :-} Kurz und gut. Ein mechanisches Modell ist gefragt. Ich meine allerdings hier schon einmal ein Oszillogramm eines Kontaktprellens gesehen zu haben. Weiss aber leider nicht mehr wo.
>Denn ein Speicheroszi steht mir nicht zu Verfügung.
Nimm es mit deiner Soundkarte auf.
Prellen von Tastern ist nicht sonderlich hochfrequent ;)
Dass ich z.B. in LTSPice oder ähnlichem ein Model erstelle, womit ich den Kurvenverlauf eines prellenden Tasters erzeugen kann.
Vielleicht mit nem Zähler? Bei Taste Up -> Down läuft er mit einer bestimmten Taktfrequenz (z. B. T = 5 µs) los: 0, 1, 2, ..., 1000. Bei Taste Down -> Up wird er umgekehrt auf 1000 gesetzt und zählt auf 0 runter. Regeln: (1) Begrenzung auf 0 und 1000. (2) Bei 0 ist der Ausgang immer L. (3) Bei 1000 immer H. (4) Für dazwischenliegende Werte lässt Du den Ausgangspegel ein paar mal wechseln (je nach Geschmack nach festem oder zufalls-mitbestimmtem Muster).
Angehängte Dateien:
-
Tastenprellen.JPG
92 KB
Es gibt Leute, die haben Probleme, die gibt's gar nicht. Wie will man etwas simulieren, dass rein stochstisch ist und wie Hmm richtig schreibt, nur von den mechanischen Eigenschften abhängig ist? Ich habe vor langer Zeit mal das Prellen aufgenommen. Verwendet habe ich Digitasten die als besonders prellarm gelten!!! Die Bilder sahen natürlich bei jedem Druck auf die Taste anders aus. Ein Schließer- kontakt prellt aber deutlich stärker als ein Öffner.
Ich stand vor dem ähnlichen Problem, einen 40193-Zähler als Bereichsschalter für einen Messverstärker mit Tasten anzusteuern, was eigentlich kein Problem sein sollte, da der 40193 über zwei separate Eingänge (count up & count down) verfügt, und nicht über einen up/down- und einen Clock-Eingang, was aber dadurch erschwert wird, dass bei der steigenden Flanke gezählt wird, wenn der jeweils andere Eingang auf high liegt, was bedeutet, dass man zum Zählen einen negativen Impuls braucht, wenn sich die Eingabe nicht ähnlich unintuitiv "anfühlen" soll, wie ein GUI-Button, der erst beim Loslassen auslöst. Es braucht also einen Tiefpass für das Entprellen und einen Hochpass für die Impulsformung. Bei der Berechnung desselbigen bin ich dann an meine Dilletanten-Grenzen gestoßen: Die Spannung an einem RC-Tiefpass zu einem bestimmten Zeitpunkt zu berechnen hätte ich noch hin bekommen, aber wenn (ohne Impedanzwandler dazwischen) ein RC-Hochpass dazu kommt, der den Tiefpass beeinflusst, bin ich erst mal hilflos. Also hatte ich das ganze in LTSpice simuliert und stieß dabei bald auf das Problem der Simulation eines prellenden Tasters. Dadurch bin ich dann auf diesen Thread gestoßen. Ich habe sogar versucht, aus den Grafiken von Ganymed händisch pwl-Dateien zu erstellen, aber das Ergebnis war nicht dem Aufwand entsprechend, also unbefriedigend. Konsequenterweise musste eine Schaltung her, mit der man die Ein/Aus-Sequenzen eines Tastendrucks aufzeichnen und über RS-232 als Zeit/Spannung-Paare ausgeben kann, und hier bietet sich ein µC an, in diesem Fall ein ATmega8, da der schon in meinem Eval-Borad steckt. Ich habe 3 Strategien implementiert und getestet: 1.: Taster an ICP1 (PB0) anschließen Bei jedem TIM1_CAPT-Ereignis den Timestamp in ICR1H:ICR1L in der Tabelle ablegen und die Flankenrichtung wechseln, wie im Handbuch ATmega8 auf Seite 84 beschrieben. Nachteil: Wenn einem Einschaltvorgang ein Auschaltvorgang folgt, bevor die Interrupt-Routine die Flankenrichtung gewechselt hat, wird dieser Ausschaltvorgang und der darauf folgende Einschaltvorgang verschluckt, und erst der wiederum darauf folgende Ausschaltvorgang registriert. Bei Tests war es in einem Fall so, dass der verschluckte Schaltvorgang der letzte beim Einschalten war, und so der Zeitraum, den die Taste gedrückt war, als ausgeschaltet protokolliert wurde. 2.: Taster an INT0 (PD2) anschließen Hier wird durch jeden Ein- und Auschaltvorgang ein Interrupt ausgelöst, ohne dass die Flankenrichtung gewechselt werden muss. Wenn hier einem Einschaltvorgang ein Auschaltvorgang folgt, bevor die Interrupt-Routine die Flankenrichtung gewechselt hat, wird zwar dieser Ausschaltvorgang nicht bemerkt, aber der darauf folgende Einschaltvorgang. Nachteile: - Der letzte Wert muss gemerkt werden, da z.B. zwei Einschaltvorgänge hintereinander folgen können. - Die Timestamps sind um ein paar Takte verschoben, da die Routine nicht auf ICR1H:ICR1L zurückgreifen kann, sondern den aktuellen Wert aus dem TCNT1H:TCNT1L lesen muss. 3. Keine Interrupts bei Flankenwechsel, sondern eine Schleife, die über den Messzeitraum wiederholt einen Eingang abfragt, und Änderungen protokolliert. Da der µC sonst nichts zu tun hat,diese Option (trotz der tollen Interrupt-Möglichkeiten) plausibel. Die 3. Strategie hat den Output mit den meisten Ein- und Ausschaltvorgängen produziert. Die anderen Strategien können auch getestet werden, indem die Zeile ".equ TASTENAUFNAHME_ALG = 3" entsprechend geändert wird. Das Programm ist etwas umständlich (z.B. dass nach der Messung, für die etwas 1 Sekunde zur Verfügung steht, noch ein "a" eingegeben werden muss, um die Ausgabe zu generieren) und lässt sich bestimmt noch verschönern, z.B. indem in die Ausgabe noch ein paar CR/LFs gepackt werden, aber es soll ja erst mal nur funktionieren. Die Datei serial.inc.asm ist noch nicht fertig entwickelt, aber ich bin ja auch noch Anfänger und mein Werkzeugkasten ist noch rudumentär. Ich habe als Beispiel auch meine Spice-Datei und ein paar Probe-Tastenklicks dazu gepackt. Ich hoffe, dass es vielleicht mal jemandem weiter hilft, der ein ähnliches Problem hat. :-)
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.