Hallo Foraner,
ich habe hier eine Schaltung mit einem PIC16F1933, wo zum Auswerten
eines Drehencoders der Interrupt-on-Change auf die fallende Flanke
verwendet wird. Verwenden möchte ich Hardware-Entprellung. Die
Oszillogramme zeigen jeweils die Werte bei 20ms, 5ms und 10us/Einheit
bei steigender und fallender Flanke.
Erster Versuch:
-Bild P1110149.jpg
-R1=10k
-R2=1k
-C=10n
Dabei sind die Preller voll durchgeschlagen => Mehrfache Interrupts.
Dann habe ich die Werte geändert auf:
-R1=100k
-R2=10k
-C=110n (10n + 100n parallel)
So habe ich langsame Flanke wie in Bild: P1110129.jpg, P1110130.jpg und
P1110131.jpg. Habe ich jetzt mehrfache Trigger wie in Bild: P1110132.jpg
und P1110133.jpg weil die Flanke so flach sind?
Jedenfalls habe ich dann die Werte weiter abgeändert auf:
-R1=100k
-R2=10k
-C=10n
So habe ich manchmal ein, zwei Trigger zuviel, wie in den Bildern
P1110136.jpg bis P1110143.jpg zu sehen.
Man sieht auch sehr gut, dass auch bei der positiven Flanke getriggert
wird. Kanal 3 wäre der Anschluss "Port", mit einem 10:1-Tastkopf, Kanal
2 ist die "led" aus der Interrupt-Routine und Kanal 1 der
"debug_ausgang" aus der Main-Schlaufe.
Meine Frage ist nun, geht hier gar keine Hardware-Entprellung, oder habe
ich was Anderes übersehen? Ich arbeite nun seit 2 Tagen an diesem
Problem.
Vielen Dank!
Gruss Chregu
Testcode, Oshonsoft Basic, aufs nötigste reduziert:
Christian M. schrieb:> Meine Frage ist nun, geht hier gar keine Hardware-Entprellung, oder habe> ich was Anderes übersehen? Ich arbeite nun seit 2 Tagen an diesem> Problem.
Sieh es mal aus der Frequenzdomäne.
Du versuchst ein relativ langsames Ereignis (Taster inkl. Entprellzeit)
mit einem schnellen Signal abzubilden. Das Signal kann auch noch gestört
sein. Das funzt prinzipiell nicht. Der IOC kommt im Bereich von Mikro-
bis Nanosekunden und der nötige Filter liegt im Millisekunden Bereich.
Das ist in etwa so als würdest du Versuchen mit einem Tiefpassfilter ein
einzigen hohen Ton zu catchen.
Du musst zeitlich den Bereich filtern der deiner Signallänge entspricht.
Ein IOC kann da das "Startsignal" geben. Mehr Information bekommst du da
nicht. Eine zeitliche Auswertung, ob das nun prellen oder Unterdrückung
von Störsignalen ist, spart dir das nicht.
Am einfachsten ist es imo die Flankenauswertung sein zu lassen.
Mehrfach abtasten, die Zeiten addieren und bei Fehlsignal zurücksetzen
ist einfach und sicher. Das spart auch alle die Kondensatoren und
Widerstände ein.
HyperMario schrieb:> Am einfachsten ist es imo die Flankenauswertung sein zu lassen.> Mehrfach abtasten, die Zeiten addieren und bei Fehlsignal zurücksetzen> ist einfach und sicher.
Danke für Deine Einschätzung. Ich selber denke aber, Flanke ist Flanke.
Ob die jetzt einmal pro Stunde oder 1 Million mal pro Sekunde kommt ist
egal.
Jedenfalls habe ich jetzt einen Schmitt-Trigger reingepfuscht (gehört
eigentlich in Quick and Dirty), einen 74HC14, jetzt funktioniert's
perfekt!
Gruss Chregu
kuck mal ins Datenblatt deines PIC.
Hat dein Pin eine Hysterese?
Falls nein, wäre das die Erklärung für das Verhalten.
Das ist nämlich so:
Dei Signal benötigt Millisekunden, um von 0 auf VCC zu steigen. Das ist
sehr langsam. Hat der Eingang keine Hysterese, kann es bei so langsam
ansteigenden Flanken zum Mehrfachtriggern kommen.
Das liegt daran, dass es einen sehr scharfen Punkt gibt, an dem der
Eingang LOW / HIGH umschaltet. "Steht" dein (langsames) Signal vom
Spannungswert her dort, kann eine sehr geringe Störung bewirken, dass
während dieser ZEit mal HIGH, mal LOW erkannt wird - zufällig.
Durchläuft dein Signal diesen Bereich in z.B. einem Taktzyklus des µC,
dann kann es nicht zum Mehrfachtriggern kommen.
Wie groß der Bereich ist, hängt davon ab, wie stark dein Signal rauscht.
Darum sollte man sich langsam ändernde Signale nicht an einen Digitalen
Eingang ohne Hysterese anlegen, wenn man Interrupts verwendet. Bei
Polling ist das allerdings relativ egal. Einige µC haben daher
schmitt-Trigger-Eingänge (STM32 zum Beispiel), da stellt sich das
Problem nicht.
Folgende Lösungen kann ich mir vorstellen:
Du kannst einen Schmitt-Trigger verwenden.
Du kannst die Zeitkonstante reduzieren (R kleiner, C größer).
Du kannst das Signal in Software pollen.
Ich persönlich polle Encodereingänge gern, aber ob das sinnvoll möglich
ist, hängt natülich vom Encoder ab.
Christian M. schrieb:> Jedenfalls habe ich jetzt einen Schmitt-Trigger reingepfuscht (gehört> eigentlich in Quick and Dirty), einen 74HC14, jetzt funktioniert's> perfekt!
Ahrg. Hätte ich mir mein Geschreibsel sparen können. Man sollte vor
Abschicken des Beitrags auch mal F5 drücken :-(
soso... schrieb:> Ahrg. Hätte ich mir mein Geschreibsel sparen können.
Das ist finde ich sehr gut erklärt. Meine Meinung möchte ich aber
hinzufügen.
Pics haben auch Schmitt Trigger an den Eingängen. Nur sind die
Schaltschwellen halt andere. Da wurde jetzt das Symptom beseitigt, aber
wenn der Encoder seine Charakteristik ändert (z.B. durch Alterung) kann
das Problem wieder auftreten. Da die Teile im Laufe der Zeit zu
stärkerem Prellen neigen passiert das auch oft.
HyperMario schrieb:> Pics haben auch Schmitt Trigger an den Eingängen. Nur sind die> Schaltschwellen halt andere.
Scheinbar nicht an den IOC Pins, sondern nur am INT Pin.
@Christian
Warum eigentlich IOC?
(Möglicherweise ist dann B0 auch als TTL und nicht ST konfiguriert)
Christian M. schrieb:> ich habe hier eine Schaltung mit einem PIC16F1933, wo zum Auswerten> eines Drehencoders der Interrupt-on-Change auf die fallende Flanke> verwendet wird.
Dumme Frage: Warum ist es ein Problem, wenn der Interrupt-Pin prellt?
Dank Gray-Code ist es doch wurscht, ob es an der Flanke ein, zwei, viele
IRQs gibt, und ob man enprellt oder nicht, und ob man per Pin-Change
oder Timer abfragt...
Brummbär schrieb:> Dank Gray-Code ist es doch wurscht,
Das wird hier vermutlich nicht ausgewertet.
(((
Wenn ich einen Encoder per PIN-Interrupt auswertet, warte ich nur auf
die Änderung eines Signals und schaue dann auf den Zustand des anderen.
)))
Volker S. schrieb:> IOC
Was ist denn für Euch "IOC"? Ist das AVR-Sprech?
Ja, die SM sind nur für die CCP-Module und den INT an RB0, jetzt seh ich
es auch. Beim Wechsel von vorher 16F876 auf jetzt 16F1933 habe ich auf
den Pin-Change-Interrupt gewechselt.
Volker S. schrieb:> Brummbär schrieb:>> Dank Gray-Code ist es doch wurscht,>> Das wird hier vermutlich nicht ausgewertet.
Ja, genau!
soso... schrieb:> Das liegt daran, dass es einen sehr scharfen Punkt gibt, an dem der> Eingang LOW / HIGH umschaltet.
Ja, Dein Beitrag war nicht umsonst! :-))
Aber gibt es diesen "scharfen Punkt" wirklich? Bei manchen Gattern
durchfährt man dort den analogen Bereich...
Gruss Chregu
Christian M. schrieb:> Was ist denn für Euch "IOC"? Ist das AVR-Sprech?
Nein das ist interrupt-on-change in PIC16f1933-Sprech.
(taucht fast hundert mal im Datasheet auf ;-)
soso... schrieb:> Darum sollte man sich langsam ändernde Signale nicht an einen Digitalen> Eingang ohne Hysterese anlegen, wenn man Interrupts verwendet. Bei> Polling ist das allerdings relativ egal.
Eigentlich auch beim Polling nicht.
'Normale' CMOS-Eingänge (PIC-Datenblätter kenne ich nicht) haben meist
eine Anforderung an die maximale Anstiegszeit. Die liegt oft bei nur
500ns oder weniger, jedenfalls sehr deutlich unter dem ms-Bereich.
Deshalb ist der Schmitt-Trigger bei solchen Eingangssignalen auch
richtig.
HildeK schrieb:> Eigentlich auch beim Polling nicht.> 'Normale' CMOS-Eingänge (PIC-Datenblätter kenne ich nicht) haben meist> eine Anforderung an die maximale Anstiegszeit. Die liegt oft bei nur> 500ns oder weniger, jedenfalls sehr deutlich unter dem ms-Bereich.> Deshalb ist der Schmitt-Trigger bei solchen Eingangssignalen auch> richtig.
Stimmt schon...
Mein Spruch ist immer:
Soetwas wie Digitaltechnik gibt es nicht. ALLES ist Analogtechnik.
Weil heutige IO-Ports recht komplex sind, kann man auch viel falsch
machen. Man könnte ein Buch mit 400 Seiten über die Behandlung von
µC-Eingänge schreiben, ohne den Stoff auswalzen zu müssen.
Aber:
Wir wollen für Basteleien mal nicht übertreiben. Darum ist ja Basteln so
schön: Man kann mal ein Auge zudrücken. PIC-Ports sind recht robust. Ich
hab erst wenige vernichtet.