I have looked at the information given Here , and I now understand the concepts of the Running, Ready, and Blocked states in an RTOS. Running is when a task is actively executing, Ready is when a task is waiting its turn, and Blocked is when a task is waiting for a specific event.
For example, in a real-time control system, a task controlling motor movements is in the Running state, while other tasks for different controls (e.g., sensor data processing) might be Ready, waiting for their turn. Additionally, a task in an industrial automation system that’s waiting for scheduled sensor readings at fixed time intervals (e.g., every 10 milliseconds) represents an example of the Blocked state.
I’m having trouble understand the Suspended state. I am looking for a real use case or example that helps me understand the concept of suspended tasks.
The difference between “Blocked” and “Suspended” is that a task in the “Blocked” state will automatically start after a timeout period, while a task is “Suspended” state will not.
A Task will end up in “Suspended” state if either it is the target of a vTaskSupsend() call, or it it makes a call to an API with a timeout parameter of configMAX_DELAY (it used to also require INCLUDE_vTaskSuspend to be 1, not sure if that is still required). In the case of a configMAX_DELAY API call, the task will still wake up when the required condition occurs. It might also wake up if some task aborts its delay or resumes it (I think).
Say you want to wait on a queue until something arrives, and not have the task woken up just because it took to long. Then you use a wait time of configMAX_DELAY, and the task will not be woken until something is put on the queue.
As I said before, the difference is that going into a “Blocked” state, says that after some defined timeout, even if the event doesn’t happen, the task is woken. While with the suspend state, there is no timeout operating, the task will wait until the event happens (or some special call that ends the wait).
Actually using vTaskSuspend directly is very uncommon. With the current direct-to-task notifications, most of the even rare cases are removed, but it could be used (with extreme care) as a way for a task to stop itself (or even rarer another task) until another task decided it was time to be worked up without needing the overhead of a semaphore.