We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.
I have a general question regarding handling ISRs which stems from my inexperience. My understanding of ISR is that the execution branches, from the main code, to the ISR upon a condition being satisfied. After executing the ISR code it goes back to the main code, essentially back to the point where it paused to go to the ISR. My question is can I call another function within the ISR instead of having the execution go back to where it had left off? Would it cause any adverse effects? I am sure I must have confused some people by now for which i would like to apologize. Your criticisms/comments are welcome.
The definition of a "call" is that it will return.
The definition of a "jump" is that it is a one-way change of execution point.
Yes, your ISR can call functions. When these functions ends, they will return back to the ISR. When the ISR ends, the processor will return to your main program (or if you run an RTOS, the ISR will return to any of your waiting threads - not always the same thread that was running when the ISR started).
But for best function, you should always try to keep your ISR short and fast. And that means that you should try to avoid to call functions from the ISR. Do what you need to do, and then let the ISR end.
you can call functions from within an ISR, but that might require extra stack space - the C166 is very different from that perspective than an ARM (which has dedicated stacks per processor mode). note that you can even "cheat" and change the right word in your processor stack to modify the return address of the ISR, so that you can manipulate the actual return location! that is how preemptive schedulers work. If you want to experiment, place a breakpoint at the entry to an ISR and have a look at your stack. Somewhere, you will see the address of the latest instruction that was executed before the interrupt!
One risk with calling functions from an ISR is that the "interrupted" code might also have been using the same function!
This, in itself, needn't be a problem - but it can cause some very "interesting" problems if you're not careful about it...!
Processors with a single stack for interrupts and the main application are quite hard to work with. The program may run very well, until the interrupt happens a the single point where the main program is at its stack maximum - a leaf in the call tree, but not always the deepest nesting.
And all asynhcronous programming (main + ISR or non-cooperative multithreading) requires great care to protect from racing conditions that may produce loss of memory, overwritten variables, random number enerators that returns the same random number twice in a row, ...
The above are two good reasons why an interrupt handler should be small and simple. The less work it does, the less it will interfere with the operation of the normal code (or interrupt handlers for other interrupts).