rtel wrote on Tuesday, June 07, 2016:
When the
periodic task is created with vTaskCreate(), it is immediately
suspended, before the call to vTaskStartScheduler().
So when the scheduler starts the task is in the Suspended state.
Later, calling a
vTaskResume(), it begins to run.
After vTaskResume() has been called the task moves out of the Suspended
state into the Ready state - and depending on its priority relative to
other tasks in the Ready state - may also move into the Running state.
If the task is now periodically calling vTaskDelayUntil() it will move
from the Running state into the Blocked state each time it calls
vTaskDelayUntil(), then out of the Blocked state into the Ready state
(it must have been in the Running state to call vTaskDelayUntil(), and
to be in the Running state it must have come from the Ready state as
only Ready tasks can be selected to run) each time the block time
expires. Again, depending on the task’s priority relative to other
Ready state tasks, the task will enter the Running state.
After a specified number of loops at
the specified period, the task suspends itself with a vTaskSuspend()
At which point it will move from the Running state into the Suspended state.
called directly after waking and calling vTaskDelayUntil() for the next
period.
So it calls vTaskSuspend() after it unblocks from a vTaskDelayUntil()
call? The sequence is not clear here but I don’t think it is relevant.
If this is the sequence then I have annotated with the states:
vTaskDelayUntil(); [Running state → Blocked state]
[Back to Ready/Running state on timeout]
vTaskSuspend(); [Running state → Suspended state]
I would think that the periodic task would move from the blocked caused
by the vTaskDelayUntil(), to the suspended state at that point.
After the task unblocks it will move to the Ready/Running state
depending on priority, and only enter the Suspended state when it
suspends itself (or another task suspends it).