[pic] ISR wigert sich, Interrupt-Flag zu löschen

[Thomas M. (xt-fahrer)]

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

[RC Funker (Gast)]

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

[Thomas M. (xt-fahrer)]

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

[RC Funker (Gast)]

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

[Joachim .. (joachim_01)]

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.

[Lehrmann M. (ubimbo)]

Thomas M. schrieb:
> INTCON,RBIF

Das hier kennst du ?
http://www.mikroe.com/forum/viewtopic.php?t=5905

[Thomas M. (xt-fahrer)]

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

[Thomas M. (xt-fahrer)]

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

[John (Gast)]

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

[Gahst (Gast)]

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