Why always use only heap4.c memory scheme in FreeRTOS?
I'm porting FreeRTOS with a microcontroller and referred to online video tutorials. And found everyone uses heap4.c but no one seems to be using heap1/2/3 or other memory schemes. So I wonder why? appreciate any help, thank you!
1 Reply
Every "heap_x.c" has different memory allocation schemes which provides different level of flexibility, and efficiency in terms of memory use.
But I find "heap4.c" is well balanced schemes in terms of flexibility, memory requirement and execution time. However its never a rule of thumb to use the "heap4.c" rather it depends on micro-controllers memory specification in term of size and firmware design requirements.
heap1: It allocates memory from a statically allocated array. It doesn't permit memory to be freed once it has been allocated. Despite this limitation, heap1.c is appropriate for many small embedded system because of few advantage. "heap1.c" has less memory requirements and helps to reduce RTOS footprint. There is no memory fragmentation with "heap1.c"
Heap2: heap_2 uses a best fit algorithm and allows previously allocated blocks to be freed. But heap4 is preferred over heap2 because heap2 can results in a heap space that is badly fragmented into multiple small blocks. Heap3: It provides wrapper for the standard C library malloc() and free() function which probably increases the RTOS footprint(RTOS code size).
Heap4: heap_4 uses a first fit algorithm and it allows dynamically allocate and free memory. It combines adjacent free memory blocks, which significantly reduces the problem of small unusable fragments. Heap4 is much more efficient that most standard C library malloc implementations. I would like to add one more thing here, In tutorials, application code is very small with 2/3 task and Queues. Most of the tutorials are on arm based controller where you get good amount of memory space and processing power with respect to embedded system. So in this case no need to think much about RTOS footprint and execution times while configuring the RTOS. But when you are working on a product code, you have to use appropriate heap and RTOS configurations to meet performance requirements.
heap1: It allocates memory from a statically allocated array. It doesn't permit memory to be freed once it has been allocated. Despite this limitation, heap1.c is appropriate for many small embedded system because of few advantage. "heap1.c" has less memory requirements and helps to reduce RTOS footprint. There is no memory fragmentation with "heap1.c"
Heap2: heap_2 uses a best fit algorithm and allows previously allocated blocks to be freed. But heap4 is preferred over heap2 because heap2 can results in a heap space that is badly fragmented into multiple small blocks. Heap3: It provides wrapper for the standard C library malloc() and free() function which probably increases the RTOS footprint(RTOS code size).
Heap4: heap_4 uses a first fit algorithm and it allows dynamically allocate and free memory. It combines adjacent free memory blocks, which significantly reduces the problem of small unusable fragments. Heap4 is much more efficient that most standard C library malloc implementations. I would like to add one more thing here, In tutorials, application code is very small with 2/3 task and Queues. Most of the tutorials are on arm based controller where you get good amount of memory space and processing power with respect to embedded system. So in this case no need to think much about RTOS footprint and execution times while configuring the RTOS. But when you are working on a product code, you have to use appropriate heap and RTOS configurations to meet performance requirements.