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

Related reading:

Debugging Noisy Power Rails

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

Noisy power rails cause some of the most frustrating hardware bugs because the symptoms look random while the root cause is often deterministic. A board that “usually works” at room temperature can fail after five minutes under load, pass again after reboot, and mislead you into chasing firmware ghosts for days.

A useful mindset shift is this: unstable power is not a side issue. It is a primary signal path. If voltage integrity is poor, every digital subsystem becomes statistically unreliable, and software symptoms are just the final expression.

My default workflow starts with measurement hygiene before diagnosis:

short ground spring on probe, not long alligator wire
scope bandwidth limit toggled on/off to compare high-frequency noise
capture at startup, idle, peak load, and transient edges
document probe points physically on board photos

Bad probing creates fake ripple. Good probing reveals real coupling.

First pass checks are simple:

DC level within regulator tolerance
ripple amplitude against component and MCU limits
transient droop during load step
recovery time after transient

If rail droop aligns with brownout resets, you are already close to root cause.

Many failures come from layout, not component choice. Long return paths, poor decoupling placement, and shared high-current loops inject noise into sensitive domains. The classic mistake is placing bulk capacitance “on the board” but not near the switching current loop that actually needs it.

Decoupling strategy must be layered:

bulk capacitors for low-frequency energy
mid-value ceramics for mid-band support
small ceramics close to IC pins for high-frequency edges

You cannot substitute one category for another and expect broad-band stability.

Another frequent issue is regulator operating mode. Some switchers enter pulse-skipping or burst modes at light loads, creating ripple patterns that vanish under bench tests with constant load but reappear in real duty cycles. If your device has sleep/wake behavior, you must test rails during those transitions explicitly.

Grounding is equally important. “Common ground” in schematic does not mean common impedance in reality. If ADC reference return shares noisy digital current paths, measurements drift. If RF front-end return shares switching loops, sensitivity collapses. Separate returns and tie at controlled points where possible.

Temperature is the hidden multiplier. ESR changes, regulator compensation margins shrink, and borderline systems cross failure thresholds. Always run a thermal variance pass:

cold start
nominal ambient
warmed board

If behavior changes sharply with temperature, inspect compensation and component derating assumptions.

I also recommend intentional stress tests:

rapid load toggling
USB cable swaps with different resistance
long harness injection
intentional supply sag within safe bounds

Robust designs degrade gracefully. Fragile ones fail theatrically.

When debugging mixed analog-digital boards, isolate domains in experiments. Power analog from clean bench source while digital remains on board regulator, then reverse. This quickly identifies whether the coupling direction is analog-to-digital, digital-to-analog, or both.

Firmware can help hardware diagnosis without becoming a crutch. Add telemetry:

brownout counters
rail ADC snapshots before reset
timestamped fault reasons
load-state markers around heavy operations

Telemetry does not fix power integrity, but it shortens hypothesis cycles dramatically.

One common anti-pattern is over-filtering after the fact. Engineers add ferrite beads and extra capacitors everywhere until symptoms soften, then ship. This can mask a fundamental loop stability or return-path problem. Prefer first-principles fixes: loop minimization, proper decoupling placement, compensation review, domain partitioning.

Board revision discipline matters too. Keep change batches small and attributable:

rev A: decoupling placement change only
rev B: regulator compensation update only
rev C: return path reroute only

If you change ten variables per spin, you learn almost nothing.

A practical “done” checklist for rail stability:

ripple within target across states
transient droop below brownout threshold margin
no unexplained resets over long stress runs
ADC/reference stability within spec
behavior stable across temperature and load profiles

Until all five pass, call the board “diagnostic,” not “production-ready.”

Power integrity work is rarely glamorous, but it is where reliable products are born. Teams that treat rails as first-class design artifacts ship fewer mysteries, write less defensive firmware, and spend less time in late-stage panic labs.

If you remember one sentence: measure the rail where the current switches, not where the schematic is pretty. That single habit catches a surprising number of expensive mistakes early.

Firmware telemetry example

void log_power_snapshot(void) {
  snapshot.vdd_mv = read_adc_mv(VDD_CH);
  snapshot.brownout_count = read_reset_counter();
  snapshot.load_state = current_load_state();
  emit_snapshot(snapshot);
}

Telemetry does not replace probing, but it shortens the path from symptom to actionable hypothesis.

Related reading:

Ground Is a Design Interface

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

Many circuit failures are not caused by “bad signals.” They are caused by bad assumptions about ground. Designers often treat ground as a neutral reference that exists automatically once a symbol is placed. In reality, ground is a physical network with resistance, inductance, and shared current paths. If we ignore that, measurements lie, interfaces become unstable, and debugging turns into superstition.

The mental shift is simple but profound: ground is not the absence of design. Ground is part of the design interface. Every subsystem communicates through it, injects noise into it, and depends on its stability. Once you frame ground this way, layout and topology decisions stop feeling cosmetic and start feeling architectural.

A common early mistake is routing sensitive analog return currents through the same narrow paths used by switching loads. The board may pass basic tests, then fail under realistic activity when motor drivers, DC-DC converters, or digital bursts modulate the local reference. The symptom appears as random ADC jitter or intermittent threshold misfires. The root cause is shared impedance, not firmware.

Star-ground strategies can help in some low-frequency or mixed-signal contexts, but they are often misapplied as a universal rule. Solid planes usually win for modern digital work because they minimize return path impedance and give high-frequency currents predictable local loops under signal traces. The key is intentional current-path thinking, not slogan-driven layout.

Measurement technique also determines whether you see truth or artifacts. Using long oscilloscope ground clips on fast edges can invent ringing that is mostly probe loop inductance. Engineers then “fix” a problem that exists in the measurement setup. Short ground springs, proper probe compensation, and awareness of reference path are not optional details; they are prerequisites for trustworthy diagnosis.

Connector strategy reveals ground philosophy quickly. Boards with inadequate ground pins in high-speed or noisy interfaces force return currents through awkward paths, increasing emissions and susceptibility. Good connector pinout design alternates signals and returns where possible, reserves dedicated quiet returns for sensitive channels, and accounts for cable behavior, not just schematic neatness.

Power integrity is entangled with ground integrity. Decoupling capacitors are often discussed as local energy reservoirs, which is true, but their effectiveness depends on short, low-inductance loops into ground. A perfectly valued capacitor placed with poor return routing underperforms dramatically. Placement and loop geometry dominate textbook capacitance calculations more often than teams expect.

Grounding errors also create software illusions. Firmware engineers may chase race conditions when the true issue is reference movement that shifts logic thresholds under load. Timing fixes sometimes appear to work because they reduce simultaneous switching activity, not because they solved software logic. Cross-disciplinary debugging prevents this misattribution and saves weeks.

Board bring-up benefits from a ground-first checklist:

Confirm continuity and low-resistance paths for primary returns.
Verify high-current loops are short and segregated from sensitive nodes.
Inspect decoupling loop geometry physically, not just in CAD netlists.
Probe critical points with low-inductance techniques.
Correlate signal anomalies with load events.

This sequence catches issues earlier than random parameter sweeps.

In mixed-voltage systems, ground partitioning decisions become even more delicate. Isolation boundaries, level shifters, and external peripherals can introduce unexpected return paths through shields, USB grounds, or measurement equipment. Teams should document intended return routes explicitly and validate them in lab setups that mirror field wiring. Bench-only success with ideal lab grounding often collapses in deployed environments.

EMC behavior is often where weak ground design is finally exposed. Boards that “work” functionally may fail emissions or immunity tests because return paths were treated as afterthoughts. Retrofitting fixes at that stage is expensive: ferrites, shield tweaks, stitching vias, and cable rework can help, but they are compensations. The cheaper path is to design current return intentionally from the first layout pass.

Ground discipline is also a communication tool. When schematics and layout notes name current paths and reference assumptions, teams align faster. Reviewers can reason about failure modes before prototypes exist. Firmware and hardware engineers share a common model instead of debating symptoms from different abstractions. This shortens iteration and improves reliability.

If there is one practical takeaway, it is this: whenever a circuit behaves inconsistently, ask “where does the return current actually flow?” before changing code, values, or component vendors. That question reframes debugging around physics instead of folklore. Ground is not background. Ground is the interface all your interfaces rely on.

Measurement snippet for repeatable captures

Point: MCU VDD pin (not regulator output only)
Probe: x10, short spring ground
Capture windows:
  - cold startup
  - idle
  - peak switching load
  - load step edge
Record:
  - ripple p-p
  - droop minimum
  - recovery time

Consistency in measurement setup is what makes comparisons meaningful across board revisions.

Related reading:

Prototyping with Failure Budgets

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

Most prototype plans assume success too early. Schedules are built around happy-path bring-up, and risk is represented as a vague buffer at the end. In practice, hardware projects move faster when failure is budgeted explicitly from the beginning.

A failure budget is not pessimism. It is resource planning for uncertainty:

time for bad assumptions
time for measurement mistakes
time for rework
time for supply surprises
time for documentation repair

Without these budgets, teams call normal engineering iteration “delay.”

The first step is failure classification. Not all failures are equal:

Design failures - wrong topology, wrong margins, incorrect assumptions.
Integration failures - interfaces disagree despite locally valid modules.
Manufacturing failures - assembly defects, tolerances, placement variance.
Operational failures - behavior differs under real workload/temperature/noise.

Each class needs different mitigation strategy, so one generic “debug week” is rarely effective.

In early prototype phases, I allocate explicit percentages:

40% planned build/measurement
40% planned failure handling
20% contingency

The exact numbers vary, but the principle is fixed: failure handling is first-class work.

Teams often underestimate setup friction too. The first useful measurement of a new board may require:

probe fixture adaptation
firmware instrumentation pass
calibration checks
power sequencing scripts

None of this ships to customers, but all of it determines debugging velocity. Budget it.

A good failure-budget workflow begins with hypothesis inventory. Before fabrication, write down the top assumptions that would hurt most if wrong:

regulator stability over load profile
oscillator startup margin
ADC reference noise limits
interface timing at worst-case cable length
thermal dissipation under sustained duty

Then attach verification plans and fallback options to each assumption.

This shifts the team from reactive debugging to prepared debugging.

Another powerful habit is “one-risk-per-revision” where feasible. If rev A changes power stage and connector pinout and clock source and firmware boot mode at once, post-failure attribution becomes slow and political. Smaller change batches reduce ambiguity and improve learning rate.

Failure budgets also improve communication with stakeholders. Instead of saying “we are late,” you can say:

planned design-risk budget consumed at 70%
integration-risk budget consumed at 40%
new unknown introduced by vendor BOM substitution

This is honest, actionable reporting.

There is a cultural benefit too. When failure time is budgeted, engineers stop hiding uncertainty. They surface problems earlier because discovery is expected, not punished. Early truth beats late heroics.

Measurement quality must be part of the budget. I have seen teams burn days on fake signals from bad probing. Allocate time for measurement validation:

sanity checks with known references
probe compensation verification
alternate instrument cross-checks
repeatability check by second engineer

If measurements are unreliable, all downstream conclusions are suspect.

Software teams have similar patterns in reliability engineering. Hardware teams can borrow them directly:

failure budget burn rate
rollback criteria
pre-declared stop conditions
postmortem with concrete follow-up

The vocabulary may differ, the operational logic is identical.

A practical board-level failure budget dashboard can be simple:

open high-risk assumptions
failed verification count by class
mean time from failure report to hypothesis
mean time from hypothesis to validated fix
unresolved supplier-related risks

Even lightweight metrics make iteration quality visible.

Another common miss is treating documentation as optional during prototyping. Under pressure, teams skip notes “to go faster,” then repeat mistakes because context is lost. Allocate explicit documentation time in the failure budget:

what failed
why it failed
how it was verified
what changed
what remains uncertain

This transforms prototype rounds into reusable knowledge.

Supply chain volatility deserves dedicated budget lines now. Alternate parts with nominally equivalent values can change behavior materially. If your prototype depends on one fragile component source, include time for qualification variants before it becomes an emergency.

Budgeting for failure does not mean accepting low quality. It means treating quality as an outcome of controlled iteration. The fastest teams are not those with few failures. They are those that detect, classify, and resolve failures with minimal confusion.

A useful decision checkpoint at each milestone:

are we failing in new ways (learning), or same ways (process issue)?
are unresolved failures shrinking in severity?
are we increasing confidence in system margins?

If answers trend poorly, stop adding features and stabilize fundamentals.

Failure budgets are especially effective for interdisciplinary projects where electrical, firmware, and mechanical decisions interact. Shared budget language prevents one domain from appearing blocked by another when the real issue is cross-domain assumption mismatch.

In the long run, failure budgeting creates calmer projects. Less panic, fewer surprises, better prioritization, cleaner postmortems. The prototype stage becomes what it should be: a deliberate learning phase that converges toward robust production behavior.

If you want one immediate change, add a “planned failure work” line to your next prototype plan and protect it from feature pressure. That single line can prevent weeks of late-stage scrambling.

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.

Related reading:

Hand-Soldering 0402 Components

Sun, 28 Dec 2025 00:00:00 +0000

0402 passives measure 1.0 × 0.5 mm. They’re barely visible to the naked eye, yet hand-soldering them is doable with the right technique: flux, a fine conical tip, thin solder wire, and patience.

The key is to tin one pad first, tack the component down, then solder the other side. A stereo microscope helps but isn’t strictly necessary if you have good lighting and steady hands.

What usually fails is not dexterity, but process order. If you approach 0402 work like through-hole soldering, parts tombstone, slide, or disappear into the carpet. If you stage the work correctly, the joints become boringly repeatable.

Workflow that keeps rework low

Clean pads with isopropyl alcohol.
Add liquid flux before touching solder.
Pre-tin exactly one pad with a tiny amount.
Hold the part with tweezers, reflow that pad, and “tack” alignment.
Solder the second pad with minimal dwell time.
Revisit the first pad only if wetting looks poor.

The microscope is optional, but magnification changes quality control. Even a cheap USB scope catches bridges and cold joints before power-on.

Common mistakes

Too much solder: creates hidden bridges under the body.
Too little flux: oxidized pads and grainy joints.
Too much heat: lifted pads, especially on cheap proto boards.
Mechanical pressure while heating: parts shoot away or skew.

My rule is simple: if the joint takes more than a few seconds, stop, re-flux, and try again. Fighting a dry joint with temperature only makes damage faster.

Related reading: