Hallo Leute,
ich habe meine ISR (16F88) massiv abgespeckt, jetzt sieht sie so aus:
org 4h ; Eintrittspunkt ISR
MOVWF W_TEMP
SWAPF STATUS,W
MOVWF STATUS_TEMP
movlw .255
btfss INTCON,INT0IF
btfss INTCON,RBIF
goto Int0
movwf RBIEFlag
goto isr_end
Int0 movwf INT0Flag
isr_end
BCF INTCON,INT0IF
BCF INTCON,RBIF
BCF INTCON,TMR0IF
SWAPF STATUS_TEMP,W
MOVWF STATUS
SWAPF W_TEMP,F
SWAPF W_TEMP,W
retfie
Bei externen Interrupt0 und bei Interrupt on change wird die ISR
aufgerufen, die enstsprechenden Speicherstellen gesetzt und gut.
Dummerweise wird bcf INTCON,RBIF ignoriert, das Bit bleibt gesetzt und
die ISR wird in Endlosschleife versetzt, zumindest im MPLAB-Debugger.
Wer sagt mir, wo der Hund begraben ist?
Tom
Gast
#2273118
Ich muss sagen, dass ich viele schlechte Erfahrungen mit den Interrupts bei PICs habe. Die sind sehr launisch. Sind die Pegel am PortB sauber? Evtl. die Pullups aktivieren. Außerdem würde ich jeweils ein "nop" zwischen die Clears schreiben, das kann helfen... Berichte bitte Fort- und Rückschritte. LG
RC Funker schrieb: > Ich muss sagen, dass ich viele schlechte Erfahrungen mit den Interrupts > bei PICs habe. Die sind sehr launisch. > Sind die Pegel am PortB sauber? Evtl. die Pullups aktivieren. > > Außerdem würde ich jeweils ein "nop" zwischen die Clears schreiben, das > kann helfen... > > Berichte bitte Fort- und Rückschritte. > > LG Hi also, NOPs zwischen den bcf brachte nichts. Ich habe auch die Reihenfolge verändert - keine Änderung. Mit den Pullups meinst du wohl Bit 7 im OPTION_REG: war zuerst 1 (keine Pullups), dann auf 0. Geändert hat sich aber nichts. Ich verstehs einfach nicht. Ich hatte vorher die ISR richtig vollgepackt, da war das Löschen von RBIF nie ein Problem. Tom, der wirklich ratlos ist... :-(
Gast
#2273142
Welche Pegel ändern sich denn an PortB? Evtl. ändern sie sich zu schnell/zu häufig... Hast Du einen Debugger zur Verfügung? Auch noch eine Möglichkeit: Die Flag zwei- oder dreimal hintereinader clearen...
Hm. Ist n Fall für n Debugger. Als ich noch keinen hatte hab ich meine Breakpoints immer mit ner Endlosschleife und einer LED getestet.
Thomas M. schrieb: > INTCON,RBIF Das hier kennst du ? http://www.mikroe.com/forum/viewtopic.php?t=5905
Also, den bcf dreimal hintereinander bringt auch nichts. Ich benutze einen Debugger, MPLAB SIM, den in MPLAB eingebauten. Der Interrupt-on-change findet bei RB4 Anwendung. Die Zeit zwischen den Änderungen beträgt 1300 microsenkunden, also dicke Zeitspanne bei 8 MHz. Daran sollte es nicht liegen. Und wie gesagt, das Ganze lief schonmal problemlos, da war die ISR nur zu voll Tom
Lehrmann Michael schrieb: > Thomas M. schrieb: >> INTCON,RBIF > > Das hier kennst du ? > http://www.mikroe.com/forum/viewtopic.php?t=5905 Jetzt ja. Ich hab das Ganze in aller Eile Überflogen und mitgekriegt, daß man PORTB vorher auslesen muß, bevor man RBIF löschen kann. Keine Ahnung, was das soll, aber jetzt steht ein movwf PORTB vor den BCFs und es läuft :-) Danke an alle für eure Mühe Tom
Gast
#2273202
Interrupt on change vergleicht den aktuellen Zustand am Port mit dem letzten eingelesenen Wert. Wenn Du nur das Flag löschst, ohne vorher den Port einzulesen, wird durch die nicht Übereinstimmung [aktueller Wert an Port <-> letzter gelesener Wert] das Flag gleich wieder gesetzt. Gruß John
Gast
#2273233
Hallo, aus dem Errata 80301b.pdf Module: I/O Ports (PORTB) When the PORTB interrupt-on-change feature and a PORTB peripheral are enabled simultaneously, the PORTB peripheral input signalís rising and fall- ing edges will trigger an interrupt-on-change event. This is due to the interrupt-on-change feature not being disabled on the respective pin for that peripheral when interrupt-on-change is enabled. The affected pins and peripheral signals on PORTB are: RB4: SCK and SCL RB5: SS RB6: T1CKI This issue does not affect the functionality of the following: T1OSI (RB7) T1OSO (RB6) TX/CK (RB5) Work around Use revision C2 silicon
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.