Die ganze Wahrheit über RTOS. Artikel Nr. 26. Kanäle: Nebendienstleistungen und Datenstrukturen



In diesem Artikel werden wir weiterhin Datenübertragungskanäle betrachten.

Channel Support Services


Nucleus RTOS verfügt über vier API-Aufrufe, die zusätzliche Funktionen für Kanäle bereitstellen: Zurücksetzen eines Kanals, Empfangen von Kanalinformationen, Abrufen der Anzahl der Kanäle in einer Anwendung und Abrufen von Zeigern auf alle Kanäle in einer Anwendung. Die ersten drei Funktionen sind in Nucleus SE implementiert.

Frühere Artikel in der Reihe:

Artikel Nr. 25. Datenkanäle: Einführung und Basisdienste
Artikel 24. Warteschlangen: Nebendienstleistungen und Datenstrukturen
Artikel 23. Warteschlangen: Einführung und Grundversorgung
Artikel 22. Postfächer: Nebendienstleistungen und Datenstrukturen
Artikel 21. Postfächer: Einführung und Basisdienste
Artikel Nr. 20. Semaphoren: Nebendienstleistungen und Datenstrukturen
Artikel Nr. 19. Semaphoren: Einführung und Grundversorgung
Artikel Nr. 18. Ereignisflag-Gruppen: Hilfsdienste und Datenstrukturen
Artikel Nr. 17. Ereignisflag-Gruppen: Einführung und Basisdienste
Artikel 16. Signale
Artikel Nr. 15. Speicherpartitionen: Dienste und Datenstrukturen
Artikel # 14. Speicherbereiche: Einführung und Grundversorgung
Artikel Nr. 13. Aufgabendatenstrukturen und nicht unterstützte API-Aufrufe
Artikel 12. Dienstleistungen für die Arbeit mit Aufgaben
Artikel 11. Aufgaben: Konfiguration und Einführung in die API
Artikel 10. Scheduler: Erweiterte Funktionen und Kontexterhaltung
Artikel 9. Scheduler: Implementierung
Artikel 8. Nucleus SE: Internes Design und Bereitstellung
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.

Kanal zurückgesetzt


Dieser API-Aufruf setzt den Kanal auf seinen ursprünglichen, nicht verwendeten Zustand zurück. Alle darin gespeicherten Nachrichten gehen verloren. Alle auf dem Kanal angehaltenen Aufgaben werden mit dem Rückkehrcode NUSE_PIPE_WAS_RESET fortgesetzt .

Kanal-Reset-Aufruf in Nucleus RTOS

Prototyp eines Serviceabrufs:

STATUS NU_Reset_Pipe (NU_PIPE * -Pipe);

Parameter:

Pipe - Ein Zeiger auf einen benutzerdefinierten Kanalsteuerblock.

Rückgabewert:

NU_SUCCESS - Der Anruf wurde erfolgreich abgeschlossen.
NU_INVALID_PIPE - ungültiger Kanalzeiger .

Channel Reset Challenge in Nucleus SE

Dieser API-Serviceaufruf unterstützt die Kernfunktionalität der Nucleus RTOS-API.

Prototyp eines Serviceabrufs:

STATUS NUSE_Pipe_Reset (NUSE_PIPE-Pipe);

Parameter:

Pipe ist der Index (ID) der Pipe, die gelöscht wird.

Rückgabewert:

NUSE_SUCCESS - Der Anruf wurde erfolgreich abgeschlossen.
NUSE_INVALID_PIPE - Ungültiger Kanalindex .

Implementierung des Kanalrücksetzens in Nucleus SE

Der Code für die Funktion NUSE_Pipe_Reset () (nach Überprüfung der Parameter) ist ziemlich einfach. Die Start- und Endindizes des Kanals sowie der Nachrichtenzähler im Kanal werden auf 0 gesetzt.

Wenn die Task-Sperre aktiviert ist, ist zusätzlicher Code für die Wiederherstellung angehaltener Tasks verantwortlich:

while (NUSE_Pipe_Blocking_Count[pipe] != 0) { U8 index; /* check whether any tasks are blocked */ /* on this pipe */ for (index=0; index<NUSE_TASK_NUMBER; index++) { if ((LONIB(NUSE_Task_Status[index]) == NUSE_PIPE_SUSPEND) && (HINIB(NUSE_Task_Status[index]) == pipe)) { NUSE_Task_Blocking_Return[index] = NUSE_PIPE_RESET; NUSE_Task_Status[index] = NUSE_READY; break; } } NUSE_Pipe_Blocking_Count[pipe]--; } #if NUSE_SCHEDULER_TYPE == NUSE_PRIORITY_SCHEDULER NUSE_Reschedule(NUSE_NO_TASK); #endif 

Jeder auf dem Kanal angehaltenen Aufgabe wird der Status "Bereit" mit dem Rückkehrcode NUSE_PIPE_WAS_RESET zugewiesen . Nach Abschluss dieses Vorgangs wird bei Verwendung des Prioritätsplaners die Funktion NUSE_Reschedule () aufgerufen , da eine oder mehrere Aufgaben mit hoher Priorität zur Ausführung bereit sein können.

Kanalinfo


Dieser Serviceabruf gibt Kanalinformationen zurück. Die Implementierung dieses Aufrufs in Nucleus SE unterscheidet sich von Nucleus RTOS darin, dass weniger Informationen zurückgegeben werden. Dies liegt daran, dass Objektnamen, Nachrichten mit variabler Länge und die Reihenfolge der Aufgabenpausen in Nucleus SE nicht unterstützt werden und die Aufgabenpause deaktiviert werden kann.

Rufen Sie Kanalinformationen in Nucleus RTOS an
Prototyp eines Serviceabrufs:

STATUS NU_Pipe_Information (NU_PIPE * Pipe, CHAR * Name, VOID ** Startadresse, UNSIGNED * Pipe_size, UNSIGNED * verfügbar, UNSIGNED * Nachrichten, OPTION * Nachrichtentyp, UNSIGNED * Nachrichtengröße, OPTION * Suspend_Typ, UNSIGNED * Aufgaben_waask;

Parameter:

Pipe - Zeiger auf den vom Benutzer bereitgestellten Kanalsteuerblock;
name - Zeiger auf den 8-stelligen Bereich für den Kanalnachrichtennamen;
start_address - ein Zeiger auf einen Zeiger, in den die Adresse des Anfangs des Kanaldatenbereichs geschrieben wird;
pipe_size - ein Zeiger auf eine Variable zum Speichern der Gesamtzahl der Bytes im Kanal;
verfügbar - Zeiger auf eine Variable zum Speichern der Anzahl der verfügbaren Bytes im Kanal;
Nachrichten - ein Zeiger auf eine Variable zum Speichern der Anzahl von Nachrichten im Kanal;
message_type - Ein Zeiger auf eine Variable zum Speichern des vom Kanal unterstützten Nachrichtentyps. Es kann die Werte NU_FIXED_SIZE und NU_VARIABLE_SIZE annehmen .
message_size - Zeiger auf eine Variable zum Speichern der Anzahl von Bytes in jeder Kanalnachricht . Wenn der Kanal Nachrichten mit variabler Länge unterstützt, ist diese Nummer die maximale Nachrichtengröße.
suspend_type - Ein Zeiger auf eine Variable zum Speichern des Typs der Suspend-Task. Es kann die Werte NU_FIFO und NU_PRIORITY annehmen .
task_waiting - ein Zeiger auf eine Variable zum Speichern der Anzahl der auf diesem Kanal angehaltenen Aufgaben;
first_task - Ein Zeiger auf einen Zeiger auf die erste angehaltene Aufgabe.

Rückgabewert:

NU_SUCCESS - Der Anruf wurde erfolgreich abgeschlossen.
NU_INVALID_PIPE - ungültiger Kanalzeiger .

Kanalinformationen in Nucleus SE anfordern
Dieser API-Aufruf unterstützt die Kernfunktionalität der Nucleus RTOS-API.

Prototyp eines Serviceabrufs:

STATUS NUSE_Pipe_Information (NUSE_PIPE-Pipe, ADDR * Startadresse, U8 * Pipe-Größe, U8 * verfügbar, U8 * Nachrichten, U8 * Nachrichtengröße, U8 * Aufgaben warten, NUSE_TASK * first_task);

Parameter:

Pipe - Index des Kanals, Informationen darüber, welche angefordert werden;
start_address - Zeiger auf eine Variable vom Typ ADDR zum Speichern der Adresse des Anfangs des Kanaldatenbereichs ;
pipe_size - ein Zeiger auf eine Variable vom Typ U8 zum Speichern der Gesamtzahl der Nachrichten, die der Kanal empfangen kann;
verfügbar - ein Zeiger auf eine Variable vom Typ U8 zum Speichern der Anzahl der Nachrichten, für die im Kanal noch freier Speicherplatz vorhanden ist;
Nachrichten - ein Zeiger auf eine Variable vom Typ U8 zum Speichern der aktuellen Anzahl von Nachrichten im Kanal;
message_size - Zeiger auf eine Variable vom Typ U8 zum Speichern der Größe der von diesem Kanal verarbeiteten Nachrichten;
task_waiting - ein Zeiger auf eine Variable zum Speichern der Anzahl der auf diesem Kanal angehaltenen Aufgaben (nichts wird zurückgegeben, wenn die Aufgabe angehalten ist);
first_task - Ein Zeiger auf eine Variable vom Typ NUSE_TASK , die den Index der ersten angehaltenen Aufgabe übernimmt (nichts wird zurückgegeben, wenn die Aufgabe angehalten ist).

Rückgabewert:

NUSE_SUCCESS - Der Anruf wurde erfolgreich abgeschlossen.
NUSE_INVALID_PIPE - ungültiger Kanalindex ;
NUSE_INVALID_POINTER - Ein oder mehrere Zeigerparameter sind falsch.

Implementieren von Kanalinformationen in Nucleus SE

Die Implementierung dieses API-Aufrufs ist ziemlich einfach:

 *start_address = NUSE_Pipe_Data[pipe]; *pipe_size = NUSE_Pipe_Size[pipe]; *available = NUSE_Pipe_Size[pipe] - NUSE_Pipe_Items[pipe]; *messages = NUSE_Pipe_Items[pipe]; *message_size = NUSE_Pipe_Message_Size[pipe]; #if NUSE_BLOCKING_ENABLE *tasks_waiting = NUSE_Pipe_Blocking_Count[pipe]; if (NUSE_Pipe_Blocking_Count[pipe] != 0) { U8 index; for (index=0; index<NUSE_TASK_NUMBER; index++) { if ((LONIB(NUSE_Task_Status[index]) == NUSE_PIPE_SUSPEND) && (HINIB(NUSE_Task_Status[index]) == pipe)) { *first_task = index; break; } } } else { *first_task = 0; } #else *tasks_waiting = 0; *first_task = 0; #endif 

Die Funktion gibt den Status des Kanals zurück. Wenn dann Task-Sperren aktiviert sind, werden die Anzahl der ausstehenden Tasks und der Index der ersten zurückgegeben (andernfalls werden diese beiden Parameter auf 0 gesetzt).

Abrufen der Anzahl der Kanäle


Dieser Serviceabruf gibt die Anzahl der in der Anwendung konfigurierten Kanäle zurück. In Nucleus RTOS kann sich dieser Wert im Laufe der Zeit ändern, und der Rückgabewert gibt die aktuelle Anzahl von Kanälen an. In Nucleus SE wird der Rückgabewert während der Erstellungsphase festgelegt und kann nicht geändert werden.

Fordern Sie einen Kanalzähler in Nucleus RTOS an
Prototyp eines Serviceabrufs:

UNSIGNED NU_Established_Pipes (VOID);

Parameter:
Sind abwesend.

Rückgabewert:
Die Anzahl der im System erstellten Kanäle.

Fordern Sie einen Kanalzähler in Nucleus SE an
Dieser Dienstprogrammaufruf unterstützt die Kernfunktionalität der Nucleus RTOS-API

Prototyp eines Serviceabrufs:
U8 NUSE_Pipe_Count (void);

Parameter:
Sind abwesend.

Rückgabewert:
Die Anzahl der in der Anwendung konfigurierten Kanäle.

Implementierung eines Kanalzählers in Nucleus SE
Die Implementierung dieses API-Aufrufs ist recht einfach: Der Wert des Symbols #define NUSE_PIPE_NUMBER wird zurückgegeben .

Datenstrukturen


Kanäle verwenden sechs oder sieben Datenstrukturen (entweder im RAM oder im ROM), die (wie andere Nucleus SE-Objekte) eine Reihe von Tabellen sind, deren Größe und Anzahl der Anzahl der konfigurierten Kanäle und ihrer Parameter entspricht.

Ich empfehle dringend, dass der Anwendungscode keinen direkten Zugriff auf diese Datenstrukturen verwendet, sondern über die bereitgestellten API-Funktionen auf sie verweist. Dies vermeidet Inkompatibilität mit zukünftigen Versionen von Nucleus SE und unerwünschte Nebenwirkungen und vereinfacht die Portierung von Anwendungen auf Nucleus RTOS. Das Folgende ist eine detaillierte Übersicht über Datenstrukturen, um das Verständnis von Serviceabruf- und Debugging-Code zu vereinfachen.

Kerneldaten im RAM


Diese Daten haben folgende Struktur:

NUSE_Pipe_Head [] ist ein Array von Zeigern vom Typ U8 , die einen Eintrag für jeden konfigurierten Kanal haben und den Beginn des Nachrichtenkanals angeben. Wird als Adressindex in NUSE_Pipe_Data [] verwendet (siehe unten).
NUSE_Pipe_Tail [] ist ein U8- Array, das einen Eintrag für jeden konfigurierten Kanal hat und auf das Ende des Nachrichtenkanals zeigt. Wird als Adressindex in NUSE_Pipe_Data [] verwendet (siehe unten).
NUSE_Pipe_Items [] ist ein Array vom Typ U8 , das einen Eintrag für jeden konfigurierten Kanal hat und ein Zähler für die aktuelle Anzahl von Nachrichten im Kanal ist. Diese Daten sind redundant, da dieser Wert über die Kanalstart- und -endindizes erhalten werden kann, das Vorhandensein eines Zählers jedoch den Code vereinfacht.
NUSE_Pipe_Blocking_Count [] - Dieses Array vom Typ U8 enthält Zähler für die Anzahl der blockierten Aufgaben auf jedem Kanal. Dieses Array wird nur erstellt, wenn die Unterstützung für Task-Sperren aktiviert ist.

Alle diese Datenstrukturen werden beim Start von Nucleus SE von der Funktion NUSE_Init_Pipe () mit Nullen initialisiert. Dies ist logisch, da alle Kanäle leer (nicht verwendet) erstellt werden. Einer der folgenden Artikel enthält eine vollständige Beschreibung der Startvorgänge für Nucleus SE.

Im Folgenden sind die Definitionen dieser Datenstrukturen in der Datei nuse_init.c aufgeführt :

 RAM U8 NUSE_Pipe_Head[NUSE_PIPE_NUMBER]; RAM U8 NUSE_Pipe_Tail[NUSE_PIPE_NUMBER]; RAM U8 NUSE_Pipe_Items[NUSE_PIPE_NUMBER]; #if NUSE_BLOCKING_ENABLE RAM U8 NUSE_Pipe_Blocking_Count[NUSE_PIPE_NUMBER]; #endif 

RAM-Benutzerdaten


Es liegt in der Verantwortung des Benutzers, einen Datenbereich im RAM bereitzustellen, um die Daten jedes konfigurierten Kanals zu speichern. Die Größe dieses Bereichs sollte ein Array vom Typ U8 enthalten , in das alle Kanalnachrichten passen.

ROM-Daten


Die Struktur dieser Daten ist wie folgt:

NUSE_Pipe_Data [] ist ein Array vom Typ ADDR , das einen Datensatz für jeden konfigurierten Kanal enthält und den Datenbereich jedes Kanals angibt (siehe Abschnitt "Benutzerdaten im RAM" oben).
NUSE_Pipe_Size [] ist ein Array vom Typ U8 , das einen Eintrag für jeden konfigurierten Kanal hat und die Anzahl der Nachrichten anzeigt , die in jeden Kanal passen können.
NUSE_Pipe_Message_Size [] ist ein Array vom Typ U8 , das einen Datensatz für jeden konfigurierten Kanal enthält und die Größe der Nachrichten (in Byte) anzeigt, die auf jedem Kanal platziert werden können.

Diese Datenstrukturen werden (statisch) in der Datei nuse_config.c deklariert und initialisiert.

 ROM ADDR *NUSE_Pipe_Data[NUSE_PIPE_NUMBER] = { /* addresses of pipe data areas ------ */ }; ROM U8 NUSE_Pipe_Size[NUSE_PIPE_NUMBER] = { /* pipe sizes ------ */ }; ROM U8 NUSE_Pipe_Message_Size[NUSE_PIPE_NUMBER] = { /* pipe message sizes ------ */ }; 

Kanalspeicher


Wie bei allen anderen Nucleus SE-Kernobjekten ist die für die Kanäle benötigte Speichermenge vorhersehbar.

Die Datenmenge im ROM (in Bytes) für alle Kanäle in der Anwendung kann wie folgt berechnet werden:

NUSE_PIPE_NUMBER * (Größe von (ADDR) + 2)

Die Menge der Kerneldaten im RAM (in Byte) für alle Anwendungskanäle, wenn Aufgaben aktiviert sind, kann wie folgt berechnet werden:

NUSE_PIPE_NUMBER * 4

Sonst:

NUSE_PIPE_NUMBER * 3

Die Menge der Benutzerdaten im RAM (in Byte) für den Kanal mit dem Pipe- Index:

NUSE_Pipe_Size [Pipe] * NUSE_Pipe_Message_Size [Pipe]

Nicht realisierte API-Aufrufe


Vier Nucleus RTOS API-Serviceaufrufe sind in Nucleus SE nicht implementiert.

Kanalerstellung


Dieser API-Aufruf erstellt einen Kanal. Nucleus SE benötigt dies nicht, da die Kanäle statisch erstellt werden.

Prototyp eines Serviceabrufs:

STATUS NU_Create_Pipe (NU_PIPE * Pipe, CHAR * Name, VOID * Start_Adresse, UNSIGNED Pipe_Size, OPTION Nachrichtentyp, UNSIGNED Nachricht_Größe, OPTION Suspend_Typ);

Parameter:

Pipe - ein Zeiger auf den vom Benutzer bereitgestellten Kanalsteuerungsblock, der in anderen API-Aufrufen als Hauptkanalaktivator verwendet wird;
name - Zeiger auf einen 7-stelligen Kanalnamen mit einer abschließenden Null;
start_address - Kanalstartadresse;
pipe_size - die Gesamtzahl der Bytes im Kanal;
Nachrichtentyp - Nachrichtentyp, der vom Kanal unterstützt wird. Es kann die Werte NU_FIXED_SIZE oder NU_VARIABLE_SIZE annehmen .
message_size - Wenn der Kanal Nachrichten mit fester Länge unterstützt, gibt dieser Parameter die genaue Größe jeder Nachricht an. Wenn der Kanal Nachrichten mit variabler Länge unterstützt, ist dieser Wert die maximale Nachrichtengröße.
suspend_type - Gibt den Typ der Task-Suspendierung auf dem Kanal an. Es kann die Werte NU_FIFO und NU_PRIORITY (FIFO-Scheduler bzw. PRIORITY-Scheduler) annehmen.

Rückgabewert:

NU_SUCCESS - Der Anruf wurde erfolgreich abgeschlossen.
NU_INVALID_PIPE - Nullzeiger auf die Kanalsteuereinheit ( NULL ) oder die Steuereinheit wird bereits verwendet;
NU_INVALID_MEMORY - In start_address wurde ein falscher Datenbereich angegeben.
NU_INVALID_MESSAGE - ungültiger Parameter message_type ;
NU_INVALID_SIZE - Entweder ist die Nachrichtengröße größer als die Kanalgröße oder die Kanal- oder Nachrichtengröße ist Null.
NU_INVALID_SUSPEND - ungültiger suspend_type- Parameter.

Kanal löschen


Dieser API-Aufruf löscht einen zuvor erstellten Kanal. Nucleus SE benötigt es nicht, da die Kanäle statisch erstellt werden und nicht gelöscht werden können.

Prototyp eines Serviceabrufs:
STATUS NU_Delete_Pipe (NU_PIPE * -Pipe);

Parameter:
Pipe - ein Zeiger auf einen Kanalsteuerblock.

Rückgabewert:
NU_SUCCESS - Der Anruf wurde erfolgreich abgeschlossen.
NU_INVALID_PIPE - ungültiger Kanalzeiger .

Kanalzeiger


Dieser API-Aufruf erstellt eine sequentielle Liste von Zeigern auf alle Kanäle im System. In Nucleus SE ist dies nicht erforderlich, da die Kanäle durch einen einfachen Index und nicht durch einen Zeiger identifiziert werden. Daher wäre eine solche Funktion redundant.

Prototyp eines Serviceabrufs:
UNSIGNED NU_Pipe_Pointers (NU_PIPE ** Zeigerliste, UNSIGNED Maximum_Pointers);

Parameter:
pointer_list - Ein Zeiger auf ein Array von NU_PIPE- Zeigern. Dieses Array wird mit Zeigern auf zuvor erstellte Kanäle im System gefüllt.
Maximale Zeiger - Die maximale Anzahl von Zeigern im Array.

Rückgabewert:
Die Anzahl der NU_PIPE- Zeiger im Array

Auf einen Kanal senden


Dieser API-Aufruf leitet die Nachricht an alle Aufgaben weiter, die auf Nachrichten von einem bestimmten Kanal warten. In Nucleus SE wurde diese Funktion nicht implementiert, da sie die redundante Komplexität erhöht.

Prototyp eines Serviceabrufs:
STATUS NU_Broadcast_To_Pipe (NU_PIPE * -Pipe, VOID * -Nachricht, UNSIGNED-Größe, UNSIGNED-Suspend);

Parameter:
Pipe - ein Zeiger auf einen Kanalsteuerblock;
Nachricht - Zeiger auf die übertragene Nachricht;
Größe - Die Anzahl der nicht signierten Datenelemente in der Nachricht. Wenn der Kanal Nachrichten mit variabler Länge unterstützt, muss dieser Parameter gleich oder kleiner als die Größe der vom Kanal unterstützten Nachricht sein. Wenn der Kanal Nachrichten mit fester Länge unterstützt, muss dieser Parameter genau der Größe der vom Kanal unterstützten Nachrichten entsprechen.
suspend - Gibt an, ob die aufrufende Aufgabe angehalten werden soll, wenn der Kanal bereits voll ist. Dies kann NU_NO_SUSPEND , NU_SUSPEND oder ein Timeout-Wert sein.

Rückgabewert:
NU_SUCCESS - Der Anruf wurde erfolgreich abgeschlossen.
NU_INVALID_PIPE - ungültiger Zeiger auf den Kanal;
NU_INVALID_POINTER - Nullzeiger auf eine Nachricht ( NULL );
NU_INVALID_SIZE - Die angegebene Nachrichtengröße ist nicht mit der beim Erstellen des Kanals angegebenen Nachrichtengröße kompatibel.
NU_INVALID_SUSPEND - Versuch, einen nicht aufgabenbezogenen Thread auszusetzen;
NU_PIPE_FULL - Im Kanal ist nicht genügend Platz für die Nachricht vorhanden.
NU_TIMEOUT - Der Kanal ist auch nach Ablauf der angegebenen Zeitspanne noch voll.
NU_PIPE_DELETED - Der Kanal wurde gelöscht, während die Aufgabe angehalten wurde.
NU_PIPE_RESET - Der Kanal wurde zurückgesetzt, während die Aufgabe angehalten wurde.

Nucleus RTOS-kompatibel


Wie bei allen anderen Nucleus SE-Objekten war es mein Ziel, die Kompatibilität des Anwendungscodes mit Nucleus RTOS zu maximieren. Kanäle sind keine Ausnahme und werden aus Sicht des Benutzers auf die gleiche Weise wie in Nucleus RTOS implementiert. Es gibt auch eine gewisse Inkompatibilität, die ich für akzeptabel hielt, da der Code dadurch verständlicher und effizienter in Bezug auf den erforderlichen Speicher wird. Andernfalls können Nucleus RTOS-API-Aufrufe fast direkt auf Nucleus SE portiert werden.

Objektkennungen


In Nucleus RTOS werden alle Objekte durch eine Datenstruktur (Steuerblock) beschrieben, die einen bestimmten Datentyp hat. Ein Zeiger auf diese Steuereinheit dient als Kanalkennung. Ich entschied, dass in Nucleus SE ein anderer Ansatz für die effiziente Nutzung des Speichers erforderlich ist: Alle Kernelobjekte werden durch eine Reihe von Tabellen im RAM und / oder ROM beschrieben. Die Größe dieser Tabellen wird durch die Anzahl der konfigurierten Objekte jedes Typs bestimmt. Die Kennung eines bestimmten Objekts ist der Index in dieser Tabelle. Also habe ich NUSE_PIPE als das Äquivalent von U8 definiert , eine Variable (kein Zeiger) dieses Typs dient als Kanal-ID. Diese leichte Inkompatibilität ist leicht zu handhaben, wenn der Code von Nucleus SE nach Nucleus RTOS und umgekehrt portiert wird. In der Regel werden keine anderen Operationen an Objektkennungen als Verschieben und Speichern ausgeführt.

Nucleus RTOS unterstützt auch die Kanalbenennung. Diese Namen werden nur zum Debuggen verwendet. Ich habe sie von Nucleus SE ausgeschlossen, um Speicherplatz zu sparen.

Nachrichtengröße und -typ


In Nucleus RTOS kann ein Kanal so konfiguriert werden, dass er Nachrichten verarbeitet, die aus einer beliebigen Anzahl von Bytes bestehen, genau wie Nucleus SE. Nucleus RTOS unterstützt auch Nachrichtenkanäle variabler Länge, für die zum Zeitpunkt der Erstellung nur die maximale Nachrichtengröße angegeben wird. Nachrichten mit variabler Länge werden in Nucleus SE nicht unterstützt.

Kanalgröße


In Nucleus SE beträgt die maximale Anzahl von Nachrichten pro Kanal 256, da alle Variablen und Konstanten vom Typ U8 sind . Nucleuts RTOS unterliegt keinen solchen Einschränkungen.

Nicht realisierte API-Aufrufe


Nucleus RTOS unterstützt zehn Kanal-Overheads. Vier davon sind in Nucleus SE nicht implementiert. Eine ausführliche Beschreibung dieser Aufrufe sowie die Gründe für diese Entscheidung finden Sie im Abschnitt "Nicht realisierte API-Aufrufe" weiter oben in diesem Artikel.

Im folgenden Artikel werden wir die Systemzeit betrachten.

Ü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.

Source: https://habr.com/ru/post/de433374/


All Articles