vTaskDelayUntil() for precise timing in FreeRTOS - Step-by-Step Execution

Concept Flow - vTaskDelayUntil() for precise timing

Start: Get current tick count

↓

Calculate next wake time = last wake time + period

↓

Call vTaskDelayUntil(&lastWakeTime, period)

↓

Task blocks until next wake time

↓

Task resumes exactly at next wake time

↓

Update lastWakeTime to next wake time

↩Back to start for next cycle

The function delays a task until a precise tick count, ensuring consistent periodic execution by updating the last wake time each cycle.

Execution Sample

FreeRTOS

TickType_t xLastWakeTime = xTaskGetTickCount();
const TickType_t xFrequency = 100;

for(;;) {
  vTaskDelayUntil(&xLastWakeTime, xFrequency);
  // Task code here
}

This code runs a task periodically every 100 ticks using vTaskDelayUntil for precise timing.

Execution Table

Iteration	xLastWakeTime (before delay)	xFrequency	Next Wake Time	vTaskDelayUntil Action	Task State	xLastWakeTime (after delay)
1	1000	100	1100	Delay until tick 1100	Blocked until 1100	1100
2	1100	100	1200	Delay until tick 1200	Blocked until 1200	1200
3	1200	100	1300	Delay until tick 1300	Blocked until 1300	1300
4	1300	100	1400	Delay until tick 1400	Blocked until 1400	1400
5	1400	100	1500	Delay until tick 1500	Blocked until 1500	1500
Exit	1500	100	1600	Delay until tick 1600	Stopped (example end)	1600

💡 Execution stops after 5 iterations for demonstration; normally runs indefinitely.

Variable Tracker

Variable	Start	After 1	After 2	After 3	After 4	After 5
xLastWakeTime	1000	1100	1200	1300	1400	1500
xFrequency	100	100	100	100	100	100

Key Moments - 3 Insights

Why do we use vTaskDelayUntil instead of vTaskDelay for periodic tasks?

vTaskDelayUntil uses a fixed reference time (xLastWakeTime) to calculate the next wake time, ensuring consistent intervals even if the task execution time varies. This is shown in the execution_table where xLastWakeTime increments by xFrequency each iteration.

What happens if the task takes longer than the period to execute?

If the task runs longer than the period, vTaskDelayUntil will not delay (or delay zero ticks) because the next wake time is already passed. This keeps the task on schedule without drifting, as seen by the fixed increments in xLastWakeTime.

Why do we update xLastWakeTime after each delay?

Updating xLastWakeTime to the next wake time keeps the timing reference fixed and prevents drift. The execution_table shows xLastWakeTime increasing by xFrequency each iteration, maintaining precise timing.

Visual Quiz - 3 Questions

Look at the execution_table, what is xLastWakeTime before the delay in iteration 3?

A 1300

B 1100

C 1200

D 1000

💡 Hint

Check the 'xLastWakeTime (before delay)' column in row for iteration 3.

At which iteration does the task delay until tick 1400?

A Iteration 4

B Iteration 5

C Iteration 2

D Iteration 3

💡 Hint

Look at the 'Next Wake Time' column in the execution_table.

If xFrequency changed to 200, how would xLastWakeTime change after iteration 2?

A It would be 1200

B It would be 1400

C It would be 1300

D It would be 1500

💡 Hint

xLastWakeTime increments by xFrequency each iteration; double the frequency doubles the increment.

Concept Snapshot

vTaskDelayUntil(&lastWakeTime, period) delays a task until a fixed tick count.
Use a TickType_t variable to store last wake time.
Each call adds period to lastWakeTime for precise periodic timing.
Prevents drift unlike vTaskDelay which delays relative to now.
Ideal for tasks needing consistent intervals.

Full Transcript

This visual execution trace shows how vTaskDelayUntil works in FreeRTOS to create precise periodic task timing. The task stores the last wake time in a variable and delays until the next scheduled tick count. Each iteration adds the fixed period to the last wake time, ensuring the task runs exactly every period ticks without drifting. The execution table tracks the last wake time before and after each delay, the next wake time, and the task state. Key moments clarify why vTaskDelayUntil is preferred over vTaskDelay for periodic tasks and how it handles tasks that run longer than the period. The quiz tests understanding of timing values and effects of changing the period. This method is essential for real-time applications requiring consistent timing.