what's wrong in using interrupt handlers as event listeners

Question

My system is simple enough that it runs without an OS, I simply use interrupt handlers like I would use event listener in a desktop program. In everything I read online, people try to spend as little time as they can in interrupt handlers, and give the control back to the tasks. But I don't have an OS or real task system, and I can't really find design information on OS-less targets.

I have basically one interrupt handler that reads a chunk of data from the USB and write the data to memory, and one interrupt handler that reads the data, sends the data on GPIO and schedule itself on an hardware timer again.

What's wrong with using the interrupts the way I do, and using the NVIC (I use a cortex-M3) to manage the work hierarchy ?

Answer 1

First of all, in the context of this question, let's refer to the OS as a scheduler.

Now, unlike threads, interrupt service routines are "above" the scheduling scheme.

In other words, the scheduler has no "control" over them.

An ISR enters execution as a result of a HW interrupt, which sets the PC to a different address in the code-section (more precisely, to the interrupt-vector, where you "do a few things" before calling the ISR).

Hence, essentially, the priority of any ISR is higher than the priority of the thread with the highest priority.

So one obvious reason to spend as little time as possible in an ISR, is the "side effect" that ISRs have on the scheduling scheme that you design for your system.

Since your system is purely interrupt-driven (i.e., no scheduler and no threads), this is not an issue.

However, if nested ISRs are not allowed, then interrupts must be disabled from the moment an interrupt occurs and until the corresponding ISR has completed. In that case, if any interrupt occurs while an ISR is in execution, then your program will effectively ignore it.

So the longer you spend inside an ISR, the higher the chances are that you'll "miss out" on an interrupt.