A real quickie about 'returning' out of an interrupt

[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>