Memory-Meister - elektronikJOURNAL

Immer pünktlich
Das passende Echtzeit-Betriebssystem auswählen
Die meisten Echtzeit-Betriebssysteme verfügen heute über
vergleichbare Kernel-Funktionalitäten: mindestens 255
Prioritätsebenen, Th read-Scheduling mit Prioritäten, deterministische
Th read-Ausführungs- und ISR-Latenzzeiten
sowie einen präemptiven Kernel. Daher macht ein bloßes Gegenüberstellen
von Anwendungsanforderungen und Kernel-Eigenschaft
en es schwer, die beste Wahl herauszufi ltern. Stattdessen
bietet sich ein strukturierter und methodischer Selektionsansatz
an, der alle Faktoren berücksichtigt. Die Vorteile werden sich über
die gesamte Lebensdauer der Applikation zeigen – und zwar sowohl
an den Kosten in der Entwicklungs- und Support-Phase als
auch in Form eines gesunkenen Entwicklungsrisikos.
API und Speichermodell
Bei der Auswahl eines Echtzeit-Betriebssystems steht das API (Application
Programming Interface) oft an erster Stelle. Die Schnittstelle
ist entweder proprietär oder Standard-basiert. Ein herstellereigenes
API kettet die Anwendung an einen einzigen Anbieter, was
sich auf den langfristigen Support auswirken kann. Man stelle sich
vor was passiert, wenn dieser Anbieter die gewünschte Prozessor-
Architektur nicht mehr unterstützt oder gar den Betrieb einstellt.
Bei einem auf off enen Standards basierenden API sind derlei Bedenken
überfl üssig, weil die Anwendung nicht an ein einziges
RTOS gebunden ist. Die Schnittstelle wird typischerweise nur neu
kompiliert, eventuell mit ein paar Anpassungen.
Der Industriestandard für ein Betriebssystems-API heißt Posix
1003.13-2003 PSE53 und wird vom IEEE gepfl egt. Posix ist die einzige
wirklich portierbare API. Sie kommt in vielen Allzweck-, aber
auch in Echtzeit-Betriebssystemen zum Einsatz. Linux und andere
kommerzielle Unix-Plattformen stimmen mit ihr überein und ermöglichen
so das Portieren existierender Anwendungen. Weitere
Vorteile einer auf off enen Standards basierenden API sind die Fülle
erfahrener Posix-Programmierer und die Vielfalt vorhandenen
Codes. Einige Anbieter von Betriebssystemen mit proprietärer API
behaupten zwar, dass diese Posix unterstützen, beschränken sich
aber auf ein abstrahiertes Mindestmaß an Posix-Funktionsaufrufen.
Oder sie raten von nicht-nativen Posix-Funktionen ab, da diese
langsamer sind als die nativen, aber proprietären Funktionen.
Die meisten Echtzeitbetriebssysteme arbeiten entweder mit einem
linearen Speichermodell (Flat Memory Model) oder mit Speicherschutz
per Paged-Process-Modell. Beim linearen Speichermodell
teilen sich alle Th reads oder Tasks einen gemeinsamen Adressraum.
Wenn ein Prozess auf eine unerlaubte Adresse zugreift , stört
er eventuell eine andere Task. Weder die Hardware noch der Betriebssystem-Kernel
bemerken, dass ein Problem aufgetreten ist.
Dies kann einen sofortigen Anwendungsausfall zur Folge haben;
manchmal entwickelt sich der Absturz aber auch erst mit der Zeit.
Ausfälle dieser Art sind schwer zu debuggen.
Entwickeln, Entwickeln, Messen und Messen Fertigen und
Softwaretools Fertigen
Das richtige Realtime-OS für ein Projekt zu fi nden ist eine herausfordernde und zeitaufwändige Aufgabe.
Eine falsche Entscheidung kann schwerwiegende Folgen haben und das Projekt sogar scheitern lassen.
Also gilt es, sich umfassend zu informieren. Autor: John Patchin
Beim fl achen Speichermodell geraten wegen des globalen Namensraums
auch globale Variablen eines Prozesses mit gleichnamigen
Variablen in einem anderen Prozess in Konfl ikt. Dies führt
zu vielen Problemen, wenn man mehrere Echtzeitanwendungen
auf einer gemeinsamen Plattform kombiniert, oder wenn mehrere
Entwicklungsteams an einem Projekt arbeiten. Das Paged-Process-
Modell (Bild 1) bietet hingegen Speicherschutz für jeden Prozess.
Es schützt nicht nur jede einzelne Anwendung, sondern auch den
Kernel und heißt mitunter Raumpartitionierung. Bei diesem Prozessmodell
führt jeder Versuch eines Th reads auf eine unerlaubte
Adresse zuzugreifen, sofort zu einer Hardware-Exception. Der Betriebssystemkern
wiederum reagiert mit einer so genannten nicht
handhabbaren Exception: er bricht den Prozess ab und schreibt
dessen kompletten Speicherbereich in eine so genannte Core-Datei.
Der Entwickler kann später diesen Core-Dump in einen Debugger
laden, um nach der Ursache des Problems zu forschen.
Echtzeit-Scheduler
Einige Universal-Echtzeitbetriebssysteme wie Lynx-OS-SE von
Lynux works gehen in Sachen Partitionierung noch weiter und addieren
zur Raumpartitionierung eine Zeitpartitionierung (Bild 3).
Diese fügt dem prioritätsgesteuerten, präemptiven Scheduler ein
zweites Steuerprogramm hinzu, das die Teilprogramme zyklisch
nach einer fest vorgegebenen Reihenfolge ausführt (cyclic fi xedtime
based scheduler). Ein einzelner Prozess oder eine Prozessgruppe
kann zur Ausführung über eine festgelegte Zeitspanne
konfi guriert werden, ehe der Cyclic-Scheduler zur nächsten Prozessgruppe
wechselt. Während die jeweilige Prozessgruppe die
Th reads innerhalb dieser Prozesse abarbeitet, wird sie dennoch
vom Priority-Preemptive-Scheduler gesteuert. Dieses Schema lässt
es nicht zu, dass ein einzelner Th read, der mit hoher Priorität im
Hard Loop rechnet, alle anderen Th reads quasi aussperrt.
Eine vollständige Embedded-RTOS-Anwendung braucht typischerweise
noch Geräte-Support, Stacks und Middleware. Wird ➔
Auf einen Blick
Am Zahn der Zeit
Welches Echtzeit-Betriebssystem soll es sein? Diese Frage lässt sich
weder rein technisch, noch rein kaufmännisch beantworten und sie
hängt immer von den Anforderungen der Applikation ab. Also muss
ein Entscheider die wichtigen Kriterien kennen, die über Erfolg oder
Scheitern eines Projekts bestimmen. Dieser Artikel gibt einen Überblick
und zeigt die große Bandbreite dieser Kriterien.
infoDIREKT www.elektronikjournal.com
Vorteil Grundlage für fundierte RTOS-Auswahl.
502ejl1110
www.elektronikjournal.com
elektronikJOURNAL 11 / 2010 57