Du bare-metal aux systèmes d'exploitation : pourquoi j'ai recentré mon développement embarqué

Retour sur l'« âge du bare-metal »

Ma première rencontre avec le logiciel embarqué remonte à 2008, lorsque j'étais étudiant de deuxième année apprenant à programmer sur une puce 8051. Avec un diplôme en informatique, la plupart de mon code s'exécutait sur PC, donc voir un programme s'exécuter directement sur une carte bare-metal a été une révélation passionnante. Je me souviens encore du moment où mon premier firmware de lampe clignotante s'est mis en marche et a fonctionné parfaitement. Pourtant, plus je m'attaquais à des projets bare-metal, plus les défis surgissaient.

Principaux points de douleur du développement bare-metal

Concurrence

Dans le firmware bare-metal, une seule boucle while (1) contient généralement presque toute la logique transactionnelle. Lorsqu'une routine appelle une fonction de délai, le CPU reste bloqué dans ce délai, forçant toutes les autres tâches à attendre. Cette exécution en série gaspille les cycles CPU et limite sévèrement la concurrence.

Modularité

La cohésion élevée et le faible couplage sont difficiles à atteindre lorsque chaque fonction vit dans cette boucle monolithique. Les dépendances sont étroites, et le résultat est un code difficile à refactoriser ou à étendre pour des projets plus importants. Par exemple :

• Les fonctions sont entassées dans la boucle infinie, rendant des frontières de modules claires impossibles.
• L'utilisation de fonctions de délai près d'un watchdog timer nécessite un timing précis ; un délai mal calculé peut déclencher une réinitialisation du watchdog, ajoutant une couche de complexité supplémentaire.

Contraintes de l'écosystème

De nombreux composants logiciels avancés reposent sur un OS de niveau inférieur. Quelques exemples :

• J'ai construit un projet open-source autour de FreeModbus et visais à le porter sur diverses plateformes, y compris des cartes bare-metal. Cependant, l'implémentation de toutes les fonctions requises sur chaque carte from scratch s'est avérée trop complexe ; ma pile Modbus ne peut actuellement pas fonctionner sur des systèmes bare-metal.
• Les SDK majeurs de Realtek, TI et MediaTek ne fonctionnent que sur un OS et n'exposent pas le code source du firmware, empêchant leur utilisation dans un environnement purement bare-metal.

Exigences temps réel

Les systèmes de contrôle industriels exigent un timing précis : les actionneurs mécaniques doivent suivre une séquence stricte. Lorsque toute la logique est compressée dans une seule boucle, garantir un comportement temps réel devient quasi impossible, risquant des défaillances système et des dangers pour la sécurité.

Réutilisabilité

Parce que la fonctionnalité est si étroitement couplée au matériel spécifique, le même code doit être réécrit pour chaque nouvelle plateforme. Cela entraîne des efforts dupliqués et ralentit le développement de produits.

Les avantages des systèmes d'exploitation

Dès 2010, les MCU STM32 gagnaient en popularité, et j'ai commencé à expérimenter avec RT-Thread. Au cours de la dernière décennie, j'ai utilisé RT-Thread intensivement et j'ai constaté qu'il transforme le développement embarqué.

Modularité

Un RTOS divise le firmware en threads indépendants, chacun avec son propre contexte d'exécution. Cette séparation améliore naturellement la modularité et simplifie la maintenance.

Concurrence

Lorsqu'un thread appelle sleep() ou cède la main, l'ordonnanceur passe automatiquement le contrôle aux autres threads prêts, améliorant l'utilisation du CPU et la concurrence globale du système.

Garanties temps réel

Les RTOS offrent un ordonnancement déterministe : les tâches ont des priorités, et le noyau assure que les tâches de priorité supérieure préemptent les tâches de priorité inférieure. Ce comportement temps réel intégré est critique pour les applications critiques pour la sécurité.

Efficacité de développement

L'OS fournit un ensemble unifié d'API — sémaphores, drapeaux d'événements, boîtes aux lettres, tampons circulaires, listes chaînées, et plus — permettant aux développeurs de se concentrer sur la logique applicative plutôt que sur la plomberie de bas niveau.

Écosystème logiciel

Linux et RT-Thread implémentent tous deux un framework de pilotes de périphériques qui abstrait les détails matériels. Les ingénieurs peuvent écrire un pilote une fois et le déployer sur de nombreuses cartes, réduisant drastiquement le code spécifique à la plateforme. Cet écosystème encourage également le partage : je publie régulièrement des composants open-source sur GitHub, et des pairs du monde entier contribuent en retour, favorisant une communauté collaborative dynamique.

Conclusion

La transition du bare-metal vers un RTOS a élargi ma capacité à écrire du code modulaire, concurrent et sûr temps réel. Elle a également débloqué un écosystème plus riche où les composants réutilisables prospèrent, et où les développeurs peuvent collaborer au-delà des frontières matérielles.