Suppose if my tick interrupt is running at 10ms, How much time would
it take for a task to switch from Ready to Running… ? in terms of
tick interrupts ? I am thinking that the time is negligible. If it is
negligible, why would we want to have two states in freeRTOS ?
You are right in that it is negligible. See http://www.freertos.org/FAQMem.html#ContextSwitchTime – which shows the time to move one task from Running to Ready, then another task from Ready to Running.
Both the Ready and Running states exist because there can be lots of tasks that are able and ready to run (tasks that are not in the Blocked or Suspended state), but assuming there is only one CPU core there can only be one task that is able to actually execute at any one time.
Also, I am confused after reading your book… I am thinking that
when we use “vTaskDelay(ms)”, we can create periodic tasks meaning we
can block a task for certain time period and execute it again once
the time expires.
Correct, except the block time is specified in tick periods, not ms. You can use pdTICKTO
MS( ms ) to convert from ms into ticks.
When you say continuous task, does it mean that it should always be
created using a crude loop ? (or) by polling a hardware timer until
it resets ? is this correct ? or are you referring to only the crude
Put as succinctly as possible, a continuous processing task is a task that never enters the Blocked state.
With more detail; if a task always has something to do, that is, it is never waiting for an event, then it will always want processing time. That does not mean it will always be executing, but does mean it will only ever be in the Ready or Running state. As it never enters the Blocked state it will always starve lower priority tasks of processing time, so can only be executed at the lowest possible priority – which is zero.
There are no restrictions imposed by FreeRTOS on how you implement a continuously processing task, and the fact that it is a continuously processing time is just a characteristic of the task’s implementation. As soon as the task makes an API call that places it into the Blocked state, by definition, it is no longer a continuously processing task. For example, if a continuously processing task uses the xQueueReceive() API function with a block time of zero it is never entering the Blocked state, but as soon as it uses a block time (that is the time it should wait in the Blocked state for data to be available on the queue) it has the potential to enter the Blocked state so is no longer wanting to execute 100% of the time.