What is embedded firmware development for wearables?
Embedded firmware development for wearables is the discipline of writing, validating, and deploying software that runs directly on the microcontrollers and processors inside wearable and IoT devices. Unlike application software, firmware operates under severe resource constraints — limited flash memory, limited RAM, and no operating system — while performing computationally intensive tasks like signal acquisition, preprocessing, and algorithm execution in real time. Clinical-grade wearable firmware adds a further layer of complexity: the code must be deterministic, thoroughly tested, and documented to support regulatory review. Porting an algorithm originally implemented in Python or MATLAB to embedded C requires careful attention to numerical precision, fixed-point arithmetic, memory layout, and execution timing. Devsort has performed 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.
This means numerical equivalence is a first-class requirement, not an afterthought. When a clinical algorithm is ported from Python to C, floating-point operations must be matched against the reference implementation with documented precision tolerance. Any deviation in output — even a rounding difference at the eighth decimal place — must be investigated and either accepted within tolerance or corrected before the firmware is considered validated.
Regulatory-tied firmware also requires change control: any modification to the embedded code after initial validation must go through a formal change assessment. Devsort's experience with the PKG Health algorithm stack — where every change was bounded by the FDA certification — gave us the discipline to work this way by default.
How do we approach wearable firmware projects?
- 1
Characterise the target hardware
We begin by understanding the processor architecture, memory constraints, available peripherals, and the sensor data path — how raw sensor output moves from the hardware to the algorithm. For clinical devices, we also review any existing regulatory documentation to understand what the change envelope is.
- 2
Port and optimise the algorithm
We reimplement the algorithm in C, matching the reference implementation's numerical behaviour within the documented tolerance. Where the resource constraints require approximations — fixed-point arithmetic, reduced-precision intermediates, loop unrolling — we document the approximation and validate that the output deviation is within 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.
Empatica device deployment: our embedded credential
As part of the PKG Health engagement, Devsort reimplemented validated clinical algorithms in embedded C for deployment on the Empatica wrist device. The algorithms — originally developed in Python as part of the cross-platform refactoring programme — had to run within the Empatica device's memory and compute constraints while producing 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 was conducted under the same regulatory constraints as the broader PKG engagement: FDA 510(k), CE, and TGA compliance, with full validation documentation produced for each implemented algorithm.
Frequently asked questions
What programming languages do you use for embedded wearable firmware?
We work primarily in C for embedded targets. For higher-level wearable platforms with OS support (watchOS, Wear OS, Embedded Linux), we also work in C++ and Swift or Kotlin as required by the platform SDK. The choice of language is driven by the target hardware and the performance requirements of the algorithm. For clinical-grade work, we default to C wherever possible 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 one of our core competencies. We have ported algorithms from Python, Julia, and MATLAB to embedded C, with full numerical validation at each step. The key challenge is ensuring that the floating-point behaviour of the high-level implementation is matched within tolerance in C, particularly where the original uses library functions with different precision characteristics. 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. For higher-level platforms, we have worked with Apple Watch (watchOS) and Samsung Galaxy Watch (Wear OS). For new platforms, we need access to the hardware specifications, SDK, and development hardware before we can scope the work accurately.
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.