Die ganze Wahrheit über RTOS. Artikel 32. Nucleus SE-Migration: Nicht realisierte Funktionen und Kompatibilität

Die Hauptanforderung für die Entwicklung von Nucleus SE war ein hohes Maß an Kompatibilität mit dem Hauptprodukt von Mentor RTOS - Nucleus RTOS. Nucleus SE unterstützt einen bestimmten Teil der Funktionalität von Nucleus RTOS, der in früheren Artikeln bereits mehrfach diskutiert wurde. In diesem Artikel werde ich jedoch versuchen, alle wichtigen Unterschiede an einem Ort zu sammeln. Dieser Artikel war als Kurzreferenz für alle gedacht, die von einem Kern zum anderen wechseln oder gerade einen Kernel für ein bestimmtes Projekt auswählen.



Neben eingeschränkten oder vereinfachten Funktionen im Vergleich zu Nucleus RTOS wurde Nucleus SE auch mit dem Schwerpunkt auf der Maximierung der Speichernutzung mit umfangreichen Anpassungsoptionen entwickelt. Ein wichtiger Teil dieses Ansatzes ist die Skalierbarkeit. Viele Funktionen der Kernelfunktionalität können bei Bedarf aktiviert oder deaktiviert werden. Das Deaktivieren der Funktionalität in einer bestimmten Implementierung erhöht offensichtlich die Inkompatibilität mit Nucleus RTOS.

In Nucleus RTOS kann ein System mit einer unbestimmten Anzahl von Kernelobjekten erstellt werden, wobei die einzige Einschränkung hier die Menge der verfügbaren Ressourcen (d. H. Speicher) ist. Nucleus SE hat eine Begrenzung von 16 Objekten jedes Typs; Das System kann eine bis sechzehn Aufgaben und null bis sechzehn Objekte jedes Typs (Postfächer, Warteschlangen usw.) haben. Trotz der Tatsache, dass diese Grenze erhöht werden kann, ist ein erheblicher Aufwand erforderlich, da Nucleus SE die Möglichkeit, den Index eines Objekts in einem Halbbyte (vier Bits) zu speichern, in großem Umfang nutzt. Darüber hinaus wird der Prioritätsplaner bei mehr als 16 Aufgaben wahrscheinlich sehr ineffizient. Eine Anwendung, deren Funktionalität ernsthaft unter diesen Einschränkungen leidet, ist für Nucleus SE nicht geeignet. In diesem Fall ist Nucleus RTOS eine viel geeignetere Wahl.

Planer

Wie alle modernen Echtzeitkerne verfügt Nucleus RTOS über einen sehr flexiblen Scheduler, der mehrere Prioritätsstufen (mit einer unbestimmten Anzahl von Aufgaben auf jeder Prioritätsstufe) sowie die Möglichkeit bietet, den Round Robin- und Time Slice-Scheduler auszuwählen. Nucleus SE ist viel einfacher und bietet vier Scheduler, die zum Zeitpunkt der Erstellung ausgewählt werden müssen: Run to Completion, Round Robin, Time Slice und Priority. Es ist unmöglich, verschiedene Scheduler zu kombinieren (dh es gibt keinen zusammengesetzten Scheduler). Beispielsweise können Sie keine Kombination aus Zeitscheiben- und Prioritätsplanern auswählen. Darüber hinaus können Sie mit dem Prioritätsplaner jeder Prioritätsstufe nur eine Aufgabe zuweisen, dh es gibt so viele Prioritätsstufen wie Aufgaben. Die Priorität der Aufgabe wird während des Builds festgelegt und ändert sich nicht mehr (wie das Zeitfenster, wenn der Zeitscheibenplaner ausgewählt ist).

API-Aufrufe

Application Programming Interface (API) - das sichtbare „Gesicht“ des Betriebssystems. Es überrascht nicht, dass hier die Unterschiede zwischen Nucleus RTOS und Nucleus SE am offensichtlichsten sind.

Die Nucleus SE-API unterscheidet sich von der Nucleus RTOS-API. Die Nucleus SE-API wurde jedoch sorgfältig entwickelt, damit sie auf das Nucleus RTOS-API-Fragment übertragen werden kann. Inhaber von lizenziertem Nucleus RTOS können eine "Shell" (eine Header-Datei mit # Define- Makros) erhalten, die die Übertragung fast direkt ausführt.

Aus der Tatsache, dass die Nucleus SE-API als „Teilmenge“ der Nucleus RTOS-API bezeichnet werden kann, folgt, dass einige API-Aufrufe fehlen. Dies ist wahr und ein unvermeidliches Ergebnis der Entwicklungskriterien von Nucleus SE. Einige API-Aufrufe sind einfach nicht sinnvoll, da sie mit nicht vorhandenen Funktionen verknüpft sind. Andere Aufrufe wurden ausgeschlossen, um die Implementierung einiger Kernelobjekte zu vereinfachen. All dies wird in den folgenden Abschnitten dieses Artikels ausführlich beschrieben.

Allgemeine API-Funktionen

Nucleus RTOS verfügt über API-Funktionen, die verschiedenen Arten von Kernelobjekten oder sogar allen Arten von Objekten gemeinsam sind. Einige von ihnen wurden auch in Nucleus SE implementiert, ein gutes Beispiel für eine solche Funktion ist das Zurücksetzen. Andere Funktionen gelten nicht für die Implementierung von Kernelobjekten in Nucleus SE.

Erstellen und löschen

In Nucleus RTOS sind alle Kernelobjekte dynamisch und werden nach Bedarf erstellt und gelöscht. Daher gibt es dafür API-Aufrufe. In Nucleus SE sind alle Objekte statisch (sie werden während der Assembly erstellt), sodass diese API-Aufrufe nicht benötigt werden.

Zeiger auf Objekte zurückgeben

Die Hauptkennung (Deskriptor) von Kernelobjekten in Nucleus RTOS ist ein Zeiger auf den Objektsteuerblock, der beim Erstellen des Objekts zugewiesen wird. Daher gibt es auch eine Reihe von API-Aufrufen, die eine Liste von Zeigern auf Objekte jedes Typs zurückgeben. Da Nucleus SE einen einfachen Index verwendet, um Kernelobjekte zu identifizieren, sind solche Aufrufe nicht erforderlich. Ein Programm kann den Kernel abfragen, um herauszufinden, wie viele Instanzen von Objekten eines bestimmten Typs konfiguriert sind (mithilfe eines Aufrufs wie NUSE_Mailbox_Count () ). Wenn dieser Wert n ist , haben die Indizes von Objekten dieses Typs Werte von Null bis n-1 .

Daten-Streaming

Für einige Arten von Nucleus RTOS-Kernelobjekten (z. B. Postfächer, Warteschlangen und Pipes) wird ein API-Overhead bereitgestellt, um die Daten zu übersetzen. Auf diese Weise können Sie Daten an jede Aufgabe senden, die Daten vom Objekt erwartet. Diese Möglichkeit wurde zur Vereinfachung von Nucleus SE ausgeschlossen, da der Zugriff auf die Daten solcher Objekte immer im Kontext einer bestimmten Aufgabe erfolgt, wodurch das Objekt freigegeben wird. Um eine Übersetzung zu implementieren, wäre daher ein zusätzlicher Flag-Mechanismus erforderlich.

API-Objekte mit einzigartigen Funktionen

Viele Kernelobjekte verfügen über API-Aufrufe, die für einen bestimmten Objekttyp eindeutig sind und sich in Nucleus RTOS und Nucleus SE unterscheiden.

Die Aufgaben

Da der Nucleus RTOS Scheduler wesentlich komplexer als der Nucleus SE ist, sind einige API-Funktionen nicht erforderlich:

• Ändern der Position eines Task-Interrupts - wird in Nucleus SE nicht unterstützt.
• Aufgabenpriorität ändern - In Nucleus SE wird die Aufgabenpriorität während der Konfiguration zugewiesen und kann nicht geändert werden.
• Ändern des Task-Zeitfensters - In Nucleus SE ist der Wert des Zeitfensters allen Aufgaben gemeinsam und wird während der Konfiguration festgelegt.
• Aufgabenerfüllung - Nucleus SE unterstützt den Status "abgeschlossene Aufgabe" nicht.

Dynamischer Speicher

Da in Nucleus SE alles statisch erstellt wird, wird der dynamische Speicher nicht unterstützt (und ist nicht erforderlich). Daher sind auch die zugehörigen API-Funktionen nicht erforderlich.

Signale

Nucleus RTOS unterstützt Signalhandler, Programme, die ausgeführt werden (wie Interrupt-Handler), wenn sich Task-Signale ändern. Diese Funktion wurde von Nucleus SE ausgeschlossen. Daher sind API-Aufrufe zum Verwalten der Signale und zum Erstellen eines Signalhandlers nicht erforderlich.

Unterbrechungen

Nucleus SE verwendet den Nicht-Interrupt-Ansatz von Interrupts und bietet lediglich die Möglichkeit, einige API-Aufrufe vom Interrupt-Handler auszuführen. Daher werden einige Nucleus RTOS-API-Aufrufe, die angeben, wie der Kernel mit Interrupts umgehen soll, nicht unterstützt.

Diagnose

Nucleus SE verfügt über sehr bescheidene Diagnosedienste, die seinem "zurückhaltenden" Entwicklungsstil folgen und sich auf die (optionale) Parameterprüfung und Ausgabe des Produktversionscodes beschränken. Daher werden Nucleus RTOS-API-Aufrufe im Zusammenhang mit der Protokollierung des Verlaufs und der Fehlerbestätigung nicht unterstützt.

Treiber

Nucleus RTOS verfügt über eine genau definierte formale Treiberstruktur und mehrere API-Funktionen im Zusammenhang mit der Treiberverwaltung. Nucleus SE hat diese Struktur nicht, daher sind entsprechende API-Aufrufe nicht erforderlich.

API-Aufruffunktion

Einige Aspekte der Funktionalität von Nucleus SE, die in vereinfachter Form implementiert sind, führen zu Unterschieden zu Nucleus RTOS. Einige davon wirken sich auf die Verwendung von API-Aufrufen und die verfügbaren Dienste aus.

Zeitüberschreitungen

Bei Verwendung von Nucleus RTOS kann es häufig vorkommen, dass ein API-Aufruf eine Aufgabe anhalten kann, die auf den Zugriff auf eine Ressource wartet: Die Aufgabe wird blockiert. Eine solche Unterbrechung einer Aufgabe kann implizit sein (dh bis die Ressource verfügbar wird), oder es kann ein Zeitlimitwert angegeben werden. Nucleus SE bietet optional die Blockierung durch API-Aufrufe. Es kann jedoch nur eine implizite Unterbrechung verwendet werden ( dh ein Aufruf kann nur NUSE_SUSPEND oder NUSE_NO_SUSPEND verwenden , keinen Timeout-Wert). Diese Funktion kann ganz einfach zu Nucleus SE hinzugefügt werden.

Suspendierungsverfahren

Wenn in Nucleus RTOS mehrere Objekttypen erstellt werden, kann eine Suspendierungsreihenfolge zugewiesen werden. Dies ist eine Sequenz, in der mehrere blockierte Aufgaben fortgesetzt werden, sobald Ressourcen verfügbar werden. Es stehen zwei Optionen zur Verfügung: FIFO, First-In-First-Out (First-In-First-Out), bei dem Aufgaben in derselben Reihenfolge wieder aufgenommen werden, in der sie blockiert sind; oder nach Priorität, bei der die Aufgabe mit der höchsten Priorität immer zuerst fortgesetzt wird. Nucleus SE bietet eine solche Auswahl nicht an. Es wird nur die Prioritätsreihenfolge implementiert. Tatsächlich ist es korrekter, die Reihenfolge anhand des Aufgabenindex zu sagen, da die Suspendierungsreihenfolge nicht nur bei Verwendung des Prioritätsplaners, sondern auch bei Verwendung der Round Robin- und Time Slice-Planer angewendet werden kann.

Einzigartige Funktionsfunktionalität

In einigen Fällen waren funktionale Änderungen in Bezug auf bestimmte Objekttypen erforderlich.

Signalhandler
Wie oben erwähnt, unterstützt die Signalimplementierung in Nucleus SE keine Signalverarbeitungsverfahren.

Anwendungs-Timer-Einstellungen
Der Timer hat eine Anfangsdauer / Anfangsbetriebsdauer und eine Dauer eines Neustarts und kann optional eine benutzerdefinierte Funktion nach Abschluss ausführen. Diese Funktionalität wird sowohl in Nucleus RTOS als auch in Nucleus SE unterstützt. Im Gegensatz zu Nucleus RTOS erlaubt Nucleus SE jedoch keine Änderung der oben beschriebenen Parameter, wenn die API-Funktion zum Zurücksetzen aufgerufen wird. Darüber hinaus ist in Nucleus SE jede Unterstützung für Timer-Abschlussverfahren optional.

Ereignisflags
Nucleus RTOS bietet die Option, Ereignisflags zu „absorbieren“. Dies bedeutet, dass Flags zurückgesetzt werden, die den von der Aufgabe festgelegten Kriterien entsprechen. Diese Funktionalität wird in Nucleus SE nicht unterstützt, da die Möglichkeit, nach den Kriterien mehrerer Aufgaben zu suchen, die Komplexität des Systems erheblich erhöht.

Datengrößen

Zwei Entwicklungskriterien für Nucleus SE: Die Aufrechterhaltung der Einfachheit und die Minimierung der Speichernutzung haben zu bestimmten Unterschieden bei der Größe der Datenelemente im Vergleich zu Nucleus RTOS geführt. Es ist erwähnenswert, dass Nucleus RTOS normalerweise vorzeichenlose Daten verwendet, bei denen es sich höchstwahrscheinlich um 32-Bit handelt. während Nucleus SE optimierte Datentypen wie U32 , U16 , U8 usw. verwendet. ( Anmerkung des Übersetzers: Meiner Meinung nach ist der Autor für 8-Bit-Systeme richtig. In modernen Systemen sind die Register immer noch 32-Bit, so dass das Schneiden des älteren Teils Speicher für Code- und Taktzyklen für seine Ausführung verbraucht und die Daten bei der Speicherung alle gleich 32 Bit sind Speicher, sonst sinkt die Systemleistung, so dass dieser Ansatz für moderne Systeme keinen Gewinn bringt, und ein Verlust aufgrund der vom Compiler hinzugefügten Anweisungen, die den älteren Teil abschneiden, kann sehr gut sein. ).

Postfächer

In Nucleus RTOS speichert ein Postfach eine Nachricht, die aus vier vorzeichenlosen Datenelementen besteht. In Nucleus SE speichert ein Postfach ein ADDR- Datenelement. Meiner Meinung nach werden Postfächer häufig verwendet, um eine Adresse (die bestimmte Daten angibt) von Aufgabe zu Aufgabe zu übertragen.

Warteschlangen

In Nucleus RTOS verarbeitet eine Warteschlange Nachrichten von einem oder mehreren vorzeichenlosen Datenelementen. Die Warteschlange kann auch für die Verarbeitung von Nachrichten mit variabler Länge konfiguriert werden. In Nucleus SE verarbeitet eine Warteschlange Nachrichten, die aus einem einzelnen ADDR- Datenelement bestehen. Meiner Meinung nach werden Warteschlangen bei Postfächern auf ähnliche Weise verwendet. Zusätzlich wird in Nucleus RTOS die Gesamtgröße der Warteschlange (d. H. Die Gesamtzahl der vorzeichenlosen Elemente, die in die Warteschlange gestellt werden können) als vorzeichenloser Wert angegeben. In Nucleus SE ist dieser Wert vom Typ U8 . Daher kann eine Warteschlange weniger Daten enthalten.

Datenkanäle

In Nucleus RTOS verarbeitet ein Kanal Nachrichten von einem oder mehreren Bytes. Der Kanal kann auch für die Verarbeitung von Nachrichten mit variabler Länge konfiguriert werden. In Nucleus SE verarbeitet ein Kanal Nachrichten, die aus einem oder mehreren Datenelementen vom Typ U8 bestehen . Die Nachrichtengröße wird während des Setups für jeden Kanal festgelegt. Außerdem wird in Nucleus RTOS die Gesamtkanalgröße ( dh die Gesamtzahl der Bytes, die in einem Kanal platziert werden können) als nicht gesungener Wert angegeben . In Nucleus SE ist dieser Wert vom Typ U8 und stellt die Anzahl der Nachrichten dar (im API-Aufruf NUSE_Pipe_Information () ). Folglich kann ein Kanal weniger Daten enthalten.

Ereignisflag-Gruppen

In Nucleus RTOS enthält eine Ereignisflag-Gruppe 32 Flags. in Nucleus SE wird ihre Anzahl auf acht reduziert. Diese Größe wurde gewählt, da die wahrscheinlichen Ziel-Nucleus SE-Prozessoren 8-Bit-Daten effizient verarbeiten können. Gleichzeitig wird es nicht schwierig sein, die Anzahl der Flags in den von Nucleus SE verarbeiteten Flag-Gruppen von Ereignissen zu ändern.

Signale

In Nucleus RTOS verfügt jede Task über einen Satz von 32 Signalflags. In Nucleus SE sind Signale optional, und jede Aufgabe verfügt über einen Satz von 8 Flags. Diese Größe wurde gewählt, weil die wahrscheinlichen Ziel-Nucleus SE-Prozessoren 8-Bit-Daten effizient verarbeiten können. Gleichzeitig wird es nicht schwierig sein, die Anzahl der Flags in den von Nucleus SE verarbeiteten Flaggensätzen von Signalen zu ändern.

Abschnitte des Gedächtnisses

In Nucleus RTOS sind Anzahl und Größe der Partitionen ohne Vorzeichen . In Nucleus SE ist die Anzahl der Partitionen ein Parameter vom Typ U8 und die Partitionsgröße ist U16 . Dies führt zu einigen Einschränkungen der Partitions- und Poolgröße.

Timer

In Nucleus RTOS arbeiten Timer (sowohl Anwendungs-Timer als auch Task-Sleep-Timer) mit vorzeichenlosen Werten. In Nucleus SE sind sie vom Typ U16 . Dieser Typ wurde gewählt, weil die wahrscheinlichen Ziel-Nucleus SE-Prozessoren 16-Bit-Daten effizient verarbeiten können (und acht Bit eindeutig nicht ausreichen, um einen Timer zu verwenden). Gleichzeitig wird es nicht schwierig sein, die Größe der Timer in Nucleus SE zu ändern.

Im folgenden Artikel wird untersucht, wie Nucleus SE in einem eingebetteten Softwareprojekt verwendet werden kann.

Ü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 professioneller Blog , E-Mail: colin_walls@mentor.com.