I have a question to the general principel of the heap-management scheme.
I use newlib as C-runtime library. I know that some of my libraries use the malloc-functions from newlib.
Than i have the FreeRTOS heap-management (e.g. heap_x.c).
For me this are 2 concurrent heap-management instances that i can’t use both in one executable. So i have to redirect one heap-management into the other so that effectively only one is used. Did i understand this right so far ?
After some researches i think it is not allowed to redirect newlib mallocs to the FreeRTOS heap-management, because malloc is part of the standard runtime library and therefore the malloc function could have several bypasses that i don’t know and therefore can’t redirect.
So i have to redirect the pvPortMalloc() and vPortFree() to the newlib malloc-functions.
Is this the right path to go?
That is not true. FreeRTOS heap_4 uses a static array and emulates malloc/free on top of that. You can use that along with the malloc/free from newlib.
That means that i have two memory-managers running parallel with two seperate memory areas. That means that load-balancing between the two memory areas is not possible.
How can i guarantee that the newlib memory does not grow into the FreeRTOS memory ?
Yes. You can use heap_3 to ensure that all the memory from one place.
The static array used by heap_4 is just like any other memory. So the answer to your question is - the same way as you gurantee that newlib memory does not grow into any other memory.
… and be aware when using both allocators both have to be threadsafe.
FreeRTOS provided memory managers are threadsafe, of course.
For (new)libc heap allocator you’ve to provide/implement __malloc_lock/unlock hocks.
Alternatively you could also replace/wrap all malloc/free/etc. calls using the --defsym/–wrap linker flags (with GCC toolchain) with a custom implementation e.g. using a FreeRTOS memory manager. But this approach is a bit more complex.
I have done the malloc redefinition but not with --defsym/-wrap. I just redefined the malloc-functions. The linker will search the library only for symbols that are not already resolved by earlier encountered object code, and object files generate from compilation are always linked before any libraries. However i found some blogs that warned to redefine malloc-functions from standard-library because standard-library is special or priviledged and malloc could have some undocumented bypasses…
As far as I remember newlib also uses the ‘reentrant’ versions internally like malloc_r etc. which might not be covered by your symbol/linker override.
For completeness reasons I’ve redefined/wrapped malloc free calloc realloc and their _r versions to be really sure (time ago).