(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 ?

Thanks.

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

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 !