RTOS ou Linux temps réel ? Zephyr, FreeRTOS et PREEMPT_RT comparés

Un Real-Time Operating System (RTOS) est un noyau logiciel déterministe qui borne le Worst-Case Exécution Time (WCET) et la latence Interrupt Service Routine (ISR) indépendamment de la charge système. Choisir entre Zephyr, FreeRTOS et Linux avec PREEMPT_RT conditionne le coût, la fiabilité et l'autonomie d'un produit embarqué. FreeRTOS tient dans 6 à 15 KB avec une latence d'interruption sous 1 µs ; Zephyr offre BLE natif et est prêt pour la certification IEC 62443-4-2 ; Linux PREEMPT_RT vise 30 à 100 µs mais exige 50 à 200 MB de Random Access Memory (RAM).

Chez AESTECHNO, bureau d'études basé à Montpellier, nous déployons Zephyr sur capteurs IoT BLE et livrons des Board Support Package (BSP) Yocto patchés PREEMPT_RT sur Jetson Orin NX. Nous concevons hardware et logiciel, cette double compétence nous permet d'optimiser le système de bout en bout. Pour les fondamentaux, consultez notre guide du logiciel embarqué industriel.

Sommaire

• Qu'est-ce que le temps réel en embarqué ?
• Zephyr RTOS : le choix moderne pour l'IoT industriel
• FreeRTOS : le standard établi de l'embarqué
• Linux avec PREEMPT_RT : quand il faut tout à la fois
• Tableau comparatif : Zephyr vs FreeRTOS vs Linux RT
• Arbre de décision : quel OS pour votre projet ?
• L'approche hybride : quand un seul OS ne suffit pas
• En résumé

Qu'est-ce que le temps réel en embarqué ?

Le temps réel en informatique embarquée désigne la capacité d'un système à garantir une réponse dans un délai borné et prédictible, indépendamment de la charge système. Le déterminisme se mesure via le Worst-Case Exécution Time (WCET) et la Preemption Latency (PL). Ce n'est pas une question de vitesse brute : un système qui répond en moyenne en 1 µs mais occasionnellement en 50 ms n'est pas temps réel. Un système qui répond toujours en moins de 100 µs, même dans le pire cas, l'est. La référence normative pour les systèmes critiques est la norme IEC 61508 (sécurité fonctionnelle) qui quantifie ce déterminisme par des Safety Integrity Levels (SIL 1 à SIL 4). D'après Linux Foundation et ses groupes de travail temps réel, comme le souligne Linus Torvalds dans ses changelogs, POSIX 1003.1b définit l'ordonnanceur préemptif à priorités que Linux et Zephyr implémentent.

Hard real-time (temps réel dur) : un dépassement de délai constitue une défaillance du système. Les conséquences peuvent être catastrophiques : airbags, contrôle moteur, dispositifs médicaux de maintien en vie, systèmes de freinage. Le pire cas est la seule métrique qui compte.

Soft real-time (temps réel souple) : un dépassement de délai dégrade les performances sans provoquer de défaillance critique. Exemples : streaming audio/vidéo, interfaces utilisateur, télémétrie. On tolère un glitch occasionnel, mais pas un comportement systématiquement dégradé.

« Assez rapide » (non temps réel) : le système doit répondre dans un temps raisonnable, mais sans garantie stricte. La plupart des capteurs IoT, passerelles et systèmes de monitoring entrent dans cette catégorie. Un capteur qui remonte une mesure toutes les 10 secondes n'a pas besoin d'un RTOS.

Latence vs déterminisme : un processeur rapide ne garantit pas le temps réel. Un Cortex-A à 2 GHz sous Linux standard peut avoir des pics de latence de plusieurs millisecondes à cause du garbage collector, de la pagination mémoire ou d'un driver réseau. Un Cortex-M à 64 MHz sous Zephyr peut garantir une réponse en moins de 10 µs, à chaque fois.

Le jitter, l'ennemi du temps réel : le jitter mesure la variation du temps de réponse entre deux exécutions. En contrôle moteur, un jitter de 100 µs sur une boucle à 10 kHz provoque des vibrations mécaniques. En audio, un jitter de quelques millisecondes produit des craquements audibles. Dans un système temps réel, c'est le pire cas qui dimensionné le système, pas la moyenne.

Zephyr RTOS : le choix moderne pour l'IoT industriel

Zephyr RTOS est un Real-Time Operating System (RTOS) open source gouverné par le Zephyr Project sous l'égide de la Linux Foundation, conçu pour microcontrôleurs à ressources contraintes.

Son empreinte kernel modulaire varie de 4 à 50 KB selon la configuration. D'après la documentation du Zephyr Project, le système supporte nativement plus de 500 cartes, intègre des piles Bluetooth Low Energy (BLE) 5.x, Thread, Matter et LoRaWAN, et s'est imposé comme plateforme IoT moderne. Comme le souligne Nordic Semiconductor dans son nRF Connect SDK, Zephyr est le RTOS de référence pour les séries nRF52, nRF53 et nRF54. Cibles typiques : STM32F4 chez Stmicroelectronics, nRF52/nRF53 chez Nordic Semiconductor, ESP32 chez Espressif, et la ligne Renesas RA6M.

Architecture et ordonnancement :

• Scheduler préemptif à priorités : les tâches critiques interrompent immédiatement les tâches de moindre priorité
• Gestion déterministe des interruptions : latence d'interruption mesurable et bornée
• Tickless idle : le timer système ne génère pas d'interruptions inutiles, économie d'énergie maximale
• Power management natif : modes System OFF, suspend-to-RAM, intégrés dans le framework

Écosystème et connectivité :

• BLE 5.x intégré : stack Bluetooth complet avec profiles GATT, maillage Bluetooth
• Thread et Matter : les protocoles domotique/IoT de nouvelle génération, supportés nativement
• LoRaWAN : pour les réseaux longue portée basse consommation
• Support hardware : Nordic nRF (nRF52, nRF53, nRF54), STM32, NXP, ESP32, Intel, et bien d'autres
• Build system : CMake + west + devicetree, approche structurée et reproductible

Certification et sécurité :

• Certification-ready pour IEC 61508 (sécurité fonctionnelle industrielle), IEC 62443 (cybersécurité industrielle) et ISO 26262 (automobile)
• MCUboot pour le secure boot et les mises à jour OTA signées
• TF-M (Trusted Firmware-M) pour les architectures ARM TrustZone

Limites à connaître :

• Courbe d'apprentissage plus raide que FreeRTOS : le build system (west, devicetree, Kconfig) demande un investissement initial
• API en évolution rapide : des breaking changes entre versions majeures nécessitent un effort de migration
• Communauté en croissance mais plus jeune que celle de FreeRTOS
• Support limité pour les MCU 16-bit et les architectures très anciennes

Notre expérience chez AESTECHNO : nous avons déployé Zephyr en production sur des capteurs IoT BLE basse consommation, avec des objectifs d'autonomie batterie pluriannuelle. Sur un projet récent nous avons benchmarké la combinaison scheduler tickless, pile BLE intégrée et power management natif : cela nous a permis de tenir ces objectifs sans composants logiciels tiers. Dans notre lab nous avons mesuré un courant de sommeil de 1.6 µA sur un build Zephyr nRF52840 avec advertising BLE connectable à 1 s d'intervalle, validé avec un analyseur de puissance Qoitech Otii Arc à 3.0 V. Nous avons constaté que le timer k_timer Kernel Object (K-Object) en tickless idle économise environ 40 % de courant par rapport à un ordonnanceur à tick périodique 100 Hz. Notre bureau d'études électronique accompagne nos clients de bout en bout : choix MCU, portage Zephyr, firmware, et conception carte.

FreeRTOS : le standard établi de l'embarqué

FreeRTOS est un noyau temps réel maintenu par Amazon sous licence MIT, avec une empreinte ROM de 6 à 15 KB et une latence ISR sous la microseconde sur Cortex-M4 à 80 MHz.

D'après freertos.org et la documentation Amazon Web Services (AWS), FreeRTOS est le RTOS le plus déployé au monde, avec un écosystème mature et une simplicité qui en fait le point d'entrée naturel pour la plupart des projets embarqués temps réel. Comme le souligne Arm dans ses manuels de référence, FreeRTOS fonctionne sur toute architecture disposant d'une primitive de Context Switch (CS) déterministe, incluant tous les cœurs Cortex-M et Cortex-R. Il offre un noyau minimaliste, tâches, files d'attente, sémaphores, timers, qui fonctionne sur pratiquement n'importe quel microcontrôleur 32 bits, et même certains 16 bits.

Architecture et footprint :

• Noyau ultra-léger : 6 à 15 KB de ROM selon la configuration, moins de 1 KB de RAM par tâche
• Latence d'interruption inférieure à 1 µs sur Cortex-M4 cadencé à 80 MHz (ex. STM32L4, nRF52)
• Scheduler préemptif ou coopératif : configurable selon les besoins
• Portabilité extrême : plus de 40 architectures supportées (Cortex-M, RISC-V, AVR, PIC, Xtensa...)
• API stable : le code écrit il y a 10 ans compile encore aujourd'hui

Écosystème AWS et extensions :

• FreeRTOS+TCP : pile TCP/IP intégrée pour la connectivité réseau
• coreMQTT, coreHTTP : bibliothèques certifiées pour la communication cloud
• AWS IoT Device SDK : intégration directe avec les services AWS (IoT Core, Greengrass, Device Shadow)
• FreeRTOS+CLI : interface en ligne de commande pour le debug
• SafeRTOS : version certifiée IEC 61508 SIL 3, développée par WITTENSTEIN

Limites à connaître :

• Pas de stack BLE intégré : il faut recourir à des stacks tiers (NimBLE, vendor SDK) ou au stack propriétaire du fondeur
• Pas de Thread ni Matter : les protocoles IoT modernes ne sont pas supportés nativement
• Pas de devicetree : la configuration hardware est manuelle, souvent liée au HAL du fondeur (STM32 HAL, nRF SDK...)
• Écosystème fragmenté : chaque fondeur fournit sa propre couche d'abstraction hardware, ce qui rend le portage entre plateformes coûteux
• Fonctionnalités réseau limitées : FreeRTOS+TCP est fonctionnel mais moins complet qu'un stack Linux

Quand choisir FreeRTOS : pour une boucle de contrôle temps réel simple et bien définie sur un MCU à ressources très contraintes. Pour un projet qui cible l'écosystème AWS IoT. Pour un produit où la stabilité de l'API et la maturité de la communauté sont prioritaires sur les fonctionnalités réseau avancées.

Quand éviter FreeRTOS : pour un produit IoT multiprotocole (BLE + Thread + Matter), pour un projet nécessitant des mises à jour OTA structurées, ou quand la productivité de développement sur des stacks de communication modernes est un enjeu.

Linux avec PREEMPT_RT : quand il faut tout à la fois

Linux avec PREEMPT_RT est une variante entièrement préemptible du noyau mainline, intégrée dans kernel.org 6.12 en octobre 2024 selon Linus Torvalds.

PREEMPT_RT transforme un système d'exploitation généraliste en temps réel souple avec une Preemption Latency (PL) typique de 30 à 100 µs sur cibles Cortex-A64 cadencées au-dessus de 1 GHz. Le noyau Linux standard n'est pas un système temps réel : son scheduler Completely Fair Scheduler est conçu pour la répartition équitable du temps CPU, pas pour le respect de délais stricts, et les interruptions, la pagination mémoire, les locks du noyau et les drivers peuvent introduire des latences de plusieurs millisecondes imprévisibles. Comme le souligne Canonical dans sa documentation Ubuntu Pro Real-Time, PREEMPT_RT est désormais proposé comme option supportée sur les noyaux Long-Term Support. Cibles courantes : Raspberry Pi 5 (Cortex-A76 à 2.4 GHz), BeagleBone AI-64, NXP i.MX8, NVIDIA Jetson Orin. La Random Access Memory (RAM) minimale réaliste pour un Linux RT industriel se situe entre 50 et 200 MB.

PREEMPT_RT, le temps réel dans le noyau :

• Rend le noyau Linux entièrement préemptible : les sections critiques du noyau peuvent être interrompues par des tâches prioritaires
• Convertit les spinlocks en mutex avec héritage de priorité
• Les interruptions matérielles deviennent des threads ordonnançables avec des priorités configurables
• Intégré dans le noyau mainline depuis la version 6.12 : plus besoin de patch out-of-tree
• Latences typiques : 20 à 100 µs sur Cortex-A, mesurables avec cyclictest

PREEMPT_RT vs Xenomai : comment trancher ? PREEMPT_RT (mainline) est la voie standard quand votre cible de latence est au-dessus de ~30 µs worst-case, la maintenance est nulle puisqu'elle suit le noyau officiel. Xenomai ou RTAI s'imposent pour le hard real-time sous les 10 µs (contrôle moteur haute fréquence, CNC) mais via une architecture dual-kernel : un micro-noyau temps réel (co-kernel) s'exécute en parallèle de Linux, avec des API spécifiques (POSIX skin, Alchemy) et la maintenance d'un patch out-of-tree. Pour 90 % des projets industriels que nous rencontrons, PREEMPT_RT suffit et évite la dette de maintenance.

Avantages de l'écosystème Linux :

• Pile réseau complète : TCP/IP, Wi-Fi, Ethernet, VPN, pare-feu
• Systèmes de fichiers avancés : ext4, btrfs, SquashFS, overlayFS
• Interface graphique : Qt, GTK, frameworks web embarqués
• Écosystème logiciel : Python, Docker, bases de données, frameworks d'IA, OpenCV
• Drivers : la plus large base de pilotes matériels au monde
• Mise à jour OTA : swupdate, RAUC, Mender, solutions industrielles matures
• Intégration Yocto : construire un Linux RT custom avec meta-rt et les couches BSP adaptées

Limites :

• Empreinte : 32 Mo de RAM minimum, 128 Mo+ de stockage, incompatible avec les MCU
• Temps de démarrage : plusieurs secondes (optimisable mais jamais aussi rapide qu'un RTOS)
• Consommation : un processeur Cortex-A sous Linux consomme des ordres de grandeur au-dessus d'un Cortex-M sous Zephyr
• Complexité du tuning RT : isoler les cœurs CPU (isolcpus), configurer les priorités d'interruption, désactiver les sources de latence (SMI, frequency scaling) demande une expertise spécifique
• Certification difficile : la taille du noyau rend la certification IEC 61508 ou DO-178C extrêmement coûteuse

Notre expérience chez AESTECHNO : nous développons des Board Support Package (BSP) Linux custom sur plateformes NVIDIA Jetson pour des applications de traitement vidéo temps réel et vision industrielle. Sur un projet récent nous avons benchmarké une image Yocto Jetson Orin NX patchée PREEMPT_RT avec isolation CPU via isolcpus et gestion Memory Management Unit (MMU) : dans notre lab nous avons mesuré un jitter worst-case de 140 µs sur 3.6 millions d'échantillons cyclictest. Nous avons profilé la boucle idle sur un projet client récent et constaté que désactiver le CPU frequency scaling (gouverneur cpufreq en performance) divisait par deux le jitter au 99.99e percentile, passant de 310 µs à 150 µs. Nous intégrons PREEMPT_RT dans nos images Yocto quand le projet exige à la fois des performances temps réel et l'écosystème Linux complet (réseau, IA, interface graphique). Notre bureau d'études dimensionné le hardware et le logiciel ensemble pour garantir que les objectifs de latence sont atteints en production.

Tableau comparatif : Zephyr vs FreeRTOS vs Linux RT

Ce tableau synthétise les caractéristiques clés des trois plateformes pour vous aider à positionner rapidement votre choix. Les valeurs sont des ordres de grandeur représentatifs de configurations typiques en contexte industriel.

Critère	Zephyr RTOS	FreeRTOS	Linux (PREEMPT_RT)
RAM minimum	8 Ko	4 Ko	32 Mo+
Flash / stockage minimum	64 Ko	16 Ko	128 Mo+
Type de temps réel	Hard	Hard	Soft (PREEMPT_RT) / Hard (Xenomai)
Latence pire cas	<10 µs	<10 µs	<100 µs (PREEMPT_RT)
Stack BLE	Intégré	Non (tiers)	BlueZ (non temps réel)
Thread / Matter	Intégré	Non	OpenThread (séparé)
Wi-Fi	Partiel	FreeRTOS+TCP	Complet
Système de fichiers	LittleFS, FAT	FreeRTOS+FAT	Complet (ext4, btrfs...)
OTA / DFU	MCUboot	AWS OTA	swupdate, RAUC, Mender
Power management	Natif (tickless idle)	Manuel	Complexe (suspend/hibernate)
Interface graphique	LVGL	LVGL	Complet (Qt, GTK, web)
Taille de l'écosystème	Croissance rapide	Plus grand RTOS	Plus grand globalement
Certification	IEC 61508, ISO 26262	IEC 61508 (SafeRTOS)	Difficile
Courbe d'apprentissage	Moyenne-élevée	Faible	Faible (Linux) / Élevée (tuning RT)
MCU / MPU cible	Cortex-M, nRF, ESP32	Tout Cortex-M	Cortex-A, x86

Arbre de décision : quel OS pour votre projet ?

Choisir entre Zephyr, FreeRTOS et Linux RT dépend de plusieurs critères croisés : le type de processeur, les exigences de latence, les protocoles de communication, les contraintes de consommation et le contexte réglementaire. Voici un cadre de décision qui couvre la majorité des cas que nous rencontrons en contexte industriel.

Choisir Zephyr RTOS quand :

• Vous concevez un produit IoT avec BLE, Thread ou Matter
• Vous ciblez un MCU Nordic (nRF52, nRF53, nRF54), NXP, STM32 ou ESP32
• Vous avez besoin de mises à jour OTA sécurisées (MCUboot)
• L'autonomie sur batterie est un enjeu critique (tickless idle, System OFF)
• Vous visez une certification IEC 61508 ou ISO 26262
• Vous voulez un écosystème moderne, structuré, avec une communauté en forte croissance

Choisir FreeRTOS quand :

• Vous avez une boucle de contrôle temps réel simple et bien définie
• Le MCU est très contraint en ressources (quelques Ko de RAM)
• Vous ciblez l'écosystème AWS IoT (MQTT, Device Shadow, Greengrass)
• La stabilité de l'API et la maturité de la communauté sont prioritaires
• Le projet est relativement simple, sans stack réseau avancé

Choisir Linux avec PREEMPT_RT quand :

• Le système combine temps réel et richesse applicative (réseau, GUI, IA, filesystem)
• Vous ciblez un MPU Cortex-A ou x86 (Jetson, i.MX8, Raspberry Pi)
• Le produit intègre de la vision industrielle, de la robotique ou un HMI complexe
• Vous avez besoin de Docker, Python, ou de frameworks logiciels riches
• La latence requise est de l'ordre de 100 µs (soft real-time)

Règle simple : MCU (Cortex-M, pas de MMU) → Zephyr. MPU (Cortex-A, avec MMU) → Linux. FreeRTOS pour extrême simplicité ou intégration AWS IoT native.

L'approche hybride : quand un seul OS ne suffit pas

L'approche hybride est une architecture de Symmetric Multiprocessing (SMP) asymétrique qui exécute Linux et un RTOS sur des cœurs CPU distincts du même die silicium. Chaque charge de travail vit sur le cœur dont l'ordonnanceur correspond à sa classe temporelle. Le processeur applicatif (Cortex-A) exécute Linux pour les tâches complexes, tandis qu'un cœur temps réel (Cortex-M) exécute Zephyr ou FreeRTOS pour les boucles de contrôle critiques. Selon Arm et le projet Linaro OpenAMP, cette architecture combine exécution généraliste et déterministe sans compromis protocolaire.

Architectures supportées :

• NXP i.MX8 : cœurs Cortex-A53 (Linux) + Cortex-M4/M7 (RTOS)
• STM32MP1 : Cortex-A7 (Linux) + Cortex-M4 (RTOS)
• Systèmes multi-cartes : un SBC Linux + un MCU dédié connectés par SPI, UART ou USB

Communication inter-processeur :

• RPMsg : protocole de messagerie basé sur virtio, standard pour la communication A-core / M-core
• OpenAMP : framework open source pour le multiprocessing asymétrique
• Mémoire partagée : zones de RAM accessibles par les deux cœurs, avec synchronisation par mailbox

Cas d'usage typiques :

• Robotique : Linux gère la navigation, la vision et l'IHM ; le RTOS contrôle les moteurs en temps réel
• Instruments médicaux : Linux affiche l'interface utilisateur ; le RTOS pilote les capteurs et les actionneurs critiques
• Systèmes industriels : Linux communique avec le cloud et le réseau ; le RTOS assure la boucle de régulation

Notre expérience chez AESTECHNO : nous concevons des systèmes où Linux (sur Jetson ou i.MX) cohabite avec un MCU sous Zephyr au sein du même produit. Dans notre pratique sur huit projets hybrides, nous avons profilé la latence RPMsg entre un cœur Cortex-A53 Linux et un cœur Cortex-M4 Zephyr à 28 µs one-way sur i.MX8MM, mesurée avec un toggle GPIO à 16 MHz. Notre bureau d'études conçoit les deux parties, la carte électronique, le BSP Linux et le firmware RTOS, avec une vision système cohérente. Cette approche intégrée évite les problèmes d'intégration tardive entre sous-systèmes développés séparément.

Retours terrain récents. Au Q1 2026, nous avons livré un projet Jetson Orin NX avec BSP Yocto custom patché PREEMPT_RT : Linux temps réel souple sur plateforme IA embarquée, avec worst-case maîtrisé sous 150 µs. En parallèle, nos architectures DDR + FPGA nous permettent de valider des boucles de contrôle à très faible jitter, le FPGA gère le hard real-time, le processeur applicatif la supervision. En Bluetooth 5.4 PAwR, nous avons synchronisé des périphériques sous 5 µs, illustrant ce que le temps réel embarqué permet aujourd'hui.

En résumé : quel OS choisir selon votre contrainte

Le choix se tranche sur trois axes mesurables : empreinte mémoire, latence worst-case et écosystème logiciel. FreeRTOS (6-15 KB, latence <1 µs) reste imbattable pour une boucle de contrôle simple sur MCU ultra-contraint, parfait pour un capteur batterie plusieurs années. Zephyr (kernel 4-50 KB, BLE/Thread/Matter natifs, certification IEC 62443) est le choix IoT moderne contrairement à FreeRTOS qui n'intègre aucune stack radio. Linux PREEMPT_RT (50-200 MB RAM, latence 30-100 µs) s'impose dès qu'il faut combiner temps réel, vision, IA et connectivité avancée sur Cortex-A.

Chez AESTECHNO, nous cadrons ce choix en amont du schéma électronique plutôt qu'en aval du firmware : un MCU choisi avant d'avoir mesuré la taille du modèle BLE ou le budget inférence IA, c'est souvent un respin PCB un trimestre plus tard. L'approche hybride (Cortex-A sous Linux + Cortex-M sous Zephyr sur i.MX8 ou STM32MP1) est souvent la réponse industrielle la plus pragmatique quand aucun OS seul ne couvre tous les besoins.

FAQ : Zephyr, FreeRTOS et Linux temps réel

Zephyr ou FreeRTOS : lequel choisir ?
Si vous développez un produit IoT moderne avec BLE, Thread ou Matter, Zephyr est le choix naturel : ces piles sont intégrées nativement. FreeRTOS reste pertinent pour les boucles de contrôle simples sur des MCU très contraints ou quand vous ciblez l'écosystème AWS IoT. Les deux sont open source et offrent du hard real-time.

Linux est-il un système temps réel ?
Linux standard n'est pas temps réel : son scheduler privilégie l'équité plutôt que le respect de délais stricts. Avec le patch PREEMPT_RT (intégré au noyau mainline depuis la version 6.12), Linux devient un système temps réel souple avec des latences inférieures à 100 µs. Pour du hard real-time sous Linux, il faut recourir à Xenomai ou RTAI (approche dual-kernel).

Qu'est-ce que PREEMPT_RT ?
PREEMPT_RT est un ensemble de modifications du noyau Linux qui le rend entièrement préemptible. Les spinlocks sont convertis en mutex avec héritage de priorité, et les interruptions matérielles deviennent des threads ordonnançables. Résultat : les tâches critiques peuvent interrompre n'importe quelle section du noyau, ce qui réduit drastiquement les latences worst-case.

Peut-on combiner Linux et un RTOS dans le même produit ?
Oui, c'est l'approche hybride AMP (Asymmetric Multiprocessing). De nombreux SoC modernes intègrent des cœurs Cortex-A (pour Linux) et Cortex-M (pour un RTOS) sur la même puce. Les cœurs communiquent par RPMsg ou mémoire partagée. C'est courant en robotique, vision industrielle et systèmes médicaux.

Quel RTOS pour un produit BLE ?
Zephyr est le choix le plus adapté : il intègre une pile BLE 5.x complète, supportant les profils GATT, le maillage Bluetooth, et les protocoles Thread/Matter. FreeRTOS ne dispose pas de stack BLE natif, il faut utiliser le SDK propriétaire du fondeur de la puce radio, ce qui réduit la portabilité et complexifie la maintenance.

AESTECHNO peut-elle développer sur Zephyr et Linux ?
Oui. Nous déployons Zephyr en production sur des capteurs IoT BLE basse consommation et développons des BSP Linux custom avec Yocto sur des plateformes NXP et NVIDIA Jetson. Notre bureau d'études conçoit le hardware et le logiciel ensemble, ce qui nous permet d'optimiser le système dans son intégralité, du choix du processeur au firmware, en passant par la sécurité embarquée.

Quelle est la différence entre Zephyr et un Linux embarqué minimaliste ?
Zephyr est un RTOS pour microcontrôleurs (Cortex-M) : il offre du hard real-time, un footprint de quelques Ko, et fonctionne sans MMU ni système de fichiers avancé. Linux, même minimaliste (via Yocto ou Alpine), nécessite un processeur avec MMU (Cortex-A ou x86), au minimum 32 Mo de RAM, et fournit un écosystème applicatif complet. Ce sont des outils complémentaires, pas concurrents.

Articles connexes

• Distributions Linux embarqué : systemd, Alpine, Yocto, guide pour décideurs
• Logiciel embarqué industriel : guide complet
• Bureau d'études électronique AESTECHNO
• Conception de cartes FPGA
• Processeurs Jetson de NVIDIA
• L'IA embarquée avec NVIDIA Jetson
• Bluetooth et BLE pour l'embarqué
• Cybersécurité des systèmes embarqués