System Exception Priorities in RTX

[tobermory]

I asked this on a Keil forum recently. Was hoping it might get seen by RTX authors, so posting here too...

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 much. Could this be maintained with the alterations described here? I am worried that PendSV handler itself could now be preempted by a Systick, and what might follow.

Any help appreciated.

[tobermory]

Sorry, I should have pointed out that I am adding SVC calls TO RTX5, and THOSE routines could possibly take longer than Systick interval. I am NOT saying that I think existing SVC calls in RTX5 can take that long. My underlying desire is to add a somewhat Unix like 'open, close, read, write, select' api to RTX so I can do device I/O (typically with uarts) in an OS-like fashion.

[tobermory]

Any RTX author care to comment?

[JonatanAntoni]

Hi @tobermory,

Sorry for late reply. We had a discussion but no real conclusion for your use case.

Basically, we struggle with "long lasting SV calls". Is there any specific reason for running "heavy load" in handler mode?

Running in handler mode easily bypasses all protection mechanisms such as MPU. We'd rather suggest to run in a high priority RTOS thread and use handler mode only for crucial and short parts.

Cheers,
Jonatan

[tobermory]

Hi Jonatan, I really appreciate the reply.

I come from the Unix world, where writing data to a hardware device, eg serial port, is done via a system call (in this case write). I am tinkering with adding some Unix-like api calls (open/close/read/write etc) to my apps, and using help from RTX5 to get there (SVC macros etc).
If I use SVC for my 'write' call, and stay in handler mode as I write bytes to say a uart at slow baud rate (9600 say), I can be in the SVC call for millis, tens of millis, hundreds even, all the while blocking systicks. It feels right to be in handler mode when accessing peripherals, and I can imagine using the MPU to protect peripherals in the address space from direct thread mode usage.

If I switch to NOT doing write via SVC call, then I need a mutex for each device/peripheral, since two threads calling write expect their data not to be garbled with other thread data. A high-priority thread may well be the solution.

My question was really about the consequences of bumping systick to a priority HIGHER than svc, and how the whole RTX kernel would hang together in that case.

[tobermory]

To add, I would like to run my RTOS applications in non-privileged mode. Alas accesses to e.g SCB->DeepSleep require privileged access, so any low-power-mode API isn't callable in that case. I know I can do a quick non-priv to priv switch, via e.g. a SVC call (with num > 0, ie a SVC_User) and do the low power stuff from there.

By expanding an RTOS api to include e.g. device open/close/read/write, we can push more and more peripheral accessing code INSIDE the 'kernel'. This should make porting an application to a new MCU much easier, since ONLY the kernel is a direct HAL user, application space is not.

In effect, applications begin to take on a 'Unix/POSIX' appearance. Whether this is a worthy goal or not is still something I am trying to decide upon.