I have a technical question regarding the implementation of the scheduler in FreeRTOS. I am currently using the AVR Atmega32 port of FreeRTOS.
Consider that there are two tasks, A and B. Task A is currently having the CPU and running but task B is in ready state. Suddenly let us say, task A needs to read a byte from the serial port. But the data is not available right now so this task has to block. So now my question is:
Does the scheduler get to know that task A is getting blocked and then suspends task A or does the scheduler allows task A to have the CPU(even in blocked state) till its time slice is over. When its time slice is over, the scheduler will anyway give the CPU to task B which was already in ready state.
In other words, is the scheduler aware when a particular task is going to block for some input?
OR
is the scheduler completely driven by the expiry of time slices (based on the tick ISR) which causes it to allocate the CPU to another ‘ready’ task.
A task in the blocked state will not consume any processor cycles. If TaskA enters the blocked state to wait for a character then TaskB will immediately start running.
But how does the scheduler get to know that task A is going to get blocked? Is the onus on task A to inform the scheduler that it is going to block? Or does task A *must* use some FreeRTOS interface to perform I/O so that the scheduler is always aware of any I/O done by any tasks ?
Task A must use a blocking FreeRTOS call to interface with the IO. For example, a queue. If TaskA attempts to read from an empty queue it will block (if it specifies a block time greater than 0). It will then unblock when there is data in the queue.
A-ha ! I get it now. Any FreeRTOS task *has* to use predefined interfaces only. It it tries to access the serial port natively, then the whole system would get blocked if there is no data available, till the timeslice of that task is over.
As far as the OS is concerned, in this particular case the task never goes into blocking mode and it would be always given its complete time slice, which might get wasted during such periods of ‘native’ hardware access.
That’s correct. If your task goes into a busy-waiting loop checking the serial port “received data ready” flag, then the OS will let it run for its whole time slice, and re-schedule it again depending on its priority, etc.
A good way to handle this is to split hardware reading into two parts: an ISR that gets executed when the serial port has actually received a character, and a blocking task. The ISR pulls the character out of the serial port hardware (you know the character is there, because you just got an interrupt) and puts it onto a FreeRTOS queue. The data-processing task calls one of the “read from queue” functions, which will block until there is actually something there. So no wasted time, and the data-processing task gets the character very shortly after it comes in the serial port. (If the data-processing task is high priority, then the return from the ISR can even cause the system to switch to the processing task immediately, rather than waiting for the current task’s timeslice to finish.)