Interrupt Management - Large AVR Projects

Question

This is for the more experienced one's out there.

I am currently involved with a large AVR project (using ATMega328) and it's getting confusing with respect to interrupts.

The project involves interrupts from the following sources

• USART
• TWI
• SPI
• External Interrupt (INT0 and INT1)

With so many interrupt sources and the fact that global interrupts get disabled when an ISR is executing, I am afraid of missing out on interrupts that might fire when my code is servicing another interrupt.

So is there some more structuralized method of managing interrupts in a large project?

Answer 1

The first rule of using interrupts: Keep them very short.

When an interrupt occurs, whether it is enabled or not, and whether it is currently servicing an interrupt or not, an Interrupt Fired flag gets set. Every interrupt has one of these flags associated with it (such as SPSR.SPIF). That always gets set as soon as the interrupt fires.

The interrupt system then cycles through the interrupts looking for any interrupt flags that have been set, and if the interrupt is enabled it then jumps to the ISR.

It will do that no matter how long ago the interrupt occurred.

So the question is not "will I miss an interrupt because I'm in an ISR", but "Will I miss successive interrupts because I am in an ISR".

So first you need to calculate the maximum rate at which an interrupt from one source can occur.

Then you check your ISR routines, and make sure that they never exceed that minimum interrupt period. Consider moving code out of an ISR and instead setting flags to get your main loop to perform operations instead.

In a more complex environment (5 interrupts is NOT lots!) you may, if resources allow, consider creating an interrupt event queue, where an event is added to a list of incoming events when the interrupt occurs, and your main loop is then free to process those events in order. You may need to use queues with different priorities for different interrupts.

That's not really feasible on a small MCU like the '328P as it lacks the resources to effectively manage those kinds of queues.

Answer 2

I am afraid of missing out on interrupts that might fire when my code is servicing another interrupt.

Majenko stated that "The interrupt system then cycles through the interrupts looking for any interrupt flags that have been set, and if the interrupt is enabled it then jumps to the ISR.". This is not entirely true because:

The interrupts have priority in accordance with their interrupt vector position. The lower the interrupt vector address, the higher the priority.

This means that an interrupt source can "starve". After an ISR is completed, the controller will prefer high priority interrupts. Depending on interrupt frequency, it may happen that there is always a high level interrupt flag set, essentially blocking a lower prio one permanently.

Keeping ISR's short and knowing their execution time is good advice.

5 interrupts really isn't much, but still requires careful though on a simple fixed priority driven system.

AVR XMEGA for example takes it to another level. I have a XMEGA project that has to handle 22 different interrupt sources (4xUART tx/rx = 8 + 4 timers + 8 ADC complete + 2 other). However, the XMEGA features a "programmable multilevel interrupt controller". This allows you to manually assign one of three interrupt levels to each interrupt (within those, interrupt vector number priority still counts). Further, you can activate a round-robin priority scheme, which addresses the before mentioned "starvation" problem.

To avoid the possible starvation problem for low-level interrupts with static priority, where some interrupts might never be served, the PMIC offers round-robin scheduling

So regarding your original question:

So is there some more structuralized method of managing interrupts in a large project?

It depends on the capabilities of your system. For a controller like the ATMega328 with simple static priority driven interrupt management there make sure that no interrupt starves and hold on to "short" and "know your execution time". For a controller like the XMEGA, there is more planning involved because you just have more control. You have to carefully distribute the priorities and have to consider using features like "round robin".