Firmware Budgets: Power, Memory and the Update Path
On constrained hardware the architecture is decided by three budgets fixed long before the first line of firmware. Treating the update mechanism as a late feature is how fleets become unfixable.
Embedded work is unforgiving in a specific way: the expensive mistakes are made before any firmware exists. By the time the schematic is frozen, the power budget, the memory budget and the update path have already decided most of what the software can be. Software cannot buy back a milliamp that the hardware spends, and it cannot add a flash bank that is not on the board.
The power budget is an architecture document
For a battery device, average current draw determines service life, and service life determines whether the product is viable. That figure is set by duty cycle, not by peak efficiency: how long the radio is on, how often the sensor is sampled, how deep the sleep state between them is, and how much energy is burned on each wake transition.
The consequences reach into ordinary code. A chatty protocol is a power decision. Retry policy is a power decision — exponential backoff with a cap is not just network hygiene, it is the difference between a device that survives an outage and one that flattens its battery during one. Logging is a power decision, because a log line that traverses the radio costs orders of magnitude more than one that does not.
Build the energy model early, on a spreadsheet, before the board exists. Then measure against it on real hardware with a current probe as soon as one does. The gap between model and measurement is where the surprises live, and finding it at month two is a design conversation while finding it at month nine is a redesign.
Memory is a static problem
On a microcontroller, dynamic allocation is not a convenience, it is a deferred fault. Fragmentation on a device that runs for years without a reset will eventually produce an allocation failure at the worst possible moment, and the failure will be unreproducible on a bench.
The workable discipline is to allocate statically: fixed pools, fixed buffers, sized for the worst case and verified at link time. Bound the stack too, and check it — a high-water-mark pattern or a stack guard costs almost nothing and turns a mysterious hard fault into a clear diagnostic. Where a dynamic structure is genuinely required, give it a dedicated pool with a hard ceiling and a defined behaviour when the ceiling is reached.
The tooling matters here. A build that reports section sizes on every commit, with a threshold that fails the build, prevents the slow creep that ends with a firmware image that no longer fits three weeks before shipping.
The update path decides whether the fleet is fixable
This is the one that gets deferred, and it is the one that determines whether the product can be supported at all. A device without a reliable update mechanism is a device whose bugs are permanent.
A workable over-the-air update has non-negotiable properties. The image is signed and verified before it is trusted. The write is atomic, with an A/B bank arrangement or a staged image and a verified swap, so that a power loss mid-update leaves a bootable device. There is automatic rollback on a failed boot, driven by a watchdog and a confirmation flag that the new firmware must set once it has proven itself. Rollout is staged, because pushing to a whole fleet at once means discovering a bad image on the whole fleet at once. And the bootloader itself is either not updatable or updatable through a separate, far more conservative path, since a failed bootloader update is a device recall.
Add up the flash cost of that — two banks plus a bootloader plus a scratch region — and it becomes obvious why this must be decided before the part is chosen.
Design the telemetry you will need at scale
A single device on a bench is legible. Ten thousand devices in the field are legible only through the telemetry you designed in advance.
The minimum useful set is small: firmware version, reset reason, uptime, battery state, connectivity statistics and a bounded error counter per category. Send it periodically, compactly, and with enough context to group by hardware revision and firmware version. The first field problem you hit will be a correlation question — which revision, which version, which environment — and telemetry that cannot answer it turns a two-hour investigation into a two-week one.
None of this is advanced. It is simply the part of the work that has to happen before it is convenient.