Firmware on TurboVision

Debouncing with Time and State, Not Hope

Sun, 22 Feb 2026 00:00:00 +0000

Button debouncing is one of the smallest problems in embedded systems and one of the most frequently mishandled. That combination makes it a perfect teaching case. Engineers know contacts bounce, yet many designs still rely on ad-hoc delays or lucky timing. These solutions pass demos and fail in real operation. A robust approach treats debouncing as a tiny state machine with explicit time policy.

Mechanical bounce is not mysterious. On transition, contacts physically oscillate before settling. During that interval, GPIO sampling can see multiple edges. If firmware interprets every edge as intent, one press becomes many events. The correct objective is not “filter noise” in the abstract; it is to infer a human action from unstable electrical evidence with defined latency and false-trigger bounds.

The naive pattern is edge interrupt plus delay_ms(20) inside the handler. This feels simple but causes collateral damage: blocked interrupt handling, jitter in unrelated tasks, and poor power behavior. Worse, fixed delays are often too long for responsive UIs and still too short for worst-case switches. Delays treat symptoms while creating scheduling side effects.

A better pattern separates observation from decision. Observation samples pin state periodically or on edge notifications. Decision logic advances through states: Idle, CandidatePress, Pressed, CandidateRelease. Each transition is gated by elapsed stable time. This design is cheap, deterministic, and testable. It also composes naturally with long-press and double-click features.

Sampling frequency matters less than many assume. You do not need MHz polling for human input. A 1 ms tick is usually enough, and even 2–5 ms can be acceptable with careful thresholds. What matters is consistent sampling and explicit stability windows. If a signal remains stable for N ticks, commit the state transition. If it flips early, reset candidate state.

Interrupt-assisted designs can reduce average CPU cost without sacrificing rigor. Use GPIO interrupts only as wake hints, then confirm transitions in the debounce state machine on a scheduler tick. This hybrid model balances responsiveness and robustness. It avoids long ISR work while still minimizing idle polling overhead.

Hardware assists are still useful. RC filters and Schmitt-trigger inputs reduce bounce amplitude and edge ambiguity. But hardware alone rarely removes the need for firmware logic, especially when you support varied switch vendors, cable lengths, or noisy environments. The best systems combine modest front-end conditioning with explicit software state handling.

Testing debouncers should include adversarial scenarios, not only clean bench presses. Vary supply voltage, inject EMI near harnesses, test with gloved and rapid presses, and capture edge traces from different switch lots. Build a replay harness in firmware that feeds recorded edge sequences into your debounce logic and asserts expected events. This turns “seems fine” into measurable confidence.

Latency trade-offs should be stated in requirements. If you require sub-20 ms press detection while tolerating noisy switches, design thresholds accordingly and verify under worst-case bounce profiles. Teams often optimize for false-trigger elimination and accidentally create sluggish interfaces. Users notice sluggishness immediately. Good debouncing balances reliability with perceived immediacy.

State-machine debouncing also scales better for many inputs. Instead of per-button delay hacks, you run a compact table of states and timestamps. This structure keeps complexity linear and enables uniform behavior across keys. It also simplifies telemetry: you can log per-button transition timing and detect degrading switches before field failures escalate.

Power-conscious designs must integrate debouncing with sleep states. Wake-on-edge can trigger from bounce bursts. Firmware should treat wake events as tentative, verify stable states, and return to low power quickly when no valid action is confirmed. Without this, noisy inputs can destroy battery life while appearing functionally correct in brief lab tests.

The biggest lesson is methodological. Debouncing rewards explicit models over folklore. Define states. Define thresholds. Define expected outcomes. Then test those outcomes with recorded traces and timing variation. This is the same engineering pattern used for larger systems, just in miniature. If a team is sloppy on debouncing, it is often sloppy elsewhere too.

So treat button handling as more than boilerplate. It is a compact reliability exercise that improves firmware architecture, testing discipline, and UX quality. Time and state beat hope every time.

If you are mentoring juniors, debouncing is an ideal first design review topic. It is small enough to reason about completely, yet rich enough to expose habits around requirements, state modeling, timing assumptions, and test quality. Teams that do debouncing well usually do larger stateful systems well too.

Tiny reference implementation pattern

if (raw != last_raw) {
  last_change_ms = now_ms;
  last_raw = raw;
}

if ((now_ms - last_change_ms) >= stable_ms && debounced != raw) {
  debounced = raw;
  emit_event(debounced ? EV_PRESS : EV_RELEASE);
}

Simple, explicit, and testable. This pattern is often enough for reliable human-input paths.

State Machines That Survive Noise

Sun, 22 Feb 2026 00:00:00 +0000

A lot of embedded bugs are not algorithm failures. They are state-management failures under imperfect signals. Inputs bounce, clocks drift, interrupts cluster, and peripherals report transitional nonsense. Firmware that assumes clean edges and ideal timing eventually fails in the field where noise is normal.

Robust systems treat noise as a design input, not a test surprise.

Why finite state machines still win

State machines are sometimes dismissed as “old-school” in modern embedded stacks. That is a mistake. They remain one of the best tools for making behavior explicit under uncertainty:

legal transitions are visible
invalid transitions can be handled deliberately
timeout behavior is encoded, not implied
recovery paths are first-class

Most importantly, state machines force you to name ambiguous phases that ad-hoc boolean logic usually hides.

A practical pattern: event queue + transition table

A resilient architecture separates interrupt capture from policy:

ISR captures minimal event.
Main loop dequeues event.
Transition function updates state.
Output actions run from resulting state.

typedef enum { ST_IDLE, ST_ARMED, ST_ACTIVE, ST_FAULT } state_t;
typedef enum { EV_EDGE, EV_TIMEOUT, EV_CRC_FAIL, EV_RESET } event_t;

state_t step(state_t s, event_t e) {
  switch (s) {
    case ST_IDLE:   return (e == EV_EDGE)    ? ST_ARMED  : ST_IDLE;
    case ST_ARMED:  return (e == EV_TIMEOUT) ? ST_ACTIVE : (e == EV_CRC_FAIL ? ST_FAULT : ST_ARMED);
    case ST_ACTIVE: return (e == EV_RESET)   ? ST_IDLE   : ST_ACTIVE;
    case ST_FAULT:  return (e == EV_RESET)   ? ST_IDLE   : ST_FAULT;
  }
  return ST_FAULT;
}

This is intentionally simple. Complexity belongs in explicit transitions, not in hidden timing side effects.

Debounce is a state problem, not just delay

Naive debounce logic (delay then read) often passes bench tests and fails with variable load. Better approach:

maintain input state
require stable duration threshold
transition only when threshold satisfied

This aligns with Debouncing with Time and State and extends it into full system behavior.

Timeouts are architectural, not patchwork

Every state that waits on external behavior should define timeout semantics:

what timeout means
whether retry is allowed
max retry budget
fallback state

Undefined timeout behavior is one of the most expensive firmware ambiguities in production debugging.

Top-aligned diagnostics in firmware logs

When logging transitions, keep entries normalized:

This format turns logs into analyzable traces instead of prose fragments. You can then diff expected transition sequences against observed ones in automated tests.

Guarding against interrupt storms

Interrupt storms can starve policy logic if ISR work is too heavy. Keep ISR minimal:

capture timestamp
capture source id
queue event
exit

Any parsing, retry decisions, or multi-step logic belongs in cooperative main-loop context where execution order is controlled.

Noise-aware testing strategy

A strong test suite includes adversarial input timing:

burst edges near threshold boundaries
delayed acknowledgments
missing edges
duplicate events
out-of-order event injections

If your machine cannot survive these, it is not ready for hardware reality.

Cross references for this design style

These pieces describe the same principle at different layers: uncertainty is part of the interface contract.

Implementation details that pay off

Keep state enum in one header, shared by firmware and test harness.
Use explicit “unexpected event” handler, never silent ignore.
Version your transition table so behavior changes are reviewable.
Add build-time switch for transition tracing in debug builds.

This sounds procedural because reliability is procedural.

Final thought

Embedded systems do not get judged by elegance under ideal inputs. They get judged by behavior under messy electrical and timing conditions. State machines that survive noise are not conservative design. They are aggressive risk management.

If you are choosing between adding one more feature and hardening transitions around existing behavior, harden first. Field failures almost always happen at transitions, not in the center of stable states.

Document each state transition in one sentence that an on-call engineer can understand at 3 AM. If the sentence is unclear, the transition is probably underspecified in code as well.