Microcontrollers 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.

SPI Signals That Lie

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

SPI looks simple on paper: clock, data out, data in, chip select. Four wires, deterministic timing, done. In real projects, SPI failures often appear as “sometimes wrong bytes,” “first transfer fails,” or “only breaks on production boards.” These are the kind of bugs that waste days because the bus seems healthy at first glance.

The core lesson is that SPI integrity is not just protocol correctness. It is electrical timing, firmware sequencing, and peripheral state management combined.

Common failure classes:

clock polarity/phase mismatch masked by forgiving devices
chip-select timing violations near transaction boundaries
signal integrity problems at higher edge rates
peripheral state not reset between commands
DMA and interrupt races corrupting transfer order

Any one can produce plausible-but-wrong data.

I start with protocol truth first. Confirm CPOL/CPHA mode from datasheets, then verify with logic analyzer captures of command/response boundaries. Do not rely on “it worked with another sensor.” Different devices tolerate different mistakes.

Chip-select discipline is frequently underestimated. Some peripherals require minimum setup/hold time around CS transitions. If firmware toggles CS too quickly under optimization changes, a previously stable transfer can degrade silently. Enforce timing explicitly, not by incidental delays.

Signal integrity matters earlier than many assume. At modest board lengths and strong GPIO drive settings, ringing and overshoot can create false edges. Scope captures at the receiver pin, not just MCU pin, are essential. What leaves the MCU is not always what arrives at the device.

Practical board-level mitigations include:

series resistors near source on high-edge lines
clean return paths
reduced edge rate where available
controlled trace length matching for sensitive links

These are cheap changes with high payoff.

On firmware side, transaction framing should be explicit. Wrap transfers in one API that controls:

CS assert/deassert
mode and speed selection
optional guard delays
retry and timeout policy

Scattered raw register writes across drivers create hidden divergence and fragile maintenance.

DMA introduces its own failure modes. If buffer ownership and completion signaling are unclear, stale or partially updated data appears intermittently. Use strict ownership rules and assert expected transfer length at completion.

Interrupt interactions can also corrupt sequencing. If high-priority ISRs preempt between CS assert and first clock edge, timing contracts may break. Critical sections around transaction start are often justified in tight timing designs.

Another subtle trap: mixed-speed peripherals on shared bus. Reconfiguration bugs happen when one driver leaves bus speed or mode altered for the next device. Centralized bus arbitration prevents this class of bug.

Diagnostic strategy that works well:

lock one known-good frequency and mode
disable DMA and run blocking transfers
validate deterministic test vectors
reintroduce DMA and concurrency incrementally
increase bus speed in controlled steps

When failures reappear, you know which complexity layer introduced them.

I strongly recommend adding protocol-level self-checks where possible:

read-back register after write
device ID verification at startup
command echo checks
CRC where supported

These catch latent bus corruption before higher-level logic misbehaves.

Power and reset sequencing also influence SPI reliability. Some peripherals accept clocks before internal state is ready, then remain in undefined mode until hard reset. Ensure boot initialization obeys datasheet timing windows.

For production robustness, perform variability tests:

temperature sweep
supply voltage corners
cable/harness variants where applicable
repeated long-run stress with error counters

If an SPI link passes only nominal lab conditions, it is not finished.

Logging can help in deployed systems:

transaction error counts
timeout counts
last failing opcode
bus-reset events

These metrics turn rare field failures into diagnosable patterns.

The big mindset shift: SPI bugs are often systems bugs, not line-by-line coding bugs. You solve them fastest by combining electrical captures, protocol verification, and firmware sequencing analysis, not by focusing on one layer alone.

If you keep one rule, keep this: trust captured timing and measured waveforms over assumptions. SPI rarely lies; our interpretation of partial evidence does.

If a design ships to production, add one recovery path too: a bus reinitialization routine that can safely reset peripheral state after repeated transaction failure. Rare field glitches become survivable when recovery is deterministic and observable rather than hidden behind random retries.

Design for recoverability, then verify it under stress.

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.

Timer Capture Without an RTOS

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

One of the most useful embedded skills is measuring external timing accurately without hiding behind a heavy runtime stack. You do not need an RTOS to capture pulse widths, frequency drift, or event latency with high reliability. You need a clear timing model, disciplined interrupt design, and careful data handoff.

Timer input-capture peripherals are built for this job. They latch counter values on configured edges and let firmware process deltas later. The hardware does the precise timestamping; software handles interpretation.

A robust architecture starts with three decisions:

counter clock source and prescaler
edge policy (rising, falling, both)
overflow handling strategy

If these are vague, accuracy claims will be vague too.

Choose timer frequency from measurement goals, not convenience. Too slow and quantization error dominates. Too fast and overflow complexity increases, especially on narrow counters. A good target is where one tick is clearly below your required resolution with margin for jitter analysis.

Input capture ISR design should be minimal:

read captured value
read/track overflow epoch
write compact event record into ring buffer
return

Do not compute expensive statistics inside ISR unless absolutely necessary. Deterministic ISR duration keeps timestamping reliable.

The ring buffer is the bridge between hard realtime edges and softer application logic. Make it explicit:

fixed-size, lock-free where possible
head/tail updates with clear ownership
overflow counter for dropped samples
sequence IDs for gap detection

If sampling can outrun processing, design for graceful loss reporting instead of silent corruption.

Overflow math is where many implementations become flaky. A 16-bit timer at high clock rate wraps frequently. You need either:

software epoch extension in overflow ISR, or
wider hardware timer if available

Then reconstruct absolute timestamps as (epoch << counter_bits) | capture_value.

Validate overflow handling with deliberate stress:

low-frequency signals to force many wraps between edges
bursty high-frequency signals near ISR capacity
mixed duty cycles

If only one scenario is tested, hidden edge cases survive to production.

Debounce and input conditioning matter too. Electrical noise can generate false captures. Hardware filtering, Schmitt inputs, or digital filter settings on capture channels often improve reliability more than post-processing hacks.

For pulse width measurement, both-edge capture is ideal:

capture rising edge timestamp
capture falling edge timestamp
subtract with wrap-safe arithmetic

For frequency measurement, rising-only with period averaging is often cleaner.

Averaging strategy should reflect signal characteristics. Fixed-window averaging smooths noise but can blur short transients. Exponential filters react faster but need careful coefficient tuning. Choose based on what errors are expensive for your application.

No RTOS does not mean no scheduling discipline. Use a simple cooperative loop:

drain capture buffer
update derived metrics
publish snapshots atomically
run non-critical tasks opportunistically

This model is predictable and usually enough for single-MCU measurement nodes.

Atomic publication is important when data is consumed by other contexts (serial output, control loop, diagnostics). Use double-buffered snapshots or short critical sections to avoid torn reads.

Instrumentation should be built in early:

dropped-sample count
max ISR latency observed
max buffer depth reached
timestamp monotonicity checks

Without instrumentation, “seems stable” can hide near-overload behavior.

Another practical pattern is calibration hooks. If timer clock derives from an internal RC oscillator, drift can distort measurements. Add a calibration path using known references where possible, or at least expose drift estimation telemetry so users understand uncertainty.

When integrating with control logic, separate measurement confidence from measurement value. For each computed metric, carry metadata:

valid/invalid
sample count
age
error flags

Control decisions should degrade safely on low-confidence inputs.

Testing must include real signal generators and ugly signals:

clean square waves for baseline
jittered waveforms
missing pulses
slow edges near threshold
EMI-contaminated lines

Embedded timing code that only passes clean-lab signals is unfinished.

One reason people reach for RTOS early is fear of concurrency complexity. That fear is understandable. But for focused timing tasks, a disciplined interrupt-plus-buffer model is simpler, faster, and easier to audit. You can always layer a scheduler later if system scope grows.

A compact bring-up checklist:

verify edge timestamps with logic analyzer correlation
force overflow and confirm wrap-safe math
saturate input rate and observe drop accounting
validate end-to-end latency from edge to published metric
confirm behavior after long-duration runs

If all five pass, you have a reliable timing subsystem.

The deeper lesson is architectural: put precision where it belongs. Let hardware timestamp edges. Let ISR move minimal data. Let foreground logic compute and publish. Clean boundaries produce reliable systems.

This design style scales from small sensor interfaces to motor control telemetry and protocol timing diagnostics. It also teaches excellent habits: deterministic ISR design, explicit loss accounting, and confidence-aware outputs.

You do not need an RTOS to do serious timing work. You need explicit constraints, measurable behavior, and the discipline to keep fast paths simple.

RISC-V on a 10-Cent Chip

Fri, 30 Jan 2026 00:00:00 +0000

The WCH CH32V003 costs less than a stamp and runs a 32-bit RISC-V core at 48 MHz. It has 2 KB of RAM, 16 KB of flash, and a surprisingly complete peripheral set: USART, SPI, I²C, ADC, timers.

We set up the open-source MounRiver toolchain, flash a UART echo program over the single-wire debug interface, and measure current consumption in sleep mode: 8 µA. For battery-powered sensors, this chip is hard to beat.

The interesting part is not only the price. It is what this device teaches about writing firmware with hard limits. With 2 KB RAM, every buffer is a design decision. With 16 KB flash, libraries have to justify their existence. That pressure tends to produce cleaner code than “just add another package.”

Bring-up notes that save time

My shortest path to first success:

Get a known-good blink or UART echo working first.
Verify clock configuration before touching peripherals.
Keep interrupts disabled until polling logic is stable.
Add one peripheral at a time and re-test power draw.

Most early failures are clock, pin mux, or toolchain path problems, not “mystical hardware bugs.” If serial output is dead, confirm GPIO mode and baud assumptions before rewriting half the project.

Why this chip is useful in practice

CH32V003 is ideal for disposable probes, tiny sensor nodes, and protocol bridges where BOM cost matters. You can still keep a disciplined structure: small drivers, explicit init sequence, and one integration test per module. That gives reliability without heavyweight frameworks.

AVR Bare-Metal Blinking

Wed, 20 Aug 2025 00:00:00 +0000

No Arduino libraries. No HAL. Just registers.

An ATmega328P has DDRB, PORTB, and a 16-bit timer. We configure Timer1 in CTC mode with a 1 Hz compare match, toggle PB5 (the onboard LED pin) in the ISR, and end up with a binary that fits in 176 bytes. The Makefile uses avr-gcc and avrdude directly — no IDE required.

This exercise looks trivial, but it trains the exact muscle many developers skip: understanding cause and effect between register writes and hardware behavior. You do not “ask an API” to blink. You define direction bits, timer prescalers, compare values, and interrupt masks yourself.

Minimal mental model

DDRB configures PB5 as output.
TCCR1A/TCCR1B define timer mode and prescaler.
OCR1A sets compare threshold.
TIMSK1 enables compare interrupt.
ISR toggles PORTB bit for the LED.

When this chain is explicit, debugging gets faster. If timing is wrong, you inspect clock and prescaler. If the LED is dark, verify direction and pin. Each symptom maps to a small set of causes.

Why still do this in 2026

Bare-metal AVR is still a great teaching platform because feedback is fast and tooling is mature. You can compile, flash, and verify behavior in a few seconds, then iterate. Even if your production target is different, this discipline transfers directly to RISC-V, ARM, and RTOS-based projects.