What is embedded firmware development for wearables?
Embedded firmware development for wearables is writing, validating and deploying the software that runs directly on the microcontrollers and processors inside wearable and IoT devices. Firmware works under tight limits that application software does not have: little flash memory, little RAM and no operating system. It still has to acquire signals, preprocess them and run the algorithm, all in real time. Clinical-grade firmware is harder again, because the code has to be deterministic, thoroughly tested and documented well enough to support regulatory review. Porting an algorithm from Python or MATLAB to embedded C means paying close attention to numerical precision, fixed-point arithmetic, memory layout and execution timing. Devsort did this work for Empatica, reimplementing validated clinical movement disorder algorithms in embedded C for deployment on the Empatica wrist device under FDA, CE and TGA requirements.
Why is clinical wearable firmware different from standard embedded development?
Standard embedded development focuses on functionality and reliability: the device does what it is supposed to do and does not crash. Clinical wearable firmware has an additional requirement: the output must be clinically correct for every patient, on every device unit, across the full range of inputs the device will encounter in clinical use.
So numerical equivalence is a requirement from day one. When a clinical algorithm is ported from Python to C, floating-point operations are matched against the reference implementation to a documented precision tolerance. Any difference in output, even a rounding difference at the eighth decimal place, gets investigated. It is either accepted within tolerance or fixed before the firmware counts as validated.
Regulatory-tied firmware also needs change control: once the embedded code is validated, any modification goes through a formal change assessment. We learned to work this way on the PKG Health algorithm stack, where every change was bounded by the FDA certification, and it is now our default.
Firmware is one of four software layers in a wearable product. The companion app, the preprocessing pipeline that feeds the algorithm, and the algorithms themselves all have to agree with it. We build all four, and our wearable app development service covers how they fit together.
How do we approach wearable firmware projects?
- 1
Characterise the target hardware
We start with the processor architecture, memory limits, available peripherals and the sensor data path, meaning how raw sensor output gets from the hardware to the algorithm. For clinical devices we also read the existing regulatory documentation, so we know how much we are allowed to change.
- 2
Port and optimise the algorithm
We reimplement the algorithm in C and match the reference implementation's numerical behaviour within the documented tolerance. When the hardware forces approximations (fixed-point arithmetic, reduced-precision intermediates, loop unrolling), we document each one and show that the output deviation stays inside the clinical tolerance.
- 3
Validate on hardware
We run the embedded implementation on the actual hardware against the same clinical datasets used to validate the reference implementation. Every output is compared. Any deviation outside tolerance is investigated at the code level. The validation log records the inputs, outputs, comparison methodology, and disposition of every deviation.
- 4
Document and hand over
We produce the deliverables: validated firmware source, build configuration, validation report, and any regulatory artefacts required. We support integration into the client's build system and CI pipeline, and we remain available during the device integration period.
What did we run on the Empatica wrist device?
As part of the PKG Health engagement, Devsort reimplemented validated clinical algorithms in embedded C for deployment on the Empatica wrist device. The algorithms were originally developed in Python as part of the cross-platform refactoring programme. On the device they had to fit within Empatica's memory and compute limits and still produce outputs numerically equivalent to the validated Python reference.
The tremor algorithm, which had already been reduced from five minutes to thirty seconds in the Python refactoring, was further adapted for the real-time execution model of the Empatica processor. Embedded deployment required rethinking the memory layout of the preprocessing buffers and the execution scheduling of the algorithm's computational stages.
This work ran under the same regulatory constraints as the rest of the PKG engagement: FDA 510(k), CE and TGA requirements, with full validation documentation for each algorithm we implemented.
Frequently asked questions
What programming languages do you use for embedded wearable firmware?
We work mostly in C for embedded targets. On wearable platforms with an operating system (watchOS, Wear OS, Embedded Linux) we also use C++, and Swift or Kotlin where the platform SDK requires it. The target hardware and the algorithm's performance needs decide the language. For clinical-grade work we default to C wherever we can, because it gives the most direct control over numerical behaviour and memory layout.
Can you port existing Python or MATLAB algorithms to C?
Yes. This is a large part of what we do. We have ported algorithms from Python, Julia and MATLAB to embedded C, with full numerical validation at each step. The hard part is matching the floating-point behaviour of the high-level version in C within tolerance, especially where the original calls library functions with different precision. We document every approximation and validate every output.
How do you test embedded firmware for clinical applications?
We test at two levels: unit-level testing of individual algorithm components against the reference implementation on a development host, and integration-level testing of the full firmware on the actual target hardware against clinical datasets. Both levels produce comparison records. Hardware-in-the-loop testing confirms that timing and real-time execution constraints are met. The complete test record forms the validation evidence for regulatory purposes.
What wearable processors and platforms do you have experience with?
We have worked with Empatica's wrist device platform and have experience with ARM Cortex-M-based architectures more broadly. On higher-level platforms we have done algorithm and data work for Apple Watch (watchOS) and Samsung Galaxy Watch (Wear OS). For a new platform we need the hardware specifications, the SDK and development hardware before we can scope the work properly.
How does regulatory compliance affect firmware development?
For firmware that is part of a cleared or certified medical device, every change must be assessed against the device's regulatory documentation. A change that affects algorithm outputs must go through the validation process before it can be deployed. A change that affects only non-clinical functions (UI, connectivity, logging) may have a lighter change process. We work within whatever change control process the client has in place and produce the technical documentation that the regulatory affairs team needs to complete the submission.