Embedded Firmware
C++ firmware for machines where a defect is not a hotfix but a stopped production line — or worse. The record runs from heavy industry to consumer energy: control software for tunnel-boring machinery, a multi-year embedded R&D programme for a novel power station for PV systems, and a smart-workspace sensor platform.
The free 30-minute session reviews your device concept or existing firmware and gives an honest read on architecture, risks and certification path. You keep the notes either way.
Firmware situations we are called into
The machine cannot be allowed to misbehave
On a tunnel-boring machine, a control fault is measured in stopped crews and geology. Firmware at this level is written defensively: watchdogs, safe states, deterministic timing, and reviews that assume Murphy is on the team.
The prototype firmware became the product firmware
The demo code from the funding round is now shipping in devices — with blocking calls in interrupt handlers and no update path. Field devices running prototype firmware are recalls waiting for a date.
The hardware team and software team meet at a connector
Electronics blames firmware, firmware blames the board, and the schedule absorbs the argument. Our firmware work sits beside our own hardware lab in Chisinau, Moldova — the argument happens at one bench, briefly.
Updates in the field are an unsolved question
Devices ship, bugs are found, and there is no safe OTA path — every fix is a truck roll. Update architecture — signed images, A/B partitions, rollback — has to be designed in, and retrofitting it is exactly the kind of work we take.
Firmware is only ever as good as its relationship with the board. Ours grow up together, at one bench, in our hardware lab in Chisinau, Moldova.
What we write
Control firmware for real machines
Deterministic C++ on RTOS or bare metal — motor control, sensor fusion, safety interlocks, HMI — engineered for the failure modes the datasheet does not mention.
You get: firmware with defined safe states and a test rig to prove them.
Device operating software
The full software stack of a power-station product: power management, connectivity, update system, user interface — firmware as a product, maintained across years and hardware revisions.
You get: a device OS with a roadmap, not a one-off image.
Connectivity and the cloud side
BLE, Wi-Fi, LTE and the protocols above them, plus the backend the fleet talks to — one team owns both ends of the connection.
You get: devices online with telemetry, OTA and a fleet view.
Rescue of existing firmware
Prototype-grade or inherited firmware stabilised: static analysis, watchdogs, update paths, tests on hardware-in-the-loop rigs.
You get: field devices you can update without holding your breath.
How it works
Architecture and risk review
The device, its duty cycle, its failure costs — and the firmware architecture that fits, in writing.
Board bring-up and skeleton
The firmware skeleton on real hardware: drivers, safe states, watchdogs, logging — the foundation everything rides on.
Features against the rig
Functionality lands against a hardware-in-the-loop test rig, so regressions surface at the bench instead of the field.
Field, fleet and iterate
OTA infrastructure, telemetry and the maintenance rhythm of a shipped device — for years, as on the Sonnenrepublik programme.
Dangerous states are exercised at the bench, on purpose.
Proof, not claims
Firmware proof is machines running — from tunnel works to rooftops to office ceilings.
Embedded R&D for a PV power station
A multi-year firmware and hardware R&D programme for a novel power station for PV systems (sonnenrepublik.de).
A sensor platform for smart workspaces
Firmware, connectivity and app for a workspace sensor product — the full small-device stack, shipped.
Years of continuous firmware development stand behind one product line — the embedded R&D programme for a novel power station for PV systems.
The habits this work demands — deterministic timing, safe states, reviews that assume failure — come from industries where firmware simply may not fail.
Start with the architecture review
One 30-minute session with an embedded engineer on your device concept or existing firmware — architecture, risks, certification path. A fixed-scope review or first milestone is then priced in writing before anything starts.
Bringing inherited firmware? Send nothing in advance — the call establishes what a safe review needs, under NDA where required.
Clients also buy
IoT & Edge AI
Connected devices with on-device intelligence — from sensors to smart power stations, hardware and cloud in one team.
Hardware & PCB Design
Schematics, PCB layout and enclosure design from our hardware lab in Chisinau, Moldova.
Prototyping, Assembly & Testing
Prototype to small batch to FCC/CE/UL/RoHS testing — one lab, one accountable team.
We build software for machines that exist — motors, batteries, sensors, geology. The physics is the spec.
The questions buyers actually ask
Which platforms and toolchains do you work with?
C++ on RTOS and bare metal across the mainstream MCU families, plus embedded Linux where the product calls for it. The discipline — deterministic timing, safe states, watchdogs, hardware-in-the-loop testing — travels across silicon; the toolchain choice is justified in the architecture review.
Can you take over firmware another team wrote?
Yes — it is a standing part of the practice: static analysis and a behaviour review first, findings in writing, then stabilisation in order of field risk: watchdogs, safe states, update path, tests. The rescue discipline from our software side applies at the device level too.
Do you handle the electronics as well?
Yes — through our hardware lab in Chisinau, Moldova, which does schematics, PCB design, prototyping and assembly. Firmware and board designed under one roof means the integration argument happens at a bench, not between vendors.
How do you test firmware safely?
Against hardware-in-the-loop rigs that simulate the machine — sensors, loads, fault injection — so dangerous states are exercised at the bench. Field devices then add telemetry, so the fleet itself reports early.
What about certification — FCC, CE, RoHS?
Designed for from the start: EMC-aware firmware behaviours, test modes for the lab, documentation as a deliverable. Our Prototyping, Assembly & Testing service covers the certification-testing path itself.
Can devices be updated after shipping?
They must be — a fleet without a safe OTA path turns every bug into a truck roll. We build signed, A/B-partitioned update systems with rollback, and retrofit them onto existing products where possible.
From schematic to certified device — the one-page version
The Hardware & IoT Lab on one printable page: firmware, electronics, prototyping and certification testing, and how a device project moves through them. Built to be forwarded to whoever holds the budget.
Firmware your machine can stake its duty cycle on
Book the free 30-minute review of your device or firmware — or describe the machine in two sentences and an embedded engineer replies in one business day.
- 30 minutes, an engineer on the call
- You keep the written notes either way
- Nobody follows up more than once
