Software · System software
Embedded firmware
Dependable code for the microcontrollers inside your product, from first board bring-up to updates in the field.
Firmware has to work in limited memory, run for years on a battery and recover by itself when something goes wrong. We write bare-metal and RTOS firmware for ARM Cortex-M, ESP32 and RISC-V parts, bring up new boards, and add the bootloaders and update paths that let you fix devices already in customers’ hands.
What we build
- Board bring-up: clocks, pins, peripherals and a working debug console
- FreeRTOS and Zephyr applications with clear task and interrupt design
- Sensor, display, motor and radio drivers over I2C, SPI, UART and CAN
- Low-power modes that stretch battery life without missing events
- Secure bootloaders and signed over-the-air firmware updates with rollback
- Bluetooth LE, Wi-Fi, LoRaWAN and Modbus communication stacks
- Unit tests on the host and automated tests on real boards in CI
DemoInteractive · sample data
Try it live.
A working sample with made-up data. It runs in your browser; nothing is sent anywhere.
#include "FreeRTOS.h"
#include "task.h"
#include "bme280.h"
#define SAMPLE_MS 2000
void sensor_task(void *arg) {
bme280_init(I2C_BUS_1, 0x76);
for (;;) {What it does well
Watchdog recovery
Faults are logged and the device restarts into a known state instead of hanging.
Measured power
Sleep currents are measured on real hardware, not estimated from the datasheet.
Safe updates
A/B firmware slots mean a failed update falls back to the last working image.
Memory budgets
Flash and RAM use is tracked on every build so new features never overflow the chip.
Hardware abstraction
Board-specific code is kept separate, so moving to a new chip is a contained job.
Production tooling
Flashing, serial-number provisioning and self-test scripts for the factory line.
Questions
Which microcontrollers do you work with?
Mostly ARM Cortex-M parts such as STM32 and Nordic nRF52 or nRF53, Espressif ESP32 chips and RISC-V microcontrollers. If your product already uses another family, we work with its vendor SDK and toolchain rather than forcing a change of chip.
Can you take over firmware someone else wrote?
Yes. We start by getting it to build reproducibly, then read through it, add logging and tests around the risky parts, and list what needs fixing first. You get a clear written report before any large changes are made.
How do over-the-air updates stay safe?
Images are signed and checked by the bootloader before they run. The new image goes into a spare slot, boots once on trial, and only becomes permanent after it reports healthy; otherwise the device rolls back to the previous version.