Die native Zephyr-Simulation ermöglicht es dem CoffeeCaller-Team, große Teile der eingebetteten Anwendung auf einem gewöhnlichen Hostcomputer zu erstellen und zu testen, ohne das Zielboard ständig neu flashen zu müssen. Der Workflow steht hinter dem Open-Hardware-Projekt CoffeeCaller nRF52840 Board – einem Kaffeepausen-Koordinator, der sich zu einer Entwicklungsplattform mit Tasten, Anzeige-LEDs, WS2812-RGB-LEDs, einem Summer, Sensoren und Stiftleisten weiterentwickelt hat.

Native Zephyr-Simulation ohne das Zielboard

In diesem Elektor-Videoclip erklärt Hardware-Entwickler Andreas Kurz, wie Software-Entwickler Stefan Kraus die Anwendung so strukturiert hat, dass sie für Zephyrs native_sim-Board kompiliert und auf dem Entwicklungs-PC ausgeführt werden kann. Statt nach jeder Änderung auf das physische Board warten zu müssen, kann das Team die Anwendungslogik schnell auf dem Host testen und nur noch periodisch zur nRF52840-Hardware wechseln, um die Ergebnisse zu bestätigen.

Der native Simulator von Zephyr emuliert den nRF52840 nicht. Er baut den Zephyr-Kernel, die Bibliotheken und die Anwendung als normales Linux-Executable. Dieser Unterschied ist entscheidend: Das Verfahren eignet sich am besten für Software, die sauber von hardwarespezifischem Verhalten getrennt ist – genau das, was die CoffeeCaller-Architektur anstrebt.

Mock-Treiber halten die Anwendung testbar

An einem Host-PC ist kein WS2812-LED-Streifen angeschlossen. Kraus hat daher einen Mock-LED-Streifen-Treiber geschrieben, der dieselbe API implementiert, die die Anwendung erwartet. Tests können eine virtuelle Taste drücken, gelbe LEDs anfordern und prüfen, ob die über die Schnittstelle gesendeten Bytes in der richtigen Reihenfolge ankommen. Der Mock kann weder Signaltiming noch elektrisches Verhalten nachweisen, aber er erkennt Fehler in Zustandsautomaten, der API und der Datenreihenfolge, bevor das Zielboard überhaupt ins Spiel kommt.

Das öffentliche CoffeeCaller-Software-Repository unterstützt den Build sowohl für native_sim als auch für das angepasste Board und enthält Tests auf mehreren Ebenen. Das macht das Projekt zu mehr als einer Demonstration eines RTOS-Features: Es ist ein praxisnahes Beispiel dafür, wie man Firmware um austauschbare Subsysteme herum entwirft, anstatt jeden Anwendungsbestandteil direkt auf physische Peripheriegeräte zugreifen zu lassen.

Agile Hardware bedeutet, Wartezeiten zu reduzieren

Dieselbe Trennung unterstützt das übergeordnete Ziel des Teams, Hardware-Entwicklung weniger zum Stop-and-go-Prozess zu machen. Hardware-Revisionen können Monate dauern, während Software-Teams trotzdem vorankommen müssen. Mit simulierten Targets, Mock-Treibern, modularen Subsystemen und Stiftleisten für zusätzliche Peripheriegeräte kann die Softwarearbeit weiterlaufen, während die nächste PCB-Revision noch entworfen oder gefertigt wird.

Zephyr Safety Architect Tobias Kästner brachte zusätzliche Ideen rund um agile Hardware-Workflows ein und half dabei, aus einem kleinen Bürogadget einen gemeinsamen Entwicklungs-Playground zu machen. Die praktische Erkenntnis lautet nicht, dass echte Hardware optional ist. Vielmehr sollten Ingenieure die Hardware-Zeit für Fehler reservieren, die nur Hardware aufdecken kann – statt das Board als teuren Ersatz für gewöhnliche Softwaretests zu nutzen. Die native Zephyr-Simulation gibt CoffeeCaller eine schnellere Feedback-Schleife, und das Projekt zeigt, wie das aussieht, wenn die Architektur von Anfang an darauf ausgelegt ist.

Abonnieren
Tag-Benachrichtigung: Abonnieren Sie das Tag Elektor Engineering Insights und erhalten Sie eine E-Mail, sobald ein neuer Beitrag dazu auf unserer Website erscheint.