Versioned EEPROM Settings on Arduino
As firmware evolves, stored settings formats change. If EEPROM layout is not versioned, upgrades can silently load garbage and produce hard-to-diagnose behavior.
TAG
As firmware evolves, stored settings formats change. If EEPROM layout is not versioned, upgrades can silently load garbage and produce hard-to-diagnose behavior.
Small Arduino prototypes often fail when moved into real environments. The cause is rarely one major bug. It is usually the accumulation of power noise, slow memory leaks, missing timeouts, and weak recovery behavior.
Writing `no_std` Rust firmware requires different habits than server Rust. Memory is constrained, timing is strict, and panic strategy must be deliberate.
Many firmware bugs are actually invalid state transitions. Rust helps by making state explicit and hard to misuse, modelling each controller state as an enum variant with transitions that consume the old state and return the next one.
Cross-compiling Rust is easy to start and hard to standardize across teams. I treat toolchains as part of the project, not local machine state. Target triples, linker config, and environment variables live in versioned project files.
Hardware abstraction layers are where embedded code often becomes difficult to test. I design traits around capabilities, then keep business logic independent from concrete drivers.
Many ESP32 projects run perfectly on a developer desk and collapse once deployed in apartments, offices, or industrial spaces with noisy Wi-Fi conditions. The main mistake is treating every disconnect as an exceptional event.
LoRa is chosen for range and efficiency, but many nodes still miss battery targets by a large margin. The reason is usually poor budgeting assumptions and missing field validation.
Unstable power is behind a large share of embedded bugs: random resets, noisy ADC values, communication drops, and drifting sensor readings. Good power design is often the highest-leverage hardware improvement.
OTA updates are high leverage and high risk. A weak update process can brick large parts of a fleet quickly. A strong one reduces support load and security risk while preserving device availability.