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
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).