This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Handling ISR

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.

Parents
  • 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).

Reply
  • 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).

Children
No data