Firmware development, for the code that moves things.
Where the software stops being an idea.
Firmware is the software that has to be right, because there is a motor, a lock, or a payment on the other side of it, and no user to apologise to. We write the code that runs on the board: bring-up on new hardware, drivers for the parts around it, the control logic that dispenses or unlocks, the buses that talk to readers and machines, and an update path that cannot leave a unit unbootable in the field.
The firmware work we take on
Some projects are a board from bare metal, some are a defect in code somebody else wrote three years ago. Both are normal.
Board bring-up and hardware validation
First code on a new board: clocks, memory, peripherals, and the unglamorous work of proving each part responds before anything is built on top. This is also where hardware problems get found, which is far cheaper now than after a production run.
- Clock, memory, and peripheral initialisation
- Bootloader and startup sequence
- Bench validation against the schematic
- Hardware issues reported back to the board designer
Drivers and peripheral integration
The parts around the microcontroller each speak their own dialect over their own bus. We write and integrate the drivers: sensors, displays, readers, relays, and the storage everything falls back to when the connection is gone.
- I2C, SPI, UART, and CAN peripherals
- Sensor, display, and reader drivers
- Local storage and logging on device
- Vendor driver integration and debugging
Motion, dispense, and lock control
The part with physical consequences. Motors, solenoids, and locks driven with the sensing to know whether the thing actually happened, and the failure handling for when it did not: a jam, a door that did not close, a product that never dropped.
- Motor and solenoid control with feedback
- Dispense verification and jam detection
- Electronic lock control and door sensing
- Safe states on fault and power loss
Payment and machine buses
Unattended hardware lives on standard buses, and they are unforgiving about timing. We implement and integrate the protocols that connect a machine to its payment devices and to the systems that audit it.
- MDB integration for payment devices
- DEX audit data extraction
- RS-485, Modbus, and vendor serial protocols
- Card and contactless reader integration
Power, reliability, and recovery
Firmware is judged on what it does at three in the morning when nobody is watching. Watchdogs, brownout handling, and state that survives a power cut, so a unit comes back on its own rather than waiting for someone to unplug it.
- Watchdogs and automatic recovery
- Brownout and power-loss handling
- Persistent state across resets
- Low-power and battery operation
Update path and long-term maintenance
Every fitted unit is a promise to be able to change it later. We build a bootloader and update mechanism that verifies an image before it commits and falls back to the last working one if it does not boot, so an update is never a site visit waiting to happen.
- Bootloader with signed image verification
- Fallback to last known good firmware
- Field diagnostics and log capture
- Handover documentation and toolchain setup
How the work runs
Tell us what you need
A short written brief is enough to start: what you are building, the stack it has to live in, and the problem behind it. Someone technical reads it, not a sales rep.
passed when we reply with questions and a proposed shape
Scope and quote
We agree what the first release contains and what it costs before anything is built. Anything we cannot estimate honestly gets scoped on its own rather than padded into the total.
passed when the scope and the quote are agreed
Build in the open
Working software arrives in increments, in your repository, with our commits visible from the first week. Progress is something you can open and run, not a status report.
passed when a real user is doing a real job in it
Iterate, then hand over
What the first release teaches sets the priority for the next one. When you want it in house, documentation and a handover period are part of the engagement rather than an extra.
passed when your team can run it without us
How pricing works
Fixed price per milestone
You approve each milestone and its price before it starts, so the cost is known before the work is rather than after. Milestones are sized to be worth reviewing on their own.
Monthly rate for a dedicated team
A set team at a set monthly cost, with notice rather than a minimum term. Priorities move between sprints without renegotiating anything.
Scoping first, quote after
We work out what it should be with you before quoting it. There is no charge for that conversation and no obligation to go ahead.
Frequently asked questions
What we bring to a board
Every build ships end to end, from first scope to live deployment and ongoing support.
