Embedded Firmware Development and Embedded Linux
RTOS and bare-metal firmware, kernel and driver work, and the board support package underneath both.
Context
Embedded firmware development usually starts at the point where the board already exists and the software on it is the problem. A vendor SDK that does not do what the datasheet implies. A kernel that will not come up on the new board revision. A part nobody has written a driver for. Firmware that passes every bench test and then hangs in the field after three weeks, which is the expensive one, because reproducing it costs more than fixing it. This is the layer between the schematic and the product: the RTOS or superloop the application sits on, the drivers underneath it, the bootloader that has to survive a failed update, and the crypto that decides whether an image is allowed to run at all. The board itself is covered on Hardware and PCB Design, and fleet-scale update and connectivity work is covered on Connected Devices.
Scope
What this covers
- 01FreeRTOS on Nordic nRF51, nRF52 and nRF52840 through the nRF5 SDK, with SoftDevice integration alongside the application.
- 02Zephyr on Nordic nRF91 through the nRF Connect SDK, including the cellular and GNSS subsystems.
- 03Bare-metal embedded firmware development in C and C++ on resource-constrained parts (Microchip PIC, ARM Cortex-M, Cypress PSoC 5): superloop and interrupt-driven architectures, hardware ISR design, and register-level peripheral and DMA configuration.
- 04Custom Linux kernel patches and driver integration through the board-files to device-tree transition, across Linux 3.x to 5.2.
- 05Board support packages on U-Boot and the OpenWRT build system, including a custom Linux kernel and a custom OpenWRT distribution authored for a 400 MHz MIPS target with 32 MB of RAM and 16 MB of flash.
- 06Driver integration over I2C, SPI and GPIO, plus user-space UART handling.
- 07Userspace Linux across x86, ARM64 and MIPS targets, including the bash and Python tooling around it.
- 08Embedded security and cryptography: mbedTLS for TLS on constrained parts, ARM TrustZone hardware crypto on nRF91 and nRF52840, TPM 2.0 key generation and storage on Linux platforms, secure boot, and passphrase-secured firmware upgrade paths.
- 09Bootloader work, including custom bootloader protocols where the standard one cannot reach the target, and staged update states that leave the device recoverable if power is lost mid-write.
- 10Defensive firmware for hardware nobody will visit: watchdogs, safe restart, brown-out behavior and recovery paths that do not require a truck.
- 11Firmware instrumentation and debug: J-Link over JTAG and SWD, GDB, logic analyzer capture on live buses, and timing measured rather than assumed.
Record
Work behind this
Delivered work, stated as facts rather than claims. Programs and employers are named where naming them is what makes the record checkable. Clients are not.
Questions
Questions technical buyers ask
Can you work inside the vendor SDK we already committed to?
Yes, and that is usually the right call. Nordic nRF Connect with Zephyr and the older nRF5 SDK with FreeRTOS and SoftDevice are both familiar ground, as is dropping below the abstraction layer to configure a peripheral or a DMA channel directly when the vendor driver cannot hold the timing. Replacing an SDK is a decision with a schedule cost, so it gets argued on evidence rather than preference.
Do you take kernel and driver work, or only application firmware?
Both. That includes custom kernel patches, driver integration over I2C, SPI and GPIO, device-tree work for new board revisions, and building a board support package from U-Boot up. One past target was a 400 MHz MIPS gateway with 16 MB of flash, where a custom kernel and a custom OpenWRT distribution were the only way to fit the product inside the part.
What does a first engagement usually look like?
Often a single defect that has resisted the existing team, because it is bounded and it is a fair test. A field hang nobody can reproduce, an update path that bricks a small percentage of units, a driver that has to exist before the next board spin. The deliverable is the fix plus the written explanation of the mechanism, which matters more than the patch: a fix without a mechanism is a coincidence.
Start a technical conversation
Describe the system, the constraint and the deadline. An engineer answers.
Tools and platforms we work with: Zephyr and FreeRTOS. Linux kernel and device tree. Nordic nRF Connect SDK and nRF5 SDK with SoftDevice. Cypress PSoC Creator. Bare-metal C and C++ on PIC and ARM Cortex-M. Linux 3.x to 5.2, U-Boot, OpenWRT build system, MIPS and ARM64 targets. mbedTLS, ARM TrustZone, TPM 2.0. SEGGER J-Link, GDB, Saleae and Digilent logic analyzers.