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

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) 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