Interrupts Revisited

[Rob Martin]

Hi All
I'm away on holiday programming by torch light in the middle of a forest (seriously) and only have web access via a mobile phone. I've tried finding my answers in the archieves but with no joy so forgive me for asking a question which has probably been asked elsewhere.


I'm using a 16f877 20MHz with all the RB ports held high using external resisitors.
I have a tri coloured LED connected to RC0 & RC1 and Ground.

My problem is the Interrupt routine below works fine and turns the LED on and off.However when the interrupt occurs I need to call another routine. As soon as I add any other command into the routine it appears to permanently call the routine! and screws everything else up although the LED's still work OK.

I happy that the RB pins are not changing state so why is my interrupt routine running! am I not clearing a flag somewhere?
or am I missing something very obvious?
I've made sure I have no other references to the RB pins in my code and the ISR can not be executed by the code running into it as it is at the end of my code.
if I remove the "ON INTERRUPt" line the rest of my code functions normally and the LEDs stop working.

Rob
(desperate of Hampshire)


'Interrupts stuff********************************************* *
TRISB = %11111111 ' Set PORTB to all input
INTCON.3 = 1 ' Enable the RB port change interrupt
OPTION_REG = $7f ' Enable PORTB pull-ups
'TRISC = %00000011 ' Set PORTB.0-2 (LEDs) to output, 3-7 to input

sw1 VAR PORTB.6
sw2 VAR PORTB.4
'SW3 VAR PORTB.7
' Define the pins that are connected to LEDs
led1 VAR PORTC.0
led2 VAR PORTC.1
ON INTERRUPT GOTO ISR




****BIG SNIP************
RETURN
DISABLE
:ISR

IF sw1 = 1 Then
high LED1

else
low led1
endif

IF sw2 = 1 Then
HIGH led2
else
low led2
endif

IF sw3 = 1 Then
HIGH led1
HIGH led2
else
low led1
low led2
endif

TempwData var WORD
Tempwdata = wData 'stores the current wdata pointer

************HERE the problem happens********************
if (sw1 = 1) then
wData = 7*256 + 0 : GOSUB Send
wData = $1F00 + $62 : GOSUB Send
else
wData = 7*256 + 0 : GOSUB Send
wData = $1000 + $0b : GOSUB Send 'b
endif
wdata = TempWData 'Restores the original wdata pointer

INTCON.1 = 0 ' Clear interrupt flag xxxxx
resume
ENABLE

[mister_e]

i'm not 100% sure but close to be. Please someone shoot me if i'm not correct.

1. You can't use a gosub in a ISR
2. You can't use var definition elsewhere than at the begining... There's no local variable in PBP.
3. :ISR should be ISR:

without checking in the datasheet, this is the firsts thing that spring to mind.

[Bruce]

If you jump to or call a sub-routine outside the ISR DISABLE / RESUME, ENABLE block, PBP will shoot you straight back to the beginning of your ISR once the 1st BASIC instruction outside this protected area completes execution.

[yettie]

rob,

i think he had the same problem in using the ON INTERRUPT method. maybe you would want to consider the ASM interrupts. Its a lot more easier than microcode interrupt. just for an idea.

DEFINE INTHAND IntHandler
...(define your variables)

;-------------
Initialize:
TRISB = $FF
INTCON = %11001000 ;(enable portb change interrupt)
OPTION_REG = $7F ;(pulls ups enable)
... (then your main routines)

;------------------
@_IntHandler ;Interrupt Service Routine
INTCON.3 = 0 ; disable portb change interrupt while in this routine
;(reset all necessary variables and call your extra routines)
INTCON.3 = 1 ; reenable portb change interrupt
@retfie


Well I hope this one will give you some ideas. ON INTERRUPT is hard to implement with so much latency compared asm interrupt. As another advatage, you saved some words since ON INTERRUPTS have so many overheads inserted per each of your line since it polls interrupt flags. ok?

regards,
Paul

[yettie]

in addition to this, save all your status, W and other registers if necessary when the program is interrupted. just reload it later. in your case i don't think you will to save your last state when interrupted, or just correct me if im wrong.

regards,
yettie

[Rob Martin]

The routine I call outside of the ISR has DISABLE & ENABLE either side of it.
It was my understanding that I can call this other routine and that it will complete the routine then jump back to the ISR.

This part appears to work fine. My problem is/was that even when an interrupt hasn't occured my code inside the ISR seems to the execute?
(it seems to execute the "ELSE" statments)

Can someone confirm I have the correct flags bits set and clear for the "on change" interrupt.

Lastly having local VARS, I have compiled like this before and never had a problem. Does the compiler just pick the VAR out at compilation time regardless of where they are?
Again with the ON INTERRUPT call does this need to be anywhere specific? it seems to my no difference where I put it.

Rob