Inputs
Example data table
A realistic baseline for a 100 MHz microcontroller. Use it to sanity-check your measurements.
| Component | Min (cycles) | Typ (cycles) | Max (cycles) |
|---|---|---|---|
| Sync/Detection | 1 | 2 | 3 |
| Arbitration | 2 | 4 | 6 |
| Vector Fetch | 2 | 6 | 10 |
| Context Save/Entry | 10 | 20 | 30 |
| Pipeline/Cache Penalty | 0 | 3 | 15 |
| ISR Prologue | 0 | 4 | 12 |
| Blocking window (µs) | 0.0 | 0.5 | 2.0 |
Formula used
Convert cycles to time using the CPU clock: Tcycle(ns) = 1000 / f(MHz).
Total interrupt latency is the sum of architectural overhead plus any blocking window:
- Ci = per-component cycle cost (min/typ/max).
- B = masking/critical-section delay (min/typ/max) in nanoseconds.
- Jitter = Lmax − Lmin.
- Worst-case slack = Deadline − Lmax (in microseconds).
How to use this calculator
- Enter your CPU clock in MHz (or the effective clock during interrupts).
- Fill min/typ/max cycles for each latency component.
- Add a blocking window if interrupts are sometimes masked.
- Optionally set a deadline to check real-time constraints.
- Press Submit to view totals, jitter, and deadline status.
- Use CSV/PDF downloads to share results or track tuning.
Architecture drivers of latency
Interrupt latency starts when an IRQ is sampled and ends at the first useful handler instruction. Synchronizers, wakeup logic, and priority resolution add predictable cycles. Vector fetch, stack entry, and automatic context saves contribute fixed overhead. Deeper pipelines can extend entry during flushes, while flash wait states or bus stalls inflate vector reads. Tail chaining can shorten back to back servicing by reusing saved context.
Converting cycles to time
This calculator converts cycle budgets into nanoseconds using Tcycle = 1000 divided by clock in megahertz. Enter min, typical, and max cycles to describe best conditions, normal traffic, and worst contention. The totals show latency in cycles and time, so you can compare devices with different clocks. Changing the clock instantly reveals how much performance headroom comes from frequency alone.
Blocking and masking effects
Software can dominate latency when interrupts are masked inside critical sections or when higher priority ISRs delay service. Model this with the blocking window in microseconds, representing the longest time interrupts remain disabled. Include RTOS scheduler locks, shared peripheral drivers, and atomic update regions. Worst case totals should use the longest plausible window, because one extended lock can violate a real time deadline.
Using results for design decisions
Design with worst case latency and jitter, not only the typical value. If slack is negative, reduce critical section time, raise the interrupt priority, shorten prologue saves, or move vectors and stacks to faster memory. If typical is high but worst is acceptable, optimize caching, alignment, and bus arbitration. Consider splitting long handlers, deferring work to tasks, and using DMA to reduce entry pressure. When deadlines are tight, budget additional margin for metastability filtering, interrupt stacking of multiple sources, and rare cache miss bursts during flash erase operations background.
Validation and measurement workflow
Validate the model by toggling a GPIO at the interrupt source and another at handler entry, then measure with a logic analyzer or scope. Compare observed values to the typical and max envelopes, then adjust component cycle inputs until they align. Re test after compiler changes, linker moves, or clock scaling. Export CSV and PDF snapshots to track progress across builds and releases.
FAQs
1) What is interrupt latency in this calculator?
It is the time from an interrupt request being recognized to the first instruction of the handler, including architectural entry costs and any masking delay you provide.
2) Why enter min, typical, and max cycles?
They represent best conditions, normal behavior, and worst contention. The calculator enforces ordering and produces an envelope so you can design for worst case and track jitter.
3) How do I estimate the blocking window?
Measure or bound the longest time interrupts can be disabled or preempted by higher priority work. Include RTOS locks, critical sections, and long peripheral driver operations.
4) What should I do if worst case misses my deadline?
Reduce masking time, shorten ISR prologue/stacking, raise priority, move hot code to faster memory, or split work so the handler only performs urgent actions.
5) Does clock speed always reduce latency proportionally?
Cycle time scales with clock, but wait states, bus stalls, and cache misses may not. Validate with measurements and model those effects using higher cycle values.
6) How can I validate the numbers?
Toggle a GPIO at the event source and another at handler entry, measure with a scope, then tune per component cycles until typical and worst case align with observed data.