B Duncan Ltd
Embedded Firmware Development
Developing and maintaining real-time embedded firmware since 2010.
What we do
Firmware development and maintenance
We develop real-time firmware for microcontrollers with tight memory and timing budgets.
Real-Time Operating Systems
RTOS-based and bare-metal designs for deterministic, low-latency systems.
System Architecture
Clean application and driver separation, so the code stays maintainable as it grows.
Communication Protocols
TCP/IP, Modbus, DNP3, CAN, and custom protocols, including PLC, DCS, and SCADA integration.
Hardware Bring-Up
Microcontroller, DSP, and FPGA bring-up and driver development from first silicon.
Low-Power & IoT
Battery and IoT designs with a tight power budget, from active modes down to sleep current.
Why us
Why choose us
Working since 2010
Real-time firmware across appliances, IoT, power controllers, motor control, and safety-critical systems.
Tested by default
Over 90% of our C code is developed test-first, so problems surface before code reaches hardware.
Published engineering practice
A written coding standard with hard limits, review gates, and release evidence. Not an aspiration.
We fit around your team
Alongside your engineers, or as the whole deliverable, for a few weeks or a few years.
Platforms
Silicon and stacks
Microcontrollers
STM32 across the F0, F1, G0, G4, L0, and L4 families. Nordic nRF52 for Bluetooth Low Energy. Espressif ESP32 for Wi-Fi and BLE. Renesas RX. Cypress PSoC 6. Silicon Labs EFM32.
Operating systems
FreeRTOS, Zephyr, and bare-metal cooperative schedulers where an RTOS costs more in overhead and analysis than it returns.
Connectivity
CAN, SPI, I2C, UART, RS485, Modbus, TCP/IP, DNP3, and IEC 60870 on the wired side. Bluetooth Low Energy, Wi-Fi, LoRa, and NFC on the wireless side, including over-the-air update with authentication.
How we work
Engineering practice
Our coding standard sets limits a reviewer checks against, and code that does not meet it is rejected.
Requirements that can be tested Requirements are written so a valid test case can be derived from them. Where a requirement specifies a solution rather than a need, engineers test the solution and miss the problem.
Over 90% of our C code is developed test-first Unit tests run on a PC in minutes, so a change is revalidated before it reaches hardware.
Bounded complexity We follow NASA JPL’s Power of 10 rules for safety-critical code as standard rather than only on regulated projects: cyclomatic complexity held below 7 wherever possible and never above 15 without approval, functions under a page, modules under 1000 lines, no heap allocation, and recursion bounded at compile time where it cannot be avoided.
Automated builds and changelogs Every release is built and tested in CI, compiler warnings are tracked, and changes are logged to a changelog against the tickets they came from, so what changed and why stays traceable.
How we engage
Three ways we work with you
Alongside your team
We work in your repository, your CI, and your review process, filling a capability or capacity gap.
The whole deliverable
Firmware owned end to end, from requirements through to release and ongoing maintenance.
A defined piece of work
A bring-up, a driver, a migration, or a specific defect, scoped and estimated before we start.
Our SDK
Built on a production-proven SDK
Our in-house Software Development Kit provides CLI diagnostics, event logging, parameter storage with redundancy, timers, and a unit-test structure, so your budget goes on your product rather than boilerplate. It is versioned and unit tested like any other deliverable, and the same modules run in anything from motor-control firmware to battery-powered BLE sensors.
FAQ
Common questions
What is the difference between firmware and embedded software?
In practice the terms overlap. Firmware usually means code running directly on a microcontroller with no operating system, or on a small RTOS, with tight memory and timing constraints. Embedded software is the broader term and includes application code running on embedded Linux. We work at the firmware end.
Do we need an RTOS?
Not always. An RTOS gives you task scheduling, priorities, and blocking calls, at the cost of memory, complexity, and harder timing analysis. For a device with a handful of periodic tasks, a bare-metal cooperative scheduler is often simpler to reason about and easier to certify.
Can you work in our repository and our process?
Yes, and it is the usual arrangement. We work in your version control, your CI, and your review process, against your coding standard where you have one.
Can you take over firmware someone else wrote?
Regularly. The first step is documenting the build, flash, and debug path, then measuring where the complexity actually sits, then improving incrementally. Starting again loses the accumulated fixes that are not written down anywhere.
How do you hand over?
Documentation of the build and debug path, the architecture, and the test suite, in your wiki or ours, so another engineer can pick the code up.
From the blog
How we work, in practice
How AI-Driven Feedback Transforms Embedded Development
Closing the loop between writing firmware and knowing it works.
Version-Control Your Workflow, Not Just Your Code
How we make project tooling executable and shared across the team.
Related services
Motor Control
Field-oriented control, VFDs, and sensorless drives, and our largest area of embedded control work. If your firmware drives a motor, this is where the depth is.
Code Review & Optimization
Already have firmware? We review it for correctness, reliability, performance, and maintainability, with written findings you can act on.
Safety-Critical Firmware
Firmware developed and audited to MISRA, JPL, DO-178C, and IEC Class B, with the evidence a certification body needs.
Discuss a firmware project
Tell us where the product is now and where it needs to get to.