NOTE: These pages have not been updated since the introduction of FreeRTOS V4.0.0. V4.0.0 introduces the concept of co-routines which would provide a different and novel solution to those presented here. The Tasks and Co-routines documentation provides further information.

Solution #3 functions tasks and priorities
We have previously seen how the timing requirements of our hypothetical application can be split into three categories:
As before, a high priority task is created to service the critical control functionality.
Solution #3 groups the RS232, keyscan and LED functionality into a single medium priority task.
For reasons previously stated it is desirable for the embedded web server task to operate at a lower priority. Rather than creating a task specifically for the web server an idle task hook is implemented to add the web server functionality to the idle task. The web server must be written to ensure it never blocks!
The LED functionality is too simple to warrant its own task if RAM is at a premium. For reasons of demonstration this example includes the LED functionality in the single medium priority task. It could of coarse be implemented in a number of ways (from a peripheral timer for example).
The plant control task, as the highest priority task, is guaranteed to be allocated processing time whenever it requires. It will pre-empt the low and medium priority tasks if necessary. The idle task will execute whenever both application tasks are blocked. The idle task has the option of placing the processor into power save mode.
![]() |
Creates only two application tasks so therefore uses much less RAM than solution #2. |
![]() |
Processor utilisation is automatically switched from task to task on a most urgent need basis. |
![]() |
Utilising the idle task effectively creates three application task priorities with the overhead of only two. |
![]() |
The design is still simple but the execution time of the functions within the medium priority task could introduce timing issues. The separation of the embedded web server task reduces this risk and in any case any such issues would not effect the plant control task. |
![]() |
Power consumption can be reduced if the idle task places the CPU into power save (sleep) mode, but may also be wasted as the tick interrupt will sometimes wake the CPU unnecessarily. |
![]() |
The RTOS functionality will use processing resources. The extent of this will depend on the chosen kernel tick frequency. |
![]() |
The design might not scale if the application grows too large. |
#define DELAY_PERIOD 4
#define FLASH_RATE 1000
void MediumPriorityTask( void *pvParameters )
{
xQueueItem Data;
portTickType FlashTime;
InitialiseQueue();
FlashTime = xTaskGetTickCount();
for( ;; )
{
do
{
// A
if( xQueueReceive( xCommsQueue, &Data, DELAY_PERIOD ) )
{
ProcessRS232Characters( Data.Value );
}
// B
} while ( uxQueueMessagesWaiting( xCommsQueue ) );
// C
if( ScanKeypad() )
{
UpdateLCD();
}
// D
if( ( xTaskGetTickCount() - FlashTime ) >= FLASH_RATE )
{
FlashTime = xTaskGetTickCount();
UpdateLED();
}
}
// Should never get here.
return 0;
}
Referring to the labels within the code fragment above:
NEXT >>> Solution #4: Reducing the processor overhead
Any and all data, files, source code, html content and documentation included in the FreeRTOS 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..