Electronics & embedded systems · Embedded firmware
Firmware from bare-metal to RTOS.
New boards back from fabrication and the firmware will not bring the board up cleanly, or a product needs drivers, a bootloader and an OTA path built properly the first time. 1722 delivers embedded firmware engineering scoped to a statement of work — bare-metal or RTOS, drivers, bootloaders, OTA, and the board bring-up and debugging that turns a populated PCB into a working system.
You commission the work, we deliver the output, you own it — the firmware source and your design IP are yours. A mutual NDA is offered as standard.
What is engineered
The firmware layer, done properly.
Firmware work across the stack a product actually needs, from first power-on to a maintainable OTA update path.
- 01
Bare-metal & RTOS firmware
Firmware architecture and implementation across bare-metal loops and RTOS tasks — scheduling, interrupt handling, power management and peripheral drivers for MCU families such as STM32, ESP32, NXP and Nordic parts, as representative examples of the class of hardware.
- 02
Drivers & bootloaders
Peripheral drivers written to the datasheet, and bootloaders built for reliable field updates — including fail-safe recovery paths so a bad update cannot brick the unit.
- 03
OTA update paths
Over-the-air update design and implementation: image signing and verification, staged rollout logic, and rollback, engineered for the constraints of the target MCU and radio.
- 04
Board bring-up & debugging
First-power bring-up on new PCBs, JTAG/SWD debugging, and root-cause diagnosis of faults that separates a firmware bug from a schematic or layout defect — the work that reduces respins instead of guessing at another board revision.
When this is engaged
When do you need embedded firmware engineering?
Three situations bring this engagement in, each with a different starting point but the same disciplined bring-up and debugging method.
- A project is stuck — firmware will not stabilise, an intermittent fault resists diagnosis, or a deadline has slipped past the point internal capacity can absorb
- First boards are in — new hardware needs bring-up from first power-on: verifying rails, clocks and peripherals, and getting a debug build running before feature firmware starts
- A design needs de-risking — firmware architecture review before a production commitment, so drivers, bootloader and OTA path are sound before volume build
What you get
Deliverables you own.
Every engagement ships concrete artefacts your team keeps and can act on — never advice alone.
- Firmware source and build configuration, handed over in full
- Driver code for the peripherals and interfaces in scope
- Bootloader & OTA implementation where in scope, with fail-safe recovery documented
- Bring-up & test notes recording what was verified, how, and against what reference
- Root-cause diagnosis for any defect investigated, distinguishing firmware, schematic and layout causes
- Handover pack so your team can maintain and extend the firmware without us
Out of scope — this is embedded firmware for microcontrollers, not application, web or mobile software — a different discipline handled elsewhere. We do not sell development boards, toolchains, firmware licences or a subscription, and we take no vendor commissions.
Point us at the board.
Describe the bring-up, the bug, or the feature set. A short discovery call, then a scoped plan.
FAQ
Embedded firmware, answered.
What does embedded firmware engineering cover?
Firmware from bare-metal up through an RTOS: peripheral drivers, bootloaders, over-the-air (OTA) update paths, power and interrupt handling, and the board bring-up and debugging that gets new hardware from a populated PCB to a running system. Scoped to a written statement of work with named deliverables.
Which microcontrollers do you work with?
The method is MCU-family independent — common families such as STM32, ESP32, NXP and Nordic parts are typical examples of the class of hardware, not a claim of specific past products. Tell us the part and toolchain on the discovery call and we will be specific about fit.
Our first boards are back and firmware is stuck — can you help?
Yes. Board bring-up and debugging is one of the most common reasons a firmware engagement starts: first silicon on a new PCB, a stalled bring-up, or a defect that needs root-cause diagnosis rather than another respin. The aim is to reduce respins by isolating whether a fault is firmware, schematic or layout before new boards are ordered.
Do you write application software or web/mobile builds?
No. Embedded firmware is a different discipline to application or web software — it runs on the microcontroller itself, close to the silicon, not in a browser or on a server. If your project needs an application, web or mobile build alongside the firmware, that is a separate scope handled by a software house, not by this engagement.
Who owns the firmware source?
You commission the work, we deliver the output, you own it — your design IP is yours, including the firmware source, drivers and bring-up notes. A mutual NDA is offered as standard before any design detail is shared.
Do you sell development boards, toolchains or firmware licences?
No. We sell engineering expertise and time, not hardware, toolchains or licences, and we take no vendor commissions. Any parts or tools used are selected on engineering merit for your project, not for revenue.
How is this priced?
Day-rate, time-and-materials or a fixed-scope statement of work, depending on how well-defined the bring-up or feature set is at the start. A short discovery call establishes scope before any commercial terms are set.
What do we receive at the end of the engagement?
The firmware source and build configuration, driver code, bootloader and OTA implementation where in scope, and bring-up and test notes documenting what was verified and how. Deliverables are handed over so your team can maintain and extend the firmware without us.