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.

Practice

1. Which statement best describes polling in embedded C programming?

easy

A. Polling repeatedly checks for an event in a loop.

B. Polling uses special functions to respond automatically to events.

C. Polling is more efficient than interrupt-driven execution.

D. Polling disables all hardware interrupts.

Solution

1. Step 1: Understand polling concept

   Polling means the program continuously checks if an event has happened by running a loop.

2. Step 2: Compare options

   Polling repeatedly checks for an event in a loop. correctly states polling as repeated checking. Options A, B, and C describe interrupts or incorrect facts.

3. Final Answer:

   Polling repeatedly checks for an event in a loop. -> Option A

4. Quick Check:

   Polling = repeated checking [OK]

Hint: Polling means checking repeatedly in a loop [OK]

Common Mistakes:

• Confusing polling with interrupts
• Thinking polling is automatic
• Assuming polling disables interrupts

2. Which of the following is the correct way to declare an interrupt service routine (ISR) in embedded C?

easy

A. void ISR() { /* code */ }

B. __interrupt void ISR() { /* code */ }

C. void interrupt ISR() { /* code */ }

D. interrupt void ISR() { /* code */ }

Solution

1. Step 1: Recall ISR declaration syntax

   In many embedded C compilers, the keyword __interrupt before the function declares it as an ISR.

2. Step 2: Check options

   __interrupt void ISR() { /* code */ } uses __interrupt correctly. Options A, B, and D use incorrect or incomplete syntax.

3. Final Answer:

   __interrupt void ISR() { /* code */ } -> Option B

4. Quick Check:

   ISR declaration = __interrupt keyword [OK]

Hint: ISR functions use __interrupt keyword before return type [OK]

Common Mistakes:

• Omitting __interrupt keyword
• Placing interrupt keyword after void
• Using plain void without interrupt

3. Consider this embedded C code snippet using polling:

while(1) {
  if (button_pressed()) {
    toggle_led();
  }
}

What happens when the button is pressed?

medium

A. The LED never toggles because interrupts are disabled.

B. The LED toggles only after the loop finishes.

C. The LED toggles immediately when the button is pressed.

D. The LED toggles only if an interrupt triggers.

Solution

1. Step 1: Analyze the polling loop

   The loop continuously checks if button_pressed() returns true, then calls toggle_led() immediately.

2. Step 2: Understand behavior on button press

   When the button is pressed, button_pressed() becomes true, so toggle_led() runs right away.

3. Final Answer:

   The LED toggles immediately when the button is pressed. -> Option C

4. Quick Check:

   Polling triggers action immediately on event [OK]

Hint: Polling checks and acts immediately inside the loop [OK]

Common Mistakes:

• Thinking toggle waits for loop end
• Confusing polling with interrupts
• Assuming interrupts are required

4. This code tries to use interrupts but has a bug:

void ISR() {
  toggle_led();
}

int main() {
  enable_interrupts();
  while(1) {}
}

What is the main problem?

medium

A. enable_interrupts() is called inside main loop.

B. The main loop should not be infinite.

C. toggle_led() cannot be called inside ISR.

D. ISR is missing the __interrupt keyword.

Solution

1. Step 1: Check ISR declaration

   The ISR function lacks the __interrupt keyword, so it won't be recognized as an interrupt handler.

2. Step 2: Review other code parts

   enable_interrupts() is correctly called once; toggle_led() can be called in ISR; infinite loop is normal in embedded main.

3. Final Answer:

   ISR is missing the __interrupt keyword. -> Option D

4. Quick Check:

   ISR needs __interrupt keyword [OK]

Hint: ISR must have __interrupt keyword to work [OK]

Common Mistakes:

• Forgetting __interrupt keyword
• Thinking infinite loop is wrong
• Assuming toggle_led() is invalid in ISR

5. You want to design a program that reads a sensor value only when it changes, without wasting CPU time checking constantly. Which method is best?

hard

A. Use an interrupt triggered by the sensor change.

B. Use polling to check sensor value in a tight loop.

C. Use a delay loop to check sensor every second.

D. Use a timer to poll sensor every millisecond.

Solution

1. Step 1: Understand the requirement

   The program should react only when the sensor changes and avoid wasting CPU time on constant checking.

2. Step 2: Compare methods

   Polling (options B, C, D) wastes CPU by checking repeatedly. Interrupt (Use an interrupt triggered by the sensor change.) triggers only on change, saving CPU.

3. Final Answer:

   Use an interrupt triggered by the sensor change. -> Option A

4. Quick Check:

   Interrupts save CPU by reacting only on events [OK]

Hint: Use interrupts to react only when events happen [OK]

Common Mistakes:

• Choosing polling for efficiency
• Using delays wastes CPU
• Confusing timer polling with interrupts