Zustandsabhängige Logik

Hallo zusammen,

ich bin noch relativer Neuling was Programmierung angeht, daher hier meine Frage, die sicher nicht sehr schwer zu beantworten sein sollte:

Ich habe ein Programm was über den debounce Befehl einen Tastereingang abfragt. Wenn der Taster gedrückt wird und die Prellzeit vorbei ist, wird also die fallende Flanke des Signals erkannt und ein Sub aufgerufen.

Nun möchte ich aber zusätzliche Sicherheit einbringen, und in dem Sub zuerst noch mal den Zustand des Tasters abfragen lassen: Das Programm soll den Zustand des Eingangs für 20ms prüfen, und erst wenn wirklich während dieser 20ms dauerhaft ein Tastendruck erkannt wurde, das Sub ausführen. Sollte der Eingang während dieser 20ms noch mal seinen Zustand wechseln, soll das Programm wieder in die Hauptschleife zurückkehren und das Sub nicht ausführen.

Wie kann ich das in Code umsetzen?

Danke für eure Tips

Einfach die Debounce Zeit um 20ms verlängern.
Sicherer geht es nicht.

Gruß Rolf

Hi rolf,

Nein, das ist nicht mein Problem. Es geht darum, dass ich in meiner Schaltung noch gelegentlich Störungen eingekoppelt bekomme. Wenn die Frequenz stimmt, dann wird der Debounce Befehl überlistet, weil immer im Augenblick der Eingangsabfrage ein Signal erkannt wird. Ich möchte daher noch eine Zustandsabfrage integrieren, die überprüft, ob das Signal auch tatsächlich für eine längere Dauer (20ms) anliegt, und nicht nur zwei kurze Spitzen das Sub ausgelöst haben.

genau dafür gibts den debounce

config debounce ist da das Stichwort

Hi,

nein, ich erklärs nochmal: Stellt euch vor mein Eingangssignal inklusive Störimpulse (damit meine ich nicht das Prellen des Tasters, sondern wirklich störimpulse) sieht aus wie ein Rechtecksignal mit einer Pulsweite von 1% - Der Controller bekommt die erste Flanke und startet den debounce, fragt 20ms später wieder ab und trifft zufällig wieder eine Spitze die eingekoppelt wurde - dann führt er das Sub aus obwohl der Taster nicht gedrückt wurde.

so krasse Störungen kannste z.B. auf n hoch- runter- Zähler
ausfiltern, aber sinnvoll währs auf alle Fälle
mal die Leitungen unter die Lupe zu nehmen bzw. den Schaltplan
zu überarbeiten. Da sind bestimmt n paar Mängel drin.

Die Idee, in der Sub nochmals zu prüfen, ob das Signal auch korrekt war, geht mir programmiertechnisch irgendwie ganz und gar gegen den Strich.

Jede Sub oder Funktion sollte allein ihre Aufgaben bewerkstelligen können. Wenn man da Aufgaben verschiebt und unsauber teilt, gibts später einen Code, den keiner mehr verstehen und bearbeiten kann. Grade wenn später Fehler auftreten, kann man beim Dezentralisieren von gleichen Aufgaben nicht mehr lokalisieren, wo der Fehler stecken könnte.

Ein erster Schritt wäre, die Leitungen und Schaltung zu überprüfen und ggf. zu verbessern.

Falls das nichts bringt, ist die Tastaturabfrage vielleicht dahingehend zu verbessern, das ein Tastendruck z.B 100ms lang verfolgt wird, ob er auch die ganzen 100ms lang vorliegt, und dann erst die Sub ausgeführt wird.

Gruß & *Daumendrück* MeckPommER

Hi zusammen,

ich geb euch vollkommen Recht mit der Ansicht, dass man derartige Störungen Hardwareseitig eliminieren sollte. Das verfolge ich auch noch parallel. Das Problem ist nur, dass ich um das ganze zu testen immer ca. 160 km weit fahren muss (die Anwendung muss auf ner Rennstrecke getestet werden, und die hab ich leider nich vor meiner haustür ^^). Deswegen wollt ich für die nächste Testfahrt alle Register ziehen. Was MeckPommER sagt trifft den Punkt doch schon mal ganz gut: Tastendruck soll 100ms lang verfolgt werden und dann erst das Sub ausgeführt - genau das meine ich ja - bloß wie setze ich das jetzt in Code um (-> wie gesagt, Anfänger in Bascom)

Hallo,

das könnte man zum Beispiel so machen:

Code:

---


Taste alias PIND.0 'oder ähnlich

dim TCounter as byte

Do 'Hauptschleife
If Taste = 0 Then Call Tastendruck
'....
loop

sub Tastendruck()
Tcounter = 0
for I = 1 to 100
if Taste = 0 then incr TCounter
waitms 1
next
if TCounter < 90 then exit sub

'... Hier die Verzweigung

end sub

---