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.

Practice

1. What is the main purpose of vTaskDelayUntil() in FreeRTOS?

easy

A. To delay a task until a fixed periodic time, keeping timing precise

B. To delay a task for a random amount of time

C. To suspend a task indefinitely

D. To immediately resume a suspended task

Solution

1. Step 1: Understand the function's purpose

   vTaskDelayUntil() is designed to delay a task until a specific time, maintaining a fixed periodic interval.

2. Step 2: Compare options with function behavior

   Only To delay a task until a fixed periodic time, keeping timing precise describes this precise periodic delay. Other options describe unrelated behaviors.

3. Final Answer:

   To delay a task until a fixed periodic time, keeping timing precise -> Option A

4. Quick Check:

   Precise periodic delay = A [OK]

Hint: vTaskDelayUntil keeps timing steady, not random delays [OK]

Common Mistakes:

• Confusing vTaskDelayUntil with vTaskDelay
• Thinking it suspends tasks indefinitely
• Assuming it resumes tasks immediately

2. Which of the following is the correct way to declare the variable used with vTaskDelayUntil() to track the last wake time?

easy

A. TickType_t xLastWakeTime = 0;

B. int xLastWakeTime = 0;

C. TickType_t xLastWakeTime;

D. void *xLastWakeTime = NULL;

Solution

1. Step 1: Identify the correct type for last wake time

   The FreeRTOS API specifies TickType_t as the type for tick counts and time tracking.

2. Step 2: Initialization rules for vTaskDelayUntil

   The variable must be declared but not necessarily initialized to zero; it is initialized by calling xLastWakeTime = xTaskGetTickCount(); before the loop.

3. Final Answer:

   TickType_t xLastWakeTime; -> Option C

4. Quick Check:

   Use TickType_t without initial zero for last wake time [OK]

Hint: Declare with TickType_t, initialize with xTaskGetTickCount() [OK]

Common Mistakes:

• Using int instead of TickType_t
• Initializing to zero instead of using xTaskGetTickCount()
• Using void pointer type

3. Given the code snippet below, what will be the approximate delay between each "Task running" print?

TickType_t xLastWakeTime;
xLastWakeTime = xTaskGetTickCount();

for (;;) {
    vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(1000));
    printf("Task running\n");
}

medium

A. Approximately 1000 milliseconds, steady without drift

B. Exactly 1000 milliseconds between prints

C. Variable delay, sometimes less than 1000 milliseconds

D. No delay, prints continuously

Solution

1. Step 1: Understand vTaskDelayUntil behavior

   It delays the task until the next fixed interval based on the last wake time, keeping timing steady.

2. Step 2: Analyze the delay duration

   The delay is set to 1000 ms converted to ticks, so the task runs approximately every 1000 ms without accumulating drift.

3. Final Answer:

   Approximately 1000 milliseconds, steady without drift -> Option A

4. Quick Check:

   vTaskDelayUntil = steady periodic delay [OK]

Hint: vTaskDelayUntil keeps intervals steady, not exact but no drift [OK]

Common Mistakes:

• Assuming exact millisecond precision
• Confusing with vTaskDelay which causes drift
• Thinking delay varies randomly

4. Identify the error in the following FreeRTOS task code using vTaskDelayUntil():

void vTaskFunction(void *pvParameters) {
    TickType_t xLastWakeTime = 0;
    for (;;) {
        vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(500));
        // Task code here
    }
}

medium

A. vTaskDelayUntil() should not be used inside a loop

B. TickType_t cannot be initialized to zero

C. pdMS_TO_TICKS() cannot be used as a delay parameter

D. xLastWakeTime should be initialized with xTaskGetTickCount() before the loop

Solution

1. Step 1: Check initialization of xLastWakeTime

   It must be initialized to the current tick count using xTaskGetTickCount() before the loop to set the reference time.

2. Step 2: Verify usage of vTaskDelayUntil

   The function is correctly used inside the loop, and pdMS_TO_TICKS is valid for converting milliseconds to ticks.

3. Final Answer:

   xLastWakeTime should be initialized with xTaskGetTickCount() before the loop -> Option D

4. Quick Check:

   Initialize xLastWakeTime with xTaskGetTickCount() [OK]

Hint: Always init last wake time with xTaskGetTickCount() before loop [OK]

Common Mistakes:

• Not initializing xLastWakeTime before loop
• Misusing vTaskDelayUntil outside loops
• Incorrect delay parameter types

5. You want a FreeRTOS task to run exactly every 200 ms without drift, but your task sometimes takes 50 ms to execute. How should you use vTaskDelayUntil() to achieve this?

hard

A. Use vTaskDelayUntil() with 50 ms delay to match task execution time

B. Initialize xLastWakeTime with xTaskGetTickCount() before the loop, then call vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(200)) inside the loop after task code

C. Initialize xLastWakeTime to zero and call vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(250)) before task code

D. Call vTaskDelay(pdMS_TO_TICKS(200)) after task code to delay fixed 200 ms

Solution

1. Step 1: Understand timing requirements

   The task must run every 200 ms total, including 50 ms execution time, so delay should be 200 ms fixed interval.

2. Step 2: Correct usage of vTaskDelayUntil

   Initialize xLastWakeTime with xTaskGetTickCount() before the loop, then call vTaskDelayUntil() with 200 ms delay after task code to maintain steady timing without drift.

3. Final Answer:

   Initialize xLastWakeTime with xTaskGetTickCount() before the loop, then call vTaskDelayUntil(&xLastWakeTime, pdMS_TO_TICKS(200)) inside the loop after task code -> Option B

4. Quick Check:

   Init last wake time + vTaskDelayUntil with full period = D [OK]

Hint: Init last wake time, delay full period after task code [OK]

Common Mistakes:

• Using vTaskDelay instead of vTaskDelayUntil causing drift
• Not accounting for task execution time in delay
• Initializing xLastWakeTime incorrectly