Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Real time embedded FreeRTOS mailing list 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT Training




Loading

A technical question regarding the scheduler

Posted by Seemanta Dutta on December 15, 2008
Hi,

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.

Hope I made myself clear.

Thanks in advance,
Seemanta

RE: A technical question regarding the scheduler

Posted by Dave on December 15, 2008
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.

RE: A technical question regarding the scheduler

Posted by Seemanta Dutta on December 15, 2008
Thanks for the reply, Dave !

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 ?

Forgive me if my questions seem stupid.

regards,
Seemanta

RE: A technical question regarding the scheduler

Posted by Dave on December 15, 2008
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.

RE: A technical question regarding the scheduler

Posted by Seemanta Dutta on December 15, 2008
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.

Correct me if I am wrong.

Thanks and regards,
Seemanta

RE: A technical question regarding the scheduler

Posted by dave m on December 15, 2008
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.)


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) 2004-2010 Richard Barry. Copyright (C) 2010-2016 Real Time Engineers Ltd.
Any and all data, files, source code, html content and documentation included in the FreeRTOSTM distribution or available on this site are the exclusive property of Real Time Engineers Ltd.. See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Real Time Engineers Ltd.

Latest News:

FreeRTOS V9.0.0 is now available for download.


Free TCP/IP and file system demos for the RTOS


Sponsored Links

⇓ Now With No Code Size Limit! ⇓
⇑ Free Download Without Registering ⇑


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Renesas Electronics Gold Alliance RTOS Partner.jpg

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

Atmel RTOS partner supporting ARM Cortex-M3 and AVR32 microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Xilinx Microblaze and Zynq partner

Silicon Labs low power RTOS partner

Altera RTOS partner for Nios II and Cortex-A9 SoC

Freescale Alliance RTOS Member supporting ARM and ColdFire microcontrollers

Infineon ARM Cortex-M microcontrollers

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

Cypress RTOS partner supporting ARM Cortex-M3

Fujitsu RTOS partner supporting ARM Cortex-M3 and FM3

Microsemi (previously Actel) RTOS partner supporting ARM Cortex-M3

Atollic Partner

IAR Partner

Keil ARM Partner

Embedded Artists