Interrupts & timers

ALearning Material

Naively, to react to an event you poll: loop forever asking "is the button pressed yet?" This wastes CPU and can miss fast events while you're busy elsewhere.

The naive way to react to an event is to poll. Loop forever asking 'is it pressed yet?', which wastes the CPU and can miss a fast event while you're busy doing something else. Interrupts invert that relationship: you tell the hardware 'when event X happens, immediately pause everything and run this small function, then resume', so the CPU does useful work (or sleeps) until the event actually occurs.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍That power comes with strict rules, and getting them wrong produces baffling bugs. An interrupt service routine must be short (flag it and get out) because the rest of the system is frozen while it runs. And any variable shared between the ISR and your main code must be volatile, or the compiler may cache a stale copy in a register and never notice the ISR changed it. Interrupts, short ISRs, and volatile are the trio that make event-driven firmware both responsive and correct.

Interrupts invert this. You tell the hardware "when event X happens, immediately pause whatever you're doing and run this small function (an ISR, Interrupt Service Routine), then resume." The CPU does useful work (or sleeps) until the event actually occurs.

volatile bool pressed = false;     // shared with the ISR -> must be volatile

void buttonISR() {                 // runs the instant the pin changes
    pressed = true;                // do the minimum; flag and exit
}

void setup() {
    attachInterrupt(BUTTON_PIN, buttonISR, FALLING);  // trigger on HIGH->LOW
}

void loop() {
    if (pressed) {                 // main code reacts when convenient
        pressed = false;
        toggleLED();
    }
}

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍ISR rules (critical): - Keep ISRs short. Set a flag, copy a value, exit. No delays, no heavy work. The rest of the system is frozen while the ISR runs. - Shared variables must be volatile. It tells the compiler the value can change outside normal flow (in the ISR), so it always re-reads it from memory instead of caching it in a register.

Timers are hardware counters that tick from a clock. They enable precise timing without blocking: - Generate a periodic interrupt (e.g. "interrupt me every 1 ms") → the basis of fixed-rate control loops on bare metal. - Produce PWM (Pulse-Width Modulation). A square wave whose duty cycle (% of time HIGH) sets average power. 25% duty ≈ 25% brightness/speed. This is how MCUs dim LEDs and drive motors.

delay() vs timers. delay(1000) blocks the whole CPU for a second, nothing else runs. Real embedded code uses timer interrupts or a non-blocking "check the clock" pattern (millis()), so multiple things happen "at once."

Why it exists. A robot must react the instant something happens (a limit switch, an encoder edge, a deadline) while still doing other work. Polling wastes the CPU and misses fast events; interrupts and timers are how bare-metal code reacts immediately and keeps precise time without blocking.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍Mental model. Polling is repeatedly opening the oven to check the food. An interrupt is a timer bell that calls you the instant it's done, so you can do other chores meanwhile. A PWM duty cycle is like rapidly flicking a light switch. Flick it on 30% of the time and it looks ~30% as bright.

Common misunderstandings.

• "Do the real work inside the ISR." Keep ISRs tiny. Set a flag and exit; the whole system is frozen while an ISR runs.
• "A normal variable shared with an ISR is fine." It must be volatile, or the compiler may cache a stale copy and never see the ISR's change.
• "delay(1000) is a harmless pause." It blocks the entire CPU for a second. Use timers / millis() so other things keep running.

Connections. The "flag in the ISR, react in the loop" pattern is the seed of RTOS deferred-interrupt processing (Turn 2); volatile is the bare-metal cousin of C++'s std::atomic (concurrency); and timer-driven periodic interrupts are the fixed-rate loop from Python Turn 1. PWM duty cycle is how a PID output drives a real motor.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍BImmediate Active Recall

CConceptual Questions

Answer each in your own words in the box, then reveal the model answer to compare. These ask why, not how, and your answers are saved.

DPractice Problems

P1 (easy). You need an LED to blink while also reading a sensor continuously. Should you use delay() or a timer/millis() approach? Why?

P2 (medium). A flag set in an ISR is sometimes ignored by the main loop even though the interrupt fired. What keyword was likely forgotten, and why does it matter?

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍P3 (harder). You want a motor at ~40% speed via PWM at 1 kHz. Conceptually, what duty cycle, and what does raising the frequency (not duty) change?

EFeynman Exercise

Explain interrupts to a beginner with the oven-bell analogy: why waiting by the oven (polling) wastes your time, and how a bell (interrupt) frees you. Then explain PWM by describing how flicking a switch on and off very fast can make a light look half as bright, and what "duty cycle" names in that picture.

FError Analysis Framework

• Heavy ISRs. Why: doing work in the ISR. Recognise: system stutters, missed interrupts. Avoid: flag-and-exit; process in main loop.
• Missing volatile. Why: unaware of compiler caching. Recognise: main loop ignores ISR updates. Avoid: volatile on all ISR-shared data.
• Blocking with delay(). Why: simplicity. Recognise: unresponsive system. Avoid: timers / millis() non-blocking patterns.
• Confusing duty and frequency. Why: both "PWM knobs." Recognise: changing frequency to set speed. Avoid: duty = power, frequency = switching rate.

‍​‌‌​​‌‌​​‌‌‌​​‌​​‌‌​​‌​‌​‌‌​​‌​‌​​‌​‌‌​‌​‌‌‌​​‌‌​‌‌​​​​‌​‌‌​‌‌​‌​‌‌‌​​​​​‌‌​‌‌​​​‌‌​​‌​‌‍GMini Challenge

Your main loop does while(!pressed){} where pressed is set in a button ISR, but it never exits even when you press the button. What keyword is missing, and why does adding it fix the problem?

Quiz Check

A quick auto-graded check, separate from the recall cards above. Your score is pooled with the recall cards into this module's Mastery score, and completing this lesson requires the quiz submitted with pooled mastery at 80% or above.