High Frequency periodic tasks scheduling

[digitaldjarin]

Hello,

Understand that the suggested systick tick rate configuration (OS_CFG_TICK_RATE_HZ) for uCOS is 10 to 1000Hz.
We need to schedule 2 high freq tasks (or more in future) to execute them periodically at fixed speed of 10Khz (or higher).
Each of these task will need to run a algorithm and floating point calculations and require relatively high timing accuracy.
Each task execution time quantum is around 15us, and it was running at ARM Cortex-m7 with 800Mhz core frequency.

I think it is not suitable to "over-clock" the tick rate to 10Khz (which could increase overall overhead), hence, currently i am using a hardware timer triggering a hardware-interrupt and post an event flags to the respective task to wakeup and run periodically.

The problem currently is due to we need to make the timer ISR as Kernel aware, and the timer interrupt priority has to make below boundary level. This causing the hardware timer sometime will be preempted by the kernel context-switching, thus we are getting some jittering effects at the timer ISR performance.

Would like to know Is there a better way to schedule a task faster than the systick tick rate?
or is there a way to make kernel-aware timer interrupt highest priority than kernel to avoid the preemption?
(with the requirement of relatively high timing consistency)

Thanks

[alexachso]

Hi @digitaldjarin ,

I am using a setup similar to yours. I want a task to execute every 200us. The execution of the task itself takes ~10us. I have configured a hardware timer to have a period of 200us and when the interrupt triggers I OSTaskSemPost() to wake up the task. The task waits for the POST with OSTaskSemPend(). I am not sure about the jitter part, I did not study the task that deeply, and even if there is a jitter for some microseconds, it won't affect my app. What I observe though is that after some running hours, the last time I observed was 31h, the task stops executing entirely, even if the ISR of the timer continues to POST the semaphore. It is as if the scheduler does not see the task as being ready anymore.

I know this setup is not that conventional, but I would like to understand what is happening and why it fails before changing the design. I did not find anywhere in the docs that it is prohibited to have a semaphore post more frequently than the OS tick itself (which in my case is 1ms). Also, because we call a semaphore post more frequently than the os tick, we also call the scheduler each time we post. Is this repeated behavior that messes up the prior table and the scheduler does not see anymore the task as being ready?

This is my task TCB once the bug is present:

By debugging I confirmed that the task calls OSTaskSemPend() and never wakes up again. What is strange is that the PendOn and PendStatus do not change state when the OSTaskSemPend() function is called.

The ISR IS kernel aware!

[Digitaljarin]

Hi @alexachso ,
If your task was setup as preemptive and not round robin, as long as your mcu/cpu processing power able to serve and response to the 200us semaphore from ISR, it should not be an issue.
1 abnormality observed from your TCB is the SemCtr counter is so high, meaning the TaskSemaphore is under serve by ur task. Have to verify if this task execution is always 10us or there could be sometime other higher priority task will block this task causing additional execution time quantum. You may monitor if SemCtr is accumulative means there could be some lags in ur task.