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.
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
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.