PIC interrupt & subroutine

Can anyone advise please?

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.

Thanks.

Reply to
PigPOg
Loading thread data ...

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.

Reply to
cbarn24050

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

Reply to
PigPOg

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

Reply to
Robert Scott

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.

Reply to
PigPOg

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.

Reply to
PigPOg

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

Ian

Reply to
Ian Bell

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

Reply to
Robert Scott

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

Reply to
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

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
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

Reply to
Meindert Sprang

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

Reply to
Ian Bell

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

Ian

Reply to
Ian Bell

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"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
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

Reply to
Ian Bell

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

Reply to
PigPOg

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.