Die ganze Wahrheit über RTOS. Artikel # 6. Andere RTOS-Dienste

Ursprünglicher Autor: Colin Walls
  • Übersetzung


In vorherigen Artikeln haben wir die Funktionalität des Kernels in Bezug auf durchgeführte Aufgaben und die Interaktionen zwischen ihnen erörtert. In diesem Artikel werden wir uns ansehen, was der Kernel sonst noch tun kann, was sich in einer Reihe anderer verfügbarer API-Aufrufe weitgehend manifestiert. Wir werden auch die Frage beantworten, was den Kernel zum Betriebssystem macht.

Vorherige Artikel in der Serie:
Artikel # 5. Interaktion zwischen Aufgaben und Synchronisation
Artikel 4. Aufgaben, Kontextwechsel und Interrupts
Artikel 3. Aufgaben und Planung
Artikel 2. RTOS: Struktur und Echtzeitmodus
Artikel 1. RTOS: Einführung.

Aufgabenverwaltung


Neben der Aufgabenplanung und der Interaktion zwischen ihnen enthält das RTOS Funktionen (API-Aufrufe) zum Verwalten von Aufgaben auf verschiedene Arten. Betrachten Sie einige Funktionen.

Erstellen und Löschen von Aufgaben

Das "dynamische" RTOS verfügt über Funktionsaufrufe, mit denen Sie Aufgaben (und andere Objekte des RTOS) erstellen können, wenn sie benötigt werden. Zu diesen Aufrufen gehören eine Vielzahl von Parametern, die eine Aufgabe definieren, wie z. B. Einstiegspunkt, Stapelgröße und Priorität. Mit dem entsprechenden Taskaufruf zum Löschen der API können Sie Ressourcen freigeben, nachdem die Task abgeschlossen ist.

Im "statischen" RTOS werden die Taskdefinitionsparameter während des Builds in einer Art Konfigurationsdatei konfiguriert.

Aufgabe aussetzen und fortsetzen

Wie wir gesehen haben, haben die meisten Echtzeitbetriebssysteme das Konzept eines "suspendierten" Task-Status. Dies kann auf verschiedene Arten erreicht werden. Eine davon ist ein expliziter Aufruf der API-Funktion "Suspend Task API". Es kann durch sich selbst oder eine andere Aufgabe verursacht werden. Mit dem entsprechenden Aufruf "Task wieder aufnehmen" kann die Task erneut zur Planung in die Warteschlange gestellt werden.

Schlafstatusaufgaben

Für ein Echtzeitsystem ist Zeitsteuerung eine wichtige Anforderung und kann viele Formen annehmen. Eine einfache Ansicht ist die Fähigkeit der Aufgabe, "einzuschlafen", das heißt, die Aufgabe wird für eine bestimmte Zeit ausgesetzt. Wenn die Zeit abgelaufen ist, „wacht“ die Aufgabe auf und wird erneut zur Planung in die Warteschlange gestellt. Zu diesem Zweck steht normalerweise ein API-Aufruf zur Verfügung. Diese Funktionalität hängt natürlich von der Verfügbarkeit des Timers ab.

Loslassen

Bei Verwendung des Round Robin-Schedulers (Task) kann es sein, dass der Task die Steuerung des Prozessors für die nächste Task in der Kette ablehnt. Dafür steht die Task Release API-Funktion zur Verfügung. Die Aufgabe ist nicht ausgesetzt, sie steht für die Planung zur Verfügung, wenn sie an der Reihe ist. Wenn Sie den Zeitscheiben-Scheduler verwenden, kann es sein, dass eine Task einen Teil ihres Zeitintervalls freigibt, wenn wichtige Aufgaben nicht sofort ausgeführt werden müssen. Die Freigabe der Aufgabe hat beim Ausführen der Scheduler keine logische Bedeutung. Ausführen bis zum Abschluss ("Fertigstellung bis zum Abschluss") oder Priorität ("Prioritätsplanung").

Aufgabe abschließen

In einem vorherigen Artikel haben wir herausgefunden, dass das RTOS zusätzlich zu den Zuständen „Bereit“ („Bereit zum Fortfahren“) oder „Ausgesetzt“ (RTOS) andere Taskzustände unterstützen kann. Die Task kann "Fertig" sein, was bedeutet, dass ihre Hauptfunktion einfach beendet wird: Es ist kein spezieller API-Aufruf erforderlich. Die Task kann „Terminated“ sein, was bedeutet, dass sie nicht für die Planung zur Verfügung steht und zurückgesetzt werden muss, um wieder für den Start verfügbar zu sein, siehe „Task zurücksetzen“. Dies erfordert einen speziellen API-Aufruf. Die Verfügbarkeit dieser zusätzlichen Aufgabenzustände, die verwendete Terminologie und ihre genauen Definitionen unterscheiden sich je nach RTOS.

Aufgabe zurücksetzen

Viele RTOSs bieten einen Aufruf der Task Reset API-Funktion, mit der Sie die Task in den ursprünglichen Zustand zurückversetzen können. Es befindet sich möglicherweise im angehaltenen Zustand und erfordert, dass die Funktion "Task fortsetzen" zur Planung in die Warteschlange gestellt wird.

Priorität von Tasks usw.

Im "dynamischen" RTOS stehen möglicherweise API-Aufrufe zur Verfügung, um mehrere Parameter der Task zur Laufzeit zu konfigurieren. Beispiele sind die Priorität und die Dauer des Zeitintervalls.

Systeminformationen


Das RTOS ist eine Reihe von API-Anrufe für das Problem der Systeminformationen, einschließlich
der Aufgaben der Information . Wie viele Aufgaben im System, ihre Konfigurationen und aktuellen Status.
Informationen zu anderen Kernel-Objekten. Wie viele Objekte jedes Typs befinden sich im System, deren Konfigurationen und Informationen zum aktuellen Status. Zum Beispiel:

  • Wie hoch ist die aktuelle Kapazität der Warteschlange? Kann ich weitere Nachrichten hinzufügen?
  • Wie viele Aufgaben werden für ein bestimmtes Postfach angehalten?
RTOS-Versionsinformationen . Ein API-Aufruf kann ähnliche Daten bereitstellen.

Speicherzuordnung


In vielen Anwendungen ist es wichtig, dass das Programm bei Bedarf dynamisch Speicherplatz aufnimmt und freigibt, wenn es nicht mehr benötigt wird. Dasselbe passiert in der eingebetteten Software. Herkömmliche Ansätze unterliegen jedoch Problemen, die bei Desktop-Anwendungen unwahrscheinlich oder unpraktisch sind, für ein eingebettetes System können sie jedoch katastrophal sein. Es gibt jedoch Möglichkeiten, solche Dienste auch in einem statischen Echtzeitbetriebssystem zu implementieren.

Probleme mit den Funktionen malloc () und free ()


In einem C-Desktop-Programm kann eine Funktion malloc () aufrufen , die angibt, wie viel Speicherplatz erforderlich ist, und einen Zeiger auf den Speicherbereich zurückrufen. Mit Hilfe von Speicher kann es durch Aufrufen von free () freigegeben werden.. Speicher wird aus einem Bereich zugewiesen, der als "Heap" bezeichnet wird. Das Problem bei diesem Ansatz ist, dass bei einer unkoordinierten Folge von Aufrufen dieser Funktionen der "Heap" -Bereich leicht fragmentiert werden kann und die Speicherzuweisung dann fehlschlägt, selbst wenn genügend Speicher verfügbar ist, weil angrenzende Bereiche sind nicht groß genug. Einige Systeme (z. B. Java und Visual Basic) verwenden komplexe "Garbage Collection" -Schemata zur Implementierung der Defragmentierung. Das Problem ist, dass diese Schemata zu erheblichen unvorhersehbaren Verzögerungen in der Ausführungszeit und der Verwendung von indirekten Zeigern führen können (was in C nicht funktioniert).

Wenn malloc () und free ()Sie wurden wiedereintrittsfähig implementiert (in der Regel nicht) und von RTOS-Tasks verwendet. Die Fragmentierung erfolgt sehr schnell und ein Systemausfall ist nahezu unvermeidlich. In C ++ gibt es neue und Löschoperatoren , die im Allgemeinen die gleichen Funktionen wie malloc () und free () ausführen. Sie unterliegen den gleichen Einschränkungen und Problemen.

Speicherabschnitte


Um ein Echtzeitsystem mit dynamisch verfügbarem Speicher bereitzustellen, können Sie einen Blockansatz für die Speicherverwaltung verwenden. Solche Blöcke werden normalerweise als "Partitionen" bezeichnet. Partitionen können aus dem "Partitionspool" zugewiesen werden.

Ein Partitionspool enthält eine bestimmte Anzahl von Blöcken, von denen jeder dieselbe Größe hat. Die Anzahl und Größe der Blöcke in einer Partition werden beim Erstellen eines Partitionspools festgelegt. Dies kann dynamisch sein, wenn das System es selbst zulässt, oder statisch während der Montage. In der Regel kann eine Anwendung mehrere Pools von Abschnitten mit Blöcken unterschiedlicher Größe enthalten.

Wenn eine Task Speicher benötigt, ruft sie eine API auf, die einen Block aus einem bestimmten Pool anfordert. Wenn dieser Aufruf erfolgreich ist, erhält die Task einen Zeiger auf den ausgewählten Block. Wenn der Anruf fehlschlägt, weil Im angegebenen Pool sind keine Partitionen vorhanden, die Aufgabe erhält möglicherweise eine Fehlerantwort. Alternativ kann eine Task gesperrt (suspendiert) werden, bis eine andere Task einen Block in einem Abschnitt freigibt.

Normalerweise überträgt eine Task einfach einen Zeiger auf einen Speicherblock auf jeden Code, den der Block verwendet. Dies führt zu einem Problem, wenn der Block nicht mehr benötigt wird. Wenn der Code nur einen Zeiger auf den Block hat, wie kann er dem RTOS über einen API-Aufruf mitteilen, aus welchem ​​Partitionspool der Speicher freigegeben werden soll? Die Antwort ist, dass die meisten Echtzeitbetriebssysteme zusätzliche Daten in einem dedizierten Block unterstützen (normalerweise einen negativen Versatz vom Zeiger), die die erforderlichen Informationen bereitstellen. Um eine API aufzurufen, um einen Block freizugeben, ist nur die Adresse erforderlich.

Der nächste Artikel enthält weitere Informationen zu den Speicherbereichen.

Zeit


Die mit der Verwendung und Kontrolle der Zeit verbundene Funktionalität ist wahrscheinlich in einem Echtzeitbetriebssystem verfügbar. Die Möglichkeiten variieren je nach RTOS, aber wir werden öffentlich verfügbar sein. In jedem Fall ist ein Echtzeit-Timer ein wesentliches Element für den Betrieb eines dieser Dienste.

Systemzeit

Fast immer steht eine einfache Systemzeit ("Timer") zur Verfügung. Es ist einfach ein Zähler (normalerweise 32 Bit), der mit einer Echtzeit-Interrupt-Serviceroutine inkrementiert wird und durch API-Aufrufe gesetzt und gelesen werden kann.

Timeouts für Service-Anrufe

Normalerweise erlaubt das RTOS das Blockieren von API-Aufrufen, d. H. Die aufrufende Task pausiert (blockiert), bis der angeforderte Dienst bereitgestellt wird. Normalerweise ist diese Blockierung unsicher, aber einige RTOS bieten eine Zeitüberschreitung, während der der Anruf nach Ablauf der Wartezeit zurückkehrt, wenn der Dienst nicht verfügbar ist. Zeitlimits für API-Aufrufe werden nicht von allen RTOS unterstützt. Ruhezustand

einer Aufgabe

Normalerweise haben Aufgaben die Möglichkeit, sich für eine bestimmte Zeitspanne auszusetzen. Dies wurde zuvor im Abschnitt "Task Management" erläutert.

Software-Timer

Für Softwareaufgaben zur Ausführung von Zeitsteuerungsfunktionen bieten die meisten Echtzeitbetriebssysteme Zeitgeberobjekte. Dies sind unabhängige Timer, die vom Echtzeit-Timer-Interrupt-Handler aktualisiert werden und von API-Aufrufen gesteuert werden können. Solche Anrufe richten den Timer ein, überwachen ihn und verfolgen ihn. Sie können in der Regel auf einmaligen Betrieb oder automatischen Neustart eingestellt werden. Normalerweise wird auch eine Ablaufroutine unterstützt, eine Funktion, die jedes Mal ausgeführt wird, wenn ein Timer einen Zyklus abschließt. Im nächsten Artikel finden Sie weitere Informationen zu Software-Timern und eine Beschreibung ihrer Implementierung.

Interrupts, Treiber und E / A


Das Ausmaß, in dem RTOS mit Interrupts und E / A verbunden ist, ist sehr unterschiedlich. In ähnlicher Weise haben einige Echtzeitbetriebssysteme eine sehr klare Struktur für Gerätetreiber, was bei der Auswahl eines bestimmten Produkts zu Problemen führen kann.

Interrupts

Interrupts sind aus zwei Gründen ein Problem für ein Echtzeitbetriebssystem.

  • Ohne Vorkehrungen „stiehlt“ der Interrupt-Handler (ISR) die Prozessorzeit und unterbricht dadurch das Echtzeit-Echtzeitbetriebsverhalten.
  • Wenn eine ISR API-Aufrufe ausführt, die sich auf die Taskplanung auswirken, sollte dies überwacht werden, und der RTOS sollte in der Lage sein, seinen Scheduling-Algorithmus auszuführen.
Ein Beispiel für einen solchen API-Aufruf ist eine Task-Aktivierungsprozedur mit einer höheren Priorität als der, die zum Zeitpunkt des Interrupts gestartet wurde.

Einige RTOS steuern alle Interrupts vollständig. Es stehen eine Reihe von API-Aufrufen zur Verfügung, mit denen Sie ISR-Programme "registrieren" können. Dieser Ansatz ermöglicht es dem Scheduler, genau zu bestimmen, wann Interrupts aktiviert sind, und erleichtert die Verwendung der meisten API-Aufrufe von einer ISR.

Beispielsweise implementiert Nucleus RTOS das Konzept der Interrupt-Handler mit niedriger Priorität und hoher Priorität, was eine zuverlässige Interrupt-Verarbeitung ohne unnötigen Overhead (d. H. Erhöhung der Interrupt-Latenz) ermöglicht.

Andere RTOSs können für Interrupts einen automatischen Hands-off-Modus verwenden. Entwickler haben so mehr Optionen, um sicherzustellen, dass Interrupt-Handler ordnungsgemäß funktionieren. In der Regel werden zusätzliche Präfixe (Prologue) und Suffixe (Epilogue-ISR) bereitgestellt, um die in ihr getätigten API-Aufrufe zu schützen.
Nucleus SE verwendet leichte Interrupt-Handling-Tools, die im nächsten Artikel beschrieben werden.

Treiber

Die meisten RTOSs bestimmen die Struktur eines Gerätetreibers. Details können je nach RTOS unterschiedlich sein, der Treiber besteht jedoch normalerweise aus zwei Komponenten, die miteinander interagieren: eingebetteter Code (API-Aufrufe) und ISR. Normalerweise stehen andere API-Aufrufe zum Verwalten und Registrieren von Treibern zur Verfügung.

Eingabe / Ausgabe

Derzeit interessieren sich die meisten RTOSs auf dem Markt nicht für übergeordnete E / A, aber einige von ihnen definieren den E / A-Fluss, der im Wesentlichen die Verbindung zwischen den entsprechenden Gerätetreibern und Standardfunktionen der C-Sprache herstellt, beispielsweise printf ().
In der Vergangenheit unterstützten RTOSs häufig eine „Konsole“, eine Benutzeroberfläche für ein RTOS über einen seriellen Kanal. Es wurde hauptsächlich für die Diagnose und das Debugging verwendet. Durch die Verwendung moderner Debugger, die das Debuggen von Anwendungen mit RTOS unterstützen, sind solche Objekte nicht mehr erforderlich.

Diagnose


Normalerweise ist ein RTOS für maximale Leistung bei minimalem Speicher erforderlich. Daher hat die Integritätsprüfung keine oberste Priorität. Mit Hilfe moderner Debugging-Technologien, die die Eigenschaften des Echtzeitbetriebssystems berücksichtigen, können die meisten Prüfungen außerhalb des Echtzeitbetriebssystems selbst durchgeführt werden.

Überprüfen der API-Aufrufparameter


API-Aufrufe können viele komplexe Parameter haben. Dies kann zu Fehlern führen. Viele RTOSs überprüfen die Laufzeitparameter mit der Rückgabe eines Fehlercodes im Falle eines falschen Parameters. Da hierfür zusätzlicher Code erforderlich ist und die Prüfungen selbst die Leistung beeinträchtigen, ist es besser, Parameterprüfungen während der Montage oder Konfiguration durchzuführen.

Stapelcheck


Bei den meisten Schedulertypen (außer Ausführen bis zum Abschluss) verfügt jede Task über einen eigenen Stack, dessen Größe individuell festgelegt wird. In einigen RTOSs hat der Kern einen separaten Stack, in anderen wird der Task-Stack während eines API-Aufrufs "entliehen". Offensichtlich ist die Integrität des Stapels für die Gesamtzuverlässigkeit des Systems wichtig. Daher bieten RTOSs häufig Werkzeuge zur Überprüfung der Integrität von Stacks zur Laufzeit. Es gibt mehrere Möglichkeiten:

  • Ein API-Aufruf, der die Menge an freiem Stapelspeicher für die aktuelle oder angegebene Aufgabe zurückgibt.
  • Begrenzung der Stack-Optionen. Ihnen wird ein eindeutiger Wert (normalerweise ungerade und ungleich Null) zugewiesen, der regelmäßig zum Überschreiben überprüft wird.


Anwendungsdiagnose


Obwohl diese Funktion im Echtzeitbetriebssystem nicht direkt unterstützt wird, kann die Anwendungstask zur Überprüfung der Integrität des gesamten Systems zugewiesen werden. Eine solche Aufgabe kann für das Zurücksetzen des Überwachungszeitgebers verantwortlich sein. Eine Task kann periodische Eingangsdaten (z. B. Signalparameter) von jeder kritischen Task empfangen. Der Watchdog-Timer-Reset (der das System nicht neu starten lässt) wird erst ausgeführt, nachdem die Daten aller Tasks eingetroffen sind.

Nicht-Kerndienste


RTOS ist mehr als nur der Kern, auf den wir uns bisher konzentriert haben. Hier unterscheidet sich das Desktop-Betriebssystem erheblich von einem eingebetteten Echtzeitbetriebssystem. Normalerweise werden im Desktop-Betriebssystem alle zusätzlichen Komponenten gebündelt oder können installiert werden (alle Desktops verfügen über eine grafische Benutzeroberfläche, von denen nur wenige keinen Zugriff auf das Netzwerk haben). Der Desktop-PC hat keine echten Ressourceneinschränkungen: Es gibt immer freien Speicher, Festplattenspeicher und ungenutzte CPU-Ressourcen. In der Welt der eingebetteten Systeme mit begrenzten Ressourcen können zusätzliche Komponenten wie Videokarten, Netzwerkkomponenten und Dateisysteme erforderlich sein, die jedoch umschaltbar und skalierbar sein müssen, um den Speicherbedarf zu minimieren.

Vernetzungsmöglichkeiten

Die meisten eingebetteten Systeme beziehen sich irgendwie auf Netzwerke. Es wird daher erwartet, dass ein erhebliches Interesse an Netzwerklösungen für eingebettete Systeme besteht, dank derer es eine Vielzahl von Produkten auf dem Markt gibt.

TCP / IP ist ein weit verbreitetes Standardprotokoll und für viele Anwendungen die naheliegende Wahl. Normalerweise wird TCP / IP für das Ethernet-Protokoll (IEEE802.3) verwendet, das im Durchschnitt eine Geschwindigkeit von 10 Mb / s bietet. Heutzutage sind 100 MB / s ziemlich üblich und liegen bei 1 Gbit / s. Außerdem kann TCP / IP für andere Protokolle verwendet werden. Beispielsweise ist PPP (Point-to-Point Protocol) eine TCP / IP-Implementierung für die serielle Datenübertragung, die für Breitband-Internetverbindungen angepasst wurde.

Bis vor kurzem wurde die Version 4 des IP-Protokolls (IPv4) verwendet. Es ist jedoch veraltet, da freie Adressen enden. Die Lösung ist IPv6, wodurch die Anzahl der möglichen Adressen erheblich erhöht wird und die Wartungs- und Sicherheitstools effizienter sind. IPv6 ist weit verbreitet und wird in der Ausrüstung vieler Länder sowie in militärischen Systemen auf der ganzen Welt verwendet.
Eine Alternative ist das User Datagram Protocol (UDP). Dieses Protokoll wird für maximale Leistung verwendet. UDP bietet nicht dieselbe Zuverlässigkeit und Konsistenz wie TCP, ist aber leicht und sehr effizient.

USB- „Universal Serial Bus“ (Universal Serial Bus) wird häufig in Geräten für den Anschluss an Desktop-Computer verwendet. Es bietet eine sehr benutzerfreundliche Oberfläche wie "Plug & Play", die ziemlich komplizierte Software hinter sich versteckt. Ein eingebettetes Gerät, das an einen PC angeschlossen werden muss, muss als USB-Funktion implementiert werden, was einen bestimmten Satz von Softwarekomponenten erfordert. Wenn das Gerät andere Geräte steuern soll, die über USB angeschlossen sind (wie ein normaler PC), ist eine Reihe von Hostsoftware erforderlich.

IEEE1394 , ein weiterer serieller Schnittstellenstandard, der zum schnellen Übertragen großer Datenmengen zwischen Geräten (z. B. zur Übertragung von Videodaten) verwendet wird, wird auch als FireWire und i.Link bezeichnet.

Drahtlose Protokolle - Die Bequemlichkeit und Verbreitung verschiedener drahtloser Technologien bei Verbrauchern hat zu einer hohen Nachfrage nach drahtlosen Funktionen in eingebetteten Geräten geführt. Wi-Fi (eine Reihe von IEEE802.11-Standards) bietet umfassende Netzwerkfunktionen, mit denen Sie sowohl Peer- als auch Infrastruktur-Topologien in ausreichender Entfernung implementieren können. Das Interesse an der Datensicherheit in solchen Netzwerken wächst, was bedeutet, dass dies Auswirkungen auf die Software haben sollte. Andere Funktechnologien wie Bluetooth und ZigBee bieten drahtlose Verbindungen von kurzer Reichweite.

Protokolle prüfen

Da Netzwerkfunktionen sehr gefragt sind, bieten viele Anbieter ihre Lösungen an. Kunden stehen vor der Herausforderung, die Qualität der verfügbaren Produkte zu überprüfen. Im Gegensatz zum RTOS-Core ist eine vollständige Überprüfung der Funktionalität und Leistung des Protokollstapels keine leichte Aufgabe. Glücklicherweise gibt es Toolkits für die Überprüfung von Protokollen (allerdings zu einem erheblichen Preis), und ein potenzieller Käufer kann beim Lieferanten nachlesen, welches Kit er während der Kaufabwicklung verwendet hat.

Grafiken

Grafische Benutzeroberflächen werden bei Embedded-Geräten immer häufiger. Es kann ein sehr einfaches, kleines monochromatisches LCD sein (wie bei älteren Telefonen, MP3-Playern, Alarmen usw.). Andererseits kann ein digitaler Fernsehempfänger einen eigenen HDTV-Bildschirm mit hoher Auflösung haben. Ein solcher Bildschirm erfordert Software-Unterstützung, die vollständig in das Kern-Echtzeitbetriebssystem integriert ist.
Da der Bildschirm normalerweise über ein Eingabegerät verfügt, ist die Unterstützung für solche Geräte häufig im Grafikpaket enthalten. Ein solches Paket kann Zeigegeräte (z. B. eine Maus), Touchscreens, Tastaturen und vollwertige Tastaturen unterstützen.
Grafiken können auf verschiedene Arten verwendet werden. Es kann einfach eine Informationsausgabe bereitstellen (z. B. als elektronische Anzeigetafel). Oder die Anzeige kann zusammen mit Menüs, Fenstern, Symbolen und ähnlichen Elementen Teil einer grafischen Benutzeroberfläche sein. In jedem Fall ist ein recht spezifischer Satz von Software erforderlich, und das im Lieferumfang des RTOS enthaltene Grafikpaket sollte die erforderliche Flexibilität bieten, ohne den Speicherbedarf erheblich zu erhöhen.

Dateisysteme

Wenn eine eingebettete Anwendung große Datenmengen speichern und verarbeiten muss, ist es offensichtlich, dass es sinnvoll ist, diese Daten in einer Art Dateisystem zu organisieren. Die Daten können sich im RAM, im eingebauten Flash-Speicher, auf einem Flash-Laufwerk, einer normalen Festplatte oder auf einem optischen Datenträger (CD-ROM oder DVD-ROM) befinden. Auch hier sollte die Unterstützung der Software vollständig in das Echtzeitbetriebssystem integriert sein. Das Dateisystem muss sorgfältig ausgelegt sein, um die Anforderungen an das Wiedereintritt von Multitasking-Systemen zu erfüllen.

Die Einhaltung von Standards ist besonders für Dateisysteme wichtig. Durch die Verwendung eines MS-DOS-kompatiblen Plattenformats können Entwickler beispielsweise eine bewährte Architektur verwenden und vollständigen Datenaustausch mit Desktopsystemen ermöglichen.

Jetzt auch beliebt: