Detailed analysis of the interrupt of the microcontroller

When the MCU CPU is processing an event A, another event B may occur and request the CPU to quickly respond (interrupt). The CPU temporarily stops what it is doing and handles event B (interrupt response and service). After event B is processed, the CPU returns to where it left off with event A and continues processing it. This process is known as an interrupt.

For example, imagine you're washing clothes when the phone rings. This interruption causes you to pause your task, answer the call, and then return to finish washing. This is a real-life example of an interrupt.

MCU interrupts are generally divided into two types: internal and external. External interrupts are generated by devices connected to the MCU, such as sensors or buttons. These signals are received through specific pins on the microcontroller. To trigger an external interrupt, the peripheral must provide one of five possible signal conditions: high level, low level, falling edge, rising edge, or both edges. Most MCUs have dedicated IO ports that can detect these signals and generate an interrupt accordingly.

However, some signal types like level-based triggers can cause issues. If the signal remains constant, the MCU might not receive repeated interrupts. For instance, if a device sends a low-level signal once, it won’t trigger again unless the signal changes. To solve this, some peripherals use pulse signals—changing from high to low and back again—to ensure continuous interrupt generation.

Some systems also include an interrupt clear function, allowing the MCU to reset the peripheral’s interrupt request signal. This ensures that the peripheral can trigger more interrupts in the future.

Internal interrupts, on the other hand, are generated by built-in modules within the MCU, such as timers, UARTs, or ADCs. These interrupts are triggered internally, often by setting a flag in a register. When the CPU responds to the interrupt, the flag is usually cleared to prevent repeated triggering.

Interrupt handling varies between MCUs. Some require developers to manually clear flags, while others do it automatically. Developers must configure interrupt control registers to enable or disable specific interrupts based on their needs. At startup, many MCUs disable all interrupts by default to avoid unexpected behavior until the system is ready.

Each interrupt has its own service routine, which the MCU executes when the interrupt occurs. These routines are typically written by the developer and placed in specific memory locations. Some MCUs use an interrupt vector table, which acts as a jump table directing the CPU to the correct service routine.

High-end MCUs may support interrupt prioritization and nesting. Priority determines which interrupt is handled first when multiple occur simultaneously. Nesting allows higher-priority interrupts to pause lower-priority ones, improving system responsiveness.

Finally, during an interrupt, the MCU saves the current program state before executing the service routine. Once the routine completes, it restores the state and resumes the main program. This ensures that the original execution flow isn't disrupted.