ac6-training, un département d'Ac6 SAS
FR
FrançaisEnglish
 
go-up

ac6 ac6-training

FreeRTOS ou Zephyr : comment choisir son RTOS pour un projet embarqué

FreeRTOS et Zephyr résolvent la même question de départ, faire cohabiter plusieurs traitements sur un microcontrôleur, avec deux réponses qui n'ont presque rien en commun. FreeRTOS est un ordonnanceur que vous intégrez à votre projet. Zephyr est un système d'exploitation dans lequel votre projet s'intègre. Tout le reste découle de cette phrase.

L'empreinte, chiffrée

C'est le premier réflexe de comparaison, et il est trompeur si on ne compare pas des périmètres équivalents.

Le seul chiffre publié par un des deux projets est celui de FreeRTOS : le noyau seul occupe 5 à 10 kilooctets de ROM selon sa documentation officielle, la valeur dépendant du compilateur, du niveau d'optimisation et des fonctionnalités activées.

Zephyr ne publie pas d'équivalent, parce que la question a moins de sens : la taille dépend entièrement des sous-systèmes activés par Kconfig. Le projet fournit en revanche les cibles west build -t ram_report et rom_report, qui donnent la répartition réelle de votre configuration, symbole par symbole. C'est la seule mesure qui vaille.

ConfigurationFlash
FreeRTOS, noyau seul (source : documentation FreeRTOS)5 à 10 Ko
Zephyr minimalà mesurer avec rom_report
L'un ou l'autre avec pile réseau et pilotesplusieurs dizaines de Ko

Retenez le principe plutôt que des chiffres : la première ligne fait pencher pour FreeRTOS. L'écart se resserre nettement dès qu'on ajoute ce dont un vrai produit a besoin, parce que ce que Zephyr embarque d'office, il faut l'ajouter à FreeRTOS. Mesurez votre propre configuration avant de trancher sur ce critère : tout chiffre général, y compris ceux qu'on lit partout, dépend d'hypothèses qui ne sont pas les vôtres.

La question utile n'est donc pas « lequel est le plus petit » mais « à périmètre fonctionnel égal, lequel est le plus petit ». La réponse dépend alors de votre périmètre.

Ce que FreeRTOS ne fournit pas

FreeRTOS donne des tâches, des sémaphores, des files, des mutex à héritage de priorité, des minuteries logicielles et des groupes d'événements. C'est complet, éprouvé, et cela s'arrête là.

Il ne fournit ni modèle de pilote, ni couche d'abstraction matérielle, ni pile réseau, ni système de fichiers, ni gestion d'énergie, ni mécanisme de configuration. Tout cela vient du fabricant du microcontrôleur, sous forme d'un SDK propre à lui.

La conséquence pratique est le verrouillage : votre code applicatif appelle des fonctions HAL du fabricant. Changer de silicium veut dire réécrire cette couche. Sur un produit dont l'approvisionnement peut se tendre, c'est un risque industriel réel.

Ce que Zephyr apporte, et ce qu'il impose

Zephyr fournit un modèle de pilote unifié. Un capteur de température s'utilise avec la même API qu'il soit en I2C, SPI ou intégré au SoC. Changer de microcontrôleur revient, dans le cas favorable, à changer un fichier de carte.

Il apporte aussi une pile réseau complète avec IPv6, Bluetooth LE, Thread et CAN, un système de fichiers, la gestion d'énergie, un système de journalisation, un shell embarqué et un cadre de tests.

Le prix à payer est réel. La courbe d'apprentissage est raide : il faut comprendre le devicetree, Kconfig, l'outil west et le modèle de modules avant d'être productif. Comptez deux à quatre semaines pour un développeur expérimenté, contre deux à trois jours pour FreeRTOS.

Et la configuration se fait par deux mécanismes distincts qu'il faut cesser de confondre : le devicetree décrit le matériel, Kconfig active les fonctionnalités logicielles. Un périphérique présent dans le devicetree mais dont le pilote n'est pas activé en Kconfig n'existera pas, et inversement.

Le facteur décisif : la sécurité et la conformité

C'est le point qui a le plus changé ces trois dernières années, et il pèse davantage que l'empreinte mémoire.

Zephyr est un projet de la Linux Foundation doté d'un processus de divulgation coordonnée écrit et public. Sa documentation prévoit qu'un problème considéré comme une vulnérabilité se voit attribuer un numéro CVE, et fixe un embargo de 90 jours au plus, décomposé en 30 jours pour corriger dans le projet et 60 jours pour que les industriels qui l'utilisent déploient le correctif. Le projet publie aussi des versions de support à long terme et intègre la génération de SBOM à son outil de construction.

Sur les certifications, soyez prudent avec ce qu'on lit : les travaux de sûreté fonctionnelle et les certifications de sécurité portent sur des configurations et des versions précises, pas sur « Zephyr » en général. Vérifiez toujours le périmètre exact d'un certificat avant de vous appuyer dessus dans un dossier.

FreeRTOS est maintenu par Amazon, avec des versions à support long terme et une variante certifiée, SafeRTOS, pour les usages soumis à des normes de sûreté. Mais la couverture ne s'étend qu'à l'ordonnanceur : les pilotes et la pile réseau que vous ajoutez restent votre responsabilité, y compris leur veille CVE.

Avec le Cyber Resilience Act, cette différence devient structurante. Un système qui produit son propre SBOM et publie ses CVE par module réduit une charge de conformité que vous porterez sinon vous-même, pendant au moins cinq ans.

Le tableau de décision

CritèreFreeRTOSZephyr
Prise en main2 à 3 jours2 à 4 semaines
Empreinte minimaleplus faibleplus élevée
Empreinte à périmètre égalcomparablecomparable
Portabilité entre siliciumfaible, dépend du SDKforte, modèle de pilote unifié
Pile réseau, système de fichiersà ajouterinclus
Gouvernance sécuritéordonnanceur seulprocessus public, CVE et embargo 90 jours
SBOMoutil externeintégré
Recrutementvivier très largevivier plus étroit

Comment trancher

Prenez FreeRTOS si le produit est simple et à fonction fixe, si l'empreinte est vraiment contrainte, si l'équipe doit livrer vite sans temps d'apprentissage, ou si le SDK du fabricant couvre déjà tout votre besoin.

Prenez Zephyr si le produit est une gamme sur plusieurs silicium, s'il est connecté et soumis au CRA, si vous avez besoin de Bluetooth ou de Thread, ou si sa durée de vie dépasse cinq ans.

Le piège le plus coûteux consiste à choisir FreeRTOS pour la rapidité de démarrage, puis à reconstruire pendant trois ans une couche d'abstraction, une pile réseau et un processus de gestion des vulnérabilités. C'est exactement ce que Zephyr fournissait, et l'avoir écrit soi-même ne rend pas la conformité plus simple.

Références

Pour aller plus loin

Ce choix se clarifie une fois qu'on a écrit la même application sur les deux, et mesuré ce que chacun exige avant la première ligne utile. C'est ce que couvrent nos formations à la programmation temps réel avec FreeRTOS et avec Zephyr RTOS.