Ich meine, wie und warum sind Echtzeit-Betriebssysteme in der Lage, Fristen einzuhalten, ohne sie jemals zu verpassen? Oder ist das nur ein Mythos (dass sie keine Fristen verpassen)? Wie unterscheiden sie sich von einem normalen Betriebssystem und was hindert ein normales Betriebssystem daran, ein RTOS zu sein?
Die Einhaltung von Fristen hängt von der Bewerbung ab, die Sie schreiben. Das RTOS bietet einfach Möglichkeiten, die Ihnen bei der Einhaltung von Fristen helfen. Sie könnten auch auf "bare metal" (ohne RTOS) in einer großen Hauptschleife programmieren und Ihre Fristen einhalten.
Bedenken Sie auch, dass ein RTOS im Gegensatz zu einem allgemeineren Betriebssystem nur eine sehr begrenzte Anzahl von Aufgaben und Prozessen ausführen kann.
Einige der Möglichkeiten, die ein RTOS bietet:
Prioritätsbasierter Planer
Die meisten RTOS haben zwischen 32 und 256 mögliche Prioritäten für einzelne Tasks/Prozesse. Der Scheduler führt die Aufgabe mit der höchsten Priorität aus. Wenn ein laufender Task die CPU aufgibt, läuft der Task mit der nächsthöheren Priorität und so weiter...
Die Aufgabe mit der höchsten Priorität im System erhält die CPU bis:
Als Entwickler ist es Ihre Aufgabe, die Prioritäten der Aufgaben so zu setzen, dass die Fristen eingehalten werden können.
Systemtakt Unterbrechungsroutinen
Das RTOS bietet in der Regel eine Art Systemuhr (zwischen 500 uS und 100ms), mit der Sie zeitabhängige Operationen durchführen können. Wenn Sie eine Systemuhr von 1 ms haben und alle 50 ms eine Aufgabe ausführen müssen, gibt es in der Regel eine API, mit der Sie sagen können: "Wecke mich in 50 ms auf". Zu diesem Zeitpunkt würde die Aufgabe schlafen, bis das RTOS sie aufweckt.
Beachten Sie, dass das bloße Aufwachen keine Garantie dafür ist, dass Sie genau zu dieser Zeit laufen werden. Das hängt von der Priorität ab. Wenn gerade eine Aufgabe mit höherer Priorität läuft, kann es zu Verzögerungen kommen.
Deterministisches Verhalten
Das RTOS gibt sich große Mühe, um sicherzustellen, dass es bei 10 oder 100 Tasks nicht länger dauert, den Kontext zu wechseln, die nächsthöhere Priorität zu bestimmen usw..
Im Allgemeinen versucht der RTOS-Betrieb, O(1) zu sein.
Einer der wichtigsten Bereiche für deterministisches Verhalten in einem RTOS ist die Interrupt-Verarbeitung. Wenn eine Unterbrechungsleitung signalisiert wird, schaltet das RTOS sofort auf die richtige Unterbrechungs-Service-Routine um und bearbeitet die Unterbrechung ohne Verzögerung (unabhängig von der Priorität einer gerade laufenden Aufgabe).
Beachten Sie, dass die meisten hardwarespezifischen ISRs von den Entwicklern des Projekts geschrieben werden. Das RTOS könnte bereits ISRs für serielle Schnittstellen, die Systemuhr und vielleicht Netzwerkhardware bereitstellen, aber alles Spezielle (Signale von Herzschrittmachern, Aktoren usw.) wäre nicht Teil des RTOS.
Dies ist eine grobe Verallgemeinerung, und wie bei allem anderen gibt es eine große Vielfalt an RTOS-Implementierungen. Einige RTOS gehen die Dinge anders an, aber die obige Beschreibung sollte auf einen großen Teil der bestehenden RTOS anwendbar sein.
"Diese Aufgabe wird bis zum Ende ausgeführt" klingt nach Windows 3.1! Sie meinen also, dass RTOSs nicht präemptiv sind?
Nein, wenn Sie die höchste Priorität haben, laufen Sie so lange, bis Sie freiwillig aufgeben ODER eine Aufgabe mit höherer Priorität als Sie fertig wird, woraufhin die (alte) hohe Priorität vorgezogen wird. Ich werde das im Haupttext klarstellen. Vielen Dank!
Die kritischsten Parameter, die bei RTOSen beachtet werden sollten, sind geringe Latenzen und Zeitdeterminismus. Dies geschieht auf angenehme Weise, indem bestimmte Richtlinien und Tricks befolgt werden.
Bei GPOS hingegen ist neben akzeptablen Latenzen ein hoher Durchsatz der kritische Parameter. Bei GPOS kann man sich nicht auf Zeitdeterminismus verlassen.
RTOSs haben Tasks, die viel leichter sind als Prozesse/Threads in GPOS.
Es könnte hilfreich sein, den Quelltext eines typischen RTOS zu lesen. Es gibt mehrere Open-Source-Beispiele, und die folgenden Links wurden bei einer kurzen Suche gefunden:
Ein kommerzielles RTOS, das gut dokumentiert ist, in Form von Quellcode zur Verfügung steht und mit dem man leicht arbeiten kann, ist µC/OS-II . Es hat eine sehr freizügige Lizenz für Bildungszwecke, und (eine leicht veraltete Version von) seine Quelle kann in ein Buch gebunden werden, die seine Theorie der Operation mit der tatsächlichen Umsetzung als Beispielcode beschreibt. Das Buch ist MicroC OS II: Der Echtzeit-Kernel von Jean Labrosse.
Ich habe µC/OS-II im Laufe der Jahre in mehreren Projekten eingesetzt und kann es empfehlen.
Es geht nicht darum, dass sie in der Lage sind, Fristen einzuhalten, sondern vielmehr darum, dass sie feste Fristen haben, während es in einem normalen Betriebssystem keine solche Frist gibt.
In einem normalen Betriebssystem ist der Taskplaner nicht wirklich streng. Das heißt, der Prozessor führt so viele Befehle pro Sekunde aus, aber es kann vorkommen, dass er dies nicht tut. So kann zum Beispiel eine Aufgabe vorzeitig beendet werden, damit eine andere Aufgabe mit höherer Priorität ausgeführt werden kann (und zwar für längere Zeit). Im RTOS wird der Prozessor immer die gleiche Anzahl von Tasks ausführen.
Außerdem gibt es in der Regel ein Zeitlimit für die Erledigung von Aufgaben, nach dessen Ablauf ein Fehler gemeldet wird. Dies ist bei normalen Betriebssystemen nicht der Fall.
Natürlich gibt es noch viele weitere Details zu erklären, aber die oben genannten sind zwei der wichtigsten Designaspekte, die in RTOS verwendet werden.
Ihr RTOS ist so konzipiert, dass es Zeitvorgaben für wichtige Ereignisse, wie die Behandlung von Hardware-Interrupts und das Aufwecken schlafender Prozesse, genau zum richtigen Zeitpunkt garantieren kann.
Durch dieses exakte Timing kann der Programmierer sicher sein, dass sein Herzschrittmacher genau dann einen Impuls ausgibt, wenn er ihn braucht, und nicht erst einige zehn Millisekunden später, weil das Betriebssystem mit einer anderen ineffizienten Aufgabe beschäftigt war.
In der Regel handelt es sich um ein viel einfacheres Betriebssystem als ein vollwertiges Linux oder Windows, einfach weil es einfacher ist, das Verhalten von einfachem Code zu analysieren und vorherzusagen. Es spricht nichts dagegen, ein vollwertiges Betriebssystem wie Linux in einer RTOS-Umgebung zu verwenden, und es verfügt über RTOS-Erweiterungen. Aufgrund der Komplexität der Codebasis kann es seine Zeitvorgaben nicht in einem so kleinen Maßstab garantieren wie ein kleineres Betriebssystem.
Der RTOS-Scheduler ist auch strenger als ein Allzweck-Scheduler. Es ist wichtig zu wissen, dass der Scheduler die Priorität Ihrer Aufgabe nicht ändern wird, nur weil Sie schon lange laufen und keine interaktiven Benutzer haben. Die meisten Betriebssysteme würden die interne Priorität dieser Art von Prozessen herabsetzen, um kurzfristige interaktive Programme zu begünstigen, bei denen die Schnittstelle nicht ins Hintertreffen geraten sollte.
CodeJaeger ist eine Gemeinschaft für Programmierer, die täglich Hilfe erhalten..
Wir haben viele Inhalte, und Sie können auch Ihre eigenen Fragen stellen oder die Fragen anderer Leute lösen.
1 Stimmen
Es ist auch wichtig, den Unterschied zwischen einem "weichen" Echtzeitsystem und einem "harten" Echtzeitsystem zu beachten.