Arduino Interrupt Handling

Watch a microcontroller pause the main loop, jump to an ISR, set a flag, return, and safely handle the event.

A beginner-first interrupt handling workbench with synchronized CPU timeline, stack/context view, ISR code path, latency estimate, debounce warning, and Arduino best-practice feedback.

Animation Arduino Interrupts

Arduino Interrupt Handling

Step through how a microcontroller pauses the main loop, saves context, jumps to an ISR, sets a flag, returns, and safely handles the work later.

Main loopCPU stage

6.0 usLatency estimate

18 usISR length

ReadyDesign status

Arduino Interrupt Workbench

Goal

See the exact handoff between main code, hardware event, ISR, stack, and safe flag handling.

Try First

Press Trigger INT0, then Step through the six stages. Watch the stack and code highlight.

Watch

Long ISRs, bouncing buttons, and high event rates create missed events or blocked timing.

Why It Matters

IoT devices use interrupts for buttons, encoders, timers, radio pins, sleep wakeups, and fast sensors.

Interrupt Scenario

Select an event source to load a realistic teaching setup.

View Mode

Timeline view follows the CPU from main loop to ISR and back.

Playback

Play speed 850 ms

Timing Knobs

ISR work 18 us

Event rate 20 Hz

Debounce 20 ms

Main work 2.0 ms

Main loop: the sketch runs ordinary code. No ISR should do slow application work.

Latency is small.Response timing

ISR is short.ISR safety

Events fit.Rate check

Flag handoff is safe.Shared data

Interrupt Lifecycle

The event line, CPU state, stack context, ISR code, and main-loop flag handling stay synchronized.

Stage 1 of 6 Main loop -> polling-free work

Execution Evidence

The selected stage explains what changes inside the CPU and sketch.

Latency Check

Latency is event edge to first useful ISR instruction.

6.0 us

ISR Fit

Short ISRs keep other timing work responsive.

Short

Code Safety

Checks Arduino-specific interrupt rules.

Safe pattern

Beginner Ramp

Polling asks the same question again and again: did the button change yet? An interrupt lets hardware raise its hand. The CPU finishes its current instruction, remembers where it was, runs a short ISR, then returns to the main loop.

Lifecycle Sequence

1. Main loop runs ordinary sketch code.
2. Hardware detects an enabled edge or timer event.
3. CPU finishes the current instruction and saves return context.
4. CPU jumps to the interrupt vector and runs the ISR.
5. ISR sets a volatile flag or increments a small counter.
6. RETI restores context and main loop handles the work.

Arduino Rules

• Use `volatile` for variables changed inside an ISR.
• Keep the ISR short; set a flag and leave.
• Avoid `delay()` and `Serial.print()` inside ISRs.
• Protect multi-byte shared reads with `noInterrupts()` and `interrupts()` when needed.

Formula Reference

• Cycle time at 16 MHz = 62.5 ns.
• Teaching latency = finish current instruction + vector/context overhead.
• CPU time used by ISR = ISR duration x event rate.
• Event period = 1000 ms / event rate in hertz.

Interrupt Pins

On Arduino Uno/Nano, external INT0 is D2 and INT1 is D3. Use `digitalPinToInterrupt(pin)` so the sketch remains clearer and more portable. Many ESP32 boards can attach interrupts to most GPIO pins, but electrical constraints still matter.

Safe Pattern Code

volatile bool buttonFlag = false;

void setup() {
  pinMode(2, INPUT_PULLUP);
  attachInterrupt(digitalPinToInterrupt(2), buttonISR, FALLING);
}

void loop() {
  if (buttonFlag) {
    buttonFlag = false;
    handleButtonPress();
  }
}

void buttonISR() {
  buttonFlag = true;
}

Practice 1

Use Button INT0. Set debounce to 0 ms. Why does the warning say a single press may create multiple events?

Practice 2

Use Encoder Pulse. Raise event rate above 1000 Hz and ISR work above 100 us. What starts to fail first?

Practice 3

Use Bad Long ISR. Which Arduino rules are violated, and where should the real work move?

Related Study

Motor ControlUse interrupts for encoder feedback. Duty CycleConnect sleep, wakeups, and periodic events. PWM ControlSee timer-driven output behavior. Circuit SolverReview pullups, edges, and GPIO levels.