CLIEncoders · Services
Embedded systems and firmware development
Firmware is the layer where hardware ambition meets the constraint of what actually fits in flash. We write it to be maintained by whoever comes next, including when that is you.
The requirement nobody writes down
Every embedded specification lists features. Almost none list the two properties that decide whether the product survives its first year in the field: can it be updated, and can a fault be diagnosed from a distance.
We treat both as requirements from the first commit. That means a bootloader and update path designed before the feature work rather than bolted on for the second production run, and structured logging with enough context that a support engineer can tell a power-supply brownout from a firmware deadlock without shipping the unit back.
Platforms and scope
Bare-metal and RTOS work on STM32, ESP32, RP2040, Nordic and Raspberry Pi, with FreeRTOS and Zephyr where an RTOS earns its keep — and without one where it does not, because a scheduler on a device with one job is complexity you pay for forever.
Peripheral and sensor driver development, low-power design where battery life is the specification that matters most, wired and wireless connectivity across BLE, Wi-Fi, LoRaWAN, CAN bus and Modbus, and secure boot with signed updates where the threat model calls for it.
How we work
Version control, code review and CI from day one — including hardware-in-the-loop tests where the target can be automated, so a regression is caught by a pipeline rather than by a customer. Firmware ships with a written architecture document explaining why it is shaped the way it is, which is the part that decays fastest and matters most a year later.
Where the hardware is also ours, firmware and board design proceed together and the pin map serves both. Where the hardware is yours, we start with a review of the schematic, because a firmware problem that is really a hardware problem is the most expensive kind to chase.
Questions
What people ask before starting
Bare-metal or RTOS — how do you decide?
By counting genuinely concurrent activities with independent timing requirements. One or two, and a super-loop with interrupts is simpler, smaller and easier to reason about. Several, especially with a network stack in the mix, and an RTOS pays for itself. We make the call explicitly and write down the reasoning, because the wrong choice is painful to reverse later.
Can you add OTA updates to a product already in the field?
Sometimes — it depends on whether the existing flash layout leaves room for a bootloader and a staging area, and whether the deployed units can be reached at all. This is worth an honest assessment before you budget for it. Retrofitting update capability is one of the few firmware jobs where the answer is occasionally no.
Do you write the mobile or web side too?
Yes, and it is usually the better arrangement for connected products. The protocol between device and app is where integration projects fail most often, and having one team own both sides of it removes an entire class of finger-pointing.
What if our hardware has a bug?
We will find it and tell you plainly, with the evidence. Firmware can work around a surprising amount of hardware trouble, but some workarounds cost more in reliability than a respin costs in money, and you deserve that trade-off stated rather than quietly absorbed.
Related
Where this usually connects
Tell us what you are building
One technical call is usually enough to tell you whether this is straightforward, genuinely hard, or the wrong approach entirely. We would rather say so early than quote for the wrong thing.
Start the conversation