PIC interrupt & subroutine

This is not a good idea, what happens if your interrupt comes when you are not in the subroutine? Have your ISR set a flag somewhere your subroutine can test it and take action as required.

This is such an obvious thing to do! Don't know why I didn't think of it. Thanks for your help.

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?

-Robert Scott Ypsilanti, Michigan

If the program is servicing the subroutine and an interrupt occurs, once the ISR is complete, I want to abort completion of the subroutine and restart the main program. Hope I've clarified this point.

If not in the subroutine, the main program will be running. If an interrupt occurs, the interrupt will be serviced and then return to the main program.

You need to define the problem more explicitly. What is supposed to happen if the interrupt occurs when not in the subroutine?

Ian

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.

-Robert Scott Ypsilanti, Michigan

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.

John Perry

Yes, you can do that, as others have suggested, with a flag.

Another approach to the sort of problem that I envision you might be dealing with is to simply mask interrupts during the execution of certain portions of your code.

Best regards, Spehro Pefhany

Well, if that is all he wants, he should connect his interrupt signal to the reset input instead of a generic interrupt pin..... :^)

Meindert

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.

Ian

Except for some unknown reason he only wants this action if the interrupt occurs whilst the subroutine is executing.

Ian

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

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.

Ian

Having read the replies, I'm going to re-think my program and hopefully avoid the situation I first described. Thanks all.