RTOS tick rate vs thread frequency.

rogue-ant wrote on Friday, May 29, 2015:

Hi, I’m trying to determine a proper tick rate for the RTOS kernel…

I have two tasks which need to iterate periodically. The first task needs to run every 1mS; the second task needs to run every 6mS. I cannot set either to run from a dedicated timer ISR - they both must be controlled by the RTOS.

Processor is an ARM @ 300MHz.

I understand the RTOS can tick at frequencies greater than 1kHz. But I am wanting the minimal RTOS overhead possible, while still achieving my timing needs…

Would 1KHz work? That would require the RTOS to kick-off the 1mS loop every iteration - but what about the 6mS loop then? If >1kHz is needed, I understand that it needs to be an even multiple, which gives a (partial) option of 0.5mS, 0.25mS, 0.1mS ticks.

What is the ideal tick time for my requirements?



rogue-ant wrote on Friday, May 29, 2015:

So, informal testing, it looks like I can set the RTOS tick to 1mS - the same as my fastest loop and it will still iterate both threads properly…

richard_damon wrote on Saturday, May 30, 2015:

Yes, it should. One way to look at it, assuming that you have preemption enabled, and the 1ms task is given the higher priority (and no higher priority interferes)

Assuming we start at a tick where both tasks should run:

Tick interrupt occurs and both 1ms and 6 ms tasks are marked as ready.

First the 1ms task runs (since it has the higher priority), until it completes (or blocks for something else), and then waits for the next timer tick to occur (next 1ms chunk).

Then the scheduler will start the 6ms task which is also ready. If it finishes before the next timer tick it can just delay till the next 6ms time mark. If it hasn’t finished, then on the timer tick the 1ms task will preempt the operation and run, returning to the 6ms task when it finishes. The 6ms task should use xTaskDelayUntil if you want the 6ms to be measured from when the task was first marked ready as opposed to when it finishes.

rogue-ant wrote on Monday, June 01, 2015:

Richard, thanks for taking the time to answer!