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

FreeRTOS eating memory

Posted by znatok on December 22, 2013

HI, I faced a problem that 16K Heap size is not enough for my project. I have started to check out where the memory goes and find out some suspicious things. I'm running: FreeRTOS-7.5.2 STM32F2 port heap_4.c

First of all why creating a binary semaphore eats more then 100 bytes of heap?


FreeRTOS eating memory

Posted by woops_ on December 22, 2013

http://www.freertos.org/FAQMem.html


FreeRTOS eating memory

Posted by znatok on December 23, 2013

Bad... I looked at CoOS implementation and found out below numbers: RAM Space for a Task TaskStackSize + 24 Bytes(MIN) - TaskStackSize + 48 Bytes(MAX) RAM Space for a Mailbox 16 Bytes RAM Space for a Semaphore 16 Bytes RAM Space for a Queue 32 Bytes RAM Space for a Mutex 8 Bytes RAM Space for a User Timer 24 Bytes

Another issue is a stack usage. NINSTACKSIZE is 128 words i.e. 128*4 bytes. I do not have nesting interrupts and my stack usage inside tasks is not intensive, still I could not reduce that number below to 96 or 64 words. I wonder how many stack is used by interrupt handler to save process context? Who else (except task itself) may use so many stack? What about scheduler?


FreeRTOS eating memory

Posted by rtel on December 23, 2013

Bad...

Software has many attributes, and trying to draw a comparison by looking at just one while ignoring the others just doesn't work.

For example, code size, testability, correctness, robustness, code reuse, design, etc. Engineering is almost by definition about finding the best compromise because you cannot optimise all attributes at once - you can only trade off by optimising one attribute at the expense of another.

FreeRTOS has just one central primitive that is re-used to provide lots of functionality - meaning that central primitive extremely well tested and robust. It also allows FreeRTOS semaphores to be implemented with practically no impact on code size at the expense of a few structure members being redundant when the structure happens to represent a semaphore. The semaphores include all the event management, including a highly efficient and ordered linked list of tasks that are blocked on the semaphore waiting to obtain the semaphore, a highly efficient and ordered linked list of tasks that are blocked on the semaphore waiting to give the semaphore, a count of the number of semaphores available (where the semaphore is of counting type), lock variables that allow the semaphore to be used from within interrupts and tasks simultaneously without causing corruption, plus some optional variables used for tracing, etc. Therefore, when you say CoOS uses 16 bytes, I doubt very much you are comparing like for like, as there cannot be all that functionality in the semaphore structure, so presumably either the functionality is not the same or the data associated with the functionality is simply somewhere else. Many OSes will allocated separate event management structures.

The above description of the FreeRTOS semaphore, with the optional tracing structure members, I have just measured to take 80 bytes on a 32-bit architecture, not the >100 bytes you have measured, so I don't know what it is you are measuring. Many it depends on the memory allocator used as some store some extra information that is not visible to the application writer.

Who else (except task itself) may use so many stack? What about scheduler?

How much stack your application uses is completely dependent on your application, the compiler you are using, and the optimisation setting of the compiler. The scheduler stores the task context on the task's stack when the task is not running - but that is a fixed size set by the architecture, has to be stored somewhere (if it wasn't on the stack it would be somewhere else), and will take up less space than most of your function call stacks anyway. Interrupts do not use any task stack, they have their own stack, and in fact re-use the stack that was originally used by the main() function to ensure no RAM is lost.

Ultimately, there are lots of RTOSes available, you have to choose the one that best suites you, which may or may not be FreeRTOS. We would like you to select FreeRTOS because we are extremely proud of it, but financially it does not make a difference to us either way. Of course, technical attributes are only a subset of the attributes to consider when making your selection.

Regards.


FreeRTOS eating memory

Posted by znatok on December 24, 2013

HI, First of all I'm not arguing and I fully agree with you that it is not right to compare some specific parameter without taking in account the whole picture. Although I have a few notes:

I have just measured to take 80 bytes on a 32-bit architecture, not the >100 bytes you have measured Unfortunately queues (semaphores are also queues) are allocated as two chunks. One for header structure and another one for data. Each allocation (in case of heap_4) takes I think 16 bytes so you can add 32 bytes to 80 bytes you've measured and thus you get 112 bytes. My project has about 20 tasks and each task has in average one semaphore or queue. So about 2K goes only for queues and semaphores.

Regarding stack usage. FreeRTOS manual mentions that best practice is to use same MINSTACKSIZE as defined in examples for specific platform. In my case for STM32F2 Cortex M3 this value is 128 words i.e. 128*4 = 512 bytes. I noticed that xTaskCreate allocate also additional control blocks so totally I get something like 800 bytes for each task. Again for 20 tasks it is 16K of memory.

I agree that code reuse and robustness is very important. But I would expect to have a special memory optimized semaphore (together with big one) that is oriented only for ONE task and ONE interrupt synchronization for instance. This is what the 90% of my semaphores are used for and I do not need all this "ordered linked list of tasks that are blocked on the semaphore". And I would expect to have such semaphore using only 16 bytes like in CoOS.

I'm sure same optimization is possible for tasks. Would be nice to have "SmallTask" that is definitely limited in features but at the same time highly reduce memory usage.

Having existing Big and universal objects together with small optimized limited objects would make FreeRTOS much more flexible and tunable.

What do you think?


FreeRTOS eating memory

Posted by rtel on December 24, 2013

Unfortunately queues (semaphores are also queues) are allocated as two chunks. One for header structure and another one for data.

Yes in part, the queue cannot operate without allocating RAM into which the queued items are placed. See the "User Model: Maximum Simplicity, Maximum Flexibility" section on http://www.freertos.org/Embedded-RTOS-Queues.html.

Next, what I was going to say was: "No in part, semaphores should only make one allocation. While pvPortMalloc may get called twice, the second time it gets called the allocated size is zero, so it only actually allocates once."

However, checking this before posting I find the second allocation is actually of 1 byte (plus any overhead added by the allocator depending one which allocator you are using). It does not actually use the space though, so there is potential to make an optimisation where if the size required by the queue is 0 no memory gets allocated at all. FreeRTOS V8 is being prepared for release now so I will see if that can be done for that release.

MINSTACKSIZE as defined in examples for specific platform.

The value of configMINIMALSTACKSIZE as supplied in a demo is the suggested minimum ever used. The only place the FreeRTOS kernel actually uses the value itself is to dimension the size of the idle task. The demo applications do use the value however because the standard demo tasks run on all platforms so the configMINIMALSTACKSIZE parameter is useful way of ensuring portability of the demos tasks.

From memory I would have said the minimum value on a Cortex-M3 was about 70 words, but that would only allow an idle task (or any other task using the same value) to do something extremely basic without allocating too many stack variables or making nested function calls. Cortex-M4F uses a little more if floating point variables are used. The worst thing for massive stack consumption is to make calls into Newlib, which is why professional GCC embedded distributions provide their own library implementations.

But I would expect to have a special memory optimized semaphore (together with big one) that is oriented only for ONE task and ONE interrupt synchronization for instance

We will take that on board. It may be possible to rearange the members of the queue/semaphore structure so optional members appear at the end and in-so-doing have a 'mini semaphore' implementation. I will give that some thought today. Incidentally the new event flag implementation allows an event group with a single flag defined to be used as a binary semaphore with broadcast capability.

What do you think?

I don't disagree, but would say that while once RAM footprint was one of the most important attributes, over time its importance is diminishing as microcontrollers are getting larger and larger all the time. Therefore if there are any quick gains to be made, taking into account your feedback, we will sure make them - long term most development will be geared towards the future direction of the embedded MCU market.

Regards.


FreeRTOS eating memory

Posted by davedoors on December 24, 2013

Ways to save semaphore memory:

Set configUSETRACEFACILITY to 0. Use a mutex instead of a binary semaphore (only one allocation is done then). Use heap2 instead of heap4 (no hidden data allocated but can fragment).


FreeRTOS eating memory

Posted by dumarjo on October 1, 2014

Hi,

I would like to know if you have any new developement for this semaphore request ? We have to create many semaphore and we don't want to use 80 bytes each time we create one.

Regards

Jonathan


FreeRTOS eating memory

Posted by heinbali01 on October 1, 2014

Hi Jonathan and others,

I'm sorry, I cannot answer your question above but.... I have some questions:

This thread is about small applications in a small CPU, for which 80 bytes is a 'considerable amount' of RAM.

Now I'm often wondering what advantage(s) it has to create more than let's say 3 or 5 tasks beside the IDLE task?

Ella wrote:

Again for 20 tasks it is 16K of memory.

20 tasks?

I know one big advantage, which is ease of coding. Each task only has one responsibility. Dispatching events is easier: a keyboard task get woken up when a key is pressed. Or you can serve clients (TCP, UDP, serial) by starting a new task for each client/connection. The task can sleep while it is waiting for user input.

Or let me ask it the other way: what is so difficult in reducing the number of tasks? Keeping track of each sub-task? Creating and using so-called status-machines?

I had one example, for which I found it difficult to merge several tasks: reading from a disk, decoding audio, and feeding a DAC. It is difficult because these activities are CPU hungry, especially audio-decoding. Now I have FreeRTOS working as an arbiter, dividing CPU time to the tasks which are in a ready-to-run state. I gave an equal priority to each of the tasks, and it works wonderfully.

Another question: have you had a chance to look at the event groups? I think they are much cheaper than using queues-as-semaphores, and I found them extremely fast. With a bit of creativity, one event group can easily replace several semaphores. To explain them in the simplest way: some task wait (block) for bits to become high, while other task(s) can set or clear any of the bits. And yes the functions have xxFromISR variants.

Regards, Hein


FreeRTOS eating memory

Posted by dumarjo on October 2, 2014

Hi,

Le 2014-10-01 15:57, Hein Tibosch a écrit : > > Hi Jonathan and others, > > I'm sorry, I cannot answer your question above but.... I have some > questions: > > This thread is about small applications in a small CPU, for which 80 > bytes is a 'considerable amount' of RAM. > > Now I'm often wondering what advantage(s) it has to create more than > let's say 3 or 5 tasks beside the IDLE task? > > Ella wrote: > > Again for 20 tasks it is 16K of memory. > > 20 tasks? > I will just explain more our application,

We have more or less 30 tasks. This run on STM32F427 MCU. This MCU have 192K RAM and 64 CCM + 2M Flash. This board control big commercial HVAC. We have many points to monitor and sets (~200 points). each monitor point are used by many tasks. So reading it's value or changing it's value need to be protected.

I know one big advantage, which is ease of coding. Each task only has one responsibility. Dispatching events is easier: a keyboard task get woken up when a key is pressed. Or you can serve clients (TCP, UDP, serial) by starting a new task for each client/connection. The task can sleep while it is waiting for user input.

Or let me ask it the other way: what is so difficult in reducing the number of tasks? Keeping track of each sub-task? Creating and using so-called status-machines?

I had one example, for which I found it difficult to merge several tasks: reading from a disk, decoding audio, and feeding a DAC. It is difficult because these activities are CPU hungry, especially audio-decoding. Now I have FreeRTOS working as an arbiter, dividing CPU time to the tasks which are in a ready-to-run state. I gave an equal priority to each of the tasks, and it works wonderfully.

Another question: have you had a chance to look at the event groups? I think they are much cheaper than using queues-as-semaphores, and I found them extremely fast. With a bit of creativity, one event group can easily replace several semaphores. To explain them in the simplest way: some task wait (block) for bits to become high, while other task(s) can set or clear any of the bits. And yes the functions have xxFromISR variants.

I don't see how I could use the event system as protection for variables ? any sample ?

Regards

Jonathan

Attachments

alternate (3573 bytes)

FreeRTOS eating memory

Posted by heinbali01 on October 2, 2014

Bonjours Jonathan,

Thanks for your reply, but I'm still wondering why you need to create 30 tasks? Why can't you control all ~200 points from a single task?

Once you've decided that a single task becomes the 'owner' of those measurement points, programming may become a lot easier: no more locking is needed, you can use plain variables and change settings whenever you like.

You might want to give this task a queue so you can send it messages from anywhere. The task will then become like a server.

I don't see how I could use the event system as protection for variables? Any sample?

Sure. An event group has up to 24 bits, which can be used as 24 individual semaphores :-)

Assuming that the right to access each of 200 variables is independent, you could use code like this:

~~~~~

/* The code below has not been tested, it's just a sketch */

/* An example of using group events as semaphores */

define VARIABLE_COUNT 200
define BITSPERGROUP 24
define GROUPCOUNT ( VARIABLECOUNT / BITSPERGROUP )

/* 9 groups will be needed for 200 variables */ EventGroupHandlet xEventGroups[ GROUPCOUNT ];

void init( void ) { for( x = 0; x < GROUPCOUNT; x++ ) { xEventGroups[ x ] = xEventGroupCreate( ); /* Set all bits to '1' so the 'semaphore' can be taken */ xEventGroupSetBits( xEventGroups[ x ], ( 1u << BITSPER_GROUP ) - 1 ); } }

void access( BaseTypet xIndex ) { EventBitst xBitMask = 1U << ( xIndex % BITSPERGROUP );

/* Setting xClearOnExit to true is important */
xEventGroupWaitBits( xEventGroups[ xIndex / BITS_PER_GROUP ],
    xBitMask, pdTRUE, pdFALSE, ( TickType_t ) portMAX_DELAY )
/* access a variable, an object, an array or whatever */

/* And release the 'semaphore' for this variable */
xEventGroupSetBits( xEventGroups[ xIndex / BITS_PER_GROUP ],
    xBitMask );

}

~~~~~

Maybe the variables are clustered in groups, and you might find that a single event group is enough to guard the access to all clusters.

Note: xEventGroupWaitBits() has a parameter 'xWaitForAllBits' which can become useful if you have a hierarchy of access rights. Suppose you want to lock the access a set of variables (expressed as a bit-mask), this can easily be done.

Regards, Hein


FreeRTOS eating memory

Posted by dumarjo on October 2, 2014

hi,

Le 2014-10-02 13:57, Hein Tibosch a écrit : > > Bonjours Jonathan, > > Thanks for your reply, but I'm still wondering why you need to create > 30 tasks? > Why can't you control all ~200 points from a single task? > Not really. this idea is the use more spécialised task to control the process. If only 1 task is needed, we won't use any RTOS. > > Once you've decided that a single task becomes the 'owner' of those > measurement points, programming may become a lot easier: no more > locking is needed, you can use plain variables and change settings > whenever you like. > > You might want to give this task a queue so you can send it messages > from anywhere. The task will then become like a server. > > I don't see how I could use the event system as protection for > variables? Any sample? > > Sure. An event group has up to 24 bits, which can be used as 24 > individual semaphores :-) > > Assuming that the right to access each of 200 variables is > independent, you could use code like this: > > /* The code below has not been tested, it's just a sketch / > > / An example of using group events as semaphores / > > #define VARIABLECOUNT 200 > #define BITSPERGROUP 24 > #define GROUPCOUNT ( VARIABLECOUNT / BITSPER_GROUP ) > > / 9 groups will be needed for 200 variables / > EventGroupHandlet xEventGroups[ GROUPCOUNT ]; > > void init( void ) > { > for( x = 0; x < GROUP_COUNT; x++ ) > { > xEventGroups[ x ] = xEventGroupCreate( ); > / Set all bits to '1' so the 'semaphore' can be taken / > xEventGroupSetBits( xEventGroups[ x ], > ( 1u << BITSPERGROUP ) - 1 ); > } > } > > void access( BaseTypet xIndex ) > { > EventBitst xBitMask = 1U << ( xIndex % BITSPERGROUP ); > > / Setting xClearOnExit to true is important / > xEventGroupWaitBits( xEventGroups[ xIndex / BITSPERGROUP ], > xBitMask, pdTRUE, pdFALSE, ( TickTypet ) portMAXDELAY ) > / access a variable, an object, an array or whatever */ > xEventGroupSetBits( xEventGroups[ xIndex / BITSPERGROUP ], > xBitMask ); > } > > Maybe the variables are clustered in groups, and you might find that a > single event group is enough to guard the access to all clusters. > now I see how I can use it. Thanx for your help !

regards

Jonathan

Attachments

alternate (6238 bytes)

FreeRTOS eating memory

Posted by znatok on October 5, 2014

Hi, I think you took the discussion to the wrong way. There is no arguing that the whole FW can be written as one single task if required. And semaphores can be substituted by even groups if you have no choose.

But we are talking about good programming practice and we do want to use all features provided by OS (in our case FreeRTOS). The problem is that these features has to be implemented in a best and most optimized way. And this is what to my opinion is not fully done in FreeRTOS. The modern 32bit CPU (mostly based on ARM Cortex M3.M4) architecture has a one (at least) big asymmetry problem - a low RAM space compared to Flash space. In my CPU SMT32F207 Cortex-M3 RAM size is 128K and Flash size is 1M. I have already working project that use about 80K RAM - about 70% and 200K Flash - about 20%. That's why RAM economy for such projects is vital. FreeRTOS due to it's attempt to be widely portable does not fully address this problem. I looked at some other OS's to see what is going on where. The oposite to FreeRTOS is CooCox - that is strictly oriented to Cortex M3/M4 architecture. As a result they use significantly less RAM (and are much more efficient in speed). But this is not widely used OS and I can't trust it too much. So I want to stay with FreeRTOS and use all it's benefits. But I would expect developers to look deeper at the RAM usage problem and make possible optimizations in this direction. All after all old good #ifdef can still do a lot. I would agree to have some #ifdef RAM_OPTIMIZED in cost of some RAM costly features. Or #ifdef for each specific feature that can be removed to optimize RAM.


FreeRTOS eating memory

Posted by rtel on October 5, 2014

Can you be more specific about where you would like the RAM saving?

I think this topic started (I have not read back through all the way) talking about the RAM consumed by semaphores. People often remark that most hardware have test and set operations that can implement a semaphore in one assembly instruction - but that is missing the point. The FreeRTOS semaphores have built in event mechanisms that allow multiple tasks to block on giving and taking - what is more the tasks are guaranteed to block in priority order (in that the highest priority waiting task is the one that will be unblocked) and if the tasks have equal priority the one that has been waiting the longest. Many RTOSes do not do this, and so are not true to their prioritised promises. Also some RTOSes require other structures to be allocated in addition to the semaphore in order to achieve this, whereas FreeRTOS builds this all in. Further the tasks are unblocked automatically when a semaphores are given/taken - that cannot be done with a single test and set instruction - nor can a test and set instruction be event driven as they require polling which forbidden in FreeRTOS (it being true real time).

Currently semaphores have lists of tasks waiting to send and lists waiting to receive. There could be optimisations that creates only one list (or even neither of the lists) if the use case in the application does not require them. That would however greatly complicate their use.

In the case of semaphores maybe you never need the list of tasks waiting to give at all? That could be done at the cost of an increase in the code size and complexity.

We have already made some big optimisation changes to the way semaphores are used in interrupts - these changes can be seen in the public SVN repository but are not yet in the release code. We would welcome the possibility to make further optimisations - but this has to be balanced against ease of use, code size, performance, and most importantly of all correctness of operation.

Regards.


FreeRTOS eating memory

Posted by znatok on October 5, 2014

HI, My observations were following: 1. Each task use about 350 bytes of heap (plus task stack) 2. Semaphores are actually queues and they use 96 bytes. 3. Semaphore allocation allocates queue and 1 element of the queue. It cause to two allocations and extra bytes for double allocation.

Let's compare to the CoOS numbers. (I'm taking it from their web site):

RAM Space for Kernel 168 Bytes RAM Space for a TaskTask StackSize + 24 Bytes(MIN) TaskStackSize + 48 Bytes(MAX) RAM Space for a Mailbox 16 Bytes RAM Space for a Semaphore 16 Bytes RAM Space for a Queue 32 Bytes RAM Space for a Mutex 8 Bytes RAM Space for a User Timer 24 Bytes

Can you put FreeRTOS numbers for the same parameters?

On Sun, Oct 5, 2014 at 12:08 PM, Real Time Engineers ltd. rtel@users.sf.net wrote: > Can you be more specific about where you would like the RAM saving? > > I think this topic started (I have not read back through all the way) > talking about the RAM consumed by semaphores. People often remark that most > hardware have test and set operations that can implement a semaphore in one > assembly instruction - but that is missing the point. The FreeRTOS > semaphores have built in event mechanisms that allow multiple tasks to block > on giving and taking - what is more the tasks are guaranteed to block in > priority order (in that the highest priority waiting task is the one that > will be unblocked) and if the tasks have equal priority the one that has > been waiting the longest. Many RTOSes do not do this, and so are not true to > their prioritised promises. Also some RTOSes require other structures to be > allocated in addition to the semaphore in order to achieve this, whereas > FreeRTOS builds this all in. Further the tasks are unblocked automatically > when a semaphores are given/taken - that cannot be done with a single test > and set instruction - nor can a test and set instruction be event driven as > they require polling which forbidden in FreeRTOS (it being true real time). > > Currently semaphores have lists of tasks waiting to send and lists waiting > to receive. There could be optimisations that creates only one list (or even > neither of the lists) if the use case in the application does not require > them. That would however greatly complicate their use. > > In the case of semaphores maybe you never need the list of tasks waiting to > give at all? That could be done at the cost of an increase in the code size > and complexity. > > We have already made some big optimisation changes to the way semaphores are > used in interrupts - these changes can be seen in the public SVN repository > but are not yet in the release code. We would welcome the possibility to > make further optimisations - but this has to be balanced against ease of > use, code size, performance, and most importantly of all correctness of > operation. > > Regards. > > ________________________________ > > FreeRTOS eating memory > > ________________________________ > > Sent from sourceforge.net because you indicated interest in > https://sourceforge.net/p/freertos/discussion/382005/ > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/


FreeRTOS eating memory

Posted by rtel on October 5, 2014

Can you put FreeRTOS numbers for the same parameters?

You already have, and its in the FAQ (I think) so no secret.

This quote:

RAM Space for a Mutex 8 Bytes

is very interesting when you make reference back to my previous post. Is that just a spin lock by another name? I am not familiar with CoOS but if it is a "test and set" spin lock then we would never allow such a structure in FreeRTOS because it is hard to use, wastes masses of CPU time (whereas an RTOS should recover CPU time wasted by such constructs), and is inherently non-deterministic at the RTOS or the application level.

If 8 bytes for a mutex is not simply a test and set spin, and assuming you can have multiple tasks blocked on the mutex, and that the tasks can be of different or the same priority (or a mix of both), and that the tasks are ordered to provide true priorities behaviour (necessary for real time characteristics but ignored by some RTOS implementations), and that a blocked task is automatically notified and made ready to run when the mutex becomes avilable....then where is the RAM that would be required for the necessary data structures? Also note that FreeRTOS will always unblock the correct task in a deterministic way (always take the same amount of time). Not in those 8 bytes. This is why comparisons of this form are difficult, because while the name may be the same the functionality you can only assume is very different.

I'm not saying we don't want to optimise these things, and I have already made one suggestion as to how it could possibly be done, and said there are already optimisations for the way mutexes are used in interrupts available, I'm just pointing out that the comparison is too simplistic.

Yes mutexes are queues with an item size of 0 - the queue mechanism is the fundamental building block on which all forms of semaphore are build - and they have all the event management built in. That is how the code size is kept so small, which has the not so obvious side effect of making testing much easier to ensure the robustness of the system. The optimisation work we are undertaking at the moment is in recognition that the underlying code is now too generic and can be rationalised in order to optimise - but that is at the expense of code size and testability.

Regards, Richard.


FreeRTOS eating memory

Posted by znatok on October 5, 2014

I can't answer your questions as I did not look deep into implementation.

One thing that I did see was that they have static (not dynamic) allocation of the OS resources. In my project I nearly do not need dynamic allocation of semaphores and queues as I know exactly what resources I need. Having them statically allocated save heap allocation headers (about 20 bytes for each allocation in my case).

  • the queue mechanism is the fundamental building block on which all forms of semaphore are build
  • and they have all the event management built in. That is how the code size is kept so small, which has the not so obvious side effect of making testing much easier to ensure the robustness of the system. The optimisation work we are undertaking at the moment is in recognition that the underlying code is now too generic and can be rationalised in order to optimise - but that is at the expense of code size and testability.

I like this effort and your understanding. As I mentioned above Cortex M CPU implementations are mostly asymmetric and code size is much less critical compared to RAM size. So I vote for RAM optimization in cost of code size. And I do not afraid of testing efforts. You have enough users around to help you in it. Testing is a matter of time.

BTW another thing that can be taken from CoOS is strict orientation to Cortex M architecture. Maybe worth to think about FreeRTOS-Cortex-M branch, optimized for that specific architecture only? I assume this is 90% of the FreeRTOS users?

On Sun, Oct 5, 2014 at 9:17 PM, Real Time Engineers ltd. rtel@users.sf.net wrote: > Can you put FreeRTOS numbers for the same parameters? > > You already have, and its in the FAQ (I think) so no secret. > > This quote: > > RAM Space for a Mutex 8 Bytes > > is very interesting when you make reference back to my previous post. > Is that just a spin lock by another name? I am not familiar with CoOS > but if it is a "test and set" spin lock then we would never allow such a > structure in FreeRTOS because it is hard to use, wastes masses of CPU > time (whereas an RTOS should recover CPU time wasted by such > constructs), and is inherently non-deterministic at the RTOS or the > application level. > > If 8 bytes for a mutex is not simply a test and set spin, and assuming > you can have multiple tasks blocked on the mutex, and that the tasks can > be of different or the same priority (or a mix of both), and that the > tasks are ordered to provide true priorities behaviour (necessary for > real time characteristics but ignored by some RTOS implementations), and > that a blocked task is automatically notified and made ready to run when > the mutex becomes avilable....then where is the RAM that would be > required for the necessary data structures? Also note that FreeRTOS > will always unblock the correct task in a deterministic way (always take > the same amount of time). Not in those 8 bytes. This is why > comparisons of this form are difficult, because while the name may be > the same the functionality you can only assume is very different. > > I'm not saying we don't want to optimise these things, and I have > already made one suggestion as to how it could possibly be done, and > said there are already optimisations for the way mutexes are used in > interrupts available, I'm just pointing out that the comparison is too > simplistic. > > Yes mutexes are queues with an item size of 0 - the queue mechanism is > the fundamental building block on which all forms of semaphore are build > - and they have all the event management built in. That is how the code > size is kept so small, which has the not so obvious side effect of > making testing much easier to ensure the robustness of the system. The > optimisation work we are undertaking at the moment is in recognition > that the underlying code is now too generic and can be rationalised in > order to optimise - but that is at the expense of code size and testability. > > Regards, > Richard. > > ________________________________ > > FreeRTOS eating memory > > ________________________________ > > Sent from sourceforge.net because you indicated interest in > https://sourceforge.net/p/freertos/discussion/382005/ > > To unsubscribe from further messages, please visit > https://sourceforge.net/auth/subscriptions/


FreeRTOS eating memory

Posted by edwards3 on October 5, 2014

Dynamic allocation makes configuration and the API much simpler. But if your app is ok with static allocation then use heap_1 to avoid the overhead.


FreeRTOS eating memory

Posted by rtel on October 5, 2014

Currently I'm supposed to be writing a presentation - that is very tedious so I'm easily distracted. Looking at the code is a lot more interesting.

I recently made a change so queues only use one memory allocation instead of two as a result of a previous feature request (that does carry a complexity in that the queue storage area may end up misaligned - which won't cause a crash but could cause inefficient memory copies). That means the overhead of allocating one byte when there is nothing to be stored in the queue storage area has already gone away. Unlike the previous optimisations I mentioned, that change has not yet been checked in so you won't see it anywhere.

Looking at the queue structure I see several members that are not used by semaphores. I'm wondering if we could split the queue structure into two - so there is a mini-queue and a full-queue - the 'full' version containing the 'mini' version as one of its members, then extending the mini version in a sort of C++ object orientated fashion (but without using C++).

That could work...but I'm not sure how to prioritise that over the other work we are doing. It might have to wait (unless I have to write more presentations soon).

Regards.


FreeRTOS eating memory

Posted by richard_damon on October 5, 2014

My first feeling is that if the semaphore structure ends in a "full sized" object (and int or a pointer), then the data following will be properly aligned.

The other option is to make the data following be at (given ptr is a pointer to the struct) (unsigned char*)(ptr+1), since ptr+1 will be the address the next structure in an array of structures would be at, which should be aligned.

I would also suggest that if you make a mini-queue a member of the full-queue, you make it the first element so that the conversion of one pointer type to the other is trivial.


FreeRTOS eating memory

Posted by bowerymarc on October 5, 2014

350 bytes per task is quite high. I have a shipping product using FreeRTOS 7.5.0 running on a Kinetis cortext-m0+ and the task sizes are 36 (==144bytes) including a small number of local variables. If I remember right when I did the first porting test just flashing an LED I had it set to 32.

On Oct 5, 2014, at 2:00 PMEDT, Ella znatok@users.sf.net wrote:

HI, My observations were following: 1. Each task use about 350 bytes of heap (plus task stack) 2. Semaphores are actually queues and they use 96 bytes. 3. Semaphore allocation allocates queue and 1 element of the queue. It cause to two allocations and extra bytes for double allocation.

Let's compare to the CoOS numbers. (I'm taking it from their web site):

RAM Space for Kernel 168 Bytes RAM Space for a TaskTask StackSize + 24 Bytes(MIN) TaskStackSize + 48 Bytes(MAX) RAM Space for a Mailbox 16 Bytes RAM Space for a Semaphore 16 Bytes RAM Space for a Queue 32 Bytes RAM Space for a Mutex 8 Bytes RAM Space for a User Timer 24 Bytes

Can you put FreeRTOS numbers for the same parameters?

On Sun, Oct 5, 2014 at 12:08 PM, Real Time Engineers ltd. rtel@users.sf.net wrote:

Can you be more specific about where you would like the RAM saving?

I think this topic started (I have not read back through all the way) talking about the RAM consumed by semaphores. People often remark that most hardware have test and set operations that can implement a semaphore in one assembly instruction - but that is missing the point. The FreeRTOS semaphores have built in event mechanisms that allow multiple tasks to block on giving and taking - what is more the tasks are guaranteed to block in priority order (in that the highest priority waiting task is the one that will be unblocked) and if the tasks have equal priority the one that has been waiting the longest. Many RTOSes do not do this, and so are not true to their prioritised promises. Also some RTOSes require other structures to be allocated in addition to the semaphore in order to achieve this, whereas FreeRTOS builds this all in. Further the tasks are unblocked automatically when a semaphores are given/taken - that cannot be done with a single test and set instruction - nor can a test and set instruction be event driven as they require polling which forbidden in FreeRTOS (it being true real time).

Currently semaphores have lists of tasks waiting to send and lists waiting to receive. There could be optimisations that creates only one list (or even neither of the lists) if the use case in the application does not require them. That would however greatly complicate their use.

In the case of semaphores maybe you never need the list of tasks waiting to give at all? That could be done at the cost of an increase in the code size and complexity.

We have already made some big optimisation changes to the way semaphores are used in interrupts - these changes can be seen in the public SVN repository but are not yet in the release code. We would welcome the possibility to make further optimisations - but this has to be balanced against ease of use, code size, performance, and most importantly of all correctness of operation.

Regards.

FreeRTOS eating memory

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

FreeRTOS eating memory

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/freertos/discussion/382005/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

Attachments

alternate (4888 bytes)


[ 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