Does freertos tasks switch based on that tick?

FreeRTOS Website
, , , ,
1

Difference between vTaskDelay(1) and vTaskDelay( pdMS_TO_TICKS( 1 ) );
How both will work ?

Does freertos tasks switch based on that tick ? or not ?
Suppose, I have three tasks 1ms , 5ms and 10ms tasks, how tasks will switch based on tick ?

Scenario 1:
System tick - 1ms ,
#define configTICK_RATE_HZ ((TickType_t )1000)
Task priorities 1ms - highest, 5ms - 2nd highest, 10ms - low priority
I used vTaskDelay(1) in first task, vTaskDelay(5) in 2nd task, vTaskDelay(10) in third task.
I created a three dummy tasks at 1ms , 5ms, 10ms in this case the only one highest priority task is running remaining 2 and 3 tasks aren’t running

Scenario 2:
System tick - 1ms ,
#define configTICK_RATE_HZ ((TickType_t )2000)
Task priorities 1ms - highest, 5ms - 2nd highest, 10ms - low priority
I used vTaskDelay(pdMS_TO_TICKS(1)); in first task, vTaskDelay(pdMS_TO_TICKS(5)); in 2nd task, vTaskDelay(10) in vTaskDelay(pdMS_TO_TICKS(10));third task.
I created a three dummy tasks at 1ms , 5ms, 10ms in this case all tasks are running based on priority 1ms , 5ms, 10ms and so on

Here I wanted to understand scenario 1 and Scenario 2

To switching the tasks what is the major point? is it ticks ? if it is tick how internally tick is impacting context switching between the tasks

Does anyone help me to understand in detailed

2

Didn’t the last discussion regarding your question Tasks aren't switching help ?
Especially the Tick Resolution - FreeRTOS™ doc pretty good explains the details.
What else is missing ?

1 Like
3

vTaskDelay(1) will delay the task until the next tick occurs, which might be just moments later, or might be up to the full period of a tick.

vTaskDelay(pdMS_TO_TICKS(1)) calls the following macro which computes how many ticks are needed to “delay at least 1 millisecond”, rounding up.

#define pdMS_TO_TICKS( xTimeInMs )    ( ( TickType_t ) ( ( xTimeInMs * configTICK_RATE_HZ ) / 1000U ) ) )

Scenario 1:
configTICK_RATE_HZ = 1000→ 1 tick = 1 ms

vTaskDelay(1);  // 1 tick → 1 ms
vTaskDelay(5);  // 5 ticks → 5 ms
vTaskDelay(10); // 10 ticks → 10 ms

At startup, the highest-priority 1 ms task runs immediately. It executes, then blocks for exactly 1 ms. On the very next tick, it unblocks, preempts any lower-priority tasks, runs again, and blocks once more. This cycle repeats every tick. As a result, the 5 ms and 10 ms tasks remain stuck in the delayed list, readying at their intervals, but constantly out-prioritized by the 1 ms task.

Scenario 2:
configTICK_RATE_HZ = 2000→ 1 tick = 0.5 ms

vTaskDelay( pdMS_TO_TICKS(1) );  // 1 ms → 2 ticks
vTaskDelay( pdMS_TO_TICKS(5) );  // 5 ms → 10 ticks
vTaskDelay( pdMS_TO_TICKS(10) ); // 10 ms → 20 ticks

Now the high priority 1 ms task actually blocks for 2 ticks each loop which gives a full 1 ms window where it’s in the Delayed state. During that window, the 5 ms task, once its 10-tick delay expires, can run uninterrupted. Similarly, the 10 ms task gets its chance at the right interval. Each task unblocks at its own tick and only preempts if its priority is higher than the task currently running.

2 Likes
4

[obsoleted and therefore deleted]

1 Like