Polling vs interrupt-driven execution in Embedded C - Trade-offs & Expert Analysis

Overview - Polling vs interrupt-driven execution

What is it?

Polling and interrupt-driven execution are two ways a microcontroller or processor can handle events or inputs. Polling means the processor repeatedly checks if an event happened, like asking "Is there new data?" over and over. Interrupt-driven execution means the processor waits for a signal (interrupt) that tells it when something needs attention, so it can do other tasks until then. Both methods help the processor respond to hardware or software events.

Why it matters

Without these methods, a processor would waste time or miss important events. Polling can waste energy and slow down other tasks because it constantly checks for events. Interrupts allow the processor to be efficient and responsive, improving performance and power use. Understanding these helps design better embedded systems that work smoothly and save battery life.

Where it fits

Before learning this, you should know basic programming and how microcontrollers run code step-by-step. After this, you can learn about real-time operating systems, multitasking, and advanced hardware communication techniques.

Mental Model

Core Idea

Polling is like repeatedly asking if something happened, while interrupt-driven execution is like being told immediately when it happens.

Think of it like...

Imagine waiting for a friend at a cafe: polling is like constantly looking at the door to see if they arrived, while interrupt-driven is like your friend calling you when they get there.

┌───────────────┐       ┌───────────────┐
│   Polling     │       │ Interrupt-    │
│               │       │ driven        │
│  Loop:        │       │ execution:    │
│  Check event  │       │ Wait for      │
│  If event:    │       │ interrupt     │
│    Handle     │       │ Handle event  │
│  Repeat       │       │ Resume other  │
│               │       │ tasks         │
└──────┬────────┘       └──────┬────────┘
       │                       │
       ▼                       ▼
   Processor busy          Processor idle
   checking constantly     until event occurs

Build-Up - 7 Steps

1

Foundation

What is Polling in Embedded Systems

Concept: Polling means the processor checks repeatedly for an event or condition.

In polling, the program runs a loop that asks a device or sensor if it has data or needs attention. For example, checking if a button is pressed by reading its state over and over. This is simple to implement but uses processor time even when nothing happens.

Result

The processor spends time continuously checking, which can slow down other tasks.

Understanding polling shows how a processor can actively look for events but at the cost of efficiency.

2

Foundation

What is Interrupt-Driven Execution

Concept: Interrupts let hardware signal the processor to stop and handle an event immediately.

Instead of checking repeatedly, the processor runs normal code until a hardware signal (interrupt) tells it to pause and run a special function (interrupt handler). After handling, it returns to what it was doing. This saves time and power.

Result

The processor can do other work or sleep until an event happens.

Knowing interrupts helps see how processors can be more efficient and responsive.

3

Intermediate

Comparing CPU Usage in Polling vs Interrupts

🤔Before reading on: do you think polling or interrupts use more CPU time when events are rare? Commit to your answer.

Concept: Polling wastes CPU cycles checking for events, while interrupts let CPU rest until needed.

In polling, the CPU runs a loop constantly, even if no event occurs. In interrupt-driven, the CPU can sleep or do other tasks until an interrupt triggers. This difference affects power consumption and multitasking.

Result

Polling leads to higher CPU usage and power drain; interrupts reduce CPU load and save energy.

Understanding CPU usage differences explains why interrupts are preferred in power-sensitive or multitasking systems.

4

Intermediate

Latency and Responsiveness Differences

🤔Before reading on: which method reacts faster to events, polling or interrupts? Commit to your answer.

Concept: Interrupts usually respond faster to events than polling because they trigger immediately.

Polling checks events at fixed intervals, so response time depends on how often it checks. Interrupts notify the processor instantly when an event occurs, minimizing delay.

Result

Interrupt-driven systems have lower latency and better real-time responsiveness.

Knowing latency differences helps choose the right method for time-critical applications.

5

Intermediate

Implementing Polling in Embedded C

Concept: Polling is implemented by looping and checking device status in code.

Example: while(1) { if (button_pressed()) { handle_button(); } // other code } This loop keeps checking the button state continuously.

Result

The program reacts to button presses but uses CPU constantly.

Seeing polling code clarifies how simple but CPU-intensive polling is.

6

Advanced

Implementing Interrupts in Embedded C

🤔Before reading on: do you think interrupt handlers can run anywhere in code or only at specific times? Commit to your answer.

Concept: Interrupts require special handler functions registered to hardware events.

Example: void ISR_Button(void) __interrupt(0) { handle_button(); } int main() { enable_interrupts(); while(1) { // main code } } The ISR runs automatically when the button interrupt triggers.

Result

The program handles button presses immediately without constant checking.

Understanding interrupt handlers shows how hardware and software coordinate asynchronously.

7

Expert

Challenges and Pitfalls of Interrupts

🤔Before reading on: do you think interrupt handlers can safely use any code or have restrictions? Commit to your answer.

Concept: Interrupt handlers must be short, fast, and careful with shared data to avoid bugs.

Interrupts can cause problems like race conditions if they access variables used elsewhere. Handlers should avoid long operations or blocking calls. Sometimes nested interrupts or priority levels complicate design.

Result

Poor interrupt design can cause crashes, missed events, or corrupted data.

Knowing interrupt pitfalls is key to writing reliable embedded software.

Under the Hood

Polling works by the CPU executing a loop that reads device registers or memory repeatedly to check status bits. Interrupt-driven execution uses hardware interrupt lines connected to the CPU. When an event occurs, the hardware signals the CPU, which pauses current execution, saves context, and jumps to a predefined interrupt service routine (ISR). After ISR completes, CPU restores context and resumes normal code.

Why designed this way?

Polling is simple and was common in early microcontrollers with limited hardware. Interrupts were introduced to improve efficiency and responsiveness, allowing CPUs to handle multiple tasks and save power. The design balances hardware complexity and software control, with interrupts requiring more hardware support but enabling better system performance.

┌─────────────┐
│   CPU       │
│  ┌───────┐  │
│  │ Poll  │  │
│  │ Loop  │  │
│  └───────┘  │
│     ▲       │
│     │       │
│  Device     │
│  Status     │
└─────────────┘

Interrupt flow:

Device Event ──▶ Interrupt Controller ──▶ CPU Interrupt Line
                                      │
                                      ▼
                               Interrupt Service Routine
                                      │
                                      ▼
                               Resume Main Program

Myth Busters - 4 Common Misconceptions

Quick: Does polling always waste more power than interrupts? Commit yes or no.

Common Belief: Polling always wastes more power than interrupt-driven execution.

Reality: Polling can be efficient if events happen very frequently or if the polling loop includes sleep or wait instructions. Interrupts add overhead from context switching.

Why it matters: Assuming polling is always worse can lead to overcomplicated designs when simple polling would suffice.

Quick: Can interrupt handlers run any code safely? Commit yes or no.

Common Belief: Interrupt handlers can run any code just like normal functions.

Reality: Interrupt handlers must be short and avoid blocking or complex operations to prevent system instability.

Why it matters: Misusing interrupts can cause hard-to-debug crashes or missed events.

Quick: Does polling guarantee immediate event handling? Commit yes or no.

Common Belief: Polling always detects events immediately as they happen.

Reality: Polling only detects events when it checks, so there can be delays depending on polling frequency.

Why it matters: Relying on polling for time-critical tasks can cause missed deadlines or slow responses.

Quick: Are interrupts always better than polling? Commit yes or no.

Common Belief: Interrupt-driven execution is always the best choice over polling.

Reality: Interrupts add complexity and overhead; for very simple or fast tasks, polling may be simpler and more reliable.

Why it matters: Choosing interrupts without need can increase development time and bugs.

Expert Zone

1

Interrupt latency depends on CPU architecture, interrupt priority, and current CPU state, which affects real-time performance.

2

Shared resources accessed by both main code and interrupts require careful synchronization, often using volatile keywords and disabling interrupts briefly.

3

Some systems use hybrid approaches: polling for frequent events and interrupts for rare or critical ones.

When NOT to use

Avoid interrupts in extremely simple systems where polling is sufficient and easier to debug. Also, avoid interrupts when event frequency is very high, causing interrupt storms; use DMA or other hardware features instead.

Production Patterns

In real-world embedded systems, interrupts handle time-critical inputs like sensors or communication, while polling manages less urgent tasks. Developers often use interrupt-driven design combined with state machines and buffers to ensure data integrity and responsiveness.

Connections

Event-driven programming

Interrupt-driven execution is a hardware-level example of event-driven programming where code reacts to events asynchronously.

Understanding interrupts helps grasp how event-driven software frameworks work by responding to signals or messages.

Operating system scheduling

Interrupts trigger context switches in operating systems, enabling multitasking and responsive scheduling.

Knowing interrupt mechanics clarifies how OS kernels manage multiple programs and prioritize tasks.

Human reflexes

Interrupts are like human reflexes that automatically respond to stimuli without conscious thought.

Seeing interrupts as reflexes helps appreciate their speed and automatic nature in system responsiveness.

Common Pitfalls

#1 Using long or blocking code inside interrupt handlers.

Wrong approach:

void ISR() __interrupt(0) {
while(!device_ready()) {
// wait
}
process_data();
}

Correct approach:

void ISR() __interrupt(0) {
set_flag(); // just set a flag
}

int main() {
while(1) {
if(flag_set()) {
clear_flag();
process_data();
}
}
}

Root cause:

Misunderstanding that interrupt handlers must be quick and non-blocking to avoid delaying other interrupts or main code.

#2 Not declaring shared variables as volatile between main code and interrupts.

Wrong approach:

int flag = 0;

void ISR() __interrupt(0) {
flag = 1;
}

int main() {
while(flag == 0) {
// wait
}
// proceed
}

Correct approach:

volatile int flag = 0;

void ISR() __interrupt(0) {
flag = 1;
}

int main() {
while(flag == 0) {
// wait
}
// proceed
}

Root cause:

Forgetting that compiler optimizations can cache variables unless marked volatile, causing main code to miss changes made in interrupts.

#3 Polling too slowly and missing fast events.

Wrong approach:

while(1) {
if(check_sensor()) {
handle_event();
}
delay(1000); // 1 second delay
}

Correct approach:

while(1) {
if(check_sensor()) {
handle_event();
}
delay(1); // 1 millisecond delay
}

Root cause:

Not realizing that polling frequency affects event detection latency and missing events if too slow.

Key Takeaways

Polling repeatedly checks for events, using CPU time even when nothing happens, which can waste power and slow other tasks.

Interrupt-driven execution lets the processor respond immediately to events without constant checking, improving efficiency and responsiveness.

Interrupt handlers must be short and careful to avoid bugs like race conditions or system crashes.

Choosing between polling and interrupts depends on application needs, event frequency, and system complexity.

Understanding these methods is essential for designing reliable, efficient embedded systems that balance performance and power.