Amotus writes embedded firmware for connected products — bare-metal, RTOS (FreeRTOS, Zephyr), and Linux user-space — with the coding discipline, traceability, and functional-safety rigour your application demands. We work to MISRA C:2012, IEC 61508 (SIL), and IEC 62304 (medical) where required, on STM32, NXP, Nordic, ESP32, and Renesas targets. Bilingual engineering team headquartered in Quebec City.
- 13+ years of embedded firmware engineering
- MISRA C:2012 · IEC 61508 · IEC 62304 when required
- C · C++ · Rust on STM32, NXP, Nordic, ESP32, Renesas
- EN / FR Quebec-based team
Book a FREE 30-min qualification call — response within 48 h →
When you need a firmware partner
You’re building new connected-product firmware
From bring-up to a shippable, maintainable firmware base: drivers, connectivity, power management, secure boot, and OTA — written to standards, not hacked together.
You have a safety- or reliability-critical function
A function where failure matters — medical (IEC 62304), industrial/functional safety (IEC 61508), automotive (ISO 26262). We bring MISRA discipline, traceability, and the verification coverage your class requires.
You need to rescue or modernize existing firmware
An undocumented, fragile, or unmaintainable codebase. We audit it, stabilize it, add tests and traceability, and give you a base you can build on — or a clean rewrite where that’s the better investment.
Standards & practices we work to
| Standard / practice | Scope |
|---|---|
| MISRA C:2012 | Safe-subset C coding guidelines for embedded |
| IEC 61508 | Functional safety (SIL) of E/E/PE systems |
| IEC 62304 | Medical device software life cycle (classes A, B, C) |
| ISO 26262 | Automotive functional safety (ASIL) |
| AUTOSAR | Automotive software architecture (Classic/Adaptive) |
| Requirements traceability | Bidirectional requirements ↔ code ↔ tests |
| Secure boot / signed OTA | Chain-of-trust & safe field updates |
| HIL / SIL testing | Hardware- and software-in-the-loop verification |
Transparency note: Amotus applies these standards’ engineering practices and produces auditable work products; we do not hold corporate certificates to them, and we integrate into our clients’ certified quality and safety systems for formal compliance.
Our firmware services
Bare-metal & RTOS firmware
Drivers, scheduling, and application firmware on FreeRTOS, Zephyr, or bare-metal, tuned for real-time behaviour and power.
Deliverables: firmware source, driver layer, build system, documentation, test suite.
Functional-safety firmware (IEC 62304 / 61508 / ISO 26262)
Safety-classified firmware with MISRA compliance, safety mechanisms, and the verification coverage and traceability your class/ASIL/SIL requires.
Deliverables: software requirements, architecture, documented code, V&V plan, coverage report, traceability matrix.
Connectivity & protocol stacks
BLE, Wi-Fi, Thread/Matter, LoRaWAN, Cellular (LTE-M), plus application protocols (MQTT, CoAP) and device-to-cloud integration.
Deliverables: connectivity firmware, protocol integration, cloud connection, interoperability tests.
Secure boot & OTA
Chain-of-trust from bootloader to application, signed images, and robust OTA (A/B or delta) with automatic rollback.
Deliverables: secure-boot design, signing infrastructure, OTA mechanism, rollback strategy.
Power optimization
Low-power MCU modes, duty-cycling, and a measured power budget for battery- and energy-harvesting-powered devices.
Deliverables: power-optimized firmware, measured power budget, battery-life validation.
Firmware audit, test & modernization
Codebase audit, static analysis, test-harness creation (unit + HIL), and refactoring or rewrite to make legacy firmware maintainable.
Deliverables: audit report, static-analysis results, test suite, refactoring/rewrite plan.
Our firmware methodology
- Requirements & classification — functionality, real-time/power constraints, safety class if any
- Architecture — RTOS vs. bare-metal, driver and connectivity strategy, safety mechanisms
- Implementation with traceability — MISRA where relevant, requirements ↔ code ↔ tests
- Verification — unit, integration, HIL/SIL, documented coverage
- Security & updatability — secure boot, signed OTA, rollback
- Release & maintenance — documented build, CI, long-term support
Project example — connected-product firmware
Project: robust firmware for a connected device — drivers, BLE/cellular connectivity, secure OTA, and power optimization — the firmware layer behind Amotus’s hardware-to-cloud projects.
What we engineered:
- RTOS-based firmware with a clean driver and HAL layer
- BLE and cellular connectivity with cloud integration
- Secure boot and signed OTA with rollback
- Measured power budget for multi-year battery life
Tech stack: STM32H7 · Nordic nRF52 · ESP32-S3 · FreeRTOS / Zephyr · C / C++ / Rust · MISRA C:2012 · GitLab CI
Most of our clients operate under confidentiality agreements, so project details on this site are kept at the technical level. We can discuss relevant, reference-checkable experience under NDA during a qualification call.
Typical firmware tech stack at Amotus
| Area | Technologies commonly deployed |
|---|---|
| MCUs | STM32 (incl. STM32H7) · NXP i.MX RT · Nordic nRF52/nRF53 · ESP32-S3 · Renesas |
| RTOS / runtime | FreeRTOS · Zephyr · bare-metal · embedded Linux user-space |
| Languages | C (MISRA C:2012) · C++ · Rust (greenfield) |
| Connectivity | BLE 5.3 · Wi-Fi · Thread/Matter · LoRaWAN · Cellular (LTE-M) · MQTT/CoAP |
| Security | Secure boot · MCUboot · signed OTA · TLS 1.3 · key management |
| QA tooling | Polyspace · Coverity · Cppcheck · Unity/Ceedling · HIL benches · GitLab CI/CD |
Frequently asked questions — firmware development
How do you handle data security?
Security is a first-class design requirement, not an afterthought. We work to SOC 2 Type II–audited practices (Groupe Vectanor), with zero-trust architecture, mTLS between devices and cloud, encryption in transit and at rest, and data residency in the region you require on our multi-region Fundamentum platform (Canada, US, Europe, and more). Your data stays yours, with clear ownership and open export.
What is MISRA C and when do I need it?
MISRA C:2012 is a set of coding guidelines that restrict C to a safer subset, avoiding constructs that cause undefined or risky behaviour. It’s expected for safety-relevant firmware (medical, automotive, industrial) and is good practice elsewhere. We apply it where it adds value and don’t impose its full overhead on a non-critical hobby-grade feature.
FreeRTOS, Zephyr, or bare-metal?
Bare-metal suits the simplest, lowest-power, most deterministic jobs. FreeRTOS is a lightweight, widely-used RTOS for general embedded work. Zephyr is a richer, connectivity-and-driver-heavy RTOS with strong long-term momentum, good when you need its ecosystem (BLE, networking, device model). We choose based on complexity, power, and the driver/connectivity ecosystem you need.
Can you develop to IEC 62304 or IEC 61508?
Yes. We develop safety-classified firmware with the requirements, architecture, traceability, and verification coverage those standards demand, producing auditable work products. We integrate into your certified quality/safety system; we’re not a certification body.
Do you do Rust for embedded?
Yes, for greenfield projects where its memory-safety guarantees reduce whole classes of bugs. Rust is increasingly viable on Cortex-M and Linux targets; we’ll recommend it where the toolchain and ecosystem support your needs, and stick with C/C++ where that’s the pragmatic choice.
How do you keep firmware updatable and secure in the field?
Secure boot establishes a chain-of-trust so only signed firmware runs; signed A/B OTA with automatic rollback means an update can’t brick the device. Together they keep a fielded product both secure and serviceable for its full life.
How much does firmware development cost?
A connected-product firmware base (drivers, one connectivity path, OTA) commonly represents 400 to 1,000 engineer-hours, roughly CAD $60,000 to $170,000. Safety-classified firmware adds substantial V&V effort on top. These are industry-typical ranges; your quote depends on scope and safety level.
Why Amotus for your firmware
- Full-stack hardware-to-cloud — firmware written with the board and the cloud in mind
- Safety-capable — MISRA, IEC 62304/61508, ISO 26262 work products when you need them
- Secure & updatable — secure boot and signed OTA as standard practice
- Right-sized rigour — discipline scaled to your application, not imposed
- Bilingual EN / FR — Quebec-based team
Book a FREE 30-min qualification call — response within 48 h →
