Wählen Sie Ihre Cookie-Einstellungen aus

Wir verwenden essentielle Cookies und ähnliche Tools, die für die Bereitstellung unserer Website und Services erforderlich sind. Wir verwenden Performance-Cookies, um anonyme Statistiken zu sammeln, damit wir verstehen können, wie Kunden unsere Website nutzen, und Verbesserungen vornehmen können. Essentielle Cookies können nicht deaktiviert werden, aber Sie können auf „Anpassen“ oder „Ablehnen“ klicken, um Performance-Cookies abzulehnen.

Wenn Sie damit einverstanden sind, verwenden AWS und zugelassene Drittanbieter auch Cookies, um nützliche Features der Website bereitzustellen, Ihre Präferenzen zu speichern und relevante Inhalte, einschließlich relevanter Werbung, anzuzeigen. Um alle nicht notwendigen Cookies zu akzeptieren oder abzulehnen, klicken Sie auf „Akzeptieren“ oder „Ablehnen“. Um detailliertere Entscheidungen zu treffen, klicken Sie auf „Anpassen“.

Inter-Task-Koordination - Kostenlos RTOS

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Inter-Task-Koordination

Dieser Abschnitt enthält Informationen über freie RTOS Primitive.

Warteschlangen

Warteschlangen sind die primäre Form der Inter-Task-Kommunikation. Sie können verwendet werden, um Nachrichten zwischen Tasks und zwischen Interrupts und Tasks zu senden. In den meisten Fällen werden sie als Thread-sichere First In First Out (FIFO) -Puffer verwendet, wobei neue Daten an das Ende der Warteschlange gesendet werden. (Daten können auch an den Anfang der Warteschlange gesendet werden.) Nachrichten werden als Kopie über Warteschlangen gesendet. Das heißt, die tatsächlichen Daten (die ein Zeiger auf größere Puffer sein können) werden in die Warteschlange kopiert – und nicht nur ein Verweis auf die Daten.

In der APIs Warteschlange kann eine Blockzeit angegeben werden. Wenn ein Task versucht, aus einer leeren Warteschlange zu lesen, wird der Task in den Status "Blocked" versetzt, bis Daten in der Warteschlange verfügbar sind oder die Blockierungsdauer abgelaufen ist. Aufgaben im Status Blockiert nehmen keine CPU Zeit in Anspruch, sodass andere Aufgaben ausgeführt werden können. Ähnlich verhält es sich, wenn ein Task versucht, in eine volle Warteschlange zu schreiben. Dann wird der Task in den Status "Blocked" versetzt, bis Platz in der Warteschlange verfügbar wird oder die Blockierungsdauer verstrichen ist. Wenn sich mehr als ein blockierter Task in einer Warteschlange befindet, wird zuerst der Task mit der höchsten Priorität freigegeben.

Andere RTOS Gratis-Primitive, wie direct-to-task Benachrichtigungen sowie Stream- und Nachrichtenpuffer, bieten in vielen gängigen Entwurfsszenarien einfache Alternativen zu Warteschlangen.

Semaphoren und Mutexe

Der kostenlose RTOS Kernel bietet binäre Semaphoren, Zählsemaphoren und Mutexe sowohl für den gegenseitigen Ausschluss als auch für Synchronisationszwecke.

Binärsemaphore können nur zwei Werte haben. Sie sind eine gute Wahl bei der Implementierung der Synchronisation (entweder zwischen Tasks oder zwischen Tasks und einem Interrupt). Zählende Semaphoren haben mehr als zwei Werte. Sie ermöglichen es vielen Tasks, Ressourcen gemeinsam zu nutzen oder komplexere Synchronisationsoperationen durchzuführen.

Mutexe sind binäre Semaphoren, die einen Vererbungsmechanismus für Prioritäten beinhalten. Das bedeutet Folgendes: Wenn ein Task mit hoher Priorität blockiert ist, währen er versucht einen derzeit von einem Task mit niedrigerer Priorität gehaltenen Mutex zu erhalten, wird die Priorität des Tasks, der das Token hält, vorübergehend auf die des blockierten Tasks erhöht. Dieser Mechanismus wurde entwickelt, um sicherzustellen, dass der Task mit höherer Priorität so kurz wie möglich im Status "Blocked" gehalten wird. So wird die aufgetretene Prioritätsumkehrung minimiert.

Direct-to-task Benachrichtigungen

Aufgabenbenachrichtigungen ermöglichen es Aufgaben, mit anderen Aufgaben zu interagieren und sich mit Interrupt-Serviceroutinen (ISRs) zu synchronisieren, ohne dass ein separates Kommunikationsobjekt wie eine Semaphore erforderlich ist. Jede RTOS Aufgabe hat einen 32-Bit-Benachrichtigungswert, der verwendet wird, um den Inhalt der Benachrichtigung, falls vorhanden, zu speichern. Eine RTOS Aufgabenbenachrichtigung ist ein Ereignis, das direkt an eine Aufgabe gesendet wird und das die Sperre der empfangenden Aufgabe aufheben und optional den Benachrichtigungswert der empfangenden Aufgabe aktualisieren kann.

RTOSAufgabenbenachrichtigungen können als schnellere und einfachere Alternative zu binären Semaphoren und Zählsemaphoren und in einigen Fällen zu Warteschlangen verwendet werden. Aufgabenbenachrichtigungen bieten im Vergleich zu anderen kostenlosen RTOS Funktionen, mit denen vergleichbare Funktionen ausgeführt werden können, sowohl Geschwindigkeits- als auch RAM Speicherplatzvorteile. Task-Benachrichtigungen können jedoch nur verwendet werden, wenn es nur einen Task als Empfänger des Ereignisses gibt.

Stream-Puffer

Stream-Puffer ermöglichen die Übergabe eines Bytestroms von einer Interrupt-Serviceroutine an einen Task oder von einem Task an einen anderen. Ein Bytestrom kann eine beliebige Länge haben und muss nicht unbedingt einen Anfang oder ein Ende haben. Es können beliebig viele Bytes auf einmal geschrieben und beliebig viele Bytes auf einmal gelesen werden. Die Stream-Pufferfunktionalität wird durch die Einbindung der Quelldatei stream_buffer.c in Ihr Projekt aktiviert.

Stream-Puffer gehen davon aus, dass es nur einen Task oder Interrupt gibt, der in den Puffer schreibt (der Writer) und nur einen Task oder Interrupt, der aus dem Puffer liest (der Reader). Writer und Reader können unterschiedliche Tasks oder Interrupt-Serviceroutinen sein. Es darf jedoch nicht mehrere Writer oder Reader geben.

Die Stream-Puffer-Implementierung verwendet direct-to-task Benachrichtigungen. Daher kann das Aufrufen eines Stream-PuffersAPI, der die aufrufende Aufgabe in den Status Blockiert versetzt, den Benachrichtigungsstatus und den Wert der aufrufenden Aufgabe ändern.

Senden von Daten

xStreamBufferSend()wird verwendet, um Daten an einen Stream-Puffer in einer Aufgabe zu senden. xStreamBufferSendFromISR()wird verwendet, um Daten in einer Interrupt-Serviceroutine (ISR) an einen Stream-Puffer zu senden.

xStreamBufferSend() ermöglicht die Angabe einer Blockierungsdauer. Wenn xStreamBufferSend() mit einer Blockierungsdauer ungleich Null aufgerufen wird, um in einen Stream-Puffer zu schreiben und der Puffer voll ist, wird der Task in den Status "Blocked" versetzt, bis Platz verfügbar wird oder die Blockierungsdauer abläuft.

sbSEND_COMPLETED()und sbSEND_COMPLETED_FROM_ISR() sind Makros, die (intern, von Free RTOSAPI) aufgerufen werden, wenn Daten in einen Stream-Puffer geschrieben werden. Sie nehmen das Handle des Stream-Puffers entgegen, der aktualisiert wurde. Beide Makros prüfen, ob ein blockierter Task im Stream-Puffer auf Daten wartet. Wenn dies der Fall ist, wird Status "Blocked" für den Task entfernt.

Sie können dieses Standardverhalten ändern, indem Sie Ihre eigene Implementierung von sbSEND_COMPLETED() in FreeRTOSConfig.h bereitstellen. Dies ist hilfreich, wenn ein Stream-Puffer verwendet wird, um Daten zwischen den Kernen auf einem Mehrkern-Prozessor zu übertragen. In diesem Szenario sbSEND_COMPLETED() kann es implementiert werden, um einen Interrupt im anderen CPU Kern zu erzeugen, und die Serviceroutine des Interrupts kann dann eine Aufgabe, die xStreamBufferSendCompletedFromISR() API auf die Daten wartet, überprüfen und gegebenenfalls entsperren.

Empfangen von Daten

xStreamBufferReceive()wird verwendet, um Daten aus einem Stream-Puffer in einer Aufgabe zu lesen. xStreamBufferReceiveFromISR()wird verwendet, um Daten aus einem Stream-Puffer in einer Interrupt-Serviceroutine (ISR) zu lesen.

xStreamBufferReceive() ermöglicht die Angabe einer Blockierungsdauer. Wenn xStreamBufferReceive() mit einer Blockierungsdauer ungleich Null zum Lesen aus einem Stream-Puffer aufgerufen wird und der Puffer leer ist, wird der Task in den Status "Blocked" versetzt, bis entweder eine bestimmte Datenmenge im Stream-Puffer verfügbar ist oder die Blockierungsdauer abläuft.

Die Datenmenge, die sich im Stream-Puffer befinden muss, bevor ein Task freigegeben wird, wird als Triggerlevel des Stream-Puffers bezeichnet. Ein mit einem Triggerlevel von 10 blockierter Task wird freigegeben, wenn mindestens 10 Bytes in den Puffer geschrieben werden oder die Blockierungsdauer des Tasks abläuft. Wenn die Blockierungsdauer eines lesenden Tasks vor Erreichen des Triggerlevels abläuft, erhält der Task alle in den Puffer geschriebenen Daten. Das Triggerlevel eines Tasks muss auf einen Wert zwischen 1 und der Größe des Stream-Puffers festgelegt werden. Das Triggerlevel eines Stream-Puffers wird beim Aufruf von xStreamBufferCreate() festgelegt. Es kann durch Aufruf von xStreamBufferSetTriggerLevel() geändert werden.

sbRECEIVE_COMPLETED()und sbRECEIVE_COMPLETED_FROM_ISR() sind Makros, die (intern, von Free RTOSAPI) aufgerufen werden, wenn Daten aus einem Stream-Puffer gelesen werden. Die Makros prüfen, ob ein Task im Stream-Puffer blockiert ist, der darauf wartet, dass Platz im Puffer verfügbar wird. Wenn dies der Fall ist, wird der Task aus dem Zustand „Blocked“ entfernt. Sie können das Standardverhalten von sbRECEIVE_COMPLETED() ändern, indem Sie in FreeRTOSConfig.h eine alternative Implementierung bereitstellen.

Nachrichtenpuffer

Nachrichtenpuffer ermöglichen die Übergabe diskreter Nachrichten variabler Länge von einer Interrupt-Serviceroutine an einen Task oder von einem Task an einen anderen. Beispielsweise können Nachrichten der Länge 10, 20 und 123 Byte in denselben Nachrichtenpuffer geschrieben und aus aus demselben Nachrichtenpuffer gelesen werden. Eine 10-Byte-Nachricht kann nur als 10-Byte-Nachricht gelesen werden, nicht als einzelne Bytes. Nachrichtenpuffer bauen auf der Stream-Pufferimplementierung auf. Sie können die Nachrichtenpufferfunktionalität aktivieren, indem Sie die stream_buffer.c-Quelldatei in Ihr Projekt einfügen.

Nachrichtenpuffer gehen davon aus, dass es nur einen Task oder Interrupt gibt, der in den Puffer schreibt (der Writer) und nur einen Task oder Interrupt, der aus dem Puffer liest (der Reader). Writer und Reader können unterschiedliche Tasks oder Interrupt-Serviceroutinen sein. Es darf jedoch nicht mehrere Writer oder Reader geben.

Die Implementierung des Nachrichtenpuffers verwendet direct-to-task Benachrichtigungen. Daher kann das Aufrufen eines Stream-PuffersAPI, der die aufrufende Aufgabe in den Status Blockiert versetzt, den Benachrichtigungsstatus und den Wert der aufrufenden Aufgabe ändern.

Um Nachrichtenpuffern die Verarbeitung von Nachrichten variabler Größe zu ermöglichen, wird die Länge jeder Nachricht vor der Nachricht selbst in den Nachrichtenpuffer geschrieben. Die Länge wird in einer Variablen vom Typ size_t gespeichert, die bei einer 32-Byte-Architektur typischerweise 4 Byte groß ist. Daher verbraucht das Schreiben einer 10-Byte-Nachricht in einen Nachrichtenpuffer tatsächlich 14 Byte Pufferspeicher. Ebenso verbraucht das Schreiben einer 100-Byte-Nachricht in einen Nachrichtenpuffer tatsächlich 104 Byte Pufferspeicher.

Senden von Daten

xMessageBufferSend()wird verwendet, um Daten von einer Aufgabe an einen Nachrichtenpuffer zu senden. xMessageBufferSendFromISR()wird verwendet, um Daten von einer Interrupt-Serviceroutine (ISR) an einen Nachrichtenpuffer zu senden.

xMessageBufferSend() ermöglicht die Angabe einer Blockierungsdauer. Wenn xMessageBufferSend() mit einer Blockierungsdauer ungleich Null für das Schreiben in den Nachrichtenpuffer aufgerufen wird und der Puffer voll ist, wird der Task in den Status "Blocked" versetzt, bis entweder Platz im Nachrichtenpuffer verfügbar wird oder die Blockierungsdauer abläuft.

sbSEND_COMPLETED()und sbSEND_COMPLETED_FROM_ISR() sind Makros, die (intern, von Free RTOSAPI) aufgerufen werden, wenn Daten in einen Stream-Puffer geschrieben werden. Sie nehmen einen einzigen Parameter entgegen, der das Handle des aktualisierten Stream-Puffers darstellt. Beide Makros prüfen, ob ein blockierter Task im Stream-Puffer auf Daten wartet. Wenn dies der Fall ist, entfernen sie den Status "Blocked" des Tasks.

Sie können dieses Standardverhalten ändern, indem Sie Ihre eigene Implementierung von sbSEND_COMPLETED() in FreeRTOSConfig.h bereitstellen. Dies ist hilfreich, wenn ein Stream-Puffer verwendet wird, um Daten zwischen den Kernen auf einem Mehrkern-Prozessor zu übertragen. In diesem Szenario sbSEND_COMPLETED() kann es implementiert werden, um einen Interrupt im anderen CPU Kern zu erzeugen, und die Serviceroutine des Interrupts kann dann eine Aufgabe, die xStreamBufferSendCompletedFromISR() API auf die Daten gewartet hat, überprüfen und gegebenenfalls entsperren.

Empfangen von Daten

xMessageBufferReceive()wird verwendet, um Daten aus einem Nachrichtenpuffer in einer Aufgabe zu lesen. xMessageBufferReceiveFromISR()wird verwendet, um Daten aus einem Nachrichtenpuffer in einer Interrupt-Serviceroutine (ISR) zu lesen. xMessageBufferReceive()ermöglicht die Angabe einer Blockzeit. Wenn xMessageBufferReceive() mit einer Blockierungsdauer ungleich Null zum Lesen aus einem Nachrichtenpuffer aufgerufen wird und der Puffer leer ist, wird der Task in den Status "Blocked" versetzt, bis entweder Daten verfügbar werden oder die Blockierungsdauer abläuft.

sbRECEIVE_COMPLETED()und sbRECEIVE_COMPLETED_FROM_ISR() sind Makros, die (intern, von Free RTOSAPI) aufgerufen werden, wenn Daten aus einem Stream-Puffer gelesen werden. Die Makros prüfen, ob ein Task im Stream-Puffer blockiert ist, der darauf wartet, dass Platz im Puffer verfügbar wird. Wenn dies der Fall ist, wird der Task aus dem Zustand „Blocked“ entfernt. Sie können das Standardverhalten von sbRECEIVE_COMPLETED() ändern, indem Sie in FreeRTOSConfig.h eine alternative Implementierung bereitstellen.

DatenschutzNutzungsbedingungen für die WebsiteCookie-Einstellungen
© 2025, Amazon Web Services, Inc. oder Tochtergesellschaften. Alle Rechte vorbehalten.