Suchen

Auswahl und Einsatz eines Embedded-Betriebssystems für Mikrocontroller

Seite: 2/2

Firmen zum Thema

Der Auswahlprozess für ein geeignetes Embedded-Betriebssystem

Für den Auswahlprozess sollte man sich auf einige wenige aussichtsreiche Kandidaten begrenzen. Als Hilfe zur Vorauswahl können neben (leider oft veralteten) Listen aus dem Internet und Informationen der Anbieter z.B. auch Erfahrungen von beteiligten Entwicklern dienen.

Der Auswahlprozess selbst ist nicht so trivial, wie man glauben könnte, weshalb es gut ist so wenige Alternativen wie möglich zu sichten. Es empfiehlt sich maximal fünf Bewerber aufzunehmen.

Anders als vermutet besteht der Prozess nicht einfach aus dem Ankreuzen von Features, sondern vorrangig aus Recherche in vorhandener Dokumentation, im Internet und Anfragen an den Support. Ob das in der Hitliste genannte Feature XY tatsächlich das geforderte X und Y zusammen ist oder ob der Hersteller darunter nur eine Teilmenge versteht ist oft nur schwer nachvollziehbar und muss aufwändig recherchiert werden.

Für den Auswahlprozess sollte eine vernünftige Deadline vorgegeben werden. Man kann sich bei der Analyse von Features schnell verzetteln. Auch empfiehlt es sich als Antworten neben „Ja“ und „Nein“ auch „sehr wahrscheinlich“ oder „zu XX Prozent“ zuzulassen um Zeit zu sparen.

Hat man die Bewertungsmatrix annähernd vollständig, so kommen abhängig von der Beantwortung der Feature-Fragen noch weitere Größen hinzu:

  • Welcher Aufwand entsteht durch eine unzureichende / nicht vorhandene Unterstützung eines Features.
  • Welches Risiko birgt die Unsicherheit, ob ein Feature (nur teilweise) unterstützt wird?
  • Welches Risiko birgt ein fehlender Support bzw. eine fehlende oder nur sehr kleine Community?

Nach einem mehrwöchigen Auswahlverfahren in dem viele Aspekte nicht nur per Dokumentation und Supportanfragen, sondern auch per Tests evaluiert werden mussten entschied sich das Projekt für das Open Source Betriebssystem NuttX.

Bei NuttX handelt es sich um ein Echtzeit-Betriebssystem mit einer POSIX-kompatiblen Treiber- und Schnittstellenarchitektur unter BSD-Lizenz. Es wurde erstmals 2007 von Gregory Nutt veröffentlicht und wird seither aktiv unter seiner Führung weiterentwickelt. Da NuttX unter BSD-Lizenz steht muss kein Nutzer (außer in seinem Handbuch) bekannt geben, dass er NuttX nutzt. So war es lange Zeit sehr still um das System.

Wenige Veröffentlichungen verwiesen auf das System, wie z.B. das Open-Hardware-Projekt PX4 - eine (Quadrocoper-) Autopilot-Hardware in Zusammenarbeit mit der ETH Zürich.

Die Anzahl der unterstützten Prozessortypen aber zeigt, dass sehr wohl viel mehr Interesse bestand als die öffentliche Wahrnehmung vermuten ließ. Aktuell umfasst diese Liste von ARM bis ZiLOG Z80 über 150 Prozessorfamilien. Zuzüglich einer Linux/Cygwin Simulationsplattform.

Die Entscheidung für NuttX fiel im Projekt denkbar knapp, da zum damaligen Zeitpunkt noch nicht alle vom Projekt benötigten Funktionen und Features integriert waren. Mittlerweile sind sie es – durch Upstreaming der Sourcecodes. Mittlerweile bekennen sich zahlreiche Firmen öffentlich dazu, NuttX einzusetzen.

Support und Extra-Features

Dies mag kein entscheidender Faktor sein, aber im vorliegenden Fall haben einige nette Extras bei der Entscheidung für die Wahl des Betriebssystems geholfen. NuttX bietet neben vielen „normalen“ Features aber auch Highlights, welche es aus der Masse der embedded Systeme hervorstechen lassen.

C++11 Support

Während der rudimentäre C++-Support bereits seit mehreren Jahren über die µClibC++ gegeben war wurde 2016 die C++11 kompatible „libc++“ aus dem LLVM Projekt integriert.

„Ist wie Linux“

Die Programmierung von NuttX unterscheidet sich kaum von der von Linux. Von „pthreads“ über „everything is a file“ innerhalb eines virtuellen Dateisystems bis zu einer Shell, welche über die serielle Schnittstelle erreichbar ist.

Diagnosebefehle wie „free“ oder „ps“ können gleichermaßen aktiviert werden wie „dd“ oder „hexdump“.

Das bedeutet, dass der Einarbeitungsaufwand für Programmierer von (normalerweise größeren) embedded Linux Systemen sehr gering ist. Auch können bestehende Sourcecodes von eigenen Funktionsbibliotheken fast nahtlos nach NuttX übernommen werden.

Tickless Scheduler

Standard-Scheduler nutzen den zyklischen Takt eines Timer-Bausteins um ihre Scheduler-Abarbeitung zu bedienen. Dabei wird bei jedem Tick eine Funktion angesprungen, welche die Verwaltung der Tasks erledigt. Dadurch tritt ab einer bestimmten Frequenz (Tick-Geschwindigkeit) eine sehr hohe Interruptlast auf, welche gerade embedded Systeme stark beeinträchtigt. NuttX bietet hier das Feature „Tickless Scheduler“, bei welchem der Scheduler errechnet, wann er die nächste Aktion ausführen muss und programmiert den Timer-Baustein (quasi als dynamischen Wecker) auf diesen Zeitpunkt. Dadurch sind höhere Genauigkeiten bei niedriger Frequenz und damit niedriger Interruptlast möglich.

Dynamisches Composite USB Device

NuttX bietet nicht nur Host-USB-Treiber, sondern auch Device-USB an. Ein recht neues Feature ist das zur Laufzeit konfigurierbare Composite USB Device. Mit diesem ist es z.B. möglich innerhalb eines Composite-Devices zusätzliche serielle Schnittstellen für Maintenance-Mode oder Debugging zu aktivieren, welche in den Standardeinstellungen nicht aktiv sind.

Visual Studio mit VisualGDB als IDE

Da NuttX Open Source ist kann die Taskverwaltung komplett eingesehen werden. Konfigurierbare Debugger-Plugins können entsprechend die Taskstrukturen und Stackframes auslesen und ermöglichen so ein komfortables Debuggen.

Im Projekt kam ein Atmel Cortex-M7 Prozessor zum Einsatz. Die Anbindung an den Hardware-Debugger erfolgte über die SWD-Schnittstelle. Die Aufbereitung der Information wurde über ein Debugger-Plugin umgesetzt, sodass die Anzeige in Visual Studio vom Debuggen eines lokalen (Windows-)Prozesses nicht zu unterscheiden war.

Fazit

Die Auswahl eines Betriebssystems für einen Mikrocontroller ist ein aufwändiger Prozess und sollte nicht unterschätzt werden. Für Projekte, welche über Monate oder Jahre laufen ist es unabdingbar eine nicht unerhebliche Zeit in die Evaluation verschiedener Systeme zu investieren.

Der Autor

Der Autor: Frank Benkert, FRB Computersysteme GmbH.
Der Autor: Frank Benkert, FRB Computersysteme GmbH.
(Bild: FRB Computersysteme GmbH)

* Frank Benkert ist seit 1992 als Systementwickler tätig. Sein Werdegang begann mit der Steuerung von Sondermaschinen; damals noch unter div. DOS-Derivaten. Für Automobilzulieferer entwickelte er embedded Datenbanken für Navigationssysteme. Seit über zehn Jahren ist er Software-Architekt für Steuerungen und Steuerungskomponenten im Großmotoren-Bau. Sein Schwerpunkt liegt auf Hardwarenähe und Implementierung von Betriebssystemen und -treibern.

(ID:45416846)