Embedded Systems & Product Development Consultancy · London, UK
Embedded software and firmware development
Firmware built for the product’s whole life, from the first board bring-up to OTA updates years after launch. We write C and C++ for microcontrollers, RTOS and embedded Linux, structured so your team can maintain it after we hand over.
Why firmware gets harder after the first demo
Most firmware works on the bench. The trouble starts when features pile up, the hardware changes and the product has to survive in the field for years.
- Prototype code that was never meant to ship, now carrying the product.
- Timing problems that only appear when the radio, sensors and display all run at once.
- Drivers that fight the hardware because nobody read the schematic and the code side by side.
- No safe way to update devices once they’ve left the factory.
- A codebase only one person understands, and that person has moved on.
We’ve inherited every one of these. Each is fixable, and the earlier it’s addressed, the cheaper the fix.
See how we workWhat we build
From the first register write to the update that ships three years later.
Drivers and board support
Peripheral drivers over SPI, I²C, UART, USB and DMA for sensors, IMUs, NFC, displays and radios.
RTOS applications
Task design, timing and power states on FreeRTOS, Zephyr and Micrium OS, or bare metal where it fits.Embedded Linux
Yocto and Buildroot images, U-Boot, kernel drivers and the application layer for i.MX and similar SoCs.Bootloaders and OTA updates
Bootloaders, secure provisioning and field updates, designed so an interrupted update never leaves a device unusable.Connectivity
BLE and Bluetooth Mesh, Thread, Wi-Fi, NB-IoT, Ethernet with lwIP, Modbus and CAN, through to MQTT and AWS IoT Core.Low-power firmware
Sleep states, sensor scheduling and radio duty cycles, measured on real hardware with a battery analyser.Edge AI integration
Vision and sensor models running on NPU microcontrollers, wired into the firmware that feeds them.Displays and HMI
Touchscreen interfaces with LVGL on microcontrollers, and display applications on embedded Linux.Tools around the device
Desktop configuration and calibration tools in C#, Python test scripts and companion mobile apps.
How we write firmware
Firmware outlives the project that created it. We write it for the engineers who will maintain it next.
- Structure before features. A modular CMake build, a clear hardware abstraction layer and reusable libraries, so a new board or a new feature doesn’t mean a rewrite.
- Measure, don’t assume. Timing, current and signals checked on real hardware with oscilloscopes, logic analysers and SWD/JTAG debuggers.
- Test as we go. Unit tests, Python-driven bench tests and CI pipelines, with IEC 61508 unit testing in LDRA where safety demands it.
- Review and document. Peer code reviews, agreed coding standards and design documents your team will actually use.
- Hand over cleanly. Documentation, build instructions and a walkthrough with your engineers, so the code stays useful after we leave.
Platforms and tools
Microcontrollers and SoCs: STM32, NXP i.MX and i.MX RT, Nordic nRF52, ESP32, Silicon Labs EFR32, Microchip PIC and SAM, NVIDIA Jetson, NPU-equipped microcontrollers
Operating systems: FreeRTOS, Zephyr, Micrium OS, embedded Linux (Yocto, Buildroot), bare metal
Languages: C, C++, Python, C#, Rust
Tools: IAR, Keil, MCUXpresso, MPLAB X, GCC, CMake, Git, LDRA, Segger J-Link
Selected work
Client names stay private. The engineering doesn’t.
A low-power wearable medical device, from concept to pre-production
nRF52840 hardware and Zephyr firmware with BLE telemetry, secure provisioning and OTA updates, taken through bring-up, power optimisation and production preparation.
Read the case study
Safety-critical firmware for a device built at over a million units
Micrium OS on Silicon Labs EFR32, detection algorithms in C and IEC 61508 unit testing with LDRA
Read the case studyMore firmware work
FreeRTOS and a tuned lwIP stack on an i.MX RT power-station monitor, multi-processor firmware for marine transponders and more.
View case studiesFrequently asked firmware questions
Can you write firmware for hardware we designed ourselves?
Yes. We start from your schematics and datasheets, bring the board up with you and raise hardware issues early, before they get baked into the firmware.
Can you take over an existing firmware codebase?
Yes. We build, read and measure what exists, document what we find, then propose changes in order of risk. A rewrite is the last option, not the first.
Do we need bare metal, an RTOS or embedded Linux
It depends on the power budget, real-time needs, connectivity, display and cost. We’ll give you a reasoned recommendation; for bigger platform decisions, see Architecture & technical advisory.
Can you work in our repositories and CI
Yes. We work in your Git repositories, follow your branching and review process and plug into your CI pipeline.
Do you write firmware to safety standards?
Yes. We have developed safety-critical firmware to IEC 61508, using LDRA for unit testing and code review, and can work within your existing safety process.
How do you handle firmware updates in the field?
We design the bootloader, the update transport and rollback together, so an interrupted update leaves the device on its last working version.
Related services: Hardware/software integration · Debugging & troubleshooting · Architecture & technical advisory
Related expertise: RTOS · Embedded Linux · Wireless & IoT · Bootloaders, OTA & security · Low-power design · Testing & verification
Have firmware that needs writing, rescuing or reviewing
Send a few lines about the product and the platform it runs on.
Share your project with us, and we’ll get back to you within one business day.
Latest from the blog
Event Scope: EW – ELECTRONIC WARFARE EUROPE 2020
June 22, 2020
Event Scope: MICRO NANO MEMS 2020
June 8, 2020
Event Scope: EMBEDDED CONFERENCE SCANDINAVIA 2020
May 29, 2020