Wann brauchen wir ein Betriebssystem im Embedded System Design?

Meine Faustregel lautet, dass Sie ein Betriebssystem in Betracht ziehen sollten, wenn das Produkt eines oder mehrere der folgenden Elemente erfordert: einen TCP/IP-Stack (oder einen anderen komplexen Netzwerk-Stack), eine komplexe GUI (möglicherweise eine mit GUI-Objekten wie Fenstern und Ereignissen). ) oder ein Dateisystem.

Wenn Sie Bare-Metal-Codierung gemacht haben, sind Sie wahrscheinlich mit der Super-Loop- Programmarchitektur vertraut. Wenn die Firmware-Anforderungen des Produkts einfach genug sind, um mit einem Super-Loop implementiert zu werden, der wartbar (und hoffentlich etwas erweiterbar) ist, benötigen Sie wahrscheinlich kein Betriebssystem.

Mit steigenden Softwareanforderungen wird die Superschleife komplexer. Wenn die Softwareanforderungen so hoch sind, dass die Superschleife zu komplex wird oder die Echtzeitanforderungen des Systems nicht erfüllen kann, ist es an der Zeit, eine andere Architektur in Betracht zu ziehen.

Eine RTOS-Architektur ermöglicht es Ihnen, die Softwareanforderungen in Aufgaben aufzuteilen. Wenn es richtig gemacht wird, vereinfacht dies die Implementierung jeder Aufgabe. Und mit der Task-Priorisierung kann ein RTOS die Erfüllung von Echtzeitanforderungen erleichtern. Ein RTOS ist jedoch kein Allheilmittel. Ein RTOS erhöht die Gesamtsystemkomplexität und öffnet Sie für neue Arten von Fehlern (z. B. Deadlocks). Als Alternative zum RTOS könnten Sie eine ereignisbasierte Zustandsmaschinenarchitektur (wie QP ) in Betracht ziehen.

Wenn Ihr Produkt über ein Netzwerk, eine komplexe GUI und ein Dateisystem verfügt, sind Sie möglicherweise an dem Punkt angelangt, an dem Sie Betriebssysteme mit vollem Funktionsumfang wie VxWorks, Windows oder Linux in Betracht ziehen sollten. Betriebssysteme mit vollem Funktionsumfang enthalten Treiber für die Low-Level-Details und ermöglichen es Ihnen, sich auf Ihre Anwendung zu konzentrieren.

Es hängt wirklich von Ihrer Definition eines "eingebetteten Systems" ab. Es mag einige geben, die behaupten würden, dass es nicht eingebettet ist, wenn es sich nicht um Bare-Metal-Programmierung handelt (was Ihre Frage ausschließt), aber ich würde dem nicht zustimmen - ich würde argumentieren, dass jedes System, das nur eine Funktion ausführen soll, dh nur eine bestimmte „Anwendung“ auszuführen, könnte als eingebettetes System bezeichnet werden.

Allerdings sollte es ziemlich einfach sein, sich Situationen vorzustellen, die von den Diensten eines ausgewachsenen Betriebssystems profitieren würden. Wo ich arbeite, ist es zum Beispiel ziemlich üblich, Leute zu finden, die Testgeräte auf einer Instrumentierungsdesign-Suite bauen, die auf Windows läuft. Diese Systeme sind so konfiguriert, dass sie in die Teststationskonfiguration booten und die allgemeine Verwendung sperren (um eine Beschädigung der Station zu verhindern) und sind daher wohl eingebettete Systeme.

Der Kauf von E/A-Modulen von der Stange, das Einstecken in einen Rack-PC und das Erstellen einer Konfiguration in einer GUI kann jedoch für manche nicht als Embedded- Systemdesign gelten . Für etwas weniger Standardsituationen sollten Sie einen benutzerdefinierten Prozesscontroller mit einem FPGA in Betracht ziehen, für den Sie eine ausgefallene Datenprotokollierung durchführen möchten. Sie können ein Softcore-Prozessorsystem (mit einem vorhandenen BSP) einbetten und ein Echtzeit-Linux ausführen, um einen Netzwerkstapel (für Ihre Protokollierung und NTP usw.) auszuführen und alles andere in Logik zu erledigen.

Meine (sehr vage) Faustregel lautet: Wenn Sie mehr als einen Steuerungsthread benötigen (z. B. mindestens ein Gerät, das ein Protokoll oder eine Zustandsmaschine und etwas anderes zu tun hat), wird Ihnen einige Software für Betriebssysteme das Leben erleichtern

Eine alte Frage, aber ich werde trotzdem kommentieren.

Auch wenn Sie keine Netzwerkstacks oder ähnliches haben, sollten Sie an dem Punkt, an dem Sie einen Taskplaner benötigen, da Sie genügend Prozesse in Ihrer eingebetteten Anwendung haben, ein RTOS in Betracht ziehen. Das Schreiben eines einfachen Timer-basierten kooperativen Multitasking-Schedulers ist nicht so schwierig, aber sicherzustellen, dass ein festgefahrener Prozess den Rest der Anwendung nicht blockiert, und es kann eine Weile dauern, bis dies richtig ist. Sie müssen ein Prioritätssystem mit einer Art Vorkehrung implementieren, um Prozesse in der Warteschlange nach unten zu verschieben, wenn sie nicht abgeschlossen sind.

RTOS bietet Ihnen auch Dinge wie Speicherschutz und dergleichen, was es viel einfacher macht, einige gängige Gaffes in C-Code zu verfolgen, aber einfache Mikrocontroller sind möglicherweise einfach nicht in der Lage, komplexen Speicherschutz zu handhaben. Beispielsweise ermöglicht MSP430 die Trennung von Code und Daten auf hoher Ebene, aber es gibt keine feinkörnige Speicherzugriffskontrolle.

Ein Betriebssystem überbrückt tatsächlich die Lücke zwischen Hardware und Anwendungssoftware (durch Gerätetreiber). Mit anderen Worten, es bietet dem Programmierer eine Plattform auf relativ hohem Niveau, was letztendlich die Codekomplexität reduziert. Darüber hinaus bietet das Betriebssystem eine starke und flexible Plattform für die Ausführung von Anwendungen.