Polling vs interrupt-driven execution in Embedded C - Visual Side-by-Side Comparison

Concept Flow - Polling vs interrupt-driven execution

Start

↓

Check device status

↓

Is device ready?

No→Repeat check

Yes↓

Process device data

↓

Back to check

↓

Start

↓

Main program runs

↓

Interrupt occurs?

No→Continue main program

Yes↓

Interrupt handler runs

↓

Return to main program

Polling repeatedly checks device status in a loop, while interrupt-driven execution waits for a signal to run a handler.

Execution Sample

Embedded C

while(1) {
  if(device_ready()) {
    process_data();
  }
}

// Interrupt handler
void ISR() {
  process_data();
}

Polling loop checks device readiness continuously; interrupt handler runs only when device signals.

Execution Table

Step	Polling Condition	Polling Action	Interrupt Event	Interrupt Action	Output
1	device_ready() == false	Check again	No	None	No data processed
2	device_ready() == false	Check again	No	None	No data processed
3	device_ready() == true	process_data() called	No	None	Data processed
4	device_ready() == false	Check again	Yes	ISR runs	Data processed by ISR
5	device_ready() == false	Check again	No	None	No data processed
6	device_ready() == true	process_data() called	No	None	Data processed
7	device_ready() == false	Check again	No	None	No data processed
Exit	Loop runs forever	Polling continues	Interrupts may occur anytime	ISR runs on interrupt	Continuous operation

💡 Polling loop never exits; interrupt handler runs asynchronously when interrupt occurs.

Variable Tracker

Variable	Start	After Step 1	After Step 2	After Step 3	After Step 4	After Step 5	After Step 6	After Step 7	Final
device_ready()	false	false	false	true	false	false	true	false	varies
Interrupt Event	No	No	No	No	Yes	No	No	No	varies
Data Processed	No	No	No	Yes	Yes	No	Yes	No	varies

Key Moments - 3 Insights

Why does polling waste CPU time when device_ready() is false?

Because polling keeps checking device_ready() in a loop even when the device is not ready, as shown in execution_table rows 1 and 2 where the CPU repeatedly checks without doing useful work.

How does interrupt-driven execution improve efficiency?

Interrupt-driven execution waits for an interrupt event before running the handler, so the CPU can do other tasks instead of constantly checking, as seen in execution_table row 4 where ISR runs only when interrupt occurs.

Can polling and interrupts run together?

Yes, polling can run continuously while interrupts can occur asynchronously, as shown in execution_table where polling steps and interrupt events happen independently.

Visual Quiz - 3 Questions

Look at the execution_table at Step 3, what happens when device_ready() is true in polling?

A The program stops checking device status

B The program waits for an interrupt

C The program processes data by calling process_data()

D The program ignores the device

💡 Hint

Check the 'Polling Action' and 'Output' columns at Step 3 in execution_table.

At which step does the interrupt handler run according to the execution_table?

A Step 4

B Step 2

C Step 6

D Step 7

💡 Hint

Look at the 'Interrupt Event' and 'Interrupt Action' columns to find when ISR runs.

If device_ready() is always false, what will happen in polling?

A process_data() will be called repeatedly

B The program will keep checking device_ready() without processing data

C The program will stop running

D Interrupt handler will run automatically

💡 Hint

Refer to variable_tracker for device_ready() values and execution_table rows 1 and 2.

Concept Snapshot

Polling:
- CPU repeatedly checks device status in a loop
- Wastes CPU time if device not ready

Interrupt-driven:
- CPU runs main tasks
- Interrupt triggers handler only when needed
- More efficient for event-driven tasks

Full Transcript

This visual execution compares polling and interrupt-driven execution in embedded C. Polling uses a loop to check if a device is ready, calling process_data() only when ready. This wastes CPU time when the device is not ready, as the CPU keeps checking. Interrupt-driven execution lets the CPU run other tasks and only runs an interrupt service routine (ISR) when the device signals an interrupt. The execution table shows polling steps checking device_ready() and interrupt events triggering ISR. Variable tracking shows device_ready() status and when data is processed. Key moments clarify why polling wastes CPU and how interrupts improve efficiency. The quiz tests understanding of when process_data() runs and when interrupts occur. The snapshot summarizes polling as continuous checking and interrupts as event-driven handling for better CPU use.