This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Relative Priorities of SVC, PendSV, Systick in RTOSes

I know that RTX uses the following system exception priorities, on my MCU (silabs efm32gg, CM3-based) with 3 priority bits

SVC = 6

PendSV = Systick = 7,

where lower numeric value is higher priority.

Just wondering what other RTOSes may use?  FreeRtos? Micrium?

I imagine the relative priorities affect how much INT_Disable/Enable might be used. The priorities also affect how one might extend the RTOS.  For instance, I added some unix-like system calls for open/close/read/write/select to/from uart devices.  I used RTX as the underlying RTOS. Each of these was a 'system call', implemented via a SVC trap.

Since SVC higher than Systick+PendSV, i get for free a mutual exclusion on threads competing for uarts.  Once one thread traps to 'kernel' via say a 'write', that thread cannot be preempted by a second thread that might also want to write to same device. The flip side is, as I learned the hard way (lost Systicks and thus timer events taking too long!) was that if you write an N-byte string to a uart at 9600 baud, inside an SVC call, that takes N millis. A tick freq of 1ms will lose ~N ticks, since the Systicks are blocked by SVC. I am now using DMA to offload the uart tx, so that the SVC call can return pronto.

In summary, in RTX, and its relative priorities, a SVC call must return to thread mode within the frequency of Systick.

Parents
  • A quick followup.  In RTX(5), if a SVC call takes longer than the interval between SysTicks, those ticks are lost. Can the RTX authors comment on the possibility of one changing the RTX code such that

    PendSV = 7

    SVC = 6

    Systick = 5

    assuming 3 irq priority bits.

    The Systick handler would be changed also to still call osRtxTick_Handler, but then NOT branch to SVC_Context, but instead call SetPendSV(), i.e. systick would just count ticks but defer any context switching to the  PendSV handler (which DOES branch to SVC_Context).

    With this setup, Systick CAN preempt SVC, so jiffies would not be lost during long-lived SVC impls. I do note that the PendSVHandler expects to find things on its 'isr_queue'.  Would the amended SysTickHandler have to add a (dummy?) element?

    I do admire the fact that RTX's kernel and thread scheduling is all done without disabling interrupts.  Could this be maintained with the alterations described here? I am worried that PendSV handler itself could now be preempted by Systick, and what might follow.

Reply
  • A quick followup.  In RTX(5), if a SVC call takes longer than the interval between SysTicks, those ticks are lost. Can the RTX authors comment on the possibility of one changing the RTX code such that

    PendSV = 7

    SVC = 6

    Systick = 5

    assuming 3 irq priority bits.

    The Systick handler would be changed also to still call osRtxTick_Handler, but then NOT branch to SVC_Context, but instead call SetPendSV(), i.e. systick would just count ticks but defer any context switching to the  PendSV handler (which DOES branch to SVC_Context).

    With this setup, Systick CAN preempt SVC, so jiffies would not be lost during long-lived SVC impls. I do note that the PendSVHandler expects to find things on its 'isr_queue'.  Would the amended SysTickHandler have to add a (dummy?) element?

    I do admire the fact that RTX's kernel and thread scheduling is all done without disabling interrupts.  Could this be maintained with the alterations described here? I am worried that PendSV handler itself could now be preempted by Systick, and what might follow.

Children
No data