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 it can be coded, it's possible.
Doing it in C might not be an effective way to do it.
Some assembly code could certainly help.
But, are you sure you're really approaching your problem in the best way? What you suggest has got a great deal of opportunity for trouble. Are you up to it?
If I were you, I'd prepare for some flak from other posters!
Yes - but don't!!
A more conventional approach is to have your ISR set a flag, and use that flag to control the flow of the main code.
There is a reason why that has gained preference...
sure it can be coded; however, since the result will be unpredictable non-debuggable and lead to increased sales of aspirin, it is equally possible to surviving being struck by lightning.
Erik
if advising against certain failure is 'flak' I am very proud of providing flak
That's not true: it could be made to work - but, as has already been noted, it's unlikely to be really approaching the problem in the best way. It has got a great deal of opportunity for trouble.
That's not true: it could be made to work agreed, however many threads where that was stated have gone on for miles before the beginner finally gave up.
I do, occasionally, make 98% a hundered to get a point across.
PS I could "make it work" however I would not try, knowing the potential ramifications of any addition or change after it was made to work. This is one of those where a totally unrelated change/addition would result in failure
Oh well, If you're so strongly against it, then I'll use a flag as you suggested...
The reason why I wanted it was that I wanted my program to react FAST to a change of one of the inputs (that I connected to EX1), so I thought I'd save the time it takes to check the condition of the flag and return from all the functions, and instead initiate my "return" right to where I need it. It would have saved me some precious microseconds that are needed for my application.
But if you all think that that's a bad idea then I'll drop it. Thanks!
If your external interrupt really is signaling such a major mess - maybe have it reset the processor and restart main?
One reason for using an RTOS, is that an ISR can signal an event, and the RTOS can perform a task switch directly when the ISR ends, thereby waking a high-prio task to handle that event.
Trying to invalidate the normal code flow by magic jumps just means that compiler warnings, manual reading and dedicated code analyzers will be totally unable to spot uninitialized variables, resource leaks etc.
When you are getting stuck trying to do something fancy, that is normally an indication that you are trying to do something you shouldn't be doing.
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.