Electronics > Microcontrollers

Interrupt routine duration

(1/11) > >>

Red_Micro:
How long is it safe for a interrupt routine to process things in it? Let's say I have an interrupt every 300 us. It means I need to keep any processing time inside below 300 us, right?

nctnico:
Yes. Typically I try to keep total interrupt processing below 90% of all available CPU time so that there is room left to do housekeeping tasks (like handling buttons). If you have several time critical processes, you'll need to create a plan on how to deal with all the priorities. There is no general approach that works for all applications.

hans:
Yes.

But also to leave enough cycles for main() code or other interrupt vectors.

The main importance of  IRQs is to service the hardware to keep it operating properly. E.g. reading a received byte from an UART has some time sensitivity, as the buffer needs to be cleared before the next byte arrives. It's real-time :) But in this case it depends how bursty the incoming data stream is. If you can guarantee that only 1 byte arrives every 300us, then there is nothing stopping you from spending 300us in 1 IRQ. The CPU simply doesn't care if it's executing code in IRQ or main.

However, if you can't guarantee that (e.g. only in the happy path, not during fault etc.), then the firmware may break. It's  therefore still best practice to keep IRQs as short as possible though. On some MCUs without a nested interrupt controller, you may also block all other interrupts for that particular amount of processing time, which could introduce issues or timing jitter. Pushing data around with buffers between IRQ and main() can solve a lot of the problems associated with bursty interrupts and long processing times.

Ian.M:
It depends - if the peripheral raising the interrupt has a multi-item hardware buffer or queue, then it *may* be acceptable to occasionally take longer to handle an interrupt than the interval to the next one, as long as on average it takes less time and the buffer/queue never overflows.   

tggzzz:

--- Quote from: Red_Micro on August 12, 2022, 05:32:28 pm ---How long is it safe for a interrupt routine to process things in it? Let's say I have an interrupt every 300 us. It means I need to keep any processing time inside below 300 us, right?

--- End quote ---

That would work if either there is no other processing to be done, or the other processing can be done on a separate core. But... If there is no other processing to be done, then it would be simpler and more predictable to spinloop waiting for the event that triggers the interrupt! Interrupts are a pragmatic complication, since in most applications it is not practical to do nothing until an input occurs.

If there is other processing to be done, especially if it is on another core, a sound technique is that the ISR captures the essential information contained in the event, puts that information in a mailbox or FIFO, and returns as fast as possible. The other core or background thread spinloops until there is something in the mailbox or FIFO, gets the event information, and processes it. That technique is easy to design, implement, verify, and (if necessary) debug. If the other system constraints allow it, then that technique can also allow for short bursts of interrupt events less than 300┬Ás apart.

Naturally in some cases that is ideal, in some cases impossible.

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version