Why interrupts are needed in Embedded C - Challenge Your Understanding

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why use interrupts instead of polling?

In embedded systems, why are interrupts preferred over polling for handling external events?

A Interrupts allow the CPU to perform other tasks and respond immediately when an event occurs.

B Interrupts slow down the CPU because they require constant checking of event flags.

C Polling uses less power than interrupts because it checks events continuously.

D Polling is better because it guarantees no events are missed.

💡 Hint

Think about how the CPU can do other work while waiting for an event.

Interrupts let the CPU work on other tasks and only stop to handle events when they happen, making the system more efficient.

❓ Predict Output

intermediate

Output of interrupt-driven vs polling code

What will be the output of the following embedded C code snippets?

Assume an external button press triggers an interrupt.

Embedded C

/* Interrupt-driven code snippet */
volatile int button_pressed = 0;
void ISR_button() {
    button_pressed = 1;
}
int main() {
    while(1) {
        if(button_pressed) {
            printf("Button pressed!\n");
            button_pressed = 0;
        }
    }
}

/* Polling code snippet */
int main() {
    while(1) {
        if(read_button_pin() == PRESSED) {
            printf("Button pressed!\n");
        }
    }
}

A Both print 'Button pressed!' repeatedly while button is pressed.

B Interrupt-driven never prints; polling prints once per press.

C Both print 'Button pressed!' only once per press.

D Interrupt-driven prints 'Button pressed!' once per press; polling prints repeatedly while pressed.

💡 Hint

Consider how often the print statement runs in each method.

Interrupt-driven code sets a flag once per press, printing once. Polling checks continuously and prints repeatedly while the button is held.

🔧 Debug

advanced

Identify the problem with this interrupt handler

What issue does this interrupt handler code have?

Embedded C

volatile int count = 0;
void ISR_timer() {
    count++;
    delay(1000); // Delay inside interrupt
}
int main() {
    setup_timer_interrupt(ISR_timer);
    while(1) {
        // main loop
    }
}

A Interrupt handler is missing a return statement.

B Incrementing count inside interrupt causes data corruption.

C Delay inside interrupt blocks other interrupts and main code, causing system lag.

D Timer interrupt is not enabled properly.

💡 Hint

Think about what happens if the interrupt takes too long.

Delays inside interrupts block the CPU from handling other tasks or interrupts, causing slow or unresponsive behavior.

📝 Syntax

advanced

Correct syntax for declaring an interrupt service routine (ISR)

Which option shows the correct way to declare an ISR for a button press in embedded C?

A void ISR_button(void) __interrupt { /* code */ }

B void __interrupt() ISR_button(void) { /* code */ }

C void ISR_button() interrupt { /* code */ }

D interrupt void ISR_button() { /* code */ }

💡 Hint

Look for the correct placement of the interrupt keyword and function signature.

In many embedded C compilers, the ISR is declared with void __interrupt() before the function name.

🚀 Application

expert

Design a system using interrupts to handle multiple sensors

You have three sensors connected to an embedded system. Each sensor triggers an interrupt when it detects an event. How should you design the interrupt handling to efficiently process events from all sensors?

A Use separate ISRs for each sensor, set flags in each ISR, and process all flags in the main loop.

B Use one ISR for all sensors and process all sensor data inside the ISR directly.

C Disable interrupts and poll sensors continuously in the main loop instead of using ISRs.

D Use one ISR that ignores sensor events and processes data only in the main loop.

💡 Hint

Consider how to keep ISRs short and avoid blocking.

Separate ISRs set flags quickly, letting the main loop handle processing without blocking interrupts, improving responsiveness.