Quesion about the function vTaskDelay()

Kernel
1

We use FreeRTOS 10.4.3. We found a problem about the vTaskDelay().
For vTaskDelay(MSToTicks(1)), the acutal delay is about 70us.
For vTaskDelay(MSToTicks(2)), the actual delay is about 1.2ms.

We expected the first call should have delay 1ms; the 2nd one should delay 2ms. We’re trying to understand why it’s behaving this way.

Here are some macros:

#ifndef configTICK_RATE_HZ
#define configTICK_RATE_HZ (1000)
#endif

#define portTICK_PERIOD_MS   ((TickType_t) 1000 / configTICK_RATE_HZ)

#if configTICK_RATE_HZ <= 1000
  #define MSToTicks(MS)     ((MS) / portTICK_PERIOD_MS)
  #define TicksToMS(Ticks)  ((Ticks) * portTICK_PERIOD_MS)
#else
  #error "configTICK_RATE_HZ is not valid for this platform"
#endif

Thanks!

2

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(2) will delay the task until 2 tick occur, if the first one occurs very quickly after the call, the delay time might be just slightly over 1 tick in length.

This is due to the granularity of measuring time in “ticks”. The whole period from the nth tick until the next tick occurs is consider to be the time of tick n, and that jumps to n+1 when the tick interrupt occurs.

You need to take this fact into account when making short delays.

3

Hi Richard,
Thank you so much for your quick response. I appreciate it. Yes, it makes sense. I’ll update my code.

4

Here is a detailed description - Tick Resolution - FreeRTOS™.