Source code
Clean, documented, version-controlled, with full ownership rights. No lock-in to the original developer.
Custom embedded firmware for microcontrollers, FPGAs, and SBCs, whether bare-metal, RTOS, or embedded Linux. Production-ready code from an electronics engineer with 20+ years of experience.
In-house teams know their product best, but firmware is one of the easiest places to under-resource, and the result is code that works on the bench, ships late, and turns into a maintenance liability. Bringing me in for the bring-up phase, a specific subsystem such as a BLE stack, OTA update, or motor control, or an entire product stack lets your team stay focused on what they do best while I handle the embedded specifics with someone who has done it before. Most of this is embedded firmware development on parts like the ESP32 and STM32, taken from first board bring-up through to tested, production firmware rather than a demo that only runs once.
Bare-metal, RTOS, or embedded Linux, plus everything around the code that a product needs to ship and stay serviceable.
Clean, documented, version-controlled, with full ownership rights. No lock-in to the original developer.
Module breakdown, interface contracts, RTOS task list with priorities, memory and stack budgets, and the design decisions that led there.
Reproducible toolchain configuration. Anyone with the source can build the exact same binary that was tested.
Clean driver layer for every peripheral on the board, portable across hardware revisions.
I2C, SPI, UART, USB, CAN, Ethernet, BLE, Wi-Fi, NB-IoT, LoRa, Modbus, MQTT. Whatever the product needs.
Field-upgradeable firmware with rollback, signed images, and the ability to recover from a failed update.
Unit tests for critical logic, hardware-in-loop tests on the actual target, and a regression suite that runs on every build.
A separate firmware image for end-of-line testing in manufacturing.
Optional desktop or mobile application for configuration, monitoring, or data analysis.
The same mistakes show up in every shipped product that was not done by someone who has been through it before.
Dynamic allocation that creeps over weeks until the device gets sluggish or crashes.
Concurrency bugs that pass QA, ship, and then surface intermittently in the field where they are impossible to reproduce.
Real-time deadlines missed under heavy load or edge conditions, causing dropped samples, missed packets, or corrupted state.
Stack sized by guesswork, then overflowed the first time a deeper code path runs in the field.
Watchdog kicked from the wrong place so it never catches the actual hang it is there to detect.
OTA with no rollback and no recovery, so a single bad release means a truck roll for every device.
I define the software architecture from your requirements, choose RTOS or bare-metal, plan the module structure, and define the interfaces between components.
I initialise core functionality: clock configuration, peripheral initialisation, and basic I/O, verifying the hardware works before building application logic.
I implement drivers for every peripheral: ADC, DAC, timers, communication interfaces, and external devices, testing each one independently.
I build the application logic on top of the drivers and RTOS: state machines, control algorithms, and user interface handling.
System integration testing verifies every component works together, and stress testing validates behaviour under edge conditions and resource constraints.
An electronics design engineer with 20+ years of professional experience across analog, digital, RF, and power designs, delivered to clients in 15+ countries. Your project is handled by the person who has shipped hardware like it, start to finish.
See the project portfolioBare-metal firmware for microcontrollers (Cortex-M, AVR, MSP430, RISC-V), RTOS-based firmware (FreeRTOS, Zephyr, ThreadX), embedded Linux firmware on SBCs and SoMs, FPGA HDL, bootloader and over-the-air update systems, and companion desktop or mobile applications that interface with the device.
Yes. Existing hardware is a common starting point. The first step is reviewing the schematic and existing firmware (if any), then proposing an architecture that fits the hardware constraints. New firmware can be written from scratch or layered on top of an existing codebase.
You do. All source code, build scripts, documentation, and assets are delivered with full ownership rights on full payment, unless the engagement explicitly involves third-party libraries that require separate licensing. No ongoing dependency on the original developer for updates or releases.
Unit tests for critical logic, hardware-in-loop testing on the actual target, automated regression suite running on every build, and a separate production test firmware for end-of-line validation in manufacturing. All tests are delivered with the source so the team can extend them.
Yes. A typical engagement covers bootloader, application firmware, drivers, communication stacks, OTA update with rollback, and any companion desktop tools. The bootloader and update mechanism are designed for field-deployable products that need to recover safely from interrupted updates.
STM32 (Cortex-M0 through M7), nRF52 / nRF53, ESP32, NXP i.MX RT and i.MX application processors, Renesas RA, TI MSP430 and Tiva, Microchip PIC and AVR, Espressif ESP-IDF, RISC-V cores, and others. Embedded Linux on SBCs (Raspberry Pi CM, Toradex, NXP i.MX SoMs).
Yes. Firmware consulting and code review engagements are available for teams that have an in-house developer but want a senior pair of eyes on architecture, code quality, real-time correctness, or release readiness. Findings are delivered as a written report with prioritised recommendations.
Engagements are typically fixed-price for a defined scope (e.g. firmware bring-up for a specific board, bootloader implementation, BLE stack integration). Open-ended consulting and ongoing maintenance is hourly. A scope and quote is provided up front before any work starts.
Yes. Embedded firmware development on ESP32, STM32, and similar microcontrollers is core work, from first board bring-up and driver development through to tested, production firmware, including the low-level peripheral and communication code the product depends on.
From board bring-up to a full product firmware stack, I write the firmware alongside the hardware it runs on. Tell me what the product needs to do, and I will send back a quote with scope, timeline, and price.
Request a Firmware Quote