If, while executing a subroutine an interrupt occurs, is it possible to service the interrupt routine and then, instead of returning to execute the subroutine, simply abort and junp straight back to the main program instead? If this is possible, how do I handle the stack? I'm using the PIC18F252. This is not something I've tried before.
This assumes that the OP wants to jump back to the main program from the subroutine regardless of when the interrupt hit, but only wants to do it after a certain subroutine is called, even if the interrupt hit a long time ago (the flag is still set). Is this what you wanted, PigPOg?
In that case the method first proposed (setting a flag in the interrupt routine and checking the flag in the subroutine) will not work. Seeing the flag set just means an interrupt occurred some time in the past, not necessarily while the subroutine was executing.
Instead you could set a flag upon entry to the subroutine and clear it upon exit from the subroutine. The the interrupt routine could check for that flag and break control if the flag is set. But even that method has its problems. If the interrupt hits just after the subroutine starts but before it has had time to set the flag, or if it hits after the subroutine clears the flag but before it returns, then the interrupt rountine will not react as if the subroutine were executing. This raises the question in my mind as to why you want an interrupt rountine to behave so differently depending on what portion of the main line program was interrupted? It seems like a strange artificial requirement to me - one that might have a much cleaner solution if looked at another way.
If I'm understanding you correctly, this is essentially what the scheduler of a real-time executive does when it aborts a task. It's not trivial, and must be done with great care, since it involves clearing the state of the running subtask (subroutine), restoring the state of the main task, a way to make the main task aware of the aborted subtask, recovery procedures in the main task, etc.
If you really need to do something like this, you should look into a real-time executive, since you obviously don't have the skills to do it on your own. There are many free and low-cost executives available.
In which case a solution would be to set a flag at the start of the subroutine and clear it at the end. Test for this flag in the ISR and if set then restart the program. Restarting must involve reseting the stack.
I am not sure why you would want to do this unless the subroutine takes a long time in which case it might be better to re-structure the design.
I'm guessing that he's got a problem with a non-reentrant library function or something of similar ilk. The 'subroutine' may be doing a periodic update or something of that kind, so that if it fails to update this time due to an interrupt, it will get done the next. The interrupt during the subroutine will cause the results of the non-reentrant routines to be invalid, so he wants to dump them before they get used.
The ISR, OTOH, needs to execute, so maybe he want it to have priority, but he doesn't want to duplicate the function of the library code for the ISR (or something along those lines).
Best regards, Spehro Pefhany
"it's the network..." "The Journey is the reward"
email@example.com Info for manufacturers: http://www.trexon.com
Possibly, but it is of course speculation. Another possibility is that that he needs an abort button but cannot poll it becuase the subroutine hogs CPU time so instead the ISR is triggered by the abort button.
In any case , it would be nice if posters gave a better description of what there problem really is else subsequent posts are full of erroneous assumptions and consequent speculations.