Embedded Firmware Development Services
Embedded firmware development for microcontrollers and embedded Linux: bare-metal, FreeRTOS and Linux firmware, low-power design, BLE, Wi-Fi and cellular stacks, secure OTA updates and rescue of inherited code, for product teams in North America, the UK, Europe, Australia and the Middle East.
Firmware Decides How a Device Behaves After It Ships
Hardware sets the limits of a product. Firmware decides how close it comes to them. It decides whether a battery lasts months or weeks, whether a device recovers from a brown-out or locks up, whether an update can be rolled back, and whether a security flaw can be fixed in the field at all. Most firmware problems stay hidden on the bench and show up only when thousands of units are running in conditions nobody tested.
MetaDesk Global writes embedded firmware for microcontrollers and embedded Linux systems, from first board bring-up to production updates. Our firmware engineers sit on the same team as our IoT hardware and cloud engineers, so the code is written knowing the schematic, the power budget and the server it talks to.
Embedded Firmware Development Services
New firmware, a single hard problem in existing firmware, or long-term ownership of your device code. Each service below can be bought on its own.
Custom firmware from scratch
Bare-metal, FreeRTOS or embedded Linux firmware designed around your hardware and use case, with a clear architecture, defined task priorities and memory budgets, and code your own team can maintain.
Board bring-up and drivers
First firmware on new boards and drivers for the peripherals that matter: I2S microphones and codecs, SPI and I2C sensors, external flash, displays, USB, camera interfaces and cellular modems.
RTOS firmware
FreeRTOS applications on ESP-IDF, STM32 and other platforms, with real-time paths that hold their timing under load: DMA transfers, interrupt design, priority inversion avoided and stacks sized from measurement.
Embedded Linux
Firmware and services on STM32MP, Rockchip RK3588 and Raspberry Pi: kernel-level ALSA audio routing, multi-camera capture, hardware video encoding and boot-to-application systems that need no keyboard. Read why Linux is used in embedded systems, and when it is wrong.
Low-power firmware
Event-driven designs, clock gating, peripheral shutdown, tuned radio intervals and controlled wake sources, validated with a power profiler. Battery life is measured, not estimated from a datasheet.
Connectivity stacks
Bluetooth Low Energy, Wi-Fi, ESP-NOW, LTE cellular modems, USB HID and USB audio, with encrypted links and reconnection logic that survives real radio conditions.
OTA updates and bootloaders
Over-the-air update paths with signed images, dual-bank or A/B layouts and rollback, so a failed update never bricks a device in the field. Our guide to OTA updates in IoT devices explains the trade-offs.
Firmware audits and rescue
A review of inherited firmware after a contractor leaves or field failures start: crash and reset analysis, memory and timing problems, security gaps, and a written plan to fix, refactor or rewrite.
Firmware Problems We Have Solved
Each row links to a published case study with the full engineering detail.
| Project | Platform | The hard part | Result |
|---|---|---|---|
| BLE IoT tag | Nordic nRF52840 | Hidden leakage current and the trade-off between fast discovery and battery life | About 11 µA idle current, measured with a Nordic PPK2, with reliable wake-up from BLE, RTC and GPIO |
| Four-headset intercom | STM32MP, embedded Linux | User-space audio buffers that built up latency and dropped audio under load | Kernel-managed ALSA PCM routing under 20 ms, zero XRUNs across 6+ hour stress tests and USB hot-plug cycles |
| Sound frequency analyzer | ESP32, INMP441 I2S | Audio capture, SD card logging, FFT and Wi-Fi posting all running at once on one chip | A staged pipeline with no dropped audio or corrupted files, posting frequency bands every five seconds |
| Offline classroom device | ESP32-S3, 64 MB SPI flash | A rich multi-screen UI that did not fit in internal flash or RAM | UI pages loaded on demand from external flash, teacher and student devices linked over ESP-NOW without internet |
| 12-axis industrial robot | STM32H7, FreeRTOS | Tightly synchronized data exchange between motor drivers, sensors and the controller | A DMA-driven SPI framework with CRC checking under FreeRTOS |
| Clinical session recorder | RK3588, embedded Linux | Two CSI cameras and a USB thermal camera recorded together without dropped frames | Hardware-accelerated H.264 encoding, button-driven sessions and automatic cloud upload |
| Farm vehicle monitor | Nordic nRF52 | Dust, vibration and unstable GPS in open fields | Sensor-fused GPS and motion data with BLE firmware updates in the field |
Firmware That Meets the New Device Security Rules
Security used to be optional for most connected products. In several of the markets our clients sell into, it is now law, and most of the requirements land on the firmware.
| Rule | Market | What it means for firmware | Applies from |
|---|---|---|---|
| PSTI Act | United Kingdom | No universal default passwords, a way to report vulnerabilities and a stated period of security updates | 29 April 2024 |
| Radio Equipment Directive, cybersecurity requirements | European Union | Network protection, safeguards for personal data and protection against fraud for internet-connected radio equipment | 1 August 2025 |
| Smart device security standard | Australia | No universal default passwords, a vulnerability disclosure policy and a published support period for consumer smart devices | 4 March 2026 |
| Cyber Resilience Act | European Union | Reporting of actively exploited vulnerabilities, then secure-by-design requirements and security updates across the support period | Reporting from 11 September 2026; full obligations from 11 December 2027 |
In practice that means unique credentials per device, secure boot and signed updates where the hardware supports them, encrypted links, a working OTA path for the whole support period and a record of the software components inside the firmware. We build these in from the start and confirm the rules that apply to your product during scoping. For the organizational side, see IoT security for connected products.
A Firmware Process Built on Real Hardware
Firmware is only as good as the hardware it was tested on, so our process keeps real boards at the center of every stage.
Review hardware and requirements
Schematics, datasheets, existing code and the product requirements. We flag hardware issues that firmware cannot fix while they are still cheap to change.
Architecture and budgets
Choice of bare metal, RTOS or Linux, task and interrupt design, memory map, flash layout for updates, and a power budget for every operating mode.
Build on target hardware
Incremental builds on your boards, with source control, code review and short demos so you see progress on the device, not on slides.
Test like the field
Stress and soak tests, power profiling, radio range tests, brown-out and hot-plug cycles, and update and rollback tests before any release.
Release and hand over
Versioned releases, build instructions, a reproducible toolchain and documentation, delivered to your repository. Ongoing maintenance is available, never required.
What Drives the Cost of Firmware Development
We quote after reviewing your hardware and requirements, because a few factors decide most of the effort.
| Cost driver | Lower effort | Higher effort |
|---|---|---|
| Hardware maturity | Proven development kit or reference design | New custom board still being debugged |
| Operating system | Single-purpose bare-metal or RTOS firmware | Embedded Linux with custom drivers and media pipelines |
| Power target | Mains powered | Multi-year battery life on a coin cell |
| Connectivity and updates | One radio, wired updates | Several radios, cellular, signed OTA with rollback |
| Real-time and safety needs | Soft timing | Hard real-time control, functional safety or medical rules |
| Starting point | Clean slate with clear requirements | Inherited code without documentation |
Firmware Engineers Who Think in Systems
A firmware bug is often a hardware, radio or server problem in disguise. Finding it takes engineers who can follow it across all of them.
- Hardware and firmware on one teamWe read schematics, probe boards and fix the interface between hardware and code ourselves. See hardware vs firmware engineers for why that split causes so many delays.
- Measured resultsCurrent draw from a power profiler, latency from timestamps, stability from hours of stress tests. The results on this page come from projects published in our portfolio.
- Code your team can ownReadable code, documented architecture and reproducible builds in your repository, so you can maintain the firmware without us.
- Beyond the deviceWhen the firmware needs a cloud backend, an app or a model on the chip, our edge AI and app development teams build it on the same protocol.