In fact, the high-priority routine in question is an A/D converter connected via SPI. I only have a small window in which to change the mux and read the contents of the A/D result register without corrupting the next reading. This requires a good number of SPI transactions. I am at the moment working on checking the RCIF while waiting for each SPI transaction to complete. I won't be able to test till tomorrow.If you find a good "middle" where you can put the check it certainly will work, but then changing your "big thingy" code will move this point back and forth in time and may disturb timing.
This is actually a great idea! I just need to analyze the A/D code to see if it'll be tolerant of random interruptions.You can try re-saving your shadow registers and enabling high-priority interrupts before entering your "big thingy" then restoring it all back at the end of it. This way your Bluetooth interrupts can interrupt your "big thingy". If your "big thingy" has critical sections which cannot be interrupted, then you can disable the interrupt around these sections.
BTW, the receiver interrupt code is pretty tight:
Code:
;****************************************************
;** RC1INT -- Capture recieved byte from Bluetooth **
;** Hi priority -- use fast return **
;****************************************************
rc1int movff fsr2l,hfsr2l ;save fsr context
movff fsr2h,hfsr2h
lfsr 2,rxbuff ;point to rxbuffer (on 256 byte boundry)
movff _rxhead,fsr2l ; next byte in queue (modulo 256)
rc1ir movff rcreg1,postinc2 ;copy byte into queue & update pointer
btfsc rcsta1,oerr ;overrun error?
bcf rcsta1,cren ;yes, toggle cren
bsf rcsta1,cren
bbs pir1,rc1if,0,rc1ir ;repeat if another character in buffer
movff fsr2l,_rxhead ;set new head position
movff hfsr2l,fsr2l ;restore context
movff hfsr2h,fsr2h
retfie fast ;fast return