Polling vs interrupt-driven execution in Embedded C - Practice Questions

Challenge - 5 Problems

❓ Predict Output

intermediate

Output of polling loop checking a flag

What will be the output of this embedded C code simulating a polling loop checking a flag variable?

Embedded C

#include <stdio.h>
#include <stdbool.h>

volatile bool flag = false;

int main() {
    int count = 0;
    while (count < 5) {
        if (flag) {
            printf("Flag set!\n");
            flag = false;
            count++;
        } else {
            printf("Waiting...\n");
            count++;
        }
    }
    return 0;
}

A

Waiting...
Flag set!
Waiting...
Flag set!
Waiting...

B

Waiting...
Waiting...
Waiting...
Waiting...
Waiting...

C

Waiting...
Waiting...
Waiting...
Waiting...
Flag set!

D

Flag set!
Flag set!
Flag set!
Flag set!
Flag set!

💡 Hint

The flag variable is never set to true in this code, so the polling loop never detects it as true.

Since the flag variable is never changed to true, the if condition is never met. The program prints "Waiting..." five times and then exits.

❓ Predict Output

intermediate

Output of interrupt-driven flag set simulation

Given this simplified embedded C code simulating an interrupt setting a flag, what is the output?

Embedded C

#include <stdio.h>
#include <stdbool.h>

volatile bool flag = false;

void interrupt_handler() {
    flag = true;
}

int main() {
    int count = 0;
    while (count < 3) {
        if (flag) {
            printf("Interrupt detected!\n");
            flag = false;
            count++;
        } else {
            printf("No interrupt\n");
        }
        if (count == 1) {
            interrupt_handler();
        }
    }
    return 0;
}

A

No interrupt
Interrupt detected!
Interrupt detected!

B

No interrupt
No interrupt
Interrupt detected!

C

No interrupt
No interrupt
No interrupt

D

Interrupt detected!
Interrupt detected!
Interrupt detected!

💡 Hint

The interrupt_handler sets the flag only after the first loop iteration.

Initially, flag is false, so "No interrupt" prints. After count == 1, interrupt_handler sets flag true. Next two loops detect the flag and print "Interrupt detected!" twice.

🧠 Conceptual

advanced

Why is interrupt-driven execution more efficient than polling?

Which of the following best explains why interrupt-driven execution is generally more efficient than polling in embedded systems?

A Interrupt-driven execution requires the CPU to check flags continuously, increasing CPU load.

B Polling uses less power because it constantly checks the flag, making it more efficient.

C Interrupt-driven execution allows the CPU to perform other tasks until an event occurs, reducing wasted cycles.

D Polling allows immediate response to events without delay, making it more efficient.

💡 Hint

Think about what the CPU does while waiting for an event in both methods.

Interrupt-driven execution lets the CPU do other work or sleep until an event triggers an interrupt, saving CPU cycles and power. Polling wastes CPU time checking repeatedly.

🔧 Debug

advanced

Identify the bug in this interrupt-driven flag example

What is the main problem with this embedded C code simulating an interrupt-driven flag?

Embedded C

#include <stdio.h>
#include <stdbool.h>

volatile bool flag = false;

void interrupt_handler() {
    flag = true;
}

int main() {
    int count = 0;
    while (count < 3) {
        if (flag) {
            printf("Interrupt detected!\n");
            flag = false;
            count++;
        }
    }
    return 0;
}

A The count variable is not incremented inside the if statement.

B The interrupt_handler function is missing a return type.

C The main function should call interrupt_handler() inside the loop.

D The flag variable should be declared volatile to prevent compiler optimization issues.

💡 Hint

Consider how the compiler might optimize access to the flag variable without volatile.

Without volatile, the compiler may optimize away repeated reads of flag, causing the loop to never detect changes made by the interrupt handler.

🚀 Application

expert

Choosing between polling and interrupt-driven execution

You are designing an embedded system that must respond to a button press within 1 millisecond and also perform heavy background data processing. Which approach is best and why?

A Use interrupt-driven execution for the button press to ensure fast response, and polling for background processing to simplify design.

B Use polling for the button press to guarantee immediate detection, and interrupts for background processing to save power.

C Use polling for both button press and background processing to keep the system simple and predictable.

D Use interrupt-driven execution for background processing and polling for the button press to prioritize tasks.

💡 Hint

Consider which tasks require immediate response and which can be done in the background.

Interrupt-driven execution allows immediate response to the button press without wasting CPU cycles, while polling can be used for background tasks that are less time-critical.

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