Kurze Fragen zur RTOS ---> IRQs

[Florian (Gast)]

Hallo Experten,

habe schon so ein bisschen mit µC programmiert aber hatte kaum Kontakt 
mit RTOS.
Nun habe ich eine ganz nette Einführung gefunden 
(http://www.emcu.it/STM32F4xx/Exe2_FreeRTOS_on_STM32F4-Discovery/EXE2_FreeRTOS_on_STM32F4-Discovery.html) 
und ein paar Fragen:

- Interrupts kommunizieren mit Tasks über Semaphoren. Ein Task ist zB 
blocked, dann kommt ein Interrupt Request, springt in die ISR und er 
wird unlocked über die Semaphore und läuft dann.
Nun dauert es aber manchmal einen SysTick bis der Task zum laufen kommt. 
Normal ist das mit der Zeit bis in den IRQ Sprung ja kritisch manchmal, 
wie ist das beim RTOS so?
- Es gibt Non-RTOs IRQ, RTOS IRQ und Kernel IRQs. Wie kann ich mir das 
vorstellen? Und wie gehen IRQs die es beim Controller eigentlich nicht 
gibt, also PendSV? Kernel Tick als Timer IRQ?

Vielen Dank für eure Hilfe!

Florian

[(prx) A. K. (prx)]

Florian schrieb:
> - Es gibt Non-RTOs IRQ, RTOS IRQ und Kernel IRQs. Wie kann ich mir das
> vorstellen?

Ohne jetzt auf dieses spezielle RTOS Bezug zu nehmen:

In diesem Fall wird dem Kernel des RTOS eine bestimmte Priorität 
irgendwo in der Mitte der vom µC zur Verfügung gestellten Prioritäten 
zugewiesen. Ein Kernelaufruf blockiert während kritischer Operationen 
nicht alle Interrupts, sondern nur alle niedrigerer Priorität.

RTOS IRQs haben eine geringere Priorität als der Kernel und dürfen 
folglich (bestimmte) RTOS-Aufrufe tätigen. So ist sichergestellt, dass 
sich kritische Datenzugriffe im RTOS und in diesen IRQs nicht ins Gehege 
kommen.

Non-RTOS IRQs dürfen eine höhere Priorität als der Kernel haben, diesen 
also beliebig unterbrechen, dürfen aber keine RTOS-Aufrufe tätigen. 
Dafür aber haben sie eine vom RTOS unbeeinflusste Latenzzeit.

> Und wie gehen IRQs die es beim Controller eigentlich nicht
> gibt, also PendSV?

PendSV wird von RTOS gerne selbst verwendet, weil er sich regelrecht 
dafür anbietet, wenn nicht sogar genau dafür implementiert wurde.

In diesem Fall sichert ein RTOS-IRQ Interrupt-Handler nicht gleich den 
kompletten für einen Kontextwechsel erforderlichen Zustand und zählt 
auch keine Verschachtelung mit, sondern benimmt sich wie ein normaler 
Handler in einem System ohne RTOS. Ein Kontextwechsel aus dem Return 
heraus ist dann direkt daraus nicht möglich.

Wenn in einem RTOS-Aufruf im Handler nun aber festgestellt wird, dass 
ein Kontextwechsel nötig ist, dann wird PendSV gesetzt und mit dem 
Return des letzten verschachtelten Handlers wird automatisch der 
PendSV-Handler aufgerufen, der nun den Kontextwechsel durchführt.

Vorteil: Trotz RTOS ist kein Zusatzaufwand im IRQ-Handler nötig, d.h. 
die Latenzzeit ist kürzer und IRQs ohne Taskwechsel sind schneller.

> Kernel Tick als Timer IRQ?

Ist ein Interrupt wie jeder andere auch und wird meist für einen 
RTOS-Timer-Tick verwendet. Denn genau dafür gibt es ihn.

[(prx) A. K. (prx)]

Florian schrieb:
> Nun dauert es aber manchmal einen SysTick bis der Task zum laufen kommt.
> Normal ist das mit der Zeit bis in den IRQ Sprung ja kritisch manchmal,
> wie ist das beim RTOS so?

Wenn in einem präemptiv arbeitenden RTOS ein Interrupt Handler einen 
RTOS-Aufruf tätigt und darin festgestellt wird, dass eine andere nun 
lauffähige Task eine höhere Priorität als die unterbrochene Task hat, 
dann kehrt der Handler nicht zur unterbrochenen Task zurück, sondern der 
mit der höheren Priorität (siehe das, was ich eben über PendSV schrieb).

Eine Task gleicher oder niedrigere Priorität jedoch kommt nicht 
unmittelar zum Zuge. Dazu gibt es ja die Task-Prioritäten. Die freilich 
nicht mit den IRQ-Prioritäten verwechselt werden sollten.

[(prx) A. K. (prx)]

A. K. schrieb:
>> Kernel Tick als Timer IRQ?
>
> Ist ein Interrupt wie jeder andere auch und wird meist für einen
> RTOS-Timer-Tick verwendet. Denn genau dafür gibt es ihn.

Gemeint war, dass bei den Cortex M i.d.R. der Systick als 
RTOS-Timer-Tick aka Kernel Tick verwendet wird.

[Florian (Gast)]

Ich möchte mich gleich mal bedanken dafür dass du so schnell und 
ausführlich geantwortet hast. Das muss ich mir nun in Ruhe zu Gemüte 
führen :)

Gruß, Flo