Autor: Frank Benkert, FRB Computersysteme GmbH<\/p>\n
Entwicklungsprojekte f\u00fcr neue embedded Produkte sehen sich zu Beginn meist mit der immer gleichen, grundlegenden Frage konfrontiert:\u00a0<\/strong>\u00a0Mit oder ohne Betriebssystem?\u00a0<\/strong>Wenn ohne, wie dann?\u00a0<\/strong>Wenn mit, welches? Es gibt f\u00fcr diese Frage nat\u00fcrlich keine allgemeing\u00fcltige Antwort. Betrachtet man jedoch die Anforderungen an das neue Produkt genauer, so ergibt sich die Antwort oft von selbst. Welche Fakten helfen aber wirklich bei der Entscheidung? Wie erarbeitet man diese Informationen? Welche Fragen muss man stellen? Wer kann diese beantworten? Im Folgenden soll anhand eines Projektes aus der Praxis aufgezeigt werden, wie dieser Auswahlprozess und die sp\u00e4tere Integration erfolgreich gelingen kann.<\/strong><\/p>\n Als Vorlage f\u00fcr die Ausf\u00fchrungen unten dient ein reales Projekt, welches die Neuentwicklung einer Ger\u00e4tefamilie zur Steuerung von Gro\u00dfmotoren zum Ziel hatte. Das Projekt kam nach fast zwei Jahren Entwicklungszeit vor wenigen Monaten zu einem erfolgreichen Abschluss (innerhalb des geplanten Budgets). Einige Auspr\u00e4gungen der Ger\u00e4te laufen bereits produktiv, andere befinden sich noch in Zertifizierungs- bzw. Zulassungsverfahren.<\/p>\n Als Plattform kam ein Arm Cortex-M7 von ATMEL (automotive Variante) zum Einsatz. Dieses Dokument soll als allgemeine Grundlage dienen, weshalb die Formulierungen (wo immer m\u00f6glich) sich nicht direkt auf das Projekt beziehen. Direkte Bez\u00fcge auf das geschilderte Entwicklungsprojekt sind in kursiver Schrift.<\/p>\n Um die Frage nach dem „Mit oder Ohne“ \u00fcberhaupt stellen zu k\u00f6nnen, muss klar sein, was die einzelnen Beteiligten unter dem Begriff Betriebssystem verstehen.<\/p>\n Je tiefer ein Entwickler im System arbeitet, desto differenzierter ist seine Sicht auf das „Ding“ zwischen Hardware und Applikation. Unabh\u00e4ngig davon, auf welche Definition man sich letztendlich einigt, ist es \u00e4u\u00dferst wichtig, das gleiche Verst\u00e4ndnis von diesem Begriff zu haben.<\/p>\n Im Projekt einigte man sich auf die Formulierung: „Ein Betriebssystem besteht aus einem Task-Scheduler mit angebundener Treiberarchitektur“. Dabei war die Gr\u00f6\u00dfe oder Vollst\u00e4ndigkeit der „Treiberarchitektur“ nicht ausschlaggebend.<\/em><\/p>\n Die Beantwortung dieser Frage ist viel einfacher als viele meinen. Als Entscheidungsgrundlage dienen nur wenige\u00a0 wichtige Punkte:<\/p>\n Sollte mindestens eine dieser Fragen mit „Ja“ beantworten werden, so ist man gut beraten, zumindest schon mal einen Scheduler einzusetzen.<\/p>\n Die Frage nach aktiv oder reaktiv weist in die Richtung von Interrupts. Ein rein reaktives System kann z.B. mit mehreren Interrupt-Routinen ebenfalls mehr als einen\u00a0 Ausf\u00fchrungsstrang besitzen. Diese sind dann allerdings (normalerweise) sequentiell. Eine Ausnahme bilden Systeme mit „Interrupt-Priorit\u00e4ten“ und „Nested-Interrupts“. Eine solche Technik kann man bereits als Pseudo-Scheduler bezeichnen.<\/p>\n Sollte man sich trotz eines „Ja“ gegen einen Scheduler entscheiden, so wird das Projekt mit absoluter Sicherheit neben dem eigentlichen Produkt zus\u00e4tzlich einen Scheduler als Output liefern.<\/p>\n Um die Frage nach der Notwendigkeit einer Treiberarchitektur zu beantworten, gibt es hingegen tats\u00e4chlich nur einen einzigen Punkt:<\/p>\n Ein „Ja“ bedeutet, dass mindestens ein Treiber ben\u00f6tigt wird. Zusammen mit der Antwort auf die Frage nach dem Scheduler l\u00e4sst sich nun sehr leicht die grundlegendste Frage nach dem „Mit oder Ohne“ beantworten.<\/p>\n Das Projekt entschied sich f\u00fcr das „Mit“.<\/em><\/p>\n Um sp\u00e4ter eine Auswahl zwischen den hunderten am Markt vertretenen Betriebssystemen treffen zu k\u00f6nnen, ist es wichtig, die Anforderungen in einer Art Matrix zusammenzutragen. Die folgende Liste soll einen Einstieg in die Fragestellung geben. Je nach Produkt muss diese nat\u00fcrlich erweitert, ver\u00e4ndert oder gek\u00fcrzt werden.<\/p>\n Wird der Prozessor-Kern unterst\u00fctzt?<\/strong><\/p>\n Prozessoren unterst\u00fctzen Betriebssysteme mittlerweile mit einer Vielzahl von integrierten Funktionen. Was fr\u00fcher im Scheduler von Hand implementiert werden musste, wird heute \u00fcber wenige Assemblerbefehle direkt vom Prozessor erledigt. Von Automatismen zur Taskumschaltung \u00fcber Stackmanagement bis hin zur Pr\u00fcfung von Berechtigungen sind viele Funktionen mittlerweile in die Prozessoren integriert. Daf\u00fcr ist es jedoch notwendig, dass der Kern des Scheduler diese Besonderheiten kennt und ansteuert. Nur so ist es m\u00f6glich, die optimale Leistung aus dem Prozessor zu holen.<\/p>\n Unterst\u00fctzt der Scheduler die notwendigen Scheduler-Strategien?<\/strong><\/p>\n Aus der Entwicklung von embedded Produkten quasi nicht mehr wegzudenken ist ein Echtzeit-Scheduler. Dieser hat daf\u00fcr zu sorgen, dass Deadlines eingehalten werden und die Vorhersagbarkeit gew\u00e4hrleistet bleibt. F\u00fcr dessen Umsetzung ist zun\u00e4chst lediglich eine strikt priorit\u00e4tsgetriebene Umsetzung ausreichend. Doch was ist, wenn mehrere Tasks auf der gleichen Priorit\u00e4t arbeiten m\u00fcssen? Welche von diesen wird dann bevorzugt?<\/p>\n Hierf\u00fcr gibt es zus\u00e4tzliche Strategien wie „Round Robin“ oder „First In, First Out“. Auch sind Scheduler erh\u00e4ltlich, welche Fairness auf die eine oder andere Art garantieren. Allerdings werden diese nur selten in embedded Systemen gefordert.<\/p>\n Welche Granularit\u00e4t muss der Scheduler bieten?<\/strong><\/p>\n Ein embedded System muss teilweise im Mikrosekunden-Raster Entscheidungen treffen oder Aktionen triggern k\u00f6nnen. Abh\u00e4ngig von der angestrebten Systemarchitektur ist es wichtig zu fragen, ob z.B. eine externe Nachricht alle 2 Millisekunden verarbeitet werden kann oder ein Aktorwert innerhalb einer Deadline von 300 Mikrosekunden neu beschrieben wird. Hat man dann einen Scheduler mit festem 20ms Raster, so ist das zwar schnell, aber unbrauchbar.<\/p>\n Werden Synchronisation und Signalisierung unterst\u00fctzt?<\/strong><\/p>\n Sobald mehrere Tasks innerhalb eines Systems laufen, bleibt es nicht aus, dass diese sich Ressourcen teilen m\u00fcssen. Um den Zugriff auf diese Ressourcen zu synchronisieren sind atomare Mechanismen erforderlich. \u00dcblicherweise sind diese in Form von „Counting Semaphores“ abgebildet, auf denen wiederum verschiedene andere Synchronisationsmechanismen aufgebaut werden k\u00f6nnen.<\/p>\n Ben\u00f6tigt das Projekt Interprozess-Kommunikation (IPC)?<\/strong><\/p>\n Werden Informationen in mehreren Tasks verarbeitet, so kann es notwendig werden, Nachrichten zwischen den Systemteilen auszutauschen. Dies kann z.B. \u00fcber Pipes oder Queues geschehen. Sofern das Produkt diese Problemstellung aufweist, sollte ein Betriebssystemkandidat auch gegen diese Anforderung gepr\u00fcft werden.<\/p>\n Beinhaltet das System Unterst\u00fctzung f\u00fcr MMUs?<\/strong><\/p>\n Immer mehr embedded Systeme sind mit Memory Management Units (MMUs) ausgestattet. Je nach Gr\u00f6\u00dfe des Systems bergen diese MMUs unterschiedlich viele Funktionen – vom einfachen Cache-Management (welcher Speicherbereich wird durch den CPU-Cache abgebildet?) \u00fcber Zugriffsteuerung bis hin zu komplexen Mappingaufgaben innerhalb eines virtuellen Adressraums. Je nach Anforderung des Produktes und Gegebenheiten der Hardware stellt dies eine hilfreiche Funktion des Betriebssystems dar.<\/p>\n Beinhaltet das System Unterst\u00fctzung f\u00fcr Speichermanagement?<\/strong><\/p>\n Die Standard-Schnittstellen zur dynamischen Speicherallokation sind jedem Programmierer gut bekannt: „malloc“ und „free“. Hinter diesem sehr einfachen Interface verbergen sich jedoch komplexe Strategien, um z.B. eine Fragmentierung des Speichers zu reduzieren. Falls das Produkt eine solche Funktion ben\u00f6tigt, ist es wichtig, im Betriebssystem bereits erprobte und getestete Mechanismen hierf\u00fcr vorzufinden.<\/p>\n Unterst\u00fctzung f\u00fcr Peripherie und Schnittstellen<\/strong><\/p>\n Auch wenn die Anbindung von Peripherie oft als Referenzimplementation bereits durch die Hersteller zur Verf\u00fcgung gestellt wird, so spart es dennoch viel Arbeit, wenn ein \u00e4hnlicher Baustein oder die geforderte Schnittstelle bereits als fertiger Treiber f\u00fcr genau dieses Betriebssystem existiert. Bevorzugt nat\u00fcrlich bereits fertig „abgehangen“ und getestet, zumindest aber mit einem Satz von Testfunktionen, welche auf der eigenen Hardware abgearbeitet werden k\u00f6nnen.<\/p>\n Unters\u00fctzung IDE und Debugging<\/strong><\/p>\n Ob ein Betriebssystem mit seiner eigenen „full featured IDE“ geliefert wird, in die bereits der Compiler integriert ist, oder ob man die Komponenten selbst zusammenstellen kann, ist unerheblich. Wichtig bei der Bewertung dieses Punktes ist, dass ein geschlossener Kreislauf vom Programmieren in einem komfortablen Editor \u00fcber die Kompilation und das Aufbringen des Kompilats auf das Target bis hin zum Debuggen auf Zeilenebene m\u00f6glich ist. Letzteres l\u00e4sst sich nat\u00fcrlich bei manchen Produkten nur durch Emulatoren erreichen. Diese M\u00f6glichkeiten sollten im Zweifel getestet werden, bevor man sich f\u00fcr eine L\u00f6sung entscheidet.<\/p>\n Liegt der Quellcode des Betriebssystems vor?<\/strong><\/p>\n Auf embedded Systemen ist die Verzahnung zwischen Applikation, Treibern und Scheduler naturgem\u00e4\u00df sehr eng. Das bedingt oft, dass w\u00e4hrend des Debuggings fremde Funktionen des besseren Verst\u00e4ndnisses wegen durchlaufen werden wollen. Viele kommerziellen Anbieter gew\u00e4hren deshalb unter bestimmten vertraglichen Bedingungen einen begrenzten Einblick in ihre Sourcecodes, um dieses Vorgehen zu unterst\u00fctzen. Bei Open-Source-Systemen stellt sich diese Frage naturgem\u00e4\u00df nicht.<\/p>\n Welcher Lizenz unterliegt das Betriebssystem?<\/strong><\/p>\n Eine Frage, die nicht nur die Techniker, sondern auch die Produktverantwortlichen umtreibt. So viele Lizenzmodelle es in der Open-Source-Welt gibt, so viele gibt es auch in der Welt der kommerziellen Produkte. Was welche Lizenz genau bedeutet, muss am jeweiligen Produkt detailliert gepr\u00fcft werden. Z.B. ist eine kommerzielle Lizenz pro Entwicklungsstandort bei verteilten Teams ebenso sch\u00e4dlich wie eine Lizenz, welche die Nennung des Autors im Handbuch bei einem Produkt ohne Kundendokumentation verlangt.<\/p>\n Support und Community<\/strong><\/p>\n Oft vernachl\u00e4ssigt, aber trotzdem wichtig ist die Frage nach der Community. Selbst der kommerzielle Support des Herstellers kann eine rege Diskussionsgruppe im Internet nur schwer ersetzen. Ein Ort, an dem unb\u00fcrokratisch Fragen beantwortet, Codeschnipsel gepostet oder Fehler gemeldet werden, ist oft mehr wert als ein Supportvertrag. Seit einiger Zeit gehen auch kommerzielle Anbieter dazu \u00fcber, Mailinglisten zu hosten, in denen sowohl Anwender als auch Supportmitarbeiter sich gegenseitig austauschen k\u00f6nnen.<\/p>\n Neben dieser allgemein gehaltenen Liste spielten im realen Projekt noch viele weitere Aspekte eine Rolle, z.B. die Unterst\u00fctzung f\u00fcr die Schnittstellen I2C, SPI, QSPI und USB, sowie Dateisysteme und Feldbusse. Weiterhin wurden in die Bewertung weiche Faktoren, wie Zukunftssicherheit, Lizenzrisiko, Testbarkeit und Einarbeitungsaufwand, mit einbezogen.<\/em><\/p>\n F\u00fcr den Auswahlprozess sollte man sich auf einige wenige aussichtsreiche Kandidaten begrenzen. Als Hilfe zur Vorauswahl k\u00f6nnen 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\u00f6nnte, weshalb es gut ist, so wenige Alternativen wie m\u00f6glich zu sichten. Es empfiehlt sich maximal f\u00fcnf Bewerber aufzunehmen.<\/p>\n Anders als vermutet besteht der Prozess nicht einfach aus dem Ankreuzen von Features, sondern vorrangig aus Recherche in vorhandener Dokumentation im Internet sowie Anfragen an den Support. Ob das in der Hitliste genannte Feature XY tats\u00e4chlich das geforderte X und Y zusammen ist oder ob der Hersteller darunter nur eine Teilmenge versteht, ist oft nur schwer nachvollziehbar und muss aufw\u00e4ndig recherchiert werden.<\/p>\n F\u00fcr den Auswahlprozess sollte eine vern\u00fcnftige 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.<\/p>\n Hat man die Bewertungsmatrix ann\u00e4hernd vollst\u00e4ndig, so kommen abh\u00e4ngig von der Beantwortung der Feature-Fragen noch weitere Gr\u00f6\u00dfen hinzu:<\/p>\n Nach einem mehrw\u00f6chigen Auswahlverfahren, in dem viele Aspekte nicht nur per Dokumentation und Supportanfragen, sondern auch per Tests evaluiert werden mussten, entschied sich das Projekt f\u00fcr das Open Source Betriebssystem NuttX [1].<\/em><\/p>\n Verk\u00fcrzt gesagt ist NuttX ein Echtzeit-Betriebssystem mit einer POSIX-kompatiblen Treiber- und Schnittstellenarchitektur unter BSD-Lizenz. Es wurde erstmals 2007 von Gregory Nutt ver\u00f6ffentlicht und wird seither aktiv unter seiner F\u00fchrung weiterentwickelt. Da NuttX unter BSD-Lizenz steht, muss kein Nutzer (au\u00dfer in seinem Handbuch) bekanntgeben, dass er NuttX nutzt. So war es lange Zeit sehr still um das System. Wenige Ver\u00f6ffentlichungen verwiesen auf das System, wie z.B. das Open-Hardware-Projekt PX4 [2] – eine (Quadrocoper-) Autopilot-Hardware in Zusammenarbeit mit der ETH Z\u00fcrich.<\/p>\n Die Anzahl der unterst\u00fctzten Prozessortypen aber zeigt, dass sehr wohl viel mehr Interesse bestand, als die \u00f6ffentliche Wahrnehmung vermuten lie\u00df. Aktuell umfasst diese Liste von ARM bis \u00a0ZiLOG Z80 \u00fcber 150 Prozessorfamilien. Zuz\u00fcglich einer Linux\/Cygwin Simulationsplattform.<\/p>\n Die Entscheidung f\u00fcr NuttX fiel im Projekt denkbar knapp, da zum damaligen Zeitpunkt noch nicht alle vom Projekt ben\u00f6tigten Funktionen und Features integriert waren. Mittlerweile sind sie es \u2013 durch Upstreaming der Sourcecodes.<\/em><\/p>\n Die Downloadzahlen [3] der NuttX-Homepage zeigen, dass Europa hinter China und USA nur an dritter Stelle rangiert. Auch das mag ein Grund daf\u00fcr sein, dass wir in Europa bisher noch so wenig von NuttX h\u00f6rten. In den letzten Jahren wurde das Interesse an NuttX jedoch immer gr\u00f6\u00dfer, was z.B. an der steigenden Beitragszahl auf der Mailingliste abzulesen ist. Weiterhin hat die erst in diesem Jahr gestartete LinkedIn-Gruppe mittlerweile \u00fcber 1000 User. Auch bekennen sich Firmen mittlerweile \u00f6ffentlich zu NuttX. Z.B. brachte Anfang des Jahres die Firma SONY eine Familie von Digital Voice Recordern (z.B. ICD-SX2000) auf den Markt und ver\u00f6ffentlichte ihre Weiterentwicklungen an NuttX in Zusammenhang mit diesen Produkten f\u00fcr die Reintegration in die Mainline unter ihrem Firmennamen.<\/p>\n Wir d\u00fcrfen gespannt sein, wie das Wachstum weiter geht.<\/p>\n NuttX bietet neben vielen „normalen“ Features aber auch Highlights, welche es aus der Masse der embedded Systeme hervorstechen lassen.<\/p>\n C++11 Support<\/strong><\/p>\n W\u00e4hrend der rudiment\u00e4re C++-Support bereits seit mehreren Jahren \u00fcber die \u00b5ClibC++ gegeben war, wurde 2016 die C++11 kompatible „libc++“ aus dem LLVM-Projekt integriert.<\/p>\n „Ist wie Linux“<\/strong><\/p>\n Die Programmierung von NuttX unterscheidet sich kaum von der von Linux – von „pthreads“ \u00fcber „everything is a file“ innerhalb eines virtuellen Dateisystems bis zu einer Shell, welche \u00fcber die serielle Schnittstelle erreichbar ist.<\/p>\n Diagnosebefehle wie „free“ oder „ps“ k\u00f6nnen gleicherma\u00dfen aktiviert werden wie „dd“ oder „hexdump“.<\/p>\n Das bedeutet, dass der Einarbeitungsaufwand f\u00fcr Programmierer von (normalerweise gr\u00f6\u00dferen) embedded Linux-Systemen sehr gering ist. Auch k\u00f6nnen bestehende Sourcecodes von eigenen Funktionsbibliotheken fast nahtlos nach NuttX \u00fcbernommen werden.<\/p>\n Tickless Scheduler<\/strong><\/p>\n 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\u00e4chtigt. NuttX bietet hier das Feature „Tickless Scheduler“, bei welchem der Scheduler errechnet, wann er die n\u00e4chste Aktion ausf\u00fchren muss, und programmiert den Timer-Baustein (quasi als dynamischen Wecker) auf diesen Zeitpunkt. Dadurch sind h\u00f6here Genauigkeiten bei niedriger Frequenz und damit niedriger Interruptlast m\u00f6glich.<\/p>\n Dynamisches Composite USB-Device<\/strong><\/p>\n 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\u00f6glich, innerhalb eines Composite-Devices zus\u00e4tzliche serielle Schnittstellen f\u00fcr Maintenance-Mode oder Debugging zu aktivieren, welche in den Standardeinstellungen nicht aktiv sind.<\/p>\n Visual Studio mit VisualGDB [4] als IDE<\/strong><\/p>\n Da NuttX Open Source ist kann die Taskverwaltung komplett eingesehen werden. Konfigurierbare Debugger-Plugins k\u00f6nnen entsprechend die Taskstrukturen und Stackframes auslesen und erm\u00f6glichen so ein komfortables Debuggen.<\/p>\n Im Projekt kam ein Atmel Cortex-M7 Prozessor zum Einsatz. Die Anbindung an den Hardware-Debugger erfolgte \u00fcber die SWD-Schnittstelle. Die Aufbereitung der Information wurde \u00fcber ein Debugger-Plugin umgesetzt, so dass die Anzeige in Visual Studio vom Debuggen eines lokalen (Windows-)Prozesses nicht zu unterscheiden war.<\/em><\/p>\n Die Auswahl eines Betriebssystems f\u00fcr einen Mikrocontroller ist ein aufw\u00e4ndiger Prozess und sollte nicht untersch\u00e4tzt werden. F\u00fcr Projekte, welche \u00fcber Monate oder Jahre laufen, ist es unabdingbar, eine nicht unerhebliche Zeit in die Evaluation verschiedener Systeme zu investieren.<\/p>\n R\u00fcckblickend war die Entscheidung des Entwicklungsprojektes\u00a0f\u00fcr NuttX\u00a0richtig, auch wenn (wie bereits ausgef\u00fchrt) die Faktenlage nicht ganz eindeutig war.<\/em><\/p>\n [1]\u00a0https:\/\/www.nuttx.org\/<\/a><\/p>\n [2]\u00a0https:\/\/pixhawk.org\/<\/a><\/p>\n [3] leider nur bis 2015 verf\u00fcgbar<\/p>\n [4]\u00a0https:\/\/visualgdb.com\/<\/a><\/p>\n Beitrag als PDF-Datei downloaden<\/strong><\/a><\/p>\n Wollen Sie sich auf den aktuellen Stand der Technik bringen?<\/strong><\/p>\n Dann informieren Sie sich\u00a0hier<\/strong>\u00a0<\/a>zu Schulungen\/ Seminaren\/ Trainings\/ Workshops und individuellen Coachings von MircoConsult zum Thema Embedded- und Echtzeit-Softwareentwicklung.<\/p>\n Training & Coaching zu den weiteren Themen unseren Portfolios finden Sie\u00a0hier<\/a>.<\/strong><\/p>\n Wertvolles Fachwissen zum Thema Embedded- und Echtzeit-Softwareentwicklung steht\u00a0hier<\/strong>\u00a0<\/a>f\u00fcr Sie zum kostenfreien Download bereit.<\/p>\nDas Projekt<\/h2>\n
Was ist ein Betriebssystem?<\/h2>\n
Mit oder ohne Betriebssystem<\/h2>\n
\n
\n
Anforderungen an das Betriebssystem<\/h2>\n
Auswahlprozess<\/h2>\n
\n
Was ist NuttX [1] – und warum diese Entscheidung?<\/h2>\n
Goodies<\/h2>\n
Fazit<\/h2>\n
Verweise<\/h2>\n
\nEchtzeit – MicroConsult Trainings & Coachings<\/h2>\n
\nEchtzeit – Fachwissen<\/h2>\n