Why and How of using Interrupts : Embedded Systems
Embedded Systems make up most of the electronic devices in our lives. These are micro-computers that may not have big RAM and Hard drives like our traditional computers, but are much more effective in doing their required task. So while the typical processors in our phones and computers provide high speeds and can do a variety of task, they also consume a lot of power and may lack the features to be built into portable and battery operated modules.
Embedded systems on the other hand, are design to perform very specific applications. Since, their scope of operations is limited, it is easier to build and design software that will optimally make use of all their limited resources.
Interrupt
An interrupt is essentially an input signal to the CPU of a micro-controller or processor. When the signal is received, the CPU halts the execution of currently running tasks and performs a list of commands associated with the interrupt. It then resumes normal operations once the interrupt is handled. This process may appear simple at first, but it is a crucial element of power critical embedded systems.
An example of the utility of interrupt in Embedded Devices can be how a device reads data from a sensor. A microcontroller needs to receive data from a sensor. This data communication may happen in one of several ways when not using an interrupt.
1. Sensor sends the data continuously and the microcontroller reads data when it is ready.
2. Microcontroller reads data from the sensor by polling a register in the sensor and fetching data from it.
In the first case, the sensor may possibly be sending data when the microcontroller may not even have a need for it. The sensor is bound to consume power for each time it sends data and in embedded systems which have to operate using limited power, it is not a very practical solution.
In the the second case, the microcontroller may poll faster than the sensor can collect data. Thus, it might be getting repeat values which is again a waste of resources since each time the microcontroller polls the sensor, its other processes get blocked in execution.
Interrupts are usually built into sensors and are essentially a signal, either high or low. The microcontroller receives this signal at a GPIO pin and an interrupt is triggered when the signal switches state. This is a viable indication to the GPIO to execute some set of actions since the state of the sensor has verifiably changed.
In the example above, the sensor will toggle the interrupt when its data is ready and send the data only when the microcontroller responds to that interrupt. Thus, the sensor is not blindly sending data nor is the microcontroller wasting resources in needless polling. A win-win scenario.
Types of Interrupt Signals
- Rising Edge: This interrupt is triggered when the signal on the interrupt pin switches from Low-to-High state.
- Falling Edge: This is when the signal on the pin switches from a High-to-Low state.
Which interrupt signal is chosen, again boils down to our specific use case and application. I primarily work on battery powered embedded devices, so I mostly use the rising-edge signal. This is because, in the absence of an interrupt signal, the signal is typically pulled low, thus it consumes zero power. Any power consumption in such a scenario is only then the interrupt is triggered. Once the interrupt is triggered, the signal line again falls back to low. The trigger initiates the actions in an Interrupt Service Routine (ISR).
Conclusion and Further Reading
Although the article above does not delve very deep into the implementation on interrupts, by the hope of the simple example, I hope that it highlights the benefits of the use of interrupts. I see several hobby projects and first time users of Arduino poll for data in the loop function in Arduino IDE. Most Arduino platforms are power-hungry micro-controllers and by using interrupts they can be made more reliable and power-efficient.
I have also written another article highlighting the use of interrupts for the STM32 platform. The principles more or less remain the same and I hope it will help the readers write code that is power-efficient and reliable.
