Introduction to Microcontrollers: 5 of 6
In this final session of our series covering MCU basics, we look at interrupt processing—one of the core concepts of MCU programming. We also look at the alternative process of polling.
Interrupts and Polling
This is the fifth and last topic to be covered in this “Introduction to Microcontrollers” series. Part 1 of the series explained about the MCU basic structure and operation, part 2 covered peripheral circuitry, part 3 covered programming languages and the software development environment, and part 4 looked at the basics of peripheral circuitry control. Today we look at interrupt processing, a key feature of MCU control.
This is the fifth and last topic to be covered in this “Introduction to Microcontrollers” series. Part 1 of the series explained about the MCU basic structure and operation, part 2 covered peripheral circuitry, part 3 covered programming languages and the software development environment, and part 4 looked at the basics of peripheral circuitry control. Today we look at interrupt processing, a key feature of MCU control.
Now assume that you are reading the book and waiting for the delivery, but you don’t have a doorbell and the delivery person has agreed to quietly drop the package off at your door. (In other words, you won’t be interrupted.) In this case, you would stop reading from time to time and go to the door to see if the package has been reached. In the MCU world, this type of periodic checking—the alternative to interrupts—is called polling.
Interrupt Processing by the MCU
In actuality, interrupt processing in the MCU is just slightly more complicated than the description above. But it’s still closely analogous to the book-reading example, as evident from the following.
| Processing an Interrupt at Home | Processing an Interrupt in the MCU |
| 1) You’re reading a book. | The main program is running. |
| 2) The delivery person rings bell. | An interrupt signal lets the MCU know that an event has occurred. |
| 3) Stop reading. | The MCU receives the interrupt signal, and suspends execution of the main program. |
| 4) Bookmark your current page. | The MCU saves the current program execution state into its registers. |
| 5) Get the delivery. | The MCU executes the interrupt routine corresponding to the received interrupt. |
| 6) Go back to the marked page. | The MCU restores the saved program execution state. |
| 7) Resume reading from where you left off. | Resume program execution. |
The above analogy should clarify the general idea. Now let’s look a little more closely at the actual process within an MCU.
When an event occurs, an interrupt signal is sent to notify the MCU. If the event occurs at an external device, the signal is sent into the MCU’s INT pin. If the event occurs in the MCU’s on-chip peripheral circuitry such as a timer increment or a serial I/F event—then the interrupt signal is issued internally.
These interrupt signals are received and processed by the MCU’s Interrupt Controller (IC). If multiple interrupt signals are received, the IC’s logic decides the order in which they are to be handled (based on each device’s priority level), and then sends the corresponding interrupt request signals to the CPU in the appropriate order. (The IC can also be set to ignore, or “mask,” particular interrupts, to block out unwanted interruptions.) When the CPU receives the request, it suspends current program execution and then loads and runs the interrupt processing code corresponding to the interrupt.
Real-Time Processing
While interrupts and polling carry out similar processing, there is a notable difference. Where interrupts are used, the MCU is immediately alerted when an event occurs, and can quickly switch to the requested processing. This rapid responsiveness is often referred to as real-time processing.
In theory, polling can also be rapid, provided that the polling frequency is very high. In practice, however, operation is slowed by the need to poll for multiple events, and by the difficulties of the main processing with a sufficiently short polling loop.
For example, consider the case where an MCU is expecting a user to eventually press a switch. Since the MCU has no way to predict when this will happen, it must continue looping and polling indefinitely. This idle looping can consume considerable amounts of CPU processing time. And if it is necessary to poll for a variety of events, then it becomes increasingly difficult to keep the polling interval short enough for rapid response.
Interrupt processing may be slightly more difficult for programmers to write, since it requires a reasonable understanding of the MCU’s hardware. But interrupts are an essential feature of MCU programming, and cannot be sidestepped. Programmers are encouraged to deepen their knowledge of MCU architecture and learn how to write effective interrupt handlers.
This completes our series on MCU basics. We hope you have found these sessions interesting, and we encourage you to proceed to some hands-on practice with MCUs.