Difference Between Interrupt and Polling

In the world of embedded systems and microprocessor design, one of the most fundamental decisions a developer faces is how to detect and respond to events. Should the CPU constantly check the status of a device, or should it go about its business and let the device tap it on the shoulder when something happens?

These two approaches are known as Polling and Interrupts. Choosing the wrong method can lead to wasted energy, missed data, or system crashes. This article explains both techniques, highlights their key differences, and provides a clear framework for deciding which one to use.

Interrupts and polling are techniques to manage peripheral device communication with a CPU. Interrupts are hardware-based, where devices signal the CPU only when service is needed, maximising efficiency. Polling is a software-based approach where the CPU repeatedly checks device status, which is simpler but wastes cycles. Interrupts are preferred for speed and low power, while polling works for simple, low-cost applications.

What is Polling?

Polling is the active, continuous checking of a device’s status by the CPU. Imagine a busy manager who walks to the mailroom every 30 seconds to see if a letter has arrived.

In technical terms, the CPU runs a loop that repeatedly reads a status register (a “flag”) on a peripheral device (e.g., a UART, ADC, or GPIO pin). If the flag indicates an event (e.g., “data ready”), the CPU processes it. If not, the CPU checks again immediately or after a short delay.

Simple Polling Example (Pseudocode)

Advantages of Polling

Simple to implement and debug. No complex interrupt vector tables or priority schemes.
Predictable execution. The code follows a linear path; no unexpected jumps.
No overhead of saving/restoring CPU context. The CPU doesn’t need to push registers onto the stack.
Ideal for simple, low-end microcontrollers that lack an interrupt controller.

Disadvantages of Polling

Wastes CPU cycles. The CPU spends most of its time checking flags, even when no event has occurred. This burns power and reduces throughput.
Slow response time. The worst-case latency is the entire polling loop duration. If the loop takes 100ms, you could miss a 50ms pulse.
Difficult to prioritize events. All devices are checked in sequence; a low-priority device can block the check for a high-priority one.
Cannot handle events during long operations. If a delay() or a slow calculation is running, no polling occurs.

What is an Interrupt?

An interrupt is a hardware-driven, asynchronous signal that temporarily pauses the CPU’s current task to run special code called an Interrupt Service Routine (ISR). This is like a manager who hires a receptionist to call him the instant a letter arrives, allowing him to focus on reports in the meantime.

When an interrupt occurs:

The CPU finishes the current instruction.
It saves its current state (registers, program counter) onto the stack.
It looks up the address of the ISR from the Interrupt Vector Table.
It jumps to and executes the ISR.
Upon finishing the ISR, it restores the saved state and resumes the original task.

Simple Interrupt Example (Pseudocode)

Key Differences: Interrupts vs. Polling

Operation Method:In polling, the CPU constantly checks the command-ready bit of each device. In interrupts, the processor is disturbed only when a device sends a signal.
Efficiency:Polling often wastes CPU cycles, whereas interrupts provide a more efficient, responsive method.
Latency:Interrupts offer faster, near-instant response times compared to the periodic checking of polling.
Complexity:Polling is easy to implement (e.g., while(!ready);), while interrupts require higher complexity in software (Interrupt Service Routines/ISRs).
Resource Usage:Interrupts allow the CPU to perform other tasks or sleep, conserving power; polling requires continuous active monitoring.

Advantages of Interrupts

Highly efficient. The CPU only responds when an event occurs, spending the rest of its time on productive tasks.
Fast, deterministic response. Latency is measured in microseconds (a few dozen CPU cycles), not milliseconds.
Supports prioritization. High-priority interrupts (e.g., fire alarm) can preempt low-priority ones (e.g., button press).
Ideal for real-time systems where missing a deadline is catastrophic.
Excellent for low-power design. The CPU can enter a “sleep” mode and wake only on interrupts.

Disadvantages of Interrupts

Complexity. Requires setting up interrupt vectors, priorities, and managing shared data (critical sections).
Risk of race conditions. If the main code and an ISR access the same variable, data corruption can occur (requires volatile and atomic operations).
Stack overhead. Each interrupt uses stack space to save context. Deep nesting can cause a stack overflow.
Latency from disabled interrupts. Some critical sections of code must disable interrupts, temporarily increasing response time.
Hardware dependent. The interrupt controller and priority scheme vary between microcontroller families.

Major Differences between Interrupt and Polling

When to Use Which Method: A Decision Framework

There is no “always correct” answer. The right choice depends on the event frequency, required latency, system complexity, and power budget.

Use Polling When:

The event is extremely rare or predictable. Example: A user pressing a configuration button once per day. The CPU overhead of an interrupt isn’t justified.
The response time requirement is slow (tens of milliseconds). Example: Reading a temperature sensor every 2 seconds. Polling a timer flag is perfectly fine.
The CPU has nothing else to do. In a single-purpose device (e.g., a LED blinker), polling simplifies the code.
You are on a very simple 8-bit microcontroller with limited interrupt capabilities (e.g., some PIC10F or ATtiny parts).
The event duration is longer than the polling interval. If you check every 1ms and the signal lasts 5ms, you will catch it.
You are debugging. Polling makes flow control explicit and easier to trace with a logic analyzer or serial print statements.

Use Interrupts When:

The event is frequent and requires immediate attention. Example: A high-speed UART receiving data at 115,200 baud. Polling will almost certainly miss bytes.
Power consumption is critical. Battery-powered IoT sensors must sleep most of the time and wake only on interrupts (e.g., a motion sensor or a real-time clock alarm).
You have real-time deadlines. Example: An engine control unit (ECU) that must fire a spark plug within 100µs of a crankshaft position pulse.
The CPU must multitask. The main loop runs a complex algorithm or a GUI, while background I/O happens via interrupts.
The event is asynchronous and unpredictable. A limit switch on a robotic arm can trigger at any moment; polling would require impossibly fast checking.
Handling multiple peripherals with different urgencies. A DMA completion interrupt (high priority) vs. a low-battery warning (low priority).

The Hybrid Approach: Polling + Timer Interrupts

In professional embedded systems, a hybrid method is common. You use a timer interrupt to create a fixed time base (e.g., 1 kHz). Inside that ISR, you set flags. Then, the main loop polls those flags.

Why this works: The ISR remains short (just setting a flag), avoiding race conditions. The main loop gets deterministic, polled behavior, but the timing is driven by a precise hardware interrupt. This is the backbone of most real-time operating systems (RTOS).

A Practical Rule of Thumb

If the time to process an event is longer than the time between events, you must use interrupts (or a buffer).

Otherwise, you will lose data.

And finally:

Simple school project with buttons/LEDs? Use polling.
Commercial product with a battery? Use interrupts.
High-speed communication (SPI, I2C, UART)? Use interrupts (or DMA + interrupts).
Safety-critical system? Use a combination: timer interrupt for periodic safety checks, and priority interrupts for emergency stops.

Conclusion

Polling and interrupts are not enemies; they are tools. Polling is like checking your phone every few minutes—simple and fine for non-urgent matters. Interrupts are like a phone’s ringer—essential for real-time communication, but requiring setup to avoid chaos.

Start with polling for simplicity. When you face missed events, high power consumption, or slow response times, graduate to interrupts. Master both, and you will design embedded systems that are efficient, responsive, and robust.