Hi everyone, Is there a way to return to a fixed location from an interrupt?
In my program I have something like this:
void main(void) { ...//some instructions while(1) { ...//some instructions EX1=1; //enable external interrupt 1 my_function(); EX1=0; //disable external interrupt 1 } }
As you can see, an external interrupt 1 can occur somewhere in the middle of my_function (or in the middle of other functions that my_function calls). And I want that when we go back from the external interrupt 1 subroutine, the processor will go right to the beginning of while(1) and SKIP the rest of my_function (instead of returning to where it was called from).
Is there a way to do this? (And by the way, I don't care about all the local variables of any of the functions or the main. They are all irrelevant if EX1 occurs, so there's no need to save them before "returning" to that location).
I'd really appreciate your help!!
If you want it to react fast just handle the task completely in the interrupt, do it quickly and efficiently.
Your example provides no insight into the complexity or requirements of the function. As presented the RESET option seems to match the coding style.
Consider also a better/faster processor.
In addition to above suggestions, also consider restructuring the code so that it doesn't get so deeply "bogged-down"...
I normally keep my main loop short and fast - each todo splitted into short enough pieces that they quickly end and have the processor ready to look for more work.
Next thing is that I have some priority hierarchy to decide what to do. So I don't have 100 individual flags and have the main loop test and process up to 100 tasks before restarting.
The main loop checks if there are any high-prio tasks to do. If not, then it checks for lower prioritized task - and may perform max one before restarting and checking for high-prio tasks.
So the loop might have some flags that gets checked every iteration. Then it might have a switch statement that round-robin tasks that needs to be done every x millisecond.
And some slots in that switch statement might call a function with a switch statement of things to that needs to be checked every 100ms.
So important flags gets polled often while less important flags get polled at larger intervalls - all the time sharing time fairly and guaranteeing that no flag has to wait too long to get polled in relation to the real-time requirement of that flag.
It's easy to poll a fast free-running timer and keep log of the iteration times, and finding out which state combination is slowest and later verify that all flags always gets serviced quickly enough.
If one or more actions just must be processed quicker than the main loop can be run, then there are basically two options. 1) get a faster processor. 2) see if the panic task can be fixed in the code/ISR that did set that flag.
Hiding "fix panic flags" logic inside lots of other actions because they are hard to split into quicker sub-steps isn't much fun. You quickly lose the ability to measure and guarantee your real-time requirements. And you are likely to forget that extra panic code in some parts of the code.