La simulation native Zephyr accélère le développement du CoffeeCaller

La simulation native Zephyr permet à l'équipe CoffeeCaller de concevoir et de tester une grande partie de son application embarquée sur un ordinateur hôte ordinaire, sans devoir flasher la carte cible à chaque modification. Ce flux de travail s'appuie sur la carte open hardware CoffeeCaller nRF52840, un coordinateur de pauses-café devenu une véritable plateforme de développement équipée de boutons, de LED indicatrices, de LED RGB WS2812, d'un buzzer, de capteurs et de connecteurs d'extension.

La simulation native Zephyr sans la carte cible

Dans cette vidéo d'Elektor, le développeur matériel Andreas Kurz explique comment le développeur logiciel Stefan Kraus a structuré l'application pour qu'elle puisse être compilée pour la carte native_sim de Zephyr et exécutée directement sur le PC de développement. Au lieu d'utiliser la carte physique après chaque modification, l'équipe peut tester rapidement la logique applicative sur l'hôte, puis valider régulièrement son fonctionnement sur le matériel nRF52840.

Le simulateur natif de Zephyr n'émule pas le nRF52840 lui-même. Il compile le noyau Zephyr, les bibliothèques et l'application sous la forme d'un exécutable Linux classique. Cette distinction est importante : l'outil convient particulièrement aux logiciels dont le code est clairement séparé du matériel, ce qui correspond précisément à l'architecture retenue pour CoffeeCaller.

Des pilotes simulés pour maintenir la testabilité de l'application

Un PC hôte ne dispose pas d'une bande de LED WS2812. Kraus a donc développé un pilote simulé de bande LED qui implémente la même API que celle utilisée par l'application. Les tests peuvent simuler l'appui sur un bouton virtuel, demander l'allumage de LED jaunes et vérifier que les octets transmis via l'interface apparaissent dans le bon ordre. Ce pilote simulé ne peut pas valider le timing des signaux ni le comportement électrique, mais il permet de détecter les erreurs de machine à états, d'API et d'ordonnancement des données avant même d'utiliser la carte cible.

Le dépôt logiciel public de CoffeeCaller prend en charge la compilation aussi bien pour native_sim que pour la carte personnalisée et comprend plusieurs niveaux de tests. Le projet va donc au-delà d'une simple démonstration des capacités du RTOS : il montre concrètement comment concevoir un firmware autour de sous-systèmes interchangeables, plutôt que de laisser chaque composant applicatif accéder directement aux périphériques matériels.

Un développement matériel agile pour réduire les délais

Cette même séparation soutient l'objectif plus large de l'équipe : rendre le développement matériel moins dépendant des interruptions. Les révisions matérielles peuvent prendre des mois, tandis que les équipes logicielles doivent continuer à avancer. Grâce aux cibles et pilotes simulés, aux sous-systèmes modulaires et aux connecteurs d'extension destinés à l'ajout de périphériques, le développement logiciel peut se poursuivre pendant que la révision suivante du PCB est en cours de conception ou de fabrication.

Tobias Kästner, architecte sécurité Zephyr, a également apporté des idées sur les méthodes de développement matériel agile, contribuant à faire évoluer ce qui n'était au départ qu'un simple gadget de bureau vers une plateforme de développement partagée. La leçon à retenir n'est pas que le matériel réel est facultatif. Les ingénieurs doivent plutôt réserver les essais sur le matériel aux défauts que lui seul peut révéler, au lieu d'utiliser la carte comme substitut coûteux aux tests logiciels classiques. La simulation native de Zephyr offre ainsi à CoffeeCaller une boucle de rétroaction plus rapide, et le projet montre concrètement les bénéfices d'une architecture conçue dans cette optique dès le départ.