Polling for a single event is not only wasteful in terms of CPU cycles and power – it also results in a system that isn't responsive to anything else, which should generally be avoided. So then, how can we get a single core processor to do things in parallel? Well, we can't – there's only one processor after all. . . but since our processor is likely to be running millions of instructions per second, it is possible to get it to perform things that are close enough to parallel. MCUs also include dedicated hardware for generating interrupts. Interrupts provide signals to the MCU that allow it to jump directly to an interrupt service routine (ISR) when the event occurs. This is such a critical piece of functionality that ARM Cortex-M cores provide a standardized peripheral for it, called the nested vector interrupt controller (NVIC). The NVIC provides a common way of dealing with interrupts. The nested portion of this term signifies that even interrupts can be interrupted by other interrupts with a higher priority. This is quite convenient since it allows us to minimize the amount of latency and jitter for the most time-critical pieces of the system.
So, how do interrupts fit into a super loop in a way that better achieves the illusion of parallel activity? The code inside an ISR is generally kept as short as possible, in order to minimize the amount of time spent in the interrupt. This is important for a few reasons. If the interrupt occurs very often and the ISR contains a lot of instructions, there is a chance that the ISR won't return before being called again. For communication peripherals such as UART or SPI, this will mean dropped data (which obviously isn't desirable). Another reason to keep the code short is because other interrupts also need to be serviced, which is why it's a good idea to push off any responsibility to the code that isn't running inside an ISR context.
To quickly get an idea of how ISRs contribute to jitter, let's take a look at a simple example of an external analog to digital converter (ADC) signaling to an MCU that a reading has been taken and the conversion is ready to be transferred to the MCU (refer to the hardware diagram shown here):
In the ADC hardware, a pin is dedicated to signaling that a reading of an analog value has been converted to a digital representation and is ready for transfer to the MCU. The MCU would then initiate a transfer over the communication medium (COM in the diagram).
Next, let's have a look at how the ISR calls might stack up against one another over time, relative to the rising edge on the conversion ready line. The following diagram shows six different instances of ISR being called in response to a rising edge of a signal. The small amount of time between when the rising edge occurs in the hardware versus when the ISR in firmware is invoked is the minimum latency. The jitter in the response of the ISR is the difference in the latency over many different cycles:
There are different ways to minimize latency and jitter for critical ISRs. In ARM Cortex-M-based MCUs, interrupt priorities are flexible – a single interrupt source can be assigned different priorities at runtime. The ability to reprioritize interrupts is one way of making sure the most important parts of a system get the CPU when they need it.
As mentioned before, it is important to keep the amount of code executing in interrupts as short as possible, since code that is inside an ISR will take precedence over any code that is not in an ISR (for example main()). Additionally, lower priority ISRs won't be executed until all of the code in a higher priority ISR has been executed and the ISR exits – which is why it is important to keep ISRs short. It is always a good idea to try and limit how much responsibility (and therefore code) an ISR has.