Embedded & IoT
Embedded work has constraints you cannot argue with. There is a fixed amount of RAM, a fixed power budget, and a device that has to keep running in a place nobody will visit.
I write firmware for that environment, including the increasingly common case of putting a neural network on it.
What that involves
- Low-level firmware. Peripherals, interrupts, DMA, bring-up on new boards, and the unglamorous work of making a device survive power loss mid-write.
- ML on microcontrollers. Sizing the tensor arena before choosing a model, quantising with real calibration data, and confirming the feature pipeline on the device matches the one used in training.
- Memory budgeting. Flash for weights, RAM for activations, and the peak layer that quietly determines whether any of it fits.
- Power awareness. Duty cycling and sleep states, so a battery figure in a spreadsheet resembles the one in the field.
- Connectivity. Getting data off the device reliably, including when the network is not there.
Signals you need this
- A model that runs on a laptop and will not fit the target.
- Accuracy that collapses once the model is quantised.
- Field behaviour that does not match bench behaviour.
- Battery life a fraction of the estimate.
- A device that needs a manual reset more often than anyone admits.
How the work runs
On the real hardware from the start. Host benchmarks mislead in both directions, and the interesting failures only appear when inference is competing with an interrupt-driven sampler for the same cycles.
Related writing
Start a conversation
Bring the awkward part. If it is not something I should take on I will say so, and point you at what would help.