DT-INTs What's legal in an INT handler?

[circuitpro]

My program spends most of it's time in a loop waiting for an interrupt (button presses). Once received, I need to decode 24 buttons and execute the right commands.

My present interrupt handler has a SELECT CASE function in it, with a GOSUB in every case to execute the functions. Is this legit? What are the specifics and restrictions in an interrupt handler?

[Bruce]

With DT_INTS using a PBP type interrupt, pretty much anything goes. I.E. use as many
PBP instructions as you like in the int handler.

That's the really cool part of using DTs' int program. He's done all the work for you.

Just don't GOSUB outside the interrupt handler - or it will go-like-splat...

[circuitpro]

Thanks Bruce. The issue that led me to this question is obviously something else.

I'm using LONG variables for the first time, and have an issue where a bit in a 24-bit LONG is being changed/corrupted by me TOGGLEING another, unrelated BIT variable! I figured the problem is me MISDECLARING my variables OR my interrupt handler. Bit 14 of the LONG variable GRN is being corrupted when I toggle the bit variable SOLO. (If I don't use interrupts, the problem goes away).

My variable declarations are:

RED         VAR     LONG                  
GRN         VAR     LONG                  
BUTTONS     VAR     LONG                  
X           VAR     LONG                   
Y           VAR     BYTE                    
Z           VAR     BYTE                    
RED0        VAR     RED.BYTE0
RED1        VAR     RED.BYTE1
RED2        VAR     RED.BYTE2
GRN0        VAR     GRN.BYTE0
GRN1        VAR     GRN.BYTE1
GRN2        VAR     GRN.BYTE2                
BU0         VAR     BUTTONS.BYTE0           
BU1         VAR     BUTTONS.BYTE1         
BU2         VAR     BUTTONS.BYTE2           
LCD         VAR     BYTE[80]            
COUNTER     VAR     BYTE                   
VOL         VAR     BYTE                   
SOLO        VAR     BIT

Thanks.

[Charles Linquis]

Bruce, could you please explain your comment to me? I would think that PBP knows what bank it is in, and keeps track of that - even in an interrupt handler. Is that not true?
And what constitutes "outside the interrupt handler"? Must all the handler code be placed between the INT entry point and the INT_RETURN?
I have to admit, I have violated your "rule" and it hasn't caused problems. Am I lucky?
Please explain.

[Michael Wakileh]

? toggle command is only good for port pins ?

[circuitpro]

Oh my gosh, you're right! I don't know why I thought that would work for a bit. That fixed it.

THANKS Michael.

[Bruce]

Bruce, could you please explain your comment to me? I would think that PBP knows what bank it is in, and keeps track of that - even in an interrupt handler. Is that not true?
And what constitutes "outside the interrupt handler"? Must all the handler code be placed between the INT entry point and the INT_RETURN?
I have to admit, I have violated your "rule" and it hasn't caused problems. Am I lucky?
Please explain.
__________________
Charles Linquist

Hi Charles,

Would be happy to answer if you could point me to the inital post...

[Charles Linquis]

This is a cut-and-paste from post #2 above.





With DT_INTS using a PBP type interrupt, pretty much anything goes. I.E. use as many
PBP instructions as you like in the int handler.

That's the really cool part of using DTs' int program. He's done all the work for you.

Just don't GOSUB outside the interrupt handler - or it will go-like-splat...
__________________

[circuitpro]

I wanted to clarify a point just to possibly help somebody else...

Unfortunately, TOGGLE does work to change the state of a BIT variable, even though this is an incorrect use of the command! It also quite possibly clobbers some other unsuspecting variable, in this case a LONG. It would be nice if the compiler would flag it, but it doesn't so BEWARE!!

Thanks again, Michael.

[Bruce]

Hi Charles,

What I meant was -- you don't want to jump outside an interrupt handler routine - without
returning to it.

I.E. if you GOSUB outside the interrupt routine, and don't re-enter it before your return, you might
experience major problems.

DT_INTS needs to exit from DT_INTS. If you jump outside of this routine, and try to return
from the interrupt on-your-own, you're going to have a problem.

Exit from an interruppt requires a lot of regitsers to be restored.

If you jump outside of the int routine, and return on-your-own, you will for sure see a problem.

[aratti]

I.E. if you GOSUB outside the interrupt routine, and don't re-enter it before your return, you might
experience major problems.

------------ DT Interrupt handler --------
Get_Byte:

do something here

If black then gosub apples
If withe then gosub peach

@ return


apples:
do something
return

peach:
do something
return

Bruce, can you please explain better your statement? from what you said, I understand that the above example code could give problems, while I am using this type of jump out of the interrupt handler, quite often and I never experienced any problem.

Al.

[Bruce]

Hi Al,

No problem at all with your code. You GOSUB outside the int handler, and you RETURN right back to it, so this isn't a problem.

The problem is only when you GOTO (or GOSUB) to another routine, outside an interrupt handler, and you do NOT return to it where it restores saved registers, and issues a RETFIE command.

You show a DT Interrupt handler. You may not see it, but i guarantee theres a lot of code on exit from a DT interrupt routine
that's restoring system file registers.

[Charles Linquis]

I feel better now! I haven't broken any laws.

[aratti]

Bruce, tank you for the explanation.

Al.