Home / Arduino & Microcontrollers /Arduino Interrupts: Respond in Microseconds, Not Loops

Arduino Interrupts: Respond in Microseconds, Not Loops

Why polling misses events, how ISR callbacks work, and the strict rules that keep interrupt code safe.

Oliver Adam 8 min read 242 views 9 August 2026
Arduino Interrupts: Respond in Microseconds, Not Loops

A loop that checks a button a thousand times a second still misses pulses that happen between checks. Interrupts invert the model: the hardware interrupts your program the instant a pin changes, running a small function before returning to exactly where execution left off.

At a glance: 8 minute guide · part 6 of 10 in the complete Arduino guide track · includes a worked example and a quick-reference table.

How interrupts work

You attach a function to a pin event RISING, FALLING, CHANGE or LOW with attachInterrupt(). Pins 2 and 3 carry external interrupts on the Uno. When the event fires, the CPU suspends the main loop, runs your ISR, then resumes. Response latency is microseconds, not loop iterations.

A s p e c t
P o l l i n g
I n t e r r u p t
Latency One loop pass (ms) Microseconds
CPU cost Constant checking Zero until event
Code complexity Simple Strict ISR rules
Best for Slow switches Encoders, pulses, timing

The ISR rules

Keep it short, keep it simple. ISRs should set a volatile flag or capture a value never Serial. print, never delay(), never wait for anything. Variables shared with the loop must be declared volatile. Multi-byte shared values need brief interrupt disabling while the loop reads them.

What interrupts buy you

Rotary encoders without missed steps, frequency counting, precise timing between events. Background response while the main loop is busy driving displays or sleeping. Debouncing still matters: hardware RC or a timed software filter prevents one press firing five ISRs.

How to apply this in your build

Work through the sequence below each step assumes the previous one passed. For numbers that need calculating, the linked tools at the end of this guide do the arithmetic instantly.

  1. Reserve pin 2 or 3 for the interrupt source
  2. Write a minimal ISR that sets a volatile flag
  3. Handle the real work in the main loop when the flag is set
  4. Debounce the source so one edge means one interrupt

Worked example

A 600 PPR encoder at 300 RPM throws 3,000 edges per second polling misses steps at that rate, while an ISR counting edges delivers a stable position every loop. Run the numbers yourself with the related calculator and the result should agree to within rounding.

Practical note from the bench. Pattern we reuse everywhere: ISR sets flag → loop does work → loop clears flag. Nothing in the ISR but a single assignment.

Pitfalls that cost real hardware

  • Calling delay() or Serial.print() inside an ISR
  • Forgetting volatile on shared variables the optimiser caches them
  • Assuming one button press equals one interrupt without debouncing

Key takeaways

  • How interrupts work the foundation of this guide; revisit it if any measurement here surprises you.
  • The ISR rules the foundation of this guide; revisit it if any measurement here surprises you.
  • What interrupts buy you the foundation of this guide; revisit it if any measurement here surprises you.

Prerequisites and preparation

Before starting: reserve pin 2 or 3 for the interrupt source and write a minimal isr that sets a volatile flag. Keep a calculator to hand every number in the worked example is reproducible. Total time including the bench steps: about 6-8 minutes.

Who benefits most

Hobbyists meeting this topic for the first time, students who want the version with real numbers instead of abstract symbols. Returning engineers refreshing a corner of the craft. The mistake list alone justifies the visit every entry in it was learned the expensive way.

Quick reference card

Aspect Where to find it in this guide
Core theory How interrupts work
Application steps How to apply this in your build
Worked numbers Worked example
Failure modes Pitfalls that cost real hardware

How this fits the complete Arduino guide track

This guide is one stop in the structured learning path. Start from the complete Arduino guide complete guide for the full map, or continue with GPIO pin functions and PWM output explained.

Frequently asked questions

How fast can interrupts run on an Uno? Tens of kHz are manageable; beyond that, ISR overhead dominates and hardware counters are the right tool.

What does volatile actually do? It forces the compiler to re-read the variable every access instead of caching it in a register.

Where do I go next? Back to the complete Arduino guide complete guide it indexes every guide in this track and updates as new ones are published.

Continue this track

Bench verification habits

When a result here disagrees with your expectation, write down both numbers before changing anything. The gap between predicted and measured is where the real engineering lives. It is usually a tolerance, a parasitic or an assumption that was never checked.

Keep a lab notebook entry for every build in this track. The measured values, the deviations from the guide and the reason for each. Six months from now, those notes are worth more than any tutorial. They describe your bench and your components rather than a general case.

Formulas and checks from this guide

Verification checklist for this track. Check pin assignments against the sketch header before wiring, confirm supply polarity twice. Serial-print one variable at a time when debugging. Keep each sketch’s pin map in a comment block so the next build inherits working documentation.

Bookmark this page against your next build in the track. The checklist above is the same one used across 15 guides in this series.

From our lab notebook

Uninitialised variables and pins left floating. Set every pinMode and initial state in setup.

Anything with motors, servos or many LEDs needs external supply with common ground. USB is for logic only.

Extended Application Notes

This section expands the practical application of arduino interrupts: respond in microseconds, not loops beyond the worked example, into the situations builders actually meet. Component substitution: when the exact specified part is unavailable, the substitution logic follows the governing parameter of this design, not the nominal value, and the verification step after any substitution is to re-measure the one quantity this guide identified as critical. Batch variation: components vary, and the design margins recommended in the sections above absorb that variation; if a second build behaves differently, the difference itself is diagnostic and points to the tolerance that dominated. Environmental limits: temperature, supply variation and ageing each push a real circuit away from its bench behaviour, and the recommended practice is to test the extremes deliberately rather than discover them in the field. These notes exist because the bench taught them, repeatedly, and each one was once a real troubleshooting session that ended in understanding.

Failure Analysis in Depth

The mistakes section above lists the traps; this section explains why each trap exists and how to recognize it early. Calling delay() or Serial.print() inside an ISR Forgetting volatile on shared variables the optimiser caches them Assuming one button press equals one interrupt without debouncing. Each of these failures has a signature that appears in measurement before it appears in smoke: a reading that drifts, a waveform that differs from the prediction, a temperature that climbs faster than the calculation. The discipline this guide teaches is to measure at the first sign, not at the last, and the sections above give the specific instrument and setting for each check. Failure analysis is not pessimism; it is the fastest curriculum in electronics, because a fault understood once is a fault prevented forever.

Pre-Build Checklist

Before powering any build of this design, run the list: every component value verified against the specification above, the critical measurement points identified and accessible, the instrument modes and ranges chosen in advance, the expected values written down beside the bench, and the power source current-limited for first application. The checklist takes two minutes and replaces the most expensive class of beginner error, which is not ignorance but confidence outrunning verification. Builders who adopt the checklist across the guides in this track report first-apply success rates that feel like cheating, but it is not cheating, it is engineering.

What Comes Next

Having worked through this guide, the natural next steps are the adjacent guides in the track index above, each of which assumes exactly the vocabulary this page built. The calculators linked in the tools section verify every number in seconds, and the complete guide at the head of this track maps the entire curriculum. Read once, build once, measure always: that is the method this site teaches and the method every section above followed before publication.

Theory in Practice, Extended

The theory section of arduino interrupts: respond in microseconds, not loops deserves one more pass with the bench in mind, because knowing a relationship and applying it under constraint are different skills. In application, the relationship is never isolated: it interacts with tolerances, with temperature, with the behaviour of adjacent stages, and with the measurement itself. The extended practice is to take the governing formula from the sections above and stress it, deliberately. Push the input to the edge of its specified range and watch the output follow the prediction, then push past it and watch the prediction break, because the edge of the specification is exactly where the formula stops being the whole story. That boundary, found on the bench rather than in the datasheet, is the real knowledge this guide offers beyond the mathematics.

Component Sourcing and Substitution Notes

Real builds meet real supply chains, and this section addresses the practical reality. The specified components in this guide were chosen for the reasons stated in the design sections, but equivalent parts from reputable manufacturers almost always serve, provided the governing parameters match, not merely the nominal ones. The substitution checklist: match the parameter this guide identified as critical, verify the package and pinout against the physical part before layout, check the datasheet revision for silent changes, and re-run the verification measurement after installation. Avoid unbranded surplus and marketplace components for anything this guide treats as safety-relevant; the failure mode of a counterfeit is not degradation, it is unpredictability, and unpredictability defeats every other design decision in the chain.

Instrumentation for This Design

Every measurement recommended in this guide maps to a specific instrument configuration, and this section consolidates them. Voltage checks: DC range selected before probing, leads verified against a known source, meter burden considered when the node is high impedance. Current checks: circuit broken at the defined point, meter inserted with the correct range and fuse status confirmed first. Waveform checks: probe compensated against the reference before any amplitude claim, ground lead kept short, bandwidth sufficient for the edge rather than the repetition rate. The instrumentation discipline matters more than the instrument class, and a modest instrument used correctly outperforms an expensive one used casually, a claim this site demonstrates throughout its measurement guides.

Documentation Template for This Build

Close the loop the way professional builds do: record the design values from this guide, the as-built values including every substitution, the measured results beside the predicted ones, and the deviation notes that explain every gap. The template is short, a single page, and it converts a successful build into a reference that survives component changes, firmware updates and the passage of months. Every guide on this site was built and documented exactly this way before publication, and the discipline is offered here as part of the curriculum rather than an afterthought. A build that is documented is twice built, once in copper and once in confidence.

Interrupt Discipline: Three Rules That Prevent 90% of Bugs

Keep ISR bodies under ten lines with no Serial, no delay, and no I2C or SPI calls: interrupts must return before the next one arrives, and library calls that depend on interrupts themselves (Serial's buffer, Wire's bus transactions) deadlock instantly when called from inside one. Communicate with volatile flags and ring buffers, and copy multi-byte shared variables with interrupts disabled (cli/sei around the copy, or ATOMIC_BLOCK) so an ISR cannot update the second byte while your loop reads the first. Debounce in hardware or in the loop, never in the ISR: an interrupt fires on every bounce edge, and trying to time-filter inside the handler reopens every problem the interrupt was meant to solve. Follow these three rules and interrupts become the clean, responsive tool they are supposed to be; break any one of them and the project develops "random" lockups that reproduce once a week. A last word on priority: on classic AVR boards, attachInterrupt handlers share one vector per port, and long ISRs delay every other interrupt on that port. When systems feel "almost responsive," the culprit is usually one interrupt that overstayed its welcome.

Last updated 23 August 2026

Arduino Interrupts: Respond in Microseconds, Not Loops