FreeRTOS-Serie fünf: API-Funktionen zum Anhalten und Fortsetzen von Aufgaben (Theorie)

 Im FreeRTOS-Echtzeit-Kernel-Nutzungshandbuch

 

Um eine Aufgabe vom angehaltenen Zustand in den Bereitschaftszustand wiederherzustellen, kann mit vTaskRexume() nur die Aufgabe fortgesetzt werden, die über die Funktion vTaskSuspend() in den angehaltenen Zustand versetzt wurde!

Wenn es eine Benutzer-Interrupt-Funktion gibt, die die von Freertos bereitgestellte Systemfunktion aufruft, stellen Sie sicher, dass Sie die von Freertos bereitgestellte Systemfunktion mit FromISR verwenden. Die Priorität dieses Benutzer-Interrupts muss zwischen den Prioritäten von configKERNEL_INTERRUPT_PRIORITY und configMAX_SYSCALL_INTERRUPT_PRIORITY liegen. Im Allgemeinen ist configKERNEL_INTERRUPT_PRIORITY festgelegt auf den niedrigsten Wert des Mikrocontrollers. Priorität, configMAX_SYSCALL_INTERRUPT_PRIORITY ist die höchste Priorität, die das FreeRTOS-System abschirmen kann . Es wird festgelegt, dass die Interrupt-Priorität höher als configMAX_SYSCALL_INTERRUPT_PRIORITY ist und die FreeRTOS-API nicht aufgerufen werden kann (eine so hohe Interrupt-Priorität liegt nicht mehr innerhalb der Kontrolle des FreeRTOS-Systems. Wie unten erwähnt, werden zur Gewährleistung der Integrität und Konsistenz der Schlüsselteile normalerweise die folgenden Maßnahmen ergriffen: Interrupts ausschalten. Vor dem Eintritt in den kritischen Teil können Sie das Auftreten von Interrupts mit höherer Priorität verhindern, indem Sie Interrupts deaktivieren. daher kann die Priorität nicht zu hoch sein). Ein Interrupt mit einer höheren Priorität als configMAX_SYSCALL_INTERRUPT_PRIORITY tritt auf und ruft die System-API auf, sodass die verknüpfte Liste der Interrupts mit niedrigerer Priorität möglicherweise unterbrochen wird und Kernel-Daten beschädigt werden.

Erklärung auf der offiziellen Website: RTOS für ARM Cortex-M (freertos.org)

Abhängigkeiten bei der Verwendung eines RTOS

FreeRTOS-Funktionen, die auf „FromISR“ enden, sind Interrupt-sicher, aber nur, wenn der Interrupt, der sie aufruft, eine logische Priorität hat, die nicht höher ist als die durch configMAX_SYSCALL_INTERRUPT_PRIORITY definierte (configMAX_SYSCALL_INTERRUPT_PRIORITY ist in der Header-Datei FreeRTOSConfig.h definiert ) . Daher muss jeder ISR, der eine RTOS-API-Funktion verwendet, manuell auf eine numerische Priorität eingestellt werden, die gleich oder größer als der  durch configMAX_SYSCALL_INTERRUPT_PRIORITY festgelegte Wert ist. Dadurch wird sichergestellt, dass die logische Priorität des Interrupts gleich oder kleiner als die Einstellung configMAX_SYSCALL_INTRUPT_PRIORITY ist.

Cortex-M-Interrupts haben standardmäßig eine numerische Priorität von 0. 0 ist die höchste Priorität. Belassen Sie daher niemals die Priorität eines Interrupts, der die interruptsichere RTOS-API verwendet, auf dem Standardwert .

In einem präemptiven Kernel kann ein Interrupt mit höherer Priorität einen Interrupt mit niedrigerer Priorität während der Ausführung seines kritischen Abschnitts unterbrechen. Hierbei handelt es sich um eine Funktion des präemptiven Kernels, die es Aufgaben oder Interrupts mit hoher Priorität ermöglicht, aktuell ausgeführte Aufgaben zu unterbrechen.

In einem Echtzeitbetriebssystem werden zur Gewährleistung der Integrität und Konsistenz kritischer Teile üblicherweise folgende Maßnahmen ergriffen:

1. Interrupts deaktivieren: Bevor Sie einen kritischen Abschnitt betreten, können Sie das Auftreten von Interrupts mit höherer Priorität verhindern, indem Sie Interrupts deaktivieren. Dadurch wird sichergestellt, dass die Ausführung kritischer Abschnitte nicht unterbrochen wird . Wenn dieser Interrupt also nicht in der Kontrolle von FreeRTOS liegt, hat das Betriebssystem keine Möglichkeit, ihn zu kontrollieren.

2. Dieser Ansatz muss jedoch mit Vorsicht angewendet werden, da das Deaktivieren von Interrupts andere Probleme wie Verzögerungen beim Takttakt, verminderte Reaktionsfähigkeit usw. verursachen kann.

3. Schutz kritischer Abschnitte: Verwenden Sie Schutzmechanismen für kritische Abschnitte, z. B. das Verbot von Vorkaufsrechten für kritische Abschnitte oder Mutex-Sperren, und fügen Sie am Anfang und am Ende kritischer Abschnitte einen Schutz für kritische Abschnitte hinzu. Dadurch wird sichergestellt, dass jeweils nur eine Task oder ein Interrupt in den kritischen Abschnitt gelangen kann. Mit dieser Methode kann das Problem des gleichzeitigen Zugriffs auf gemeinsam genutzte Ressourcen bis zu einem gewissen Grad vermieden werden.

4. Statusflags: Setzen Sie Statusflags am Anfang und Ende kritischer Abschnitte, beispielsweise mithilfe atomarer Operationen oder Flagbits. Andere Interrupts oder Aufgaben können die Statusflags überprüfen, um festzustellen, ob die kritischen abschnittsbezogenen Aufgaben ausgeführt werden können.

Referenz:

Hier sehen Sie, warum die Interrupt-Priorität im Zuständigkeitsbereich des Betriebssystems liegen muss

 FreeRTOS – Achtung bei Interrupt-Nutzung – Running Light – Blog Garden (cnblogs.com)