bowerymarc wrote on Sunday, October 05, 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:
- Each task use about 350 bytes of heap (plus task stack)
- Semaphores are actually queues and they use 96 bytes.
- 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 BytesCan 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
SourceForge.net: Log In to SourceForge.netTo unsubscribe from further messages, please visit
SourceForge.net: Log In to SourceForge.netFreeRTOS eating memory
Sent from sourceforge.net because you indicated interest in SourceForge.net: Log In to SourceForge.net
To unsubscribe from further messages, please visit SourceForge.net: Log In to SourceForge.net