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

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.

“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.