Services · Embedded
Embedded software development, from first boot to production.
I write the software that runs on the device itself. The firmware at its core, the drivers underneath it, and the tooling that gets a build tested, signed and out to the field. Most of that work has been on products with a long service life, where a shortcut taken in the first year is still being paid off in the fifth.
What the work looks like
Product firmware
Bare-metal C on ARM Cortex-M (NXP LPC18xx, LPC11xx and LPC17xx, TI TM4C, Atmel) and on adjacent platforms such as ESP32. Greenfield work where the board is new, and just as often the other kind: an existing codebase that has to keep shipping while it changes underneath.
Hardware bring-up and drivers
The schematic-to-driver loop: read the schematic, read the datasheet, write the driver, then put a scope or an analyser on the bus to check that the hardware agrees with the code. New silicon comes up from the PDF, and the first boot on a new board revision is usually where the interesting problems live.
A bring-up that has stalled
A board that will not boot, an interface that works on the bench and fails in the field, a fault that only shows up in the customer's rack. This usually arrives as someone else's half-finished project, and the first job is separating what is genuinely broken from what was only ever assumed.
Protocols and interfaces
Links between devices, and between a device and its host, where the off-the-shelf option does not fit: control protocols over UDP, BLE between microcontrollers, HTTP and REST surfaces served by the device itself, serial links to an FPGA.
Test, build and release tooling
Firmware that is awkward to update has to be right before it leaves. That means CI building every branch, a test suite running against real hardware instead of a simulator, signed images, and a release flow that walks the whole sequence without depending on someone remembering a step.
Production-line test firmware
A codebase separate from the product firmware, with different constraints. It runs once per board on the assembly line, has to fail loudly rather than gracefully, and its job is to catch a bad solder joint before the board is in a box.
How this usually starts
Three shapes cover most of it.
A bounded problem
Something specific and diagnosable: a driver that has to exist, an interface misbehaving, a board that will not come up. Scoped up front, delivered, done.
Development partner over a longer run
Working alongside a product team for the length of a programme, carrying the embedded side while the team carries the product. This is the shape most of my Pulse-Eight work has taken.
A second opinion
A review before the money is committed: architecture, schematic, or the test strategy for a board about to go into production. Often a day or two, and worth the most while the decisions can still move.
Where this comes from
For Pulse-Eight I am the primary firmware author across their product lines. Most of that is MatrixOS, the firmware OS their smart products run on: the OneIP AV-over-IP family, the neo matrix range and the ProAmp audio amplifiers all boot the same platform. Around it sit the bootloaders with signed OTA across several board variants, and the production-line test firmware behind them.
Before the embedded work it was backend and server-side software, and that has stayed part of the job. Most embedded products now have a cloud side, and it helps when the same person is on both ends of the protocol.
I am also the original author and lead maintainer of libCEC, the HDMI-CEC library packaged in effectively every Linux distribution and running underneath Kodi, LibreELEC and OSMC. It has been in the field since 2011, on hardware I do not control, talking to television firmware I cannot test against. That is a useful school for building things that have to survive contact with reality.
Talk it through
If you have a board that needs software on it, or software on a board that is not behaving, a short call is usually enough to work out whether I am the right person for it.
Schedule an introductory meeting →