Industrial embedded software: RTOS, Linux, firmware certification

What is industrial embedded software?

Industrial embedded software covers all programs that run directly on a microcontroller or processor integrated into a product, interacting in real time with sensors, actuators and communication buses. Three architectures dominate: bare-metal, RTOS (typically FreeRTOS or Zephyr) and embedded Linux (most often built with the Yocto Project). The choice drives reliability, security and the 10-year-plus industrial lifetime of the product.

At AESTECHNO, we have been developing embedded software for more than 10 years on production products running Zephyr, FreeRTOS, Yocto, embedded Linux and Windows. This guide lays out the decision methodology we use to avoid the recurring pitfalls (critical bugs, excessive power draw, certification failure) and to align the firmware architecture with regulatory constraints (IEC 62304 medical, IEC 61508 SIL, ISO 26262 automotive).

RTOS vs embedded Linux vs bare-metal: which choice for your product?

The choice between bare-metal, RTOS and embedded Linux is the first architectural decision of any firmware project. Each approach forces different trade-offs in power consumption, determinism, complexity and networking capability, and that single choice shapes the entire development cycle of the product.

Bare-metal (no OS)

Principle: your code runs directly on the microcontroller, with no abstraction layer.

Pros:

• Minimal power draw: no scheduler, no idle tasks.
• Ultra-low latency: deterministic response in microseconds.
• Tiny memory footprint: 8-32 KB of Flash is enough.
• Simplicity: no complex task management.

Cons:

• Hard to maintain past 5,000 lines of code.
• No native multitasking (manual state-machine handling).
• Reinventing the wheel (timers, drivers, network stacks).

Use cases: ultra low-power sensors (1-2 measurements per hour), simple actuators, coin-cell wearables.

RTOS (Real-Time Operating System)

Principle: a minimalist operating system with a real-time scheduler, task management, and synchronisation primitives.

Pros:

• Preemptive multitasking: clean handling of concurrent tasks.
• Determinism: bounded latency (certified RTOS variants).
• Mature ecosystem: drivers, middleware, networking stacks ready to use.
• Scalability: from 16 KB to several MB of code.

Cons:

• Memory footprint: +20-50 KB Flash minimum.
• Power draw: +10-30% vs bare-metal (active scheduler).
• Learning curve (RTOS concepts: semaphores, queues, mutexes).

Use cases: multi-sensor systems, complex protocols (Modbus, BACnet), medical devices, motor control. Stepper motors and similar actuators are typical RTOS use cases where temporal determinism is critical for positioning accuracy - see our firmware engineering expertise for the methodology we apply.

Embedded Linux

Principle: a full Linux on an ARM/x86 application processor with an MMU (Memory Management Unit).

Pros:

• Massive software ecosystem: 10,000+ open-source packages.
• Advanced connectivity: WiFi, LTE, Ethernet, Bluetooth out of the box.
• High-level languages: Python, Node.js, Java on top of C/C++.
• Powerful debugging: GDB, Valgrind, strace, perf.

Cons:

• High power draw: 100-500 mA running (vs 1-10 mA on RTOS).
• Slow boot: 5-30 seconds (vs <1s RTOS).
• Limited real-time: variable latency (except PREEMPT_RT kernel, mainline since 6.12).
• Footprint: >64 MB Flash, >128 MB RAM minimum.

Use cases: IoT gateways, touch HMIs, edge computing, computer vision, complex acquisition systems.

Approach	Complexity	Real time	Use cases
Bare-metal (super-loop)	Low	Deterministic	Simple sensors, motor control
FreeRTOS	Medium	Preemptive, configurable	IoT, multi-task, AWS IoT
Zephyr RTOS	High	Preemptive, certifiable	BLE, Thread, Matter, security
Embedded Linux	Very high	Not real-time (except PREEMPT_RT)	HMIs, gateways, embedded AI

For a deeper benchmark of the three families - latency, certification readiness, footprint - see our companion piece on Zephyr, FreeRTOS and Linux PREEMPT_RT compared.

RTOS 2025: FreeRTOS vs Zephyr vs ThreadX selection guide

The RTOS choice fixes the development ecosystem, the certification path and the long-term sustainability of the product. Each RTOS targets different segments with distinct trade-offs in memory footprint, ecosystem maturity and availability of industrial certifications.

FreeRTOS, the industry standard

According to the FreeRTOS documentation maintained by Amazon Web Services, FreeRTOS is the most widely deployed RTOS in the world.

Strengths:

• Massive adoption: 40+ billion devices deployed.
• Universal MCU support: ARM Cortex-M0 to M7, RISC-V, ESP32, STM32.
• AWS IoT integration: OTA updates, device shadow, jobs.
• Certifications available: SafeRTOS (IEC 62304, DO-178B/C).
• Tiny footprint: 4-9 KB code + 200 bytes/task RAM.

Limits:

• No MPU (Memory Protection Unit) by default.
• Manual configuration is fiddly (FreeRTOSConfig.h).
• Drivers must be implemented by hand.

Verdict: pick FreeRTOS for commercial IoT products with tight memory budgets (<128 KB Flash) on the AWS ecosystem.

Zephyr RTOS, the open-source future

According to the Linux Foundation, host of the Zephyr Project, and per Nordic Semiconductor (one of the major contributors), Zephyr explicitly targets certifiable IoT products (security, medical, industrial).

Strengths:

• Modern architecture: Device Tree, Kconfig, West build system.
• Built-in drivers: 300+ MCUs, sensors and displays out-of-the-box.
• Native security: TLS 1.3, secure boot, Trusted Firmware-M.
• Mature Bluetooth: certified BLE 5.4 stack, Mesh, Direction Finding.
• Safety roadmap: Zephyr Safety Certification Project (IEC 61508 in progress).

Limits:

• Larger footprint: 30-100 KB minimum (vs 4 KB for FreeRTOS).
• Steep learning curve (Devicetree, Kconfig).
• Not yet certified medical/aero (ongoing).

Verdict: pick Zephyr for any new project starting in 2025+ with advanced Bluetooth needs, critical security or long-term scalability.

Azure RTOS (ThreadX), certification ready

Strengths:

• Multiple certifications: IEC 62304, DO-178B, IEC 61508, ISO 26262.
• Advanced network stack: NetX Duo (IPv4/IPv6), MQTT, CoAP native.
• FileX: fault-tolerant file system.
• GUIX: graphical UI framework for touch displays.

Limits:

• Less momentum (acquired by Microsoft, transferred to the Eclipse Foundation).
• Smaller community than FreeRTOS or Zephyr.

Verdict: pick ThreadX when immediate certification is mandatory (medical, aero) and a complete networking stack is needed.

Embedded Linux with Yocto Project: when and how

The Yocto Project is the reference build system for crafting custom embedded Linux distributions. It produces a complete Linux image - kernel, rootfs, drivers, applications - tuned for the target hardware, with full reproducibility and tight control over every component included in the distribution.

The Yocto Project is the reference tool for building bespoke embedded Linux distributions.

When to use Yocto Linux?

• Processor >400 MHz: ARM Cortex-A, Intel Atom, AMD, RISC-V application class.
• RAM >128 MB: ideally 512 MB to 2 GB.
• Complex connectivity: WiFi/LTE/Ethernet + web server + local database.
• Graphical interface: Qt, GTK, Wayland, X11.
• Edge computing: local data processing (ML, vision).

Yocto alternatives

Tool	Complexity	Use case
Buildroot	Low	Simple systems, learning, fast PoCs
Yocto Project	High	Commercial products, scalability, custom BSPs
Debian/Ubuntu	Medium	Raspberry Pi, prototypes, IoT gateways
OpenWrt	Medium	Routers, network gateways, WiFi mesh

Yocto development: 20-60 engineer-days for a first version (BSP + custom image + drivers). Maintenance: 5-10 days per year (security updates, kernel patches).

NVIDIA JetPack: high-performance edge AI

The NVIDIA Jetson platform with the JetPack SDK has become the reference for high-performance embedded AI. It provides a complete environment - CUDA, TensorRT, DeepStream - to deploy inference models in the field, delivering 40 to 275 TOPS depending on the chosen module.

For embedded AI workloads (computer vision, video analytics, ML inference), the NVIDIA Jetson platform with the JetPack SDK has become the standard. We cover the silicon side in our Jetson Orin embedded AI piece.

Jetson modules 2025

• Jetson Orin Nano: 40 TOPS AI, 8 GB RAM, 10-25 W, industrial edge AI.
• Jetson Orin NX: 100 TOPS AI, 16 GB RAM, 25-40 W, robotics, autonomous vehicles.
• Jetson AGX Orin: 275 TOPS AI, 64 GB RAM, 60-120 W, edge servers, multi-camera setups.

JetPack SDK, batteries included

Pre-integrated components:

• CUDA, cuDNN, TensorRT: GPU acceleration for ML inference.
• DeepStream: multi-camera video analytics pipeline.
• VPI: Vision Processing Interface (filtering, edge detection).
• Ubuntu 20.04/22.04: full Linux base.
• Docker, Kubernetes: containerised deployment.

Development: simpler than RTOS work (Python + PyTorch/TensorFlow), but power draw lands in the 10-100 W range (vs 0.01-1 W on RTOS). Reserved for applications that genuinely need advanced AI.

Ultra low power: optimisations for 10-year battery life

Power optimisation is the central challenge of battery-powered IoT sensors. Reaching 5 to 10 years of life on a single lithium cell demands a systematic approach covering sleep mode selection, wake-up source management and tight firmware-level optimisation. We dive deeper into the topic in embedded power management for 3+ year battery life.

For battery-powered IoT sensors, power consumption is the #1 criterion. Target: 5-10 years on a single 3.6 V / 2 Ah lithium cell.

Deep-sleep modes

Typical power hierarchy (STM32L4, nRF52):

• Active (CPU ON): 10-50 mA. Reserved for acquisition and transmission.
• Sleep (CPU OFF, peripherals ON): 1-5 mA. Rarely used.
• Deep Sleep / Stop Mode: 10-100 uA. RAM retained, fast wake-up (<10 us).
• Standby / Shutdown: 0.5-5 uA. RAM lost, full boot on wake (ms).

Optimisation strategies

1. Smart wake-up sources

• RTC (Real-Time Clock): periodic wake-up (e.g. once per hour).
• External GPIO: PIR motion detector, button.
• Analog comparator: temperature threshold crossed.
• LPUART: wake-up on a LoRaWAN radio frame (CAD mode).

2. Code-level optimisation

• Disable unused peripherals (ADC, UART, SPI, I2C).
• Lower CPU frequency during measurements: 32 MHz down to 4 MHz (8x lower power).
• DMA for transfers: CPU can sleep during SPI/I2C activity.
• Flash: low-power read mode (2x lower power vs normal).

3. Suspend-to-RAM (embedded Linux)

On Linux systems (Jetson, i.MX8), suspend-to-RAM (S3) drops consumption from 500 mA down to 10-50 mA:

• CPU, GPU, DDR put in low-power mode.
• Wake-up via RTC, GPIO, Ethernet (Wake-on-LAN).
• Resume in <1 second (vs 10-20 s cold boot).

Yocto config example:

• Kernel: CONFIG_SUSPEND=y, CONFIG_PM_SLEEP=y.
• Userspace: systemd-suspend, pm-utils.
• Wake-up: /sys/class/rtc/rtc0/wakealarm.

AESTECHNO field experience: we observed that a battery-powered LoRaWAN gateway using suspend-to-RAM 23 hours per day reaches 3 days of autonomy, against only 8 hours without suspend.

Firmware security: secure boot, OTA, encryption

Firmware security has become a non-negotiable requirement for any connected product. Unprotected firmware exposes the product to cloning, malicious code injection and data interception, all risks that regulations like IEC 62443 and the European Cyber Resilience Act now demand be addressed at design time. Our secure IoT product design and deployment guide covers the full picture, and the Cyber Resilience Act IoT compliance piece details the regulatory side.

An unsecured firmware is a major risk. In 2025, embedded cybersecurity is mandatory.

Secure boot

Principle: verify the firmware's cryptographic signature before execution.

Implementation:

1. The bootloader (U-Boot, MCUboot) verifies the firmware signature (RSA-2048, ECDSA-256).
2. If the signature is invalid, the device refuses to boot.
3. The public key sits in OTP (One-Time Programmable) memory or eFuses.

MCU support: STM32 (Secure Boot & Secure Firmware Update), nRF52 (ARM TrustZone), ESP32 (Flash Encryption + Secure Boot v2).

OTA updates (Over-The-Air)

Recommended architecture:

• Dual-bank Flash: 2 firmware slots (active + backup).
• Smart bootloader: MCUboot, U-Boot with rollback.
• Delta updates: ship only the differences (5-10x smaller payloads).
• Mandatory signing: refuse unsigned firmware.

Development effort: 10-20 days for bootloader + OTA client + backend (AWS IoT Jobs, Azure IoT Hub).

Data encryption

• TLS 1.3: server-side communications (MQTT, HTTPS).
• AES-256: storage of sensitive data in Flash/EEPROM.
• Secure element: ATECC608, SE050 for cryptographic keys.

Code architecture: HAL and layered design

The Hardware Abstraction Layer (HAL) is a foundational architectural pattern in embedded development. It separates hardware-dependent code from application logic, letting the firmware be ported to new platforms without rewriting the business logic - an investment that pays off on the very first migration.

A well-structured firmware project separates hardware-dependent code from application logic via a hardware abstraction layer. This layered architecture is typically organised in three tiers: a low-level driver layer (register access), a HAL/middleware layer (portable API) and an application layer (business logic). In our experience, this separation is especially valuable during migrations between MCU families - moving from STM32 to NXP, for instance, because only the driver layer needs rewriting while the application stays untouched.

Key architectural principles we apply at AESTECHNO:

• Modular design: each peripheral or functional block has its own module with a clear interface.
• Dependency injection: upper layers depend on abstractions, not on concrete hardware implementations.
• State machines: complex behaviours are modelled as explicit state machines for predictability and testability.
• Minimal global state: shared mutable state is the leading source of hard-to-reproduce bugs in embedded systems.

This HAL architecture is also the answer to obsolescence questions: as detailed in the FAQ below, a clean architecture lets a firmware migrate from STM32F1 to STM32L4 in three weeks rather than several months. Investing 20% of the time in architecture upfront saves significantly more in future refactoring.

Anti-patterns to avoid at all costs

Firmware anti-patterns are recurring mistakes we see at AESTECHNO during embedded code audits. Catching them early - ideally through automated linting rules in the CI pipeline - avoids costly fixes in production, particularly in certified systems where every anomaly must be documented.

Across many embedded projects, we keep seeing the same mistakes that lead to unreliable products. Avoiding them upfront is far cheaper than fixing them in production:

• No watchdog timer: every production firmware must implement a watchdog to recover automatically from unexpected hangs.
• Unbounded loops and blocking waits: they freeze the system if a peripheral does not respond as expected.
• Dynamic memory allocation in real-time paths: malloc/free introduces fragmentation and non-deterministic latency. Prefer static allocation or memory pools.
• Ignoring compiler warnings: warnings about type conversions, unused variables or implicit casts often hide real bugs.
• Hard-coded magic numbers: configuration values buried in the code make maintenance and adaptation almost impossible.
• No error handling on peripheral access: SPI transfers fail, I2C devices stop responding, Flash writes get interrupted. A robust firmware handles every failure case gracefully.

These anti-patterns are particularly dangerous in certified applications (IEC 62304, ISO 26262) where every anomaly must be documented and corrected. Folding them into code reviews and CI checklists prevents them from reaching production.

Testing, CI/CD and firmware validation

Firmware validation rests on a three-tier test pyramid: unit tests (70%), integration tests (20%) and system tests (10%). This shape gives maximum coverage while keeping feedback cycles fast, and it is a prerequisite for any normative certification path. For the full DevOps story, see our embedded DevOps CI/CD guide.

Embedded test pyramid

Level 1: unit tests (70% of tests)

• Tools: Unity, Google Test, Ceedling.
• Execution: PC (gcc) + target (cross-compiler).
• Coverage: >80% code coverage (gcov, lcov).

Level 2: integration tests (20%)

• QEMU: ARM Cortex-M, RISC-V emulation.
• Renode: multi-core, peripheral simulation.
• Hardware-in-the-Loop (HIL): real board + automated stimuli.

Level 3: system tests (10%)

• End-to-end tests: sensor to cloud to dashboard.
• Long-duration tests: 1000h+ (memory leak detection).
• Environmental tests: -40 C to +85 C, vibration, EMC.

Firmware CI/CD pipeline

Mastery of versioning is a prerequisite for any CI/CD pipeline. Our embedded DevOps CI/CD guide covers the broader methodology, from branch strategy to signed artefacts.

GitLab CI / GitHub Actions example:

1. Build: multi-target compilation (Debug, Release, Test).
2. Static analysis: Cppcheck, Coverity, MISRA C checker.
3. Unit tests: execution + coverage report.
4. Flash & test: target programming via JTAG (Segger, ST-Link).
5. Artefacts: generation of .bin, .hex, signature, release notes.

Tools:

• PlatformIO: cross-platform build system.
• West (Zephyr): meta-tool for Zephyr RTOS.
• CMake + Ninja: fast C/C++ builds.
• Docker: reproducible environment (frozen SDK).

Payoff: bugs caught 48 h after commit (vs 6 months in production). Critical ROI for certified products.

At AESTECHNO, we have set up CI/CD pipelines for several customer projects with one non-negotiable principle: the pipeline is the only path to production. The dual goal is safety (minimal regression) and auto-deployment gated on tests: backend servers and Play Store rollouts trigger automatically only if the unit, integration and HIL suites pass. No manual shortcut, no desensitisation to flaky tests - a flaky test is a bug to fix, not to ignore.

On those same pipelines, we industrialise firmware signing and secure OTA as a direct outcome of that discipline: every binary pushed to devices is signed, versioned and tied to an auditable commit. This end-to-end approach, from embedded firmware through to the data cluster, is rare. At AESTECHNO we cover hardware, firmware and cloud/data on a single project, including the top-tier HA cluster we deployed to ingest IoT streams in production.

Regulatory compliance: IEC 62304, DO-178C, ISO 26262

Software certifications for safety-critical embedded systems impose strict requirements on traceability, test coverage and documentation. Each standard - IEC 62304 for medical, DO-178C for aerospace, ISO 26262 for automotive - defines criticality levels with processes proportionate to the risk involved.

IEC 62304, medical software

According to the IEC (International Electrotechnical Commission), the IEC 62304 standard is mandatory for medical-device software placed on the market in Europe (MDR 2017/745) and in the United States (FDA 21 CFR Part 820).

Key requirements:

• Software classification: class A (low risk) up to C (life-critical).
• Development plan: traceability from requirements to code to tests.
• Risk management: ISO 14971 (FMEA analysis).
• Validation: documented tests, >90% coverage (class C).
• Maintenance: anomaly handling, security patches.

IEC 62304-certified RTOS:

• SafeRTOS (FreeRTOS-based, certified).
• Azure RTOS (ThreadX): certification included (free since 2024).
• embOS Safety.

DO-178C, aerospace software

FAA/EASA standard for avionics. Five levels: A (catastrophic) down to E (no effect).

DO-178C process:

• Coverage objectives generation: MC/DC (Modified Condition/Decision Coverage).
• Bidirectional traceability: requirements, code, tests.
• Formal code reviews: pair programming, inspections.
• Qualified tooling: certified compilers, linkers, static analysers.

ISO 26262, automotive software

Automotive functional safety. ASIL A (low) up to D (critical).

Specifics:

• AUTOSAR compliance (standardised software architecture).
• SafeRTOS or MICROSAR OS (Vector).
• Mandatory HIL testing (dSPACE, ETAS).

Firmware development: in-house vs outsourced

The choice between in-house development and firmware outsourcing depends on project size, skill availability and time-to-market constraints. For a one-off project under 12 months, outsourcing to a specialised design house avoids the fixed costs of hiring and brings expertise that is operational from day one.

Scenario 1: in-house development

Direct costs (France, 2025):

• Senior firmware engineer: significant annual budget, employer charges included.
• Tooling: IDE, debugger, certified RTOS licence, static analysers.
• Debug hardware: oscilloscope, logic analyser, JTAG probes, dev boards.

Risks:

• Single-person dependency (departure = blocked project).
• Lack of certification experience (costly failures).
• Stretched time-to-market (learning curve).

Scenario 2: outsourcing (design house)

AESTECHNO advantages:

• Experienced team (10+ years of expertise).
• Tooling already amortised (licences, hardware).
• No ramp-up, productivity from day one.
• Skills transfer (documentation, team training).

Outcome: for a project under 12 months, outsourcing typically proves more economical than in-house development by avoiding fixed costs and turnover risk.

Summary: what to remember about industrial embedded software

The architecture choice is the most structuring decision. Bare-metal suits ultra low-power sensors. RTOS (FreeRTOS or Zephyr) is the right fit for multi-task real-time products. Embedded Linux via Yocto covers gateways, HMIs and edge AI.

Certification shapes the ecosystem. Per the IEC, IEC 62304 governs medical software. IEC 61508 covers industrial SIL levels. ISO 26262 applies to automotive. Firmware security is no longer optional: secure boot, RSA-2048 or ECDSA-256 signing, dual-bank OTA with rollback, TLS 1.3 per RFC 8446.

SBOMs have become mandatory under the European Cyber Resilience Act. The CycloneDX format is published per OWASP CycloneDX. The SPDX format is published by the Linux Foundation. MISRA C rules from MISRA structure quality for critical code.

In our practice, most firmware failures in production come from avoidable anti-patterns: missing watchdog, dynamic allocation in real-time paths, hard-coded magic numbers, no error handling on SPI and I2C buses. Fixing them in code review costs a day. Fixing them after deployment costs a recall.

Field experience: on a recent project integrating an NVIDIA Jetson Orin NX, we delivered in Q1 2026 a fully customised Yocto BSP (custom layers, kernel configuration, device tree). Contrary to the "ready-made distribution" approach that looks faster, despite the Yocto learning curve, a tailored BSP guarantees build reproducibility over a 10-year lifetime, a non-negotiable criterion for industrial products. Conversely, for a prototype to validate in two weeks, Debian or Ubuntu on Raspberry Pi remains a pragmatic choice. We systematically measure power with the Nordic PPK2 and the Keithley DMM7510 to validate quiescent currents in deep sleep.

Related articles

To round out your embedded software strategy:

• Zephyr, FreeRTOS, real-time Linux: which embedded OS to choose?, RTOS comparison with latency benchmarks, certification readiness and BLE stack maturity.
• Secure IoT product design and deployment, Secure boot, signed OTA, TLS 1.3, key provisioning - end-to-end security.
• Embedded DevOps: CI/CD and automated testing, Pipeline-as-the-only-path-to-production, HIL benches, signed releases.
• Cyber Resilience Act: IoT compliance, SBOM, vulnerability handling, CRA obligations from 2027.
• Industrial IoT cybersecurity, Threats, Zero Trust, IEC 62443 compliance for connected products.
• Embedded power management: 3+ year battery life, Deep sleep budgets, wake-up sources, current measurement methodology.
• CVE-2026-31431: copy_fail Linux kernel LPE, How a kernel CVE bites embedded Linux fleets and why patch cadence matters.

FAQ: embedded software and firmware development

What is the difference between firmware and embedded software?
The terms are often used interchangeably, but technically: firmware means the software stored in non-volatile memory (Flash, ROM) and executed directly on the microcontroller, while embedded software is a broader term that also covers Linux applications, drivers and middleware layers. AESTECHNO develops both: ultra-low-power RTOS firmware and Linux applications for NVIDIA Jetson processors.

How long does it take to develop a firmware from scratch?
Plan on 2-4 months minimum for a simple firmware (RTOS, 2-3 sensors, serial communication), 6-9 months for a complex firmware (embedded Linux, cellular connectivity, OTA updates), and 12-18 months for a certified firmware (IEC 62304, DO-178C) including documentation and validation testing. Our firmware engineering team applies an Agile methodology that delivers a functional MVP in 6-8 weeks to validate the architecture.

Can a firmware be updated without an internet connection (offline OTA)?
Yes, several methods exist: (1) USB/UART via a bootloader using the Xmodem/Ymodem protocol, (2) SD Card with automatic detection at boot, (3) NFC for short-range transfer (medical devices), (4) Bluetooth via a mobile app (Nordic nRF Connect, ST BLE Sensor). At AESTECHNO, we have implemented dual-bank bootloaders with automatic rollback if the new firmware crashes at startup (safety-critical).

FreeRTOS vs Zephyr: which one to pick in 2025 for a new project?
Pick FreeRTOS if you face: extreme memory constraints (<64 KB Flash), AWS IoT ecosystem mandate, or immediate certification need (SafeRTOS available). Pick Zephyr if you have: a greenfield project, advanced Bluetooth needs (BLE 5.4, Mesh, Direction Finding), critical security (TLS 1.3, native secure boot), or a long-term sustainability goal (very active Linux Foundation community). Our 2025 recommendation: Zephyr for new products, gradual migration if already on FreeRTOS.

How do you handle component obsolescence in firmware?
A three-pronged strategy: (1) HAL (Hardware Abstraction Layer) to isolate business code from MCU-specific drivers, (2) multi-platform from day one (e.g. compile for STM32 + nRF52 + ESP32), (3) MCU choice with guaranteed longevity (STM32: 10 years, NXP i.MX: 15 years, Infineon AURIX: 20 years automotive). At AESTECHNO, we migrated a firmware from STM32F1 (obsolete) to STM32L4 in 3 weeks thanks to a clean HAL architecture. Investing time in architecture upfront saves substantially on future migrations.