I'm sorry. I just realized that. Do you reset you're interrupt flag somewhere? Should there be an Intf = 0 just before the retfie?
I'm sorry. I just realized that. Do you reset you're interrupt flag somewhere? Should there be an Intf = 0 just before the retfie?
first off all you forgot to clear int flag
in your int handler so your PIC will always
be in interrupt routine. you have to put line
before retfie instruction.Code:bcf INTCON,1
also I suggest you to turn on and off
LED in int routine with little delay
in between (although it is not adviceable to use
delays in interrupt)
to see the interrupt more clearly. you can
use this int handler for example:
Code:asm int_handler ; Save Resisters ; movwf wsave ; Save W Register into wsave swapf STATUS,W ; Save STATUS Register into ssave clrf STATUS movwf ssave movf PCLATH,W ; Save PCLATH Register into psave movwf psave movf FSR,W ; Save FSR Register into fsave movwf fsave endasm high LED pause 100 low LED ; Interrupt Code ; ;bsf _LED ; Turn on LED asm ; Restore Resisters ; movf fsave,W ; Restore FSR Resister movwf FSR movf psave,W ; Restore PCLATH Resister movwf PCLATH swapf ssave,W ; Restore STATUS Resister movwf STATUS swapf wsave,F ; Restore W Resister swapf wsave,W bcf INTCON,1 retfie endasm
I would have thought the interrupt flag would be reset automatically when it returns from the interrupt handler. I havnt seen interrupt routines that reset the flag, but I guess its worth a try.
Ahh yep, that did the trick. Thanks Ingvar.
Just a single line at the end of the interrupt handler: bcf _INTF
Tom: is there any down side of including picbasic commands in your interrupt handler. I thought to work as a proper interrupt it had to be in asm?
You always have to clear interrupt flag in software
before retfie instruction. If you don't clear the flag,
instruction retfie will set GIE bit and PIC will be
interrupted again. Logical AND function beetwen
int flag bit and int enabled bit (AND-ed with GIE)
will result in interrupt.
kamikaze 47:
well, of course it's better to use asm in my opinion
but this also work. I try it.
Kamikaze47 is right.
There is definately a problem using PAUSE in an ASM interrupt.
Pause uses 2 internal PBP variables. (R0 and R1). So if, another PBP statement that uses either R0 or R1 gets interrupted, the interrupt routine will change those values and the main program will get confused.
It's possible to have a pause in the interrupt, IF you save both of the system vars first, then restore them when the int is finished.
In that case, toms example would look like this...But then, like tom says ... "it is not advisable to use delays in interrupt"Code:R0save VAR WORD R1save VAR WORD asm int_handler ; Save Resisters ; IF (CODE_SIZE <= 2) movwf wsave ; Save W Register into wsave swapf STATUS,W ; Save STATUS Register into ssave clrf STATUS movwf ssave movf PCLATH,W ; Save PCLATH Register into psave movwf psave movf FSR,W ; Save FSR Register into fsave movwf fsave endif endasm R0save = R0 R1save = R1 high LED pause 100 low LED R1 = R1save R0 = R0save asm ; Restore Resisters ; movf fsave,W ; Restore FSR Resister movwf FSR movf psave,W ; Restore PCLATH Resister movwf PCLATH swapf ssave,W ; Restore STATUS Resister movwf STATUS swapf wsave,F ; Restore W Resister swapf wsave,W bcf INTCON,1 retfie endasm
<br>
Last edited by Darrel Taylor; - 16th November 2005 at 18:48.
DT
Thanks for that info Darrel.
Is there a reference somewhere that tells you what (if any) internal variables PBP uses for each command?
No, unfortunately.
Depending on how and where certain statements are used in the program, the actual system variables used might change. So there's really no way to make a "List".
You pretty much have to sift thru the .LST file to find out which vars are used. That includes following every CALL to other routines too. It can take a while.
PAUSE was easy though, it's pretty small, and only has 1 CALL.
Of course, you can take the easy route and just save them all to be sure. But then we're back to OXIMBIT's routine again.
<br>
DT
Bookmarks