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


Why each task needs a seperate stack?

Posted by WendyZ on November 7, 2010
Forgive me for this simple question, but I am new to tFreeRTOS. The FreeRTOS system seems to require that each task has its own stack, which is 85bytes minimum. So If I have multiple tasks, the memory usage is sort of large.
I am wondering, why each task needs a seperate task? My understanding of FreeRTOS schedules tasks based on priority, and higher priority task always interrupts lower priority tasks. So when a task is executing, only a higher priority task would preempt it and the higher priority task would execute until it finishes (or preempted or even higher ones). This scheme seems similar to the general interrupt scheme, so only one stack would suffice the need. Is it correct?
The possibility for requiring multiple stack seems only to be when a higher priority task is blocked/suspended and willingly yield the processor to other processes (i.e., the lower priority ones). So is it true that if the process don't block or suspend one stack would suffice?
Can anyone illustrate why multiple stacks is a must? Thank you very much!

RE: Why each task needs a seperate stack?

Posted by MEdwards on November 7, 2010
FreeRTOS is a fully preemptive system that uses the stack to store the context of each task individually. Interrupts run to completion so do not have an execution context across calls. I suggest reading the 'how FreeRTOS works' section of the website.

RE: Why each task needs a seperate stack?

Posted by Richard Damon on November 7, 2010
The higher priority task doesn't run till it is "finished" but until it blocks (waiting on a queue, semaphore or mutex, or executes a delay). At that point a lower priority task will start up. This switching back and forth is why each task needs its own stack.

In general, tasks rarely "finish", almost every task will be an infinite loop with a wait for resource somewhere in the loop.

If you want to avoid the stacks, you could look at the co-routines, there are a few restrictions on what they can do, and in exchange for that, they all share the same stack.

RE: Why each task needs a seperate stack?

Posted by WendyZ on November 8, 2010
Thanks for your awesome replies. In my current system I have a fair number of periodical tasks that needs to be executed at different frequencies. If I assign tasks according to their execution frequencies, I would need to have one task for each frequency, e.g., 1 task for 10ms functions, 1 task for 30ms functions, etc, , then it seems I might ended up with a large number of tasks and the memory consumption seems larger than I like. If they are all in one task, then they will not be preempting and loses the purpose of RTOS. Is there any solution to this? I am thinking about Rate Monotonic scheduling so that only one stack is needed (without using blocking calls, and this might make the design a little bit harder...). Any ideas?

RE: Why each task needs a seperate stack?

Posted by Richard Damon on November 8, 2010
It sounds like co-routine might be a good fit for you. If all/most of your tasks just need for one signal to start (like a timer) and then just run till they produce a result, it should fit well. To allow the sharing of the stack, co-routines can't remember anything on the stack when they block (and the block can't be is a subroutine of the task, it needs to be in the main task loop), but that shouldn't be a problem for you the way you have described things. Co-routine CAN be interrupted by a higher priority co-routine, but they don't round-robin at same priority level (except at block/yeild points).

[ 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