Five different heap implementations, named "heap 1-5" available in FreeRTOS.

Heap_1.c implementation:

• Heap 1 is similar to static allocation in the way that once the memory is taken, it cannot be freed or reallocated.
• It is less useful since FreeRTOS added support for static allocation.
• This implementation subdivides a single array into smaller blocks as RAM is requested.

1. The total size of the array (total size of the heap) is defined by the configTOTAL_HEAP_SIZE define, which is defined in FreeRTOSConfig.h.
2. The configAPPLICATION_ALLOCATED_HEAP configuration constant allows the heap to be placed at a specific memory address.
3. The xPortGetFreeHeapSize() function provides information about the remaining unallocated heap size.

Heap 1 Suitable Usage Scenarios:

• If the application never deletes a task, queue, etc.
• The implementation always takes the same amount of time to execute.
• "Deterministic" and avoids memory fragmentation.
• It can be used in applications that don't support true dynamic memory allocation.

Heap_2.c implementation:

• Heap 2 uses a best-fit algorithm and allows previously allocated blocks to be freed. It does not combine adjacent free blocks into a single large block.
• Points (1), (2), (3) of Heap 1 are the same in Heap 2, but Heap 2 does not provide information on how the unallocated memory is fragmented into smaller blocks.

• pvPortCalloc() function: This function allocates memory for an array of objects and initializes all bytes in the allocated storage to zero. It has the same signature as the standard library calloc function.

Heap 2 Usage Considerations:

• Heap 2 allows for the deallocation of previously allocated blocks, making it suitable for applications that repeatedly create and delete tasks, queues, etc.
• It may lead to memory fragmentation and allocation failures when dealing with variable-sized memory.
• The application can directly call pvPortMalloc() and vPortFree() instead of using them indirectly through other FreeRTOS API functions.
• Heap 2 is not deterministic, but it is more efficient than most standard C library malloc implementations.
• Suitable for small real-time systems that require dynamic object creation.
• Not recommended for new projects and kept due to backward compatibility.

Heap_3 implementation:

• The heap for FreeRTOS is located in the free RAM area outside the stack and heap areas for the main application.
• The only exception is the heap_3 model, which is located in the heap area of the main application.
• In heap_3 model, we have full control over memory allocation by creating our own linker script file and our own methods to allocate and deallocate the memory.

• The heap_3 uses the malloc() and free() functions, so the size of the heap is defined by the linker configuration, and the configTOTAL_HEAP_SIZE has no effect when heap_3 is used.
• Heap_3 will probably considerably increase the RTOS kernel code size.
• It is not recommended for both systems with critical and limited resources.
• Requires the linker to set up a heap and the compiler library to provide malloc and free implementations.
• It is not deterministic.

Heap-4 implementation: (not deterministic- but is much more efficient)

→the most popular one.

→It uses first fit algorithm to allocate memory

→it is able to combine adjacent Free blocks into a single larger block, which minimize the risk of memory fragmentation.

→The memory array for the heap is declared within the heap.4.C file itself. the starting address of the heap memory array is automatically configured by the Linker

→if configAPPLICATION_ALLOCATED-HEAP is set to zero, a static declaration of the heap array occurs within heap.4.C, and its size is determined by Config TOTAL HEAP. SIZE

→FreeRTOS allows for custom heap allocation by the application writer.

→To use a custom memory area for the FreeRTOS heap:

? Set config APPLICATION-ALLOCATED-HEAP to 1 in the FreeRTOS Config.h File

? Declare the heap memory array within the user's code, specifying the desired start address and size using config TOTAL-HEAP-SIZE

→heap 4: heap memory is organized as a Linked List for better efficiency when dynamically allocating / Freeing memory.

→ When allocating "N" bytes in the heap memory using "PVPortMalloc " API, it Consumes:

? 8 bytes for the structure of the "Linked list heap block"

? N bytes for the data that needs to be allocated.

? Padding for 8 bytes alignment.

*ex: if we need to allocate 52 bytes

8+ 52 = 60 bytes aligned to 8 bytes it gives 64 bytes consumed From the heap.

Heap-5 implementation:

→the algorithm used by heap-5 to allocate and free memory is identical to that used by heap.4

→unlike heap.4, heap_s is not Limited to allocating memory from a single Statically declared array, it can allocate memory from multiple and separated memory spaces.

→heap 5 is used in case we have Mcu with separated RAM areas that not Visible as Continuous memory space.

→it is able to combine adjacent free memory blocks into a single block like Heap-4

→it is the only memory allocation scheme that must be explicitly initialized before any os object can be created before first call of PVPortMalloc() .

→to initialize this scheme vPortDefineHeapRegions () function should be called

-it specifies start address and size of each separate memory area that we Would like to dedicate as a heap for our as application.

FreeRTOS memory allocation depends on stack operation models:

→Cortex-M Processor uses the "Full Descending stack" model

-cach push operation, the processor first decrements the Sp. then stores the Value in the memory location pointed by sp

-the SP points to the memory location where the Last data was pushed to the stack

-each pop operation, the value of the memory location pointed by sp is read, and then the Value of Sp is incremented automatically.

→if the stack grows down then allocate the stack then the TCB so the stack does not grow into the TCB. Likewise if the stack grows up then allocate the TCB then the stack