Overview
Firmware performance is a budget with three currencies: cycles, bytes, and microamps. Every product has a ceiling on all three, and optimization is usually the last work to get attention — it lands late, after the product works, when nobody wants to risk touching firmware that finally behaves. So devices ship drawing more current than they should, booting slower than they could, and pressed against a flash ceiling, with the spec written to match the firmware rather than the other way around.
Embedder treats performance as a measurable, closed-loop engineering problem instead of a guessing game. It baselines the firmware on real hardware — current trace, timing capture, memory map — finds what the silicon actually offers, applies changes grounded in the reference manual, and re-measures on the board to prove each one paid for itself. The result reads directly onto the product: battery life is a feature, a faster loop is headroom for the next feature, and firmware that fits a smaller flash part or a smaller battery is money on every unit built.
1. Why optimization gets skipped
Performance is hard to reason about by reading code. A line that looks harmless keeps a peripheral clock running; a poll loop that should have been an interrupt holds the core out of its sleep state; a forgotten pull-up bleeds microamps for the life of the product. The hot path is rarely where anyone thinks it is. The linker map goes unread, and task stacks get sized by doubling until the crashes stop.
None of it shows up in a debugger. It shows up on a current rail, a bus capture, a map file — which means the work waits for a specialist and a bench, and the bench is always busy. Add the late-program timing, when every edit to working firmware feels like risk, and optimization becomes the work everyone agrees matters and nobody schedules.
Meanwhile the costs compound quietly: the battery gets bigger to cover the sleep current, the flash part gets upgraded to cover the image size, and the BOM absorbs what the firmware didn’t.
2. Why generic AI can’t optimize firmware
Optimization claims are measurements. Ask a general-purpose agent to make firmware faster or leaner and you get advice — use DMA, enable link-time optimization, sleep more aggressively. Some of it is even right. But an optimization that isn’t measured on the target is a guess wearing a number, and desktop-software intuition about where time and power go is reliably wrong on a microcontroller.
The options live in the silicon, not the training data. Which sleep states exist, what wakes the part from each, which clocks gate independently, whether the hot path can run from RAM instead of wait-stated flash — all of it is part-specific, buried in the reference manual and its errata. Generic advice that ignores what your silicon allows is at best wasted and at worst a lockup that only happens in the deepest sleep state.
Unverified edits trade a working product for an unmeasured improvement. Performance changes are the riskiest edits firmware takes late in a program, and the three budgets trade against each other: the change that saves current can cost latency; the one that saves flash can cost cycles. Without hardware in the loop, those trades hide in commit messages instead of showing up in numbers.
3. How Embedder optimizes
3.1 Measure first
Embedder starts by measuring, not editing. Through the same proprietary SDK and hardware interaction layer the rest of the agent runs on, it captures a baseline in whichever currency the product is spending too much of: a power profiler trace across the workload with high-draw windows correlated back to what the firmware was doing at that moment, bus and timing captures for latency and throughput, and the build’s own evidence — map file, section sizes, stack watermarks — for the memory picture.
3.2 Ground every change in the part
From the baseline, the agent reads the reference manual for what the silicon actually supports — low-power modes, clock gates, wake sources, DMA channels, memory regions — and proposes changes grounded in what the part allows rather than what optimization folklore suggests. The wins are unglamorous and real:
- Power: moving the core into a deeper sleep state between events, gating clocks to idle peripherals, replacing busy-wait polling with interrupt- or DMA-driven paths, tuning wake sources, trimming GPIO and analog blocks left powered.
- Speed: hot paths and interrupt handlers placed out of wait-stated flash, DMA taking over copy loops the core was babysitting, ISRs trimmed to what must happen at interrupt time, compiler and linker options chosen by measurement instead of habit.
- Memory: dead code and duplicated HAL layers stripped, buffers and task stacks sized from measured watermarks instead of superstition, logging and string bloat put on a diet, the image walked back under the ceiling of the part you wanted to buy.
3.3 Measure, change, re-measure
The loop is the whole point. The agent applies a change, flashes the board, and re-runs the same profiling workload to confirm the number actually moved — and that nothing else regressed, with the firmware’s tests running alongside the measurement in the same closed loop. Where a change trades one budget for another, the trade shows up in the measurements, side by side, instead of hiding in a commit message. And because the loop runs without anyone at the keyboard, a full profiling sweep across workloads runs overnight from VS Code, with the results waiting in the morning.
A 40 µA saving is a number you can see, not a claim. So is a boot that got 80 ms faster, and an image that got 30 KB smaller.
3.4 Ship it as diffs
What lands is a pull request, or a series of them, each with the before-and-after measurement attached and the datasheet citation for why the change is safe on your part. There’s no black-box rewrite of the firmware. Your engineers review every change commit by commit, with the agent’s reasoning and the numbers right alongside the code — which matters most exactly when this work usually happens, late in a program, when trust in every edit has to be earned.
4. Scoping the win
The quickest path is a scoping call: bring the budget you’re missing — the sleep current that’s double the spec, the boot time the customer noticed, the image that no longer fits the flash — and the board it lives on. We’ll hook up the instruments, capture a baseline together, and size the win honestly, including the point of diminishing returns, because every optimization curve has one.