Die ganze Wahrheit über RTOS von Colin Walls

Die ganze Wahrheit über RTOS. Artikel 1.

Echtzeitbetriebssysteme: Einführung

Diese Artikelserie widmet sich einer gründlichen Untersuchung aller Aspekte von Echtzeitbetriebssystemen (RTOS). Die Artikel richten sich an Entwickler, die neugierig sind, wie das RTOS funktioniert und wie man es verwendet. Der Ausgangspunkt wird die Diskussion über Echtzeitsysteme im Allgemeinen sein, und dann werden wir darüber sprechen, wie RTOS ihre Implementierung vereinfachen und den resultierenden Code zuverlässiger machen kann.

Wenn wir uns das RTOS ansehen, werden wir sehen, wie der Taskplaner funktioniert. Dank Multithreading scheint die CPU mehrere Vorgänge gleichzeitig auszuführen. Dies ist keine Zauberei, ein Verständnis der Prinzipien des Taskplaners steht selbst einem unerfahrenen Softwareentwickler zur Verfügung. Wir werden über andere Objekte des RTOS sprechen: über die Interaktion zwischen Aufgaben und Synchronisation, über den Echtzeitmodus, über die Speicherverwaltung usw. Alles wird genau beschrieben und durch Codebeispiele unterstützt.

Für den Entwickler ist ein wesentlicher Aspekt des RTOS die API, eine Reihe von Prozeduraufrufen, die den Zugriff auf die RTOS-Funktionalität ermöglichen. Die Reihe enthält Artikel zum Thema Funktionsweise der API, verfügbaren Standards und zum Wechsel von einer API zur anderen.

Nachfolgend finden Sie eine Liste von Themen, die wir in naher Zukunft behandeln werden:

• Programmstruktur und Echtzeit
• Echtzeitbetriebssysteme
• Aufgaben und Planung
• Aufgabeninteraktion und Synchronisation
• Andere Betriebssystemdienste
• Nucleus SE
• Planer
• Die Aufgaben
• Abschnitte des Gedächtnisses
• Signale
• Ereignisflag-Gruppen
• Semaphoren
• Postfächer
• Warteschlangen
• Kanäle
• Systemzeit
• Software-Timer
• Unterbrechungen
• Diagnose und Fehlerprüfung
• Initialisierung und Start

Die Artikelserie ist nicht an ein bestimmtes Echtzeitbetriebssystem gebunden, der größte Teil des Materials ist auf öffentlich verfügbare Optionen zur Implementierung von RTOS anwendbar. Laut dem Autor ist die Verwendung eines vorgefertigten kommerziellen Betriebssystems mit vorhandener Unterstützung die zuverlässigste und produktivste Arbeitsweise. Einer der Artikel widmet sich einer ausführlichen Diskussion zum Thema „Make vs Buy“ und anderen Methoden zur Auswahl eines RTOS.

Zur Erläuterung des internen Designs des RTOS werden jedoch Beispiele für den realen Produktcode Nucleus SE verwendet.

Quelle: http://www.embedded.com/design/operating-systems/4442729/Introducing--RTOS-Revealed

Die ganze Wahrheit über RTOS. Artikel 2

RTOS: Struktur und Echtzeitmodus
Programmstruktur und Echtzeit

Diese Artikelserie befasst sich mit eingebetteten Systemen und insbesondere mit Software, die auf eingebetteten Systemen ausgeführt wird. Beginnen wir mit der Definition. Was ist ein eingebettetes System? Als ich 1986 das erste Buch zu diesem Thema schrieb, gab es einen solchen Begriff nicht. Die Konzepte des "dedizierten Systems" oder "Mikrosystems" wurden verwendet, aber sie spiegelten natürlich nicht die gesamte Essenz wider. Einige Jahre später wurde das Wort „eingebaut“ verwendet, und alle Spezialisten begannen, es aktiv zu verwenden.

Zurück zur Definition eines eingebetteten Systems. Um Freunden und meiner Familie zu erklären, woran ich arbeite, habe ich folgende Erklärung gefunden: Ein eingebettetes System ist ein elektronisches Gerät mit einem Prozessor, das jedoch normalerweise nicht als Computer akzeptiert wird.

Das Betriebssystem (OS) befindet sich immer auf dem Computer. In modernen eingebetteten Systemen werden nur einige Arten von Betriebssystemen verwendet. Trotz der Tatsache, dass die Verwendung des Kernels in Hochleistungssystemen (32- und 64-Bit) vorherrscht, ist es möglich, von seiner Verwendung in Geräten mit geringem Stromverbrauch zu profitieren. Der Schwerpunkt dieser Artikel liegt auf Betriebssystemen im Allgemeinen und mit spezifischer Implementierung.

Warum überhaupt das Betriebssystem verwenden?

Mal sehen, warum Betriebssysteme grundsätzlich verwendet werden. Es gibt viele Erklärungen, von denen einige sowohl vom menschlichen Faktor als auch von technischen Merkmalen abhängen. Ich erinnere mich an die Geschichte. In einem unserer Büros gab es eine Küchenecke, in der man Kaffee kochen konnte. An der Tür befand sich ein Schild mit der Aufschrift: "Bitte schließen Sie die Tür nicht." Darunter schrieb jemand: "Warum nicht?", Worauf jemand anderes antwortete: "Weil." Eine sehr verkürzte Version des Satzes "weil wir Ihnen sagen, dass Sie genau das tun sollen." Aus den gleichen Gründen werden auf einigen Systemen Betriebssysteme verwendet, einfach weil dies erforderlich ist.

Eine weitere Erklärung ist die Verwendung von Desktop-Anwendungen. Wo fangen Sie an, wenn Sie Software für PC oder Mac schreiben? Sie schalten den Computer ein, starten Windows / Linux oder macOS und beginnen mit der Programmierung. Ein Betriebssystem zu haben, ist eine gegebene Bedingung und bietet eine Reihe nützlicher Dienste. Es ist unwahrscheinlich, dass Sie sich bei der Programmierung von Bare Metal für einen Neuanfang entscheiden. Daher ist es nicht verwunderlich, dass ein Ingenieur, der Erfahrung im Schreiben von Software hat, für den jedoch die Firmware neu ist, auf das Vorhandensein eines Betriebssystems in dem von ihm entwickelten System angewiesen ist.

Es ist erwähnenswert, dass ein wichtiger Aspekt des Desktop-Betriebssystems, den Benutzer kennen, die Benutzeroberfläche ist. Wenn Sie jemanden fragen, was Windows ist, wird er antworten, dass es sich um Fenster, Menüs, Dialogfelder und Symbole handelt. Das Dateisystem, die programmübergreifende Kommunikation und die Fähigkeit zur Interaktion mit anderen Systemen werden jedoch kaum erwähnt. Dies ist der Hauptunterschied zwischen dem Desktop und dem eingebetteten System: Letzteres verfügt möglicherweise nicht über eine Benutzeroberfläche, und wenn dies der Fall ist, ist dies recht einfach. Dies ist der erste von vielen Hauptunterschieden:

• Auf einem eingebetteten System wird normalerweise eine einzelne Softwareanwendung vom Ein- bis zum Ausschalten ausgeführt.
• Eingebettete Systeme verfügen nur über begrenzte Ressourcen. Die Speichermenge kann sehr groß sein, nicht jedoch die Tatsache, dass sie erweitert werden kann. Der Prozessor hat eine begrenzte Leistung.
• Viele eingebettete Anwendungen arbeiten in Echtzeit. Mehr dazu im Artikel unten.
• Firmware-Entwicklungstools sind spezialisiert und werden auf dem Host-Computer (z. B. einem PC) und nicht auf dem Zielsystem ausgeführt.
• Das Aktualisieren der Firmware ist ein komplexer Prozess. Trotz der Möglichkeiten, die sich durch angeschlossene Geräte ergeben, sind Firmware-Updates während des Betriebs immer noch nicht die Norm (im Gegensatz zu regulären Updates und Patches (Patches), die für Desktop-Software verwendet werden).

Bevor wir uns mit der Strukturierung eingebetteter Anwendungen befassen, werden wir die Konzepte verstehen, die auf Computern zum Ausführen von Programmen unter Verwendung des Betriebssystems verwendet werden.

Erstens gibt es eine Ausführung von Programmen im DOS-Stil, wenn die Programme abwechselnd ausgeführt werden.



Jedes Programm wird gestartet, implementiert und beendet. Wir verwenden beispielsweise Programm 1, dann Programm 2, machen dann vielleicht eine Pause, wenden uns Programm 3 zu und kehren dann zu Programm 2 zurück. Die zweite Verwendung von Programm 2 beginnt von neuem: Der Start beginnt nicht dort, wo wir aufgehört haben dies (außer in Fällen, in denen der Antrag selbst keine solche Gelegenheit bietet).

Nach DOS wurde es etwas komplizierter, da Windows mittlerweile alltäglich ist. Das Ausführen von Programmen im Windows-Stil bedeutet das Ausführen mehrerer Programme im Multithread-Modus.



In diesem Modus scheinen die Programme gleichzeitig ausgeführt zu werden, und Windows kontrolliert diese Illusion. Zuerst startet Programm 1, dann startet gleichzeitig Programm 2, dann Programm 3. Programm 2 endet, Programme 1 und 3 laufen noch. Programm 3 endet, nur Programm 1 bleibt übrig. Später wird Programm 2 fortgesetzt und Programm 1 endet, nur Programm 2 bleibt übrig. Dies ist ein realistischer Ablauf, wenn Windows von einem normalen Benutzer verwendet wird. Das Betriebssystem weist Ressourcen zu, sodass alle Programme den Prozessor korrekt verwenden. Es bietet auch eine einfache Kommunikation zwischen Programmen (z. B. Zwischenablage) und steuert die Benutzeroberfläche.

Einige tragbare Geräte erfordern mehr Flexibilität, als DOS bieten kann. Bei begrenzten Ressourcen ist jedoch ein geringerer Overhead erforderlich als bei Windows. Als Ergebnis haben wir die Ausführung von Programmen im Stil von iOS, nämlich:



Programme werden einzeln gestartet, ihr Status wird jedoch automatisch gespeichert, sodass Sie beim Schließen an derselben Stelle fortfahren können. Zum Beispiel startet Programm 1, pausiert dann, um Programm 2 zu verwenden, und dann schaltet sich das Gerät beispielsweise für eine Weile aus. Wenn Sie fortfahren, wird Programm 3 geladen (der Status von Programm 2 wurde automatisch gespeichert), und dann kehrt der Benutzer zu Programm 2 zurück und arbeitet weiter daran. Ich verstehe, dass das Ausführungsmodell einer iOS-Anwendung viel komplizierter ist als das oben beschriebene. Diese Beschreibung ist jedoch nur eine kurze Zusammenfassung der anfänglichen Wahrnehmung des Benutzers.

Die meisten integrierten Anwendungen stimmen mit keinem der oben genannten Modelle überein. In der Regel startet das Gerät das Programm beim Einschalten und arbeitet nur mit dieser Software auf unbestimmte Zeit weiter. Die Struktur eines solchen Codes sollte sorgfältig durchdacht werden.

Firmware-Modelle

Desktop-Systeme sind fast alle gleich. Aus Sicht des Anwendungsprogramms sind alle PCs mit Windows identisch. Eingebettete Systeme sind einzigartig: Jedes unterscheidet sich von den anderen. Unterschiede können technischer Natur sein: Prozessortyp, Speichergröße, Anzahl der Peripheriegeräte. Prioritätsaspekte von Anwendungen können sich auch in Geschwindigkeit, Energieverbrauch, Sicherheit und Zuverlässigkeit unterscheiden. Es kann kommerzielle Unterschiede geben, die sich auf die Preisgestaltung auswirken: Produktionsvolumen und die Wahl zwischen kundenspezifischer oder Standardhardware.

Diese Unterschiede sind für eingebettete Entwickler wichtig. Beispielsweise hängt die Auswahl der Entwicklungstools (Compiler, Debugger usw.) vom Prozessortyp ab. Viele Faktoren beeinflussen die Wahl des Betriebssystems oder sogar die Entscheidung, es grundsätzlich anzuwenden. Die Softwarestruktur (Softwaremodell) muss für jede einzelne eingebettete Anwendung sorgfältig ausgewählt werden.

Abhängig von den Anforderungen der Anwendung kann die eingebettete Software verschiedene Strukturen mit unterschiedlichen Komplexitätsstufen aufweisen, zum Beispiel:



Die einfachste Form ist eine geschlossene Struktur, in der dieselbe Abfolge von Aktionen wiederholt wird. Wenn die Anwendung so einfach ist, dass sie auf diese Weise implementiert werden kann, ist dies ideal: Einfacher Code ist zuverlässig und verständlich. Eine solche Struktur ist jedoch äußerst empfindlich gegenüber dem Teil des Codes, der zu viel Prozessorzeit in Anspruch nehmen kann, dh einige Befehle werden so lange ausgeführt, dass sie die Ausführung anderer Anwendungsaufgaben verzögern. Darüber hinaus lässt sich dieses Modell nicht gut skalieren: Die Verbesserung des Codes kann ein Problem sein, da Add-Ons die Leistung des alten Codes beeinträchtigen können.

Wenn etwas Komplizierteres benötigt wird, können Sie versuchen, einen unkritischen Teil des Codes in der Hauptschleife und einen zeitkritischen Teil im Interrupt-Handler (Interrupt Service Routines, ISR) zu platzieren. Die Aktionen des Interrupt-Handlers sind im Grunde genommen recht kurz. Er führt nur kritische Aufgaben aus und markiert Abschnitte der Hauptschleife, um die Arbeit so schnell wie möglich abzuschließen. Schwierigkeiten können auftreten, wenn die Arbeit zwischen der Hauptschleife und dem Interrupt-Handler (sowie zwischen mehreren Entwicklern) verteilt werden muss.

Für maximale Anwendungsflexibilität muss es in mehrere separate, relativ unabhängige Programme unterteilt werden (nennen wir sie Aufgaben oder Threads), die im Multithread-Modus ausgeführt werden. Es können auch kleine Interrupt-Handler in das System aufgenommen werden, die jedoch hauptsächlich über Aufgaben benachrichtigen oder eine Aktion auslösen. Um dies zu erreichen, benötigen Sie ein Betriebssystem oder zumindest einen Kernel. Die Verwendung von Multithreading bietet nicht nur eine flexible Verteilung der Funktionen in Software, sondern erleichtert auch die Verteilung der Arbeit zwischen Entwicklern.

Was ist Echtzeit?

Zuvor habe ich geschrieben, dass viele eingebettete Anwendungen in Echtzeit funktionieren. In diesem Zusammenhang ist es üblich, über Echtzeitbetriebssysteme und nicht über ein einfaches Betriebssystem zu sprechen. Definieren wir die Terminologie.

„Ein Echtzeitbetriebssystem ist ein System, bei dem die Richtigkeit von Berechnungen nicht nur von der logischen Richtigkeit der Berechnungen abhängt, sondern auch von der Zeit, für die das Ergebnis erzielt wird.

Wenn die Zeitbeschränkungen des Systems nicht eingehalten werden, wird angenommen, dass ein Systemfehler aufgetreten ist. "

Ein wichtiges Merkmal eines solchen Systems ist seine Vorhersagbarkeit oder, wie oft gesagt wird, Determinismus.

Ein Echtzeitbetriebssystem ist nicht unbedingt sehr schnell. "Echtzeit" bedeutet nicht immer "sehr schnelle Zeit". Dies bedeutet, dass alle erforderlichen Maßnahmen rechtzeitig abgeschlossen werden. Das heißt, schnell genug, aber gleichzeitig nicht zu schnell (das heißt langsam genug).

RTOS (bei korrekter Verwendung) bietet eine sehr genaue Kontrolle über die Verteilung der Prozessorzeit für Aufgaben und macht Anwendungen daher vollständig deterministisch. Das einzige, was dieses Bild ruinieren kann, sind Unterbrechungen. Es gibt RTOSs, die Interrupts vollständig steuern. Ihre Aufgabe ist es, den Interrupt-Service als Teil des Task-Schedulers zu verwalten. Trotz der Tatsache, dass dies zu vorhersehbarem Verhalten führen sollte, ist dieser Mechanismus ziemlich kompliziert und verursacht hohe Gemeinkosten.

Die meisten RTOS erlauben dem Interrupt-Handler einfach, Zeit von einer Aufgabe zu "stehlen", die zum Zeitpunkt des Interrupts ausgeführt wurde. Dies wiederum zwingt den Programmierer, den Interrupt-Handler-Code so kurz wie möglich zu schreiben. Infolgedessen haben wir einen zulässigen Fehler in Echtzeit. Die einzige Schwierigkeit besteht darin, die RTOS-Dienste im Rahmen einer Handleraufgabe aufzurufen. Einige Anrufe können ziemlich harmlos sein, während andere bei der Rückkehr von einem Interrupt einen Kontextwechsel verursachen. Diese Situation sollte speziell angegangen werden, was mit Hilfe verschiedener RTOS möglich ist.

Quelle: https://www.embedded.com/design/operating-systems/4442900/Program-structure-and-real-time

Als wir an unserem eigenen Echtzeit-Betriebssystem OSRV MAX arbeiteten (zuvor veröffentlichte Artikel darüber) , stieß unser Team auf den Blog von Colin Walls, einem Experten für Mikroelektronik und Firmware bei Mentor Graphics. Artikel schienen interessant, übersetzten sie für sich selbst, aber um nicht "an den Tisch zu schreiben", beschlossen sie, sie zu veröffentlichen. Ich hoffe, sie werden Ihnen auch nützlich sein. Wenn ja, planen wir, alle übersetzten Artikel in der Reihe zu veröffentlichen.

Über den Autor: Colin Walls ist seit über dreißig Jahren in der Elektronikindustrie tätig und widmet sich die meiste Zeit der Firmware. Heute ist er Firmware-Ingenieur bei Mentor Embedded (einer Abteilung von Mentor Graphics). Colin Walls spricht häufig auf Konferenzen und Seminaren, Autor zahlreicher technischer Artikel und zweier Bücher über Firmware. Lebt in Großbritannien. Colins professionelles Blog: http://blogs.mentor.com/colinwalls , E-Mail: colin_walls@mentor.com

Artikel 3 wird hier veröffentlicht.