znatok wrote on Sunday, 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?
znatok wrote on Monday, 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. NIN_STACK_SIZE 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?
rtel wrote on Monday, 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.
znatok wrote on Tuesday, 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 MIN_STACK_SIZE 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?
rtel wrote on Tuesday, 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.
MIN_STACK_SIZE as defined in examples for specific platform.
The value of configMINIMAL_STACK_SIZE 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 configMINIMAL_STACK_SIZE 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.
davedoors wrote on Tuesday, December 24, 2013:
Ways to save semaphore memory:
Set configUSE_TRACE_FACILITY to 0.
Use a mutex instead of a binary semaphore (only one allocation is done then).
Use heap_2 instead of heap_4 (no hidden data allocated but can fragment).
dumarjo wrote on Wednesday, October 01, 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
heinbali01 wrote on Wednesday, October 01, 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
dumarjo wrote on Thursday, October 02, 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
heinbali01 wrote on Thursday, October 02, 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 BITS_PER_GROUP 24
#define GROUP_COUNT ( VARIABLE_COUNT / BITS_PER_GROUP )
/* 9 groups will be needed for 200 variables */
EventGroupHandle_t xEventGroups[ GROUP_COUNT ];
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 << BITS_PER_GROUP ) - 1 );
}
}
void access( BaseType_t xIndex )
{
EventBits_t xBitMask = 1U << ( xIndex % BITS_PER_GROUP );
/* 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
dumarjo wrote on Thursday, October 02, 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 semaphoresAssuming 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 BITS_PER_GROUP 24
#define GROUP_COUNT ( VARIABLE_COUNT / BITS_PER_GROUP )/* 9 groups will be needed for 200 variables */
EventGroupHandle_t xEventGroups[ GROUP_COUNT ];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 << BITS_PER_GROUP ) - 1 );
}
}void access( BaseType_t xIndex )
{
EventBits_t xBitMask = 1U << ( xIndex % BITS_PER_GROUP );/* 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 */ 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.
now I see how I can use it. Thanx for your help !
regards
Jonathan
znatok wrote on Sunday, October 05, 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.
rtel wrote on Sunday, October 05, 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.
znatok wrote on Sunday, October 05, 2014:
HI,
My observations were following:
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/
rtel wrote on Sunday, October 05, 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
Regards,
Richard.
znatok wrote on Sunday, October 05, 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/
edwards3 wrote on Sunday, October 05, 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.
rtel wrote on Sunday, October 05, 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.
richard_damon wrote on Sunday, October 05, 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.