I would like to create a heap structure independent of the one used by FreeRTOS. I need it for dynamic memory allocation and I also need to be able to specify the memory location and size of the heap. I would like to take advantage of the heap management code in FreeRTOS.
In other words, I like to create it like I would a queue, task, or any other structure in FreeRTOS.
FreeRTOS only calls pvPortMalloc() and vPortFree(). Assuming their implementation doesn’t just map to malloc() and free() (which would be the case if you use heap_3.c) then you are free to implement malloc() and free() to behave in anyway that suites your needs.
I did resolve my issue. Unfortunately, I had to go to a solution outside of FreeRTOS. This seems like a duplication of effort. FreeRTOS already has multiple heap managers. However, it is somewhat restrictive in its use. It seems targeted for OS use only and not for general purposes. I think a simple tweak to allow a memory block of the user’s choosing, would make the FreeRTOS heap managers much more useful. In other words, make it available to the user just like the task, queue, semaphore, etc. mechanisms are.
I need a completely separate memory block for application use purposes only. I’ve found a number of dynamic memory managers, but I’d rather use the FreeRTOS implementation. Your colleague’s answer in which I would need to copy and paste the source code of the FreeRTOS heap manager and tweak it for my needs is unacceptable. I want a single point of reference in terms of code. In other words, there should be one copy of the heap manager code that can be instantiated for multiple purposes including use by the kernel. If a bug was fixed or a new feature added to your heap manager, I would need to manually copy that to my tweaked copy. That is a headache and is asking for trouble in terms of bugs in the code.
Just so you understand what I need this for, I’m using the nRF9160 which is a dual core ARM Cortex M33. The first core is the application. The second core is an LTE modem. The two cores communicate via an IPC interface and shared memory. One of the memory blocks needs to have a dynamic memory manager that allocates/deallocates memory as data is being transmitted to the modem core. This memory block may not be accessed by the kernel. It is for LTE modem transactions only.
There is a secondary restriction in that this block of memory must be located in the lower part of RAM. So, I would need to specify the location of the block and its length.
I’ve looked at the heap managers provided by FreeRTOS and you use a variable ucHeap to specify the memory block that the heap manager works with. I think it would be very advantageous if this can be provided through an API to the heap manager as well as to accommodate multiple memory blocks to be managed by the same heap management code.
Is the separate NRF fixed block allocator an appropriate alternative ?
Or make use of the preprocessor and #define (override or tag) all relevant symbols (ucHeap, public functions) with appropriate names and e.g. #include “heap_4.c” in a separate my_heap.c file to create your dedicated heap with dedicated API using the provided memory manager code.
Thank you for the link. The Nordic SDK you’ve pointed me to has a lot of goodies including a dynamic memory manager. If I don’t obtain a good solution to use the FreeRTOS heap manager, I will use the Nordic SDK.
As I’ve said, I’ve seen many other memory managers available out there. I would prefer to use the FreeRTOS heap manager as it would be one code base instead of multiple code bases. By the way, Zephyr make this available in their OS (just a point of information). At least the Nordic SDK is a source I have to pull from for other code used in the nRF9160. So, this would be a good second alternative. I can also pull in updates and bug fixes that Nordic might make to the SDK.
I clearly see your point. And the FreeRTOS memory managers like heap_4/5 are pretty good. but as you’ve recognized the current implementations don’t support having multiple heap instances. But I think (didn’t try) you could make use of them (single source) with the preprocessor trick mentioned.
in e.g. my_heap.c add something like this: