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.
