Quality RTOS & Embedded Software

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


Heap_1 memory along using new and standard malloc.

Posted by simointe on June 13, 2016

(TMS570LC4, nested interrupt, C++, FreeRTOS V9.0.0rc2, compiler TI v5.2.7, rtos running ok).

Using heap1, I want to know if I can also use new() and standard malloc at other places in my application ? Is there a conflict to do this ? My problem is that when I use standard C++ librairy, like map stuff ~~~ mapTaskId.insert( std::makepair( ptr->getId(), task ) ); ... pos = mapTaskId.find( taskId ); ... ~~~ after a couple of insert, these thing do not work anymore, it seems there is a problem.

On something related, I've tried to manage memory using FreeRtos pvPortMalloc() instead of pure new() using this code: ~~~ ////Use RTOS's allocation strategy instead of new. ptr = pvPortMalloc( ..., sizeof( ThreadMsg) );

////A trick to call the constructor without creating the object. new(ptr) ThreadMsg( (TaskFunction_t)TaskBased::OSCallBack, task->stackSize, task->priority, sizeof(TaskBased::Message), task->mbNbElement );

     //instead ofcreating the object with new like this:

//ptr = new ThreadMsg( (TaskFunction_t)TaskBased::OSCallBack, task->stackSize, //task->priority, sizeof(TaskBased::Message), task->mbNbElement ); ~~~ Do I really have to use that trick ? Or I can use new with no problem ?


Heap_1 memory along using new and standard malloc.

Posted by rtel on June 13, 2016

The RTOS code called pvPortMalloc() and vPortFree() in place of the standard library malloc() and free(). Your application code can use either or both.

You must always provide an implementation of pvPortMalloc() and vPortFree(), but these can be directed to malloc() and free() by, for example, compiling heap_3.c into your build.

If you only call pvPortMalloc() and vPortFree(), and these are not directed to the standard library malloc() and free(), then you do not need to provide a separate heap for use by the standard library (the 'normal' heap size can be set to 0).

I presume new() and delete() somewhere along the line will map to the standard library malloc() and free().

Note that, if you are using heap_1.c, then you CANNOT free memory using pvPortFree().

Heap_1 memory along using new and standard malloc.

Posted by hs2sf on June 18, 2016

When using C++ incl. STL and maybe provided binary libraries not aware of your multi-tasking environment you have to take care yourself about new, delete and malloc/free yourself. Concerning new/delete you can provide all sorts (!) of global new/delete operators calling appropriate allocation/de-allocation functions supposed that maybe used (binary) library code doen't call C-lib malloc/../free. Alternatively provide the appropriate (low-level) malloc/calloc/realloc/free implementations and don't care about new/delete anymore just using the provided compiler versions. I'm using the latter way by making use of a GNU linker feature called 'wrapping' and add the mentioned allocation / free implementations myself. Obviously this requires a GNU toolchain. So you might check your toolchain if it provides something similar or how to ensure linking the complete application exclusively with your OS aware allocation / free functions. In addition some generic C-lib malloc implementations (not aware of a specific multi-tasking OS) provide hook-functions/callbacks for the required locking. If this is possible for you providing these lock/unlock callbacks is the most simple way to add multi-tasking support when using C++ with STL and (potentially unknown) binary libraries. Also when you've solved this issue you can simply define the pvPortMalloc and vPortFree macros with malloc/free. Good luck !

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

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

Latest News

NXP tweet showing LPC5500 (ARMv8-M Cortex-M33) running FreeRTOS.

Version 10.1.1 of the FreeRTOS kernel is available for immediate download. MIT licensed.

View a recording of the "OTA Update Security and Reliability" webinar, presented by TI and AWS.


FreeRTOS and other embedded software careers at AWS.

FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

Espressif ESP32

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

Xilinx Microblaze and Zynq partner