A real quickie about 'returning' out of an interrupt

[HankMcSpank]

When entering into an interrupt, you normally want to exit the interrupt & return to the same place in the program from where the interrupt came in, but I have a need to jump out of my main program loop, say when a switch is pressed - is this even do-able, will it cause problems, will my PIC spontaneously combust?

An example...

Main program is looping
A switch is pressed
the program jumps to an IOC interrupt routine
the interrupt routine 'points' the program to run from another location & exits?

sorry for the n00b line of questioning...I've never had to tackle this problem perviously.

(I'm aware that the elegant way of doing this is to set a variable/flag within the interrupt, then the main program picks up the flag & acts upon it ...but there may be delay between returning out the interrupt & the main loop picking up that the flag has been set - in this short elapsed time worlds may have collided)

[cncmachineguy]

Hank, -how to say this, hmmmm.....

There are a few things in life one CAN do, but shouldn't. we CAN bungie jump, we CAN take a motorcycle above 160mph on city streets, and we CAN jump out of an interrupt.

If you know what is happening in the uP's world, you can re-direct the program to wherever you want. But some things to be aware of:

an ISR is just a subroutine that gets executed under a "special" gosub if you will. As such, you can gosub to a routine and never return.

When an ISR is called, things get saved to the stack. this is where the combustion MAY occur. If you don't return from the ISR, the stack gets corrupted. I am not sure how this will affect the continued running of your main. I am sure there is a way to "POP" the stack to remove what should get taken away with the return. I am NOT sure if this is needed.

I am pretty sure DT_INT may get even more mad then a low level interrupt call as there is lots of stuff going on there to make sure the ISR can be entered and exited without issue.

I am sure there may be more things to keep track of, but these are the first things that come to mind.

But the most fun thing to do is try it out. write some code to turn on some led's using subroutines. turn on another from the ISR, and yet another from the ISR jump to location. If everything goes as expected, you can prolly assume a 75% chance of success. The other 25% is for things I don't know.

Hopefully Darrel will come on in and clear up the rest.

[Darrel Taylor]

First, I'll agree with Bert. Some things just shouldn't be done.
And with that said ...

If you are using ON INTERRUPT, just add a Label to the RESUME statement.
Interrupts will still be active, so either DISABLE that section or use a new ON INTERRUPT GOTO for that section.

Once you do that, you can never RETURN to where the program was before the interrupt.
It's as if the chip started running from that point at power-up.

With ASM interrupts on 16F's it's pretty much the same because the stack is circular and it will wrap around and overwrite previous entries. Interrupts will be turned off after the jump in this case.

With ASM interrupts on 18F's, you must clear the stack first to prevent an overflow.

[cncmachineguy]

First, I'll agree with Bert.

whoo hoo!!

Once you do that, you can never RETURN to where the program was before the interrupt.
It's as if the chip started running from that point at power-up.

do you mean just with respest to the program counter - stack is bad? all registors and user variables will still be intact, yes?

With ASM interrupts on 16F's it's pretty much the same because the stack is circular and it will wrap around and overwrite previous entries. Interrupts will be turned off after the jump in this case.

they are off because they were turned off by the interrupt hardware in the uP? So if this JUMPING ISR turned them back on, is the stack the only issue?

With ASM interrupts on 18F's, you must clear the stack first to prevent an overflow.

So the ISR will need to clear the stack AND turn interrupt's back on?


New question, in the 16f1's, do we care about the auto context save?

Mind you, much like jumping from a bridge with a rubber band ties to my foot, I can't imagine doing this. But you (Darrel) said it best, knowledge is intoxicating

[Darrel Taylor]

whoo hoo!!
do you mean just with respest to the program counter - stack is bad? all registors and user variables will still be intact, yes?

Yes, only the stack can't be trusted anymore. Everything else is still the way it was.

they are off because they were turned off by the interrupt hardware in the uP? So if this JUMPING ISR turned them back on, is the stack the only issue?

Correct, but that ISR shouldn't turn them back on unless something else is changed so that the interrupts will be handled by the new program section. That could just be a bit that the ISR recognizes.

So the ISR will need to clear the stack AND turn interrupt's back on?

Yes, but again, let the new section turn them back on.

New question, in the 16f1's, do we care about the auto context save?

Not in this context, pun intended ...
But the stack is only circular if the configuration bit STVREN = 0.
There is no PUSH or POP instructions, so the stack can't be cleared.

Mind you, much like jumping from a bridge with a rubber band ties to my foot, I can't imagine doing this. But you (Darrel) said it best, knowledge is intoxicating

<object width="480" height="390"><param name="movie" value="http://www.youtube.com/v/OE053VV_rE4?fs=1&amp;hl=en_US&amp;rel=0"></param><param name="allowFullScreen" value="true"></param><param name="allowscriptaccess" value="always"></param><embed src="http://www.youtube.com/v/OE053VV_rE4?fs=1&amp;hl=en_US&amp;rel=0" type="application/x-shockwave-flash" allowscriptaccess="always" allowfullscreen="true" width="480" height="390"></embed></object>