Does vTaskdelay(1) delay up to one tick or circa one tick?

Kernel
#1

hooverphonique wrote on Monday, January 28, 2019:

I have a system consisting of 3 priorities on an Atmega1281 using FreeRTOS 9.0.0.
Pri 0 is the idle task and RailTask.
Pri 1 is SlaveTask.
Pri 2 is the software timer task.

RailTask runs in a little loop which contains (a.o.) a vTaskDelay(1) statement.
This old thread suggests that vTaskDelay(1) may resume the task on the next tick - depending on how far we are into the present tick when vTaskDelay(1) is called, this means that RailTask may get delayed arbitrarily less than one tick, is that correct? The reason I’m asking is that the system shows a rare problem which suggests that the delay is sometimes much shorter than expected (it’s so rare that it’s hard to do any diagnostics on it).

#2

rtel wrote on Monday, January 28, 2019:

There is only one answer to this:

Time resolution is set by the tick frequency. If, for example, you have
a tick every 1ms, then vTaskDelay() will block for 0.00001ms if you call
vTaskDelay( 1 ) immediately before the next tick interrupt, or 0.99999ms
if you call vTaskDelay( 1 ) immediately after the next tick interrupt.
To do anything else would take a lot of math (even floating point math)
and (non portable) clock manipulation to get sub tick frequency
interrupts within the kernel so the run time hit would not be tolerable
to most applications.