
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 BasisdiensteArtikel 24. Warteschlangen: Nebendienstleistungen und DatenstrukturenArtikel 23. Warteschlangen: Einführung und GrundversorgungArtikel 22. Postfächer: Nebendienstleistungen und DatenstrukturenArtikel 21. Postfächer: Einführung und BasisdiensteArtikel Nr. 20. Semaphoren: Nebendienstleistungen und DatenstrukturenArtikel Nr. 19. Semaphoren: Einführung und GrundversorgungArtikel Nr. 18. Ereignisflag-Gruppen: Hilfsdienste und DatenstrukturenArtikel Nr. 17. Ereignisflag-Gruppen: Einführung und BasisdiensteArtikel 16. SignaleArtikel Nr. 15. Speicherpartitionen: Dienste und DatenstrukturenArtikel # 14. Speicherbereiche: Einführung und GrundversorgungArtikel Nr. 13. Aufgabendatenstrukturen und nicht unterstützte API-AufrufeArtikel 12. Dienstleistungen für die Arbeit mit AufgabenArtikel 11. Aufgaben: Konfiguration und Einführung in die APIArtikel 10. Scheduler: Erweiterte Funktionen und KontexterhaltungArtikel 9. Scheduler: ImplementierungArtikel 8. Nucleus SE: Internes Design und BereitstellungArtikel 7. Nucleus SE: EinführungArtikel 6. Andere RTOS-DiensteArtikel 5. Aufgabeninteraktion und SynchronisationArtikel 4. Aufgaben, Kontextwechsel und InterruptsArtikel 3. Aufgaben und PlanungArtikel 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 RTOSPrototyp 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 SEDieser 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 SEDer 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 anPrototyp 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 anfordernDieser 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 SEDie 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 anPrototyp 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 anDieser 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 SEDie 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 * 4Sonst:
NUSE_PIPE_NUMBER * 3Die 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.