Why Are Interrupts Better Than Polling?


In embedded systems, peripherals constantly generate events.

A UART receives a byte.
A timer expires.
A GPIO pin changes state.
An ADC conversion completes.

The processor needs to respond to these events.

There are two common approaches:

  • Polling
  • Interrupts

At first, polling looks simple. But interrupts usually provide a more efficient way for the CPU to respond to asynchronous events.

What Is Polling?

In polling, the CPU repeatedly checks whether an event has occurred.

For example:

while (1)
{
    if (UART_RX_READY)
    {
        read_uart_data();
    }
}

The processor keeps asking the UART:

"Did data arrive?"

If no data has arrived, the CPU checks again.

And again.

And again.

Imagine UART data arrives only once every 100 ms.

During those 100 ms, the CPU may check the same status flag thousands of times even though nothing has happened.

That CPU time could have been used for something else.

What Changes With Interrupts?

With interrupts, the CPU does not continuously check the peripheral.

Instead, the peripheral informs the CPU when an event occurs.

For example:

CPU executing main application
            |
            |
        UART receives data
            |
            v
   UART generates interrupt
            |
            v
   CPU pauses current work
            |
            v
      UART ISR executes
            |
            v
   CPU resumes previous work

The CPU can spend most of its time doing useful work.

Only when the UART actually receives data does the CPU handle it.

A Simple Analogy

Imagine waiting for a food delivery.

Polling

You keep opening the door every 10 seconds.

Check door
   ↓
Nobody there

Check again
   ↓
Nobody there

Check again
   ↓
Nobody there

This wastes your time.

Interrupt

Instead, the delivery person rings the doorbell.

You continue doing something else until:

Doorbell rings
      ↓
You respond

The doorbell is similar to an interrupt.

The event tells you when your attention is required.

Why Are Interrupts More Efficient?

1. Better CPU Utilization

With polling, the CPU spends time repeatedly checking status registers.

With interrupts, the CPU can execute:

Application code
Communication tasks
Control algorithms
Background processing

until an event occurs.

2. Lower Power Consumption

This becomes especially important in battery-powered systems.

With polling:

CPU awake
↓
Check peripheral
↓
Check peripheral
↓
Check peripheral

The CPU remains active.

With interrupts:

CPU enters sleep
      ↓
Peripheral event occurs
      ↓
Interrupt wakes CPU
      ↓
CPU processes event

The processor can remain in a low-power state until something actually requires attention.

3. Faster Response to Asynchronous Events

Some events can happen at unpredictable times.

Examples include:

  • UART receive
  • GPIO input
  • sensor data ready
  • external fault signal
  • timer expiration

Waiting for the next polling cycle introduces delay.

For example:

CPU polls GPIO
      |
      |---- does other processing ----|
                                      |
                              GPIO changes here
                                      |
                                      |---- waiting ----|
                                                       |
                                              Next GPIO poll

The event may not be detected immediately.

With an interrupt:

GPIO changes
     ↓
Interrupt generated
     ↓
CPU responds

The response can occur much sooner.

But Interrupts Are Not Free

An interrupt also introduces overhead.

When an interrupt occurs, the processor typically needs to:

Pause current execution
        ↓
Save execution context
        ↓
Find the ISR
        ↓
Execute ISR
        ↓
Restore context
        ↓
Resume previous execution

So if an event occurs extremely frequently, generating an interrupt for every event may become inefficient.

This is sometimes called an interrupt storm.

When Can Polling Be Better?

Polling is not inherently bad.

It can be useful when:

  • the event occurs very frequently
  • the CPU has nothing else important to do
  • deterministic timing is required
  • the operation takes only a few cycles
  • interrupt overhead would be larger than the polling cost

For example, firmware may briefly poll a hardware status bit:

while (!(STATUS_REG & READY_BIT))
{
}

If the peripheral becomes ready within only a few microseconds, setting up an interrupt may not provide much benefit.

Interrupts vs Polling

Polling Interrupt
CPU repeatedly checks the peripheral Peripheral alerts the CPU
CPU time may be wasted CPU can perform other work
Often keeps CPU active CPU can sleep
Response depends on polling interval Response occurs when event is raised
Simple implementation Requires ISR and interrupt configuration
Useful for very frequent/simple events Useful for asynchronous events

A Real Embedded-System Example

Suppose a microcontroller receives UART data once every second.

Polling approach

CPU
 |
 | Check UART
 | Check UART
 | Check UART
 | Check UART
 | Check UART
 |
 | DATA ARRIVES
 |
 | Read UART

Most checks returned nothing.

Interrupt approach

CPU runs application
        |
        |
        |
UART data arrives
        |
        v
Interrupt
        |
        v
Read UART
        |
        v
Resume application

The processor responds only when necessary.

The Key Idea

Polling asks:

"Did something happen?"

over and over again.

Interrupts say:

"Tell me when something happens."

That simple difference allows embedded systems to use CPU time and power much more efficiently.

One Important Design Rule

Interrupts are most effective when the ISR remains short.

A typical design is:

Interrupt occurs
      ↓
ISR captures the event/data
      ↓
ISR sets a flag / sends an event
      ↓
ISR exits quickly
      ↓
Main task performs the heavier processing

Comments

Post a Comment

Thanks for reading through the Embedded Systems World.
Feel free to ask questions or share your thoughts on the topic.

Popular posts from this blog

Why Do Microcontrollers Start with an Internal Oscillator?

Why Does a Microcontroller Start With an Internal Oscillator? When a microcontroller powers on, it needs one thing before it can execute even its first instruction: A clock. Most microcontrollers initially run from an internal oscillator. But if an external crystal is more accurate, why doesn't the microcontroller simply start with it? The answer comes down to startup speed, reliability, and initialization sequence. 1️⃣ Fast Startup Internal RC oscillators can become usable very quickly. External crystals need additional time for their oscillations to build and stabilize. Instead of waiting, the MCU can start executing firmware using its internal clock. Power ON → Internal Oscillator → CPU Starts Executing Meanwhile, the external clock source can be initialized and allowed to stabilize. 2️⃣ Guaranteed Availability The internal oscillator is built into the microcontroller. An external crystal depends on components outside the MCU, such as: • Crystal or resonator • Load capacitors • ...
Read more

What Happens Inside a Microcontroller in the First Few Microseconds After Power-On?

Image
When power is applied to a microcontroller, the CPU does not immediately start executing your program. Instead, a sequence of hardware-controlled steps occurs to prepare the system for execution. Understanding this startup process helps explain how embedded systems begin running firmware. 1. Power Is Applied When the device receives power: Internal circuits begin initializing. The microcontroller enters a reset state to ensure safe startup. During this stage, the CPU is held in reset and cannot execute instructions yet. 2. Internal Oscillator Starts Most microcontrollers start using an internal RC oscillator. The reason is simple: It starts very quickly It does not require external components It allows the processor to begin operating immediately This oscillator provides the initial system clock. 3. Reset Controller Holds the CPU Even though the clock has started, the CPU is still held in reset by the reset controller. This ensures: Power is stable Clock is stable Internal hardware is ...
Read more

Why RISC is ideal for embedded systems

Image
While revisiting CPU architecture concepts, I summarized why many microcontrollers use RISC architectures. 🔹 1. Predictable execution timing RISC processors typically use fixed-length instructions, making decoding simpler and execution timing more predictable — important for embedded and real-time systems. Example: ADD R1, R2, R3 SUB R4, R5, R6 🔹 2. Register-based operations RISC follows a Load–Store architecture. ALU operations use registers, while memory is accessed only through LOAD and STORE instructions. Example: LOAD R1, [100] LOAD R2, [104] ADD R3, R1, R2 STORE R3, [108] 🔹 3. Simpler hardware design Because instructions are simple and uniform, the control logic and instruction decoding hardware are simpler, which also helps reduce silicon die size. Example: MOV R1, R2 ADD R3, R1, R4 Conceptually: Register → ALU → Register 🔹 4. Efficient pipelining Fixed instruction formats allow CPUs to pipeline instructions efficiently, improving throughput. Example s...
Read more