Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

Thoughts on memory management

Posted by on June 12, 2011
Hi!

In this forum I often read the recommendation to use heap_3.c as soon as any task (I am not talking about the kernel) needs to call malloc() or free() itself. When using heap_3.c one should probably also replace any calls to malloc() and free() with the thread-safe versions pvPortMalloc() and vPortFree().

But I wonder if there isn't still a benefit in using the simple heap_1.c instead of the complex heap_3.c when I don't need to dynamically create / delete tasks, queues, etc.? The Memory Management chapter of FreeRTOS states that using heap_3.c "will probably considerably increase the kernel code size". If this is the case, I would prefer to use heap_1.c and just make the tasks (not the kernel) use the thread-safe pvPortMalloc() and vPortFree(). Right?

If I have only a single task that needs to call malloc() and free() it would be probably even possible to use the original malloc() and free() for that task when using heap_1.c, because there is no need for reentrancy. The kernel would not need to be suspended in this case anymore, as nothing but this single task would ever touch the heap, so this task could be safely preempted at any time.

Any comments are welcome...

Greetings,
Anguel

RE: Thoughts on memory management

Posted by Richard Damon on June 12, 2011
I believe the increase in kernel code size for using heap_3.c is due to the inclusion of malloc/free in the code, if you are already including it for other purposes, than using heap3 likely takes LESS space than heap_1/2.c since heap_3.c is itself very simple. Having the kernel use heap_3.c also adds a bit of efficiency to memory usage, as you don't lose the part of the heap_1/2 space not used from the rest of the program.

Also note, you can NOT mix heap_1 and heap_3 usage in the same program as heap_1, heap_2, and heap_3 all define the same functions (pvPortMalloc() and pvPortFree() ), just with different implementations.

RE: Thoughts on memory management

Posted by on June 13, 2011
“I believe the increase in kernel code size for using heap_3.c is due to the inclusion of malloc/free in the code”


That was what I also thought but was somehow irritated by the description on FreeRTOS.org.

“ if you are already including it for other purposes, than using heap3 likely takes LESS space than heap_1/2.c since heap_3.c is itself very simple. Having the kernel use heap_3.c also adds a bit of efficiency to memory usage, as you don't lose the part of the heap_1/2 space not used from the rest of the program.”


You are right, heap_3.c has the advantage that no RAM is wasted and should not give any penalty as long as one does not need to delete tasks, etc.

“Also note, you can NOT mix heap_1 and heap_3 usage in the same program as heap_1, heap_2, and heap_3 all define the same functions (pvPortMalloc() and pvPortFree() ), just with different implementations.”


That's right, one would need to use other names. But as mentioned above this is only interesting if only a single task (e.g. gatekeeper) is using malloc() and free(). This way one could probably do without disabling the scheduler when malloc() or free() are called.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS