The Tasks and Co-Routine documentation pages provide information to allow judgment as to when co-routine use may and may not be appropriate. Below is a brief summary. Note that an application can be designed using just tasks, just co-routines, or a mixture of both - however tasks and co-routines use different API functions and therefore a queue (or semaphore) cannot be used to pass data from a task to a co-routine or visa versa.
In brief: A real time application that uses an RTOS can be structured as a set of independent tasks. Each task executes within its own context with no coincidental dependency on other tasks within the system or the scheduler itself. Only one task within the application can be executing at any point in time and the real time scheduler is responsible for deciding which task this should be. The scheduler may therefore repeatedly start and stop each task (swap each task in and out) as the application executes. As a task has no knowledge of the scheduler activity it is the responsibility of the real time scheduler to ensure that the processor context (register values, stack contents, etc) when a task is swapped in is exactly that as when the same task was swapped out. To achieve this each task is provided with its own stack. When the task is swapped out the execution context is saved to the stack of that task so it can also be exactly restored when the same task is later swapped back in. See the How FreeRTOS Works section for more information.
|
Simple. |
|
No restrictions on use. |
|
Supports full preemption. |
|
Fully prioritised. |
|
Each task maintains its own stack resulting in higher RAM usage. |
|
Re-entrancy must be carefully considered if using preemption. |
All the co-routines within an application share a single stack. This greatly reduces the amount of RAM required compared to a similar application written using tasks.
Co-routines use prioritised cooperative scheduling with respect to other co-routines, but can be included in an application that uses preemptive tasks.
The co-routine implementation is provided through a set of macros.
The reduction in RAM usage comes at the cost of some stringent restrictions in how co-routines can be structured.
|
Sharing a stack between co-routines results in much lower RAM usage. |
|
Cooperative operation makes re-entrancy less of an issue. |
|
Very portable across architectures. |
 |
Fully prioritised relative to other co-routines, but can always be preempted by tasks if the two are mixed. |
|
Lack of stack requires special consideration. |
|
Restrictions on where API calls can be made. |
|
Co-operative operation only amongst co-routines themselves. |
Copyright (C) 2003 - 2008 Richard Barry
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 Richard Barry.
See the files license.txt (included in the distribution) and this copyright notice for more information. FreeRTOSTM and FreeRTOS.orgTM are trade marks of Richard Barry.