Die ganze Wahrheit über RTOS. Artikel 8. Nucleus SE: Internes Design und Bereitstellung

Dieser Artikel setzt die Überprüfung von Nucleus SE fort.

Dienstleistungen

Nucleus SE bietet eine Reihe von Tools, die von jedem RTOS erwartet werden können.
Erstens enthält Nucleus SE einen relativ einfachen Scheduler, der jedoch dank der vier verfügbaren Optionen Flexibilität bietet. Der Scheduler unterstützt die Algorithmen Run to Completion, Round Robin, Carousel, Time Slice und Priority.

Die Nucleus SE-API enthält etwa 50 Dienstprogrammaufrufe, mit denen Entwickler auf Aufgabenverwaltung, Speicherabschnitte, Signale, Ereignisflaggruppen, Semaphoren, Postfächer, Warteschlangen, Pipelines, Systemzeit, Anwendungszeitgeber und Diagnose zugreifen können.

Neben der einfachen Aufgabenplanung unterstützt Nucleus SE (optional) die Aufgabenpause. Diese Funktion kann "sauber" sein (z. B. als Ergebnis eines explizit festgelegten API-Aufrufs für den Suspendierungsdienst), eine "Sleep" -Funktion (wenn eine Task für einen bestimmten Zeitraum angehalten wird) oder das Ergebnis eines anderen API-Aufrufs, bei dem die Task blockiert wird (die sogenannte "bedingte" Suspendierung), die auf den Zugriff auf die Kernelressource wartet. Im Gegensatz zu Nucleus RTOS unterstützt Nucleus SE keine Zeitüberschreitungen beim Blockieren von API-Aufrufen.

Die Vielzahl der vorgestellten Mechanismen ermöglicht es Ihnen, aus einer Hierarchie von Mitteln zur Synchronisierung und Kommunikation zwischen Aufgaben auszuwählen: von Semaphoren über Signale, Ereignisflags, Postfächer bis hin zu Warteschlangen / Pipelines.

Frühere Artikel in der Reihe:
Artikel 7. Nucleus SE: Einführung
Artikel 6. Andere RTOS-Dienste
Artikel 5. Aufgabeninteraktion und Synchronisation
Artikel 4. Aufgaben, Kontextwechsel und Interrupts
Artikel 3. Aufgaben und Planung
Artikel 2. RTOS: Struktur und Echtzeitmodus
Artikel 1. RTOS: Einführung.

Überprüfung der Parameter

Bei Auswahl der Konfiguration NUSE_API_PARAMETER_CHECKING ist der Code zum Überprüfen der Parameter in allen API-Funktionen enthalten: Überprüfen auf Nullzeiger, Objektindizes usw. Da dies zusätzlicher Code ist, der zusätzlichen Speicher benötigt, ist es ratsam, diese Funktion während des Debuggens zu aktivieren, sie jedoch in der Release-Assembly zu deaktivieren.

Konfiguration

Nucleus SE hat eine flexible Struktur, die uns zwei positive Punkte gibt. Einerseits kann der Kernel eine fein abgestimmte Konfiguration haben, die aufgrund der einfachen Konfiguration der verfügbaren Funktionen und der einfachen Verwaltung der Speichernutzung die Aufgaben einer bestimmten Anwendung erfüllt. Andererseits kann der Nucleus SE-Code problemlos zwischen beiden Tools und zwischen Prozessoren übertragen werden.

Namenskonventionen

Da Klarheit und Verständlichkeit bei der Entwicklung von Nucleus SE wichtig waren, wurden die Namenskonventionen sorgfältig durchdacht. Jedem Zeichen im Code wird NUSE_ vorangestellt . Alles, was diesem Präfix folgt, folgt einer Reihe einfacher Regeln.

API-Aufrufe

Jede API- Aufruffunktion in Nucleus SE beginnt mit NUSE_, auf das fast immer ein Objekttyp folgt, gefolgt von einer Operation in gemischten Groß- und Kleinschreibung, die durch Unterstriche getrennt ist. Ein Beispiel ist die Funktion NUSE_Queue_Send () , mit der Nachrichten in die Warteschlange gestellt werden .

Andere Funktionen und Variablen

Die übrigen Funktionen und (globalen) Variablen im Nucleus SE-Code verwenden ebenfalls das Präfix NUSE_, der Rest des Namens hat jedoch nicht immer eine „Struktur“. Dies ist für den durchschnittlichen Kernel-Benutzer unwichtig, da er über genügend API-Funktionen verfügt.

Konfigurationssymbole

Da Nucleus SE mit # define-Zeichen konfiguriert ist, befolgen sie auch Namenskonventionen. Sie werden nur in Großbuchstaben geschrieben. Die Namen der Aktivatoren der API-Aufrufe stimmen mit den Namen der Funktionen überein und werden auch in Großbuchstaben geschrieben, z. B. NUSE_QUEUE_SEND.

Andere #define Zeichen

Alle anderen # Define- Zeichen (z. B. API-Aufrufparameter und Rückgabestatuswerte), die vom Anwendungscode verwendet werden können, befolgen dieselben Regeln. Sie beginnen mit NUSE_ und werden in Großbuchstaben geschrieben. Zum Beispiel NUSE_SUCCESS.

Datenstrukturen

Alle RTOSs verfügen über eine Reihe von Datenstrukturen, die Kernelobjekte beschreiben. In den meisten Implementierungen handelt es sich um Datenstrukturen in C, die verknüpfte Listen bilden, häufig mit bidirektionaler und sogar zirkulärer Kommunikation. Dies ist logisch, da wichtige Daten bequem gekapselt werden und Listenelemente hinzugefügt oder gelöscht werden können, wenn Objekte erstellt und gelöscht werden.

In Nucleus SE sind alle Objekte statisch, daher war es naheliegend, alle Datenstrukturen dieser Objekte in einer einfachen Liste zu organisieren. Dies reduziert das Volumen und die Komplexität von Vorwärts- und Rückwärtszeigern. Ich entschied mich jedoch, die Optimierung des Systems zu verstärken und lehnte es ab, überhaupt Strukturen zu verwenden. In Nucleus SE werden alle Daten von Kernelobjekten durch mehrere einfache Arrays (auch als Tabellen bezeichnet) verschiedener Typen dargestellt, eines oder mehrere für jeden Objekttyp. Es gibt mehrere Argumente für diese Entscheidung:

• Nucleus SE wurde unter Berücksichtigung der Kompatibilität mit 8-Bit-Strukturen entwickelt. Die meisten kleinen CPUs verfügen nicht über optimale Tools zum Implementieren von Datenstrukturen in einem C-Compiler. Einfache Arrays sind viel effizienter.
• Da die maximal zulässige Anzahl von Objekten jedes Typs 16 beträgt und der Zugriff auf die Elemente jedes Arrays vier Bits erfordert, wird häufig ein Byte verwendet. Dies ist effizienter als eine Adresse, die normalerweise 16 oder 32 Bit benötigt.
• Permanente Objektdaten müssen im ROM gespeichert und nicht in den RAM kopiert werden. Da die Struktur nicht zwischen ROM und RAM aufgeteilt werden kann (im herkömmlichen tragbaren C), kann jeder Objekttyp zwei Strukturen aufweisen, was zu komplex ist. In Nucleus SE können Objektbeschreibungstabellen je nach Bedarf sowohl im ROM als auch im RAM gefunden werden.
• Aufgrund der hohen Konfigurierbarkeit von Nucleus SE („ultrahohe Skalierbarkeit“) können einige Objektbeschreibungsdaten abhängig von den ausgewählten Werkzeugen optional sein. Dies führt zu einer weit verbreiteten Verwendung der bedingten Kompilierung. Eine strukturelle Definition mit integrierten Anweisungen zur bedingten Kompilierung ist sehr schwer zu verstehen. Die Steuerung der Instanziierung einzelner Arrays mit dieser Methode ist wiederum recht einfach zu verstehen.

Alle Objektdatentabellen unterliegen der oben genannten hierarchischen Namenskonvention. Somit ist es ziemlich leicht zu verstehen, welche Tabellen logisch zusammenhängen.

Hauptunterschiede zu Nucleus RTOS

Obwohl Nucleus SE mit einem hohen Grad an Kompatibilität mit Nucleus RTOS entwickelt wurde, konnten einige kleine und größere Unterschiede nicht vermieden werden. Sie werden in den entsprechenden Artikeln ausführlich beschrieben, und eine kurze Beschreibung wird unten gegeben.

Objektdaten

In Nucleus RTOS werden Objekte auf Anfrage erstellt und gelöscht. In Nucleus SE werden alle Objekte statisch erstellt und während der Montage festgelegt.

Anzahl der Objekte

Nucleus RTOS unterstützt eine unbestimmte Anzahl von Objekten jedes Typs. Nucleus SE unterstützt maximal 16 Objekte jedes Typs.

Objektnamen

Mit Nucleus RTOS können Sie einigen Objekttypen Texttypen zuweisen, die zum Debuggen verwendet werden können. Nucleus SE verfügt nicht über diese Funktion.

Task-Sperrmechanismus

Der Mechanismus zum Blockieren von Aufgaben mit einem API-Aufruf in Nucleus SE ist ziemlich einfach. Wenn eine Ressource freigegeben wird, werden alle ausstehenden Aufgaben fortgesetzt und konkurrieren (mithilfe des Aufgabenplaners) um Ressourcen. Die verlorenen Aufgaben werden erneut ausgesetzt (blockiert). In Nucleus RTOS ist der Mechanismus komplexer, es werden nur wichtige Aufgaben ausgeführt, was effektiver ist.

API-Aufruf-Timeout

Beim Aufrufen der blockierenden API kann der Entwickler mit Nucleus RTOS eine Zeitüberschreitung angeben, nach der der Aufruf fortgesetzt wird, auch wenn die Ressource nicht freigegeben wird. Nucleus SE verfügt nicht über diese Funktion.

Aufgabenplanung

Der Nucleus RTOS Scheduler ist flexibel, effizient und gut definiert. Nucleus SE bietet eine Reihe von Schedulern, von denen jeder einfach und effektiv genug für eine reduzierte Anzahl unterstützter Aufgaben ist: von 1 bis 16.

Aufgabenprioritäten

Ein System, das Nucleus RTOS verwendet, kann eine beliebige Anzahl von Aufgaben haben, denen eine von 256 Prioritätsstufen zugewiesen werden kann, während mehrere Aufgaben eine Prioritätsstufe haben können. Die Aufgabenprioritätsstufen können sich auch zur Laufzeit ändern. Wenn in Nucleus SE ein Prioritätsplaner ausgewählt ist, muss jede Aufgabe eine eindeutige Prioritätsstufe haben, die nicht dynamisch geändert werden kann. Es kann nur eine Prioritätsstufe pro Aufgabe geben.

Behandlung unterbrechen

Nucleus RTOS unterstützt die ausgefeilte Architektur eines zweistufigen Interrupt-Handlers, der eine effiziente Interoperabilität zwischen Interrupt-Handler und Kernel-Diensten ermöglicht. Nucleus SE verwendet einen ähnlichen Ansatz, der sowohl einfache Interrupt-Handler ohne Kernel (nicht verwaltete Interrupts) als auch vollständig kontextsensitive Interrupt-Handler unterstützt, die API-Aufrufe (verwaltete Interrupts) verwenden können.

Gerätetreiber

Nucleus RTOS verfügt über eine gut gestaltete Gerätetreiberarchitektur. Nucleus SE verfügt nicht über eine solche Architektur, sodass der Entwickler die Aufgabe hat, die Gerätesteuerung auf die Aufgaben und den Interrupt-Handler-Code zu verteilen.

Verteilung von Nucleus SE

Die Quellcodes von Nucleus SE werden im Zuge der Entwicklung dieser Artikelserie veröffentlicht. Verfügbare Dateien sind auf Anfrage per E-Mail erhältlich. Gegen Ende der Artikelserie wird ein Repository zum Herunterladen aller veröffentlichten Dateien erstellt.