Do interrupts block other interrupts?

Question

If I have an interrupt attached to two pins and the handler of the first is still executing when the second interrupt fires, does it:

a) queue the second interrupt,

b) ignore the second interrupt (missing it altogether), or

c) pause processing of the first interrupt to execute the second?

I am writing code that logs the exact time the interrupt occurs. Quite lightweight, but have three pins and am logging the rise and fall of each, so there is the potential for collisions. If a) then the second interrupt timestamp will be late, b) there is no timestamp for the later interrupt or c) the timing of the first and second interrupts will be ambiguous.

b) is the worst case, the other two are manageable.

• Gerben: By default the compiler disables interrupts at the start of the ISR and re-enables them at the end. You can disable this, and enable interrupts inside other interrupts by adding the ISR_NOBLOCK attribute to your ISR. But you have to know what you are doing.
• Gerben: It sound like Timer Input Capture Mode might be useful for your specific problem.
• J Collins: Gerben expand on this. I've been working hard to get up to speed on interrupts, and have got as far as external interrupts on pins and internal interrupts. You might be suggesting something better for the task
• chrisl: Depending on your board it might not be possible to use Timer Input Capture Mode for your pins. With that mode you can let a hardware Timer capture the duration of a pulse (not its timestamp at the general timelime). But you would need one hardware Timer per pin. Most boards don't have that much timer left, especially, if you still want to use functions like delay(), millis() or micros(), which need Timer0 to be configured for them. Maybe a simple pin change interrupt would be the easiest. Though that depends on your timing requirements ( how accurate should the recorded timestamp be?)
• Edgar Bonet: @Gerben: On AVR, interrupts are disabled at the start of the ISR not by the compiler, but by the hardware. The ISR_NOBLOCK attribute is a way to ask the compiler to re-enable interrupts as early as possible within the ISR.

Answer 1

It depends on the architecture.

Assuming AVR (8-bit Arduino) then it will queue the second interrupt until the first is finished.

It works by setting a flag in a register at the moment the interrupt occurs. Then between instructions it checks that flag and executes the associated interrupt routine. If an interrupt is in progress at the time the flag still gets set, but it is unable to check the state of that flag until after the current interrupt is over and normal execution occurs, at which point after the next instruction is completed it checks the interrupt flag statuses and runs the second interrupt routine.

Answer 2

It depends on the specific MCU, not all are exactly the same.

Some have interrupt priority circuitry that you can use. But in general, an ISR can be interrupted by another incoming IRQ, etc. What you often do in an ISR is mask IRQ, handle the IRQ, and then unmask to let any pending IRQs be handled.

This is one reason why long-running ISRs should be avoided!