0

I stumbled upon a this embedded system question, can we call an function inside an ISR ? Working ARM Cortex M4, Have called function many times from ISR without any fault.

I assume behavior will be same for other micro controller as well or am i wrong ?

Note : Please ignore calling an function in ISR would increase my ISR time in turn increasing the interrupt latency.

PartTimeEngineer
  • 33
  • 1
  • 5
  • Is the function called only by the ISR? Is the function re-entrant? Are there other interrupt with higher priority that can interrupt your ISR? So: you should elaborate a little more to have an answer. Otherwise is too broad. – LPs Sep 14 '16 at 06:37
  • Is the function called only by the ISR? No Is the function re-entrant? Yes Are there other interrupt with higher priority that can interrupt your ISR? our code doesn't have knowledge about the complete system and if there are ISR of higher priority. – PartTimeEngineer Sep 14 '16 at 06:43
  • 1
    Based on those answers calling that function into ISR can be safe, as far as the worse case of race conditions grant that the next ISR call can be served. – LPs Sep 14 '16 at 07:03

2 Answers2

3

Generally, there is nothing stopping you from calling a function from an ISR. There are however some things to consider.

First of all, you should keep ISRs as short as possible. Even the function call overhead might be considered too much in some cases. So if you call functions from inside an ISR, it might be wise to inline those functions.

You must also ensure that the called function is either re-entrant or that it isn't called by other parts of the code except the ISR. If a non re-entrant function is called by the main program and your ISR both, then you'll get severe but subtle "race condition" bugs. (Just as you will if the main program and the ISR modify the same shared variable non-atomically, without semaphore guards.)

And finally, designing a system with interrupts, where you don't know if there are other interrupts in the system, is completely unprofessional. You must always consider the program's interrupt situation as whole when designing the individual interrupts. Otherwise the program will have non-existent real-time performance and no programmer involved in the project will actually know what the program is doing. And from the point where nobody knows what they are doing, bugs are guaranteed to follow.

Lundin
  • 195,001
  • 40
  • 254
  • 396
  • You also need to ensure that the OS saves the registers that the routine might use. For instance, if you have floating point or NEON these registers would need to be saved. Co-processor register and other special machine resources should be managed carefully. Maybe helpful: [Threadsafe vs re-entrant](http://stackoverflow.com/questions/856823/threadsafe-vs-re-entrant) – artless noise Sep 14 '16 at 13:34
  • @artlessnoise Given Cortex M, I assumed that either bare metal or RTOS was used. – Lundin Sep 14 '16 at 14:29
0

Some RTOS will enforce a policy of which of its macros can or can't be called from an ISR context, i.e. functions that will block on some shared resource. For example:

http://www.freertos.org/a00122.html

ad3angel1s
  • 484
  • 1
  • 5
  • 17