When I call vTaskDelay(N), or I call ulTaskNotifyTake(true, N), N is a number of system ticks. If the task gets rescheduled immediately after the timeout expires, is that after N tick interrupts have occurred (so that the actual delay is only guaranteed to at least (N-1) times the tick period), or after N+1 tick interrupts have occurred (so that the actual delay is guaranteed to be at least N times the tick period)? A RTOS I used in the past added 1 to the tick count passed so that the delay was guaranteed to be at least N tick periods, but it looks to me that FreeRTOS doesn’t do that.
but it looks to me that FreeRTOS doesn’t do that.
That is correct: blocking functions will wait at most N ticks. Delaying 1 tick may turn out to last only a few microseconds.
Yes, the parameter is the number of Ticks to wait for. I tend to modify the conversion macro to first, round up (so asking for 9 ms with a 5 ms tick gives you 2 ticks, not 1) and then at the end adds 1, so it gives the minimum time to make sure you wait at least that long, but often it is longer. I use a different version for things like vTaskDelayUntil that rounds so that I get the closest period possible for that usage.
I take similar measures as Richard. Except for (not) waiting exactly 0 ms/ticks I usually want to wait at least the specified time and round up the number of ticks accordingly.
Just my 2ct
Also see vTaskDelayUntil().
Thanks for the replies. This came up because I needed to use ulTaskNotifyTake to wait for a DMA complete interrupt, where the DMA is expected to complete in under 1ms if the device is responding and the tick rate is 1000Hz. So I need to use ulTaskNotifyTake(true, 2) not ulTaskNotifyTake(true, 1).