Anbieter zum Thema
Wie die Datenkonsistenz gewahrt bleibt
Der Datenaustausch zwischen Aufgaben geschieht bei konventioneller Programmierung häufig über globale Variablen. Um Datenkonsistenz zu gewährleisten, müssen beim Zugriff auf diese Daten Interrupts gesperrt werden, was das Echtzeitverhalten verschlechtert. Die globalen Variablen erhöhen zudem die Fehlerträchtigkeit des Programms, weil von jedem Programmmodul auf sie zugegriffen werden kann.
RTOS stellen für die Inter-Task-Kommunikation deshalb FIFO-Mechanismen bereit, so genannte Mailboxes oder Queues. Die schreibende Task stellt neue Daten in den First-In-First-Out-Puffer der Mailbox, die lesende Task holt sie ab, worauf der Speicherplatz im Puffer wieder freigegeben wird. Durch diese Art des Datenaustausches vermeidet das RTOS die unerwünschten Seiteneffekte, die bei der Verwendung von globalen Variablen auftreten können.
Entkopplung der einzelnen Software-Prozesse
Durch die Strukturierung des Programmes in verschiedene priorisierte Aufgaben, die sich über normierte interne Schnittstellen verständigen, entsteht ein leichter überschaubares Gesamtgebilde. Die Entkoppelung der einzelnen Software-Prozesse bewirkt eine bessere Modularisierung, Portabilität und damit Wiederverwendbarkeit.
Dadurch können Anwender folgende Softwareprojekte aus bestehenden Bausteinen zusammenbauen und profitieren von einer kürzeren Time-to-Market. Manche Compiler/Debugger unterstützen durch „RTOS-Awareness“ deren Einsatz. Der Hersteller des RTOS liefert dazu ein Plug-In für den Compiler/Debugger, wodurch dem Anwender zusätzliche Ansichten mit Informationen zu den Tasks während einer Debug-Sitzung zur Verfügung stehen. Darüber hinaus liefern die RTOS meist auch Werkzeuge zur statistischen Auswertung von CPU-Belastung und Zustände der einzelnen Tasks.
RTOS mit weniger Speicher und ohne Bootzeit
Im Vergleich mit großen Betriebssystemen wie Linux bieten RTOS neben der Echtzeitfähigkeit einen weiteren Vorteil: Sie benötigen deutlich weniger Speicher und keine Bootzeit, so dass die Geräte nach dem Einschalten sofort betriebsbereit sind.
Um eine breite Kundenbasis anzusprechen sind Hersteller von RTOS bestrebt, möglichst viele CPU-Architekturen zu unterstützen. Das RTOS „embOS“ des Rutronik-Partners SEGGER etwa unterstützt mit ARMs 7, 9, Cortex-M, Cortex-A8, PICs 18, 24/dsPIC, 32, Renesas K0R V850, RX, R32, M16C, SH, Infineon C16x, STMicroelectronics STM8 die verbreitetsten, darüber hinaus viele mehr.
Um die Hardware auf breiter Front zu unterstützen, ist embOS zweischichtig aufgebaut: Es besteht aus einem großen generischen Teil und einem kleinen CPU-spezifischen Teil. Damit braucht bei der Anpassung an einen neuen Controller lediglich der CPU-spezifische Teil entsprechend abgewandelt werden.
Nicht nur die technischen Eigenschaften des RTOS sind relevant
Je nach Hersteller des Betriebssystems sind Gerätetreiber für bestimmte Peripherals wie ADC, USB, TCP/IP oder für SD-Karte und ein Dateisystem verfügbar, manchmal zugeschnitten auf ein bestimmtes Evaluation Board. Der Hersteller spricht dann von einem Board Support Package, kurz BSP. Solche Packages unterstützen und beschleunigen die Entwicklung und ermöglichen so eine kürzere Time-to-Market.
Neben den technischen Eigenschaften und der Ausstattung gilt es, bei der Auswahl eines RTOS weitere Aspekte zu beachten. Dazu gehört, mit welchen Compilern das RTOS auf die Ziel-CPU portiert wurde. Wenn der Hersteller auch kurzfristig auf neue Architekturen portiert, kann der Nutzer sein bereits erworbenes Knowhow weiter einsetzen. Dank einer längeren Nutzung verbessert sich zudem der Return of Investment.
Auch der technische Support spielt eine wichtige Rolle. Einfache Erreichbarkeit und kurze Antwortzeiten kompetenter Ansprechpartner bevorzugt in Landessprache unterstützen den Kunden bei der Einhaltung des Entwicklungszeitplan auch bei kurzen Time-to-Market Zeiten.
Auf die Lizenzkosten der Software achten
Große Unterschiede bestehen bei den Lizenzmodellen. Häufig basieren die Kosten auf der Stückzahl der verkauften Endprodukte. Das Kostenmodell von SEGGER unterscheidet sich davon grundlegend, hier sind alle Lizenzkosten unabhängig von der Anzahl der hergestellten Endprodukte. Für embOS stellt SEGGER Lizenzen für Source- und Objektcode zur Auswahl, beide Varianten können als Produkt-, Entwickler-, CPU- oder Buyout-Lizenz gewählt werden. Für jede Anwendung und Budgetierung steht eine passende Lösung zur Verfügung.
Damit der Kunde nicht die Katze im Sack kaufen muss, stellen viele RTOS-Hersteller Trialversionen mit eingeschränkter Funktionalität auf ihrer Homepage zum Download bereit. Von SEGGER sind sogar ganze Trial-Startprojekte für viele EVA-Boards zum kostenlosen Download verfügbar. Diese beinhalten je nach Board neben embOS auch weitere Softwaremodule wie emFILE oder emUSB und müssen – im Gegensatz zu anderen OS – nicht konfiguriert werden, da für jede CPU/Compiler-Kombination die passende Lösung zur Verfügung steht.
Den Trend, Mikrocontroller verstärkt nach ihrem Ecosystem auszuwählen, hat Rutronik bereits früh erkannt und schon vor Jahren mit SEGGER einen Anbieter umfangreicher Embedded Software Solutions in sein Partnernetzwerk aufgenommen.
* * Ralf Hickl betreut den Support Microcontroller bei Rutronik Elektronische Bauelemente.
(ID:30259480)