PDA

View Full Version : DT-INTs What's legal in an INT handler?



circuitpro
- 29th January 2010, 01:33
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
- 29th January 2010, 01:50
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
- 29th January 2010, 02:07
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
- 29th January 2010, 03:58
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
- 29th January 2010, 04:01
? toggle command is only good for port pins ?

circuitpro
- 29th January 2010, 04:27
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
- 29th January 2010, 04:36
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
- 29th January 2010, 04:43
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
- 29th January 2010, 04:54
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
- 29th January 2010, 06:53
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
- 29th January 2010, 07:21
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
- 29th January 2010, 07:43
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
- 29th January 2010, 12:27
I feel better now! I haven't broken any laws.

aratti
- 29th January 2010, 18:43
Bruce, tank you for the explanation.

Al.