Forum: Mikrocontroller und Digitale Elektronik PIC16F1933: Interrupt triggert mehrfach; Flanke zu flach?


von Christian M. (Gast)


Angehängte Dateien:

Lesenswert?

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:
1
Define CONFIG1 = 0x0fc2  'Define für PIC16F1933
2
Define CONFIG2 = 0x1dff
3
Define CLOCK_FREQUENCY = 32  'MHz
4
5
AllDigital
6
7
Symbol led = PORTC.5
8
ConfigPin led = Output
9
10
Symbol debug_ausgang = PORTA.5
11
ConfigPin debug_ausgang = Output
12
Low debug_ausgang
13
14
Symbol encoder0 = PORTB.0
15
Symbol encoder1 = PORTB.1
16
ConfigPin encoder0 = Input
17
ConfigPin encoder1 = Input
18
Dim encoder As Byte
19
encoder = 128
20
21
'Interrupt für PORTB0:
22
INTCON.IOCIE = 1  'allow individual PORTB pins to generate an interrupt
23
IOCBN.IOCBN0 = 1  'enable to detect a falling edge on PB0
24
OPTION_REG.7 = 1  'disabled PORTB pull-ups
25
'Allgemein:
26
INTCON.GIE = 1  'Interrupt generell erlauben
27
28
loop:
29
debug_ausgang = encoder0
30
'WaitMs 100
31
32
Goto loop
33
End                                               
34
35
On Interrupt
36
  If IOCBF.IOCBF0 = 1 Then  'ist eine fallende Flanke aufgetreten?
37
    High led
38
    If encoder1 = 1 Then
39
      encoder = encoder + 1
40
    Else
41
      encoder = encoder - 1
42
    Endif
43
    IOCBF.IOCBF0 = 0  'RB0-Interrupt-Flag löschen
44
    Low led
45
  Endif
46
Resume

von HyperMario (Gast)


Lesenswert?

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.

von Christian M. (Gast)


Angehängte Dateien:

Lesenswert?

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

von soso... (Gast)


Lesenswert?

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.

von soso... (Gast)


Lesenswert?

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 :-(

von HyperMario (Gast)


Lesenswert?

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.

von Volker S. (vloki)


Lesenswert?

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)

von Brummbär (Gast)


Lesenswert?

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...

von Volker S. (vloki)


Lesenswert?

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.
)))

von Christian M. (Gast)


Lesenswert?

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

von Volker S. (vloki)


Lesenswert?

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 ;-)

: Bearbeitet durch User
von HildeK (Gast)


Lesenswert?

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.

von Pfusch Sucks (Gast)


Lesenswert?

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.

Bitte 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
Noch kein Account? Hier anmelden.