Discretizing control for firmware

A microcontroller acts at discrete instants. It reads sensors, updates controller state, and writes an actuator command. Continuous equations are useful designs, but firmware must choose a sample period, numerical approximation, state initialization, and behavior when execution is late. Those choices can change the closed loop.

Forward Euler integration uses x_{k+1} = x_k + Δt f(x_k, u_k). A discrete integral uses I_k = I_{k-1} + e_kΔt; a backward difference estimates derivative as (e_k - e_{k-1})/Δt. Omitting Δt makes gains depend accidentally on loop frequency. For the first-order system dx/dt = -x/τ, forward Euler becomes x_{k+1} = (1 - Δt/τ)x_k. The approximation decays without sign flipping when 0 < Δt/τ < 1; for larger steps it can oscillate numerically, and at Δt/τ ≥ 2 it is unstable even though the continuous system is stable.

Sampling should be comfortably faster than the dynamics the loop must control, but “as fast as possible” is not a design. ADC settling, sensor buses, computation, PWM update timing, and logging consume time. Use a monotonic timer and measured Δt when appropriate; separate slow communication or screen updates from a time-critical loop. The build decision may be to keep control at 100 Hz while updating a display at 10 Hz, preventing rendering delays from becoming motor-command jitter.

A common misconception is that a nominal delay call guarantees a fixed period. Work performed in the loop adds time, interrupts add jitter, and blocking I/O can miss deadlines. Another failure is changing sample rate without retuning or rescaling discrete gains. Quantization can create limit cycles near a setpoint, while saturation can wind up hidden state. Log timestamps, execution duration, missed-deadline count, raw input, state, and bounded output. The GPIO state-machine simulation, if used, is a bounded behavioral timing model, not MCU emulation.