xTaskDelayUntil related doubts

Hi,
If I am using xTaskDelayUntil instead of xTaskDelay then I can run my task exactly same interval right?
what if xTaskDelayUntil() called task (low priority) is unblocked (time expired) and one more high priority task is still running will this task preempt that or not?

Hi @vigneshv, welcome to the FreeRTOS Community.

The key difference between xTaskDelayUntil() and vTaskDelay() is that it calculates the delay relative to a fixed reference time and therefore this API specifies the absolute (exact) time at which the task wishes to unblock. To read more about this API, you can look at (xTaskDelayUntil() - FreeRTOS™)

If your periodic task is low priority and a high-priority task is already running, the scheduler will continue running the high-priority task. The low-priority task will stay in the Ready state and only run when there are no higher-priority tasks ready to run.

However, the API still calculates the next wake time based on the original schedule (by adding the increment to the previous wake time), not on the basis of when the task actually runs. So even though the task is scheduled to run at regular intervals, its actual execution may be pushed back if the system is busy with other high-priority tasks at that moment.

1 Like

Hi @rohitmdn ,
In the situation like high priority task is running over low priority task,
L1- is low priority task, H1 is high priority task,
I need to run the L1 task with the period of 1 sec,
At this time even though I am using xTaskDelayUntill() I can not able run my L1 task in 1sec interval because of H1 task is running already right?
Is there any way like I need to run a task in particular interval regardless of priority?

Hi @vigneshv

Yes as I had explained, if H1 is running at that moment, L1 will not be able to run. L1 will run as soon as H1 blocks.

In your case if you really want the task to run every 1 sec, I would suggest increasing it’s priority (greater than other non-periodic tasks). This ensures that it runs periodically every 1 sec and then blocks because of xTaskDelayUntil(), giving room for other tasks to execute.

If the time at which you want the task to run periodically is a hard constraint, you could configure a hardware timer (for eg a peripheral timer) which can be set to generate an interrupt every 1 second, and then signal/notify to unblock a task from the ISR by using xSemaphoreGiveFromISR() or xTaskNotifyFromISR(). This would ensure that the timer fires exactly on time and the task that you want to execute is woken up from the ISR.

This would still require that no other higher priority task is running when the task is notified from the ISR. Otherwise, even though your task will be “Ready” after it is notified from the ISR, it won’t run until all other higher priority tasks relinquish the CPU.

Therefore, just raising the priority of your periodic task is likely enough for your use case.

1 Like

This gets into a question of the actual specifications you need. If you have a small time margin in which the task needs to be run for the system to be considered “working”, then that task needs to have a high priority. To make sure it will meet the specification, you need to be sure that the maximum CPU requirements for every task at the same or higher priority sums to less than the response time requirement for this task.

If the response time isn’t as critical, but you want the activation rate to be right, then xTaskDelayUntil() is the right tool, and priroity doesn’t need to be high.

As soon as you start asking about higher priority tasks interfearing with this task, it calls into question if you have thought properly about the priorities of the tasks and what they really need to be. High Priority doesn’t mean most important. Priority is more aligned to urgency, not importance.

2 Likes