from : https://www.freertos.org/a00111.html

FreeRTOS keeps the memory allocation API in its portable layer. The portable layer is outside of the source files that implement the core RTOS functionality, allowing an application specific implementation appropriate for the real time system being developed to be provided. When the RTOS kernel requires RAM, instead of calling malloc(), it instead calls pvPortMalloc(). When RAM is being freed, instead of calling free(), the RTOS kernel calls vPortFree().

freertos 把  分配内存和释放内存 的接口留在了 portable layer。

两个接口  pvPortMalloc   vPortFree

1 Memory allocation implementations included in the RTOS source code download

The FreeRTOS download includes five sample memory allocation implementations, each of which are described in the following subsections. The subsections also include information on when each of the provided implementations might be the most appropriate to select.

Each provided implementation is contained in a separate source file (heap_1.c, heap_2.c, heap_3.c, heap_4.c and heap_5.c respectively) which are located in the Source/Portable/MemMang directory of the main RTOS source code download. Other implementations can be added as needed. Exactly one of these source files should be included in a project at a time [the heap defined by these portable layer functions will be used by the RTOS kernel even if the application that is using the RTOS opts to use its own heap implementation].

下载的freertos 的源码自带 5 个内存管理器的实现。(heap_1.c, heap_2.c, heap_3.c, heap_4.c and heap_5.c)

一个项目中只能启用 5 个中的1 个。

Following below:

• heap_1 - the very simplest, does not permit memory to be freed.

非常简单的实现，没有内存释放。

• heap_2 - permits memory to be freed, but does not coalescence adjacent free blocks.

    包含内存释放，但是内存释放时，不会合并空闲空间。

• heap_3 - simply wraps the standard malloc() and free() for thread safety.

对标准库的malloc 的包裹

• heap_4 - coalescences adjacent free blocks to avoid fragmentation. Includes absolute address placement option.

内存释放时会对相邻的空闲空间进行合并。包括 绝对地址位置的 选项。

• heap_5 - as per heap_4, with the ability to span the heap across multiple non-adjacent memory areas.

和4相同，增加了 扩展内存到其他非相邻区域的能力。

Notes:

• heap_1 is less useful since FreeRTOS added support for static allocation.
• heap_2 is now considered legacy as the newer heap_4 implementation is preferred.

heap 4 是heap2的升级，heap2是heap1的升级。heap 1 的已经很少使用了。heap4是最好的选择。

进一步的 5中heap的优缺点，如下原文：

heap_1.c

heap_1 is less useful since FreeRTOS added support for static allocation.

heap_1 is the simplest implementation of all. It does not permit memory to be freed once it has been allocated. Despite this, heap_1.c is appropriate for a large number of embedded applications. This is because many small and deeply embedded applications create all the tasks, queues, semaphores, etc. required when the system boots, and then use all of these objects for the lifetime of program (until the application is switched off again, or is rebooted). Nothing ever gets deleted.

The implementation simply subdivides a single array into smaller blocks as RAM is requested. The total size of the array (the total size of the heap) is set by configTOTAL_HEAP_SIZE - which is defined in FreeRTOSConfig.h. The configAPPLICATION_ALLOCATED_HEAP FreeRTOSConfig.h configuration constant is provided to allow the heap to be placed at a specific address in memory.

The xPortGetFreeHeapSize() API function returns the total amount of heap space that remains unallocated, allowing the configTOTAL_HEAP_SIZE setting to be optimised.

The heap_1 implementation:

• Can be used if your application never deletes a task, queue, semaphore, mutex, etc. (which actually covers the majority of applications in which FreeRTOS gets used).
• Is always deterministic (always takes the same amount of time to execute) and cannot result in memory fragmentation.
• Is very simple and allocated memory from a statically allocated array, meaning it is often suitable for use in applications that do not permit true dynamic memory allocation.

configAPPLICATION_ALLOCATED_HEAP FreeRTOSConfig.h configuration constant is provided to allow the heap to be placed at a specific address in memory.

The xPortGetFreeHeapSize() API function returns the total amount of heap space that remains unallocated, (allowing the configTOTAL_HEAP_SIZE setting to be optimised), but does not provided information on how the unallocated memory is fragmented into smaller blocks.

This implementation:

• Can be used even when the application repeatedly deletes tasks, queues, semaphores, mutexes, etc., with the caveat below regarding memory fragmentation.
• Should not be used if the memory being allocated and freed is of a random size. For example:
  • If an application dynamically creates and deletes tasks, and the size of the stack allocated to the tasks being created is always the same, then heap2.c can be used in most cases. However, if the size of the stack allocated to the tasks being created was not always the same, then the available free memory might become fragmented into many small blocks, eventually resulting in allocation failures. heap_4.c would be a better choise in this case.
  • If an application dynamically creates and deletes queues, and the queue storage area is the same in each case (the queue storage area is the queue item size multiplied by the length of the queue), then heap_2.c can be used in most cases. However, if the queue storage area were not the same in each case, then the available free memory might become fragmented into many small blocks, eventually resulting in allocation failures. heap_4.c would be a better choise in this case.
  • The application called pvPortMalloc() and vPortFree() directly, rather than just indirectly through other FreeRTOS API functions.
• Could possible result in memory fragmentation problems if your application queues, tasks, semaphores, mutexes, etc. in an unpredictable order. This would be unlikely for nearly all applications but should be kept in mind.
• Is not deterministic - but is much more efficient that most standard C library malloc implementations.

heap_2.c is suitable for many small real time systems that have to dynamically create objects. See heap_4 for a similar implementation that combines free memory blocks into single larger blocks.

configAPPLICATION_ALLOCATED_HEAP FreeRTOSConfig.h configuration constant is provided to allow the heap to be placed at a specific address in memory.

The xPortGetFreeHeapSize() API function returns the total amount of heap space that remains unallocated when the function is called, and the xPortGetMinimumEverFreeHeapSize() API function returns lowest amount of free heap space that has existed system the FreeRTOS application booted. Neither function provides information on how the unallocated memory is fragmented into smaller blocks.

MSVC Win32 simulator demo also uses heap_5 so can be used as a reference.

/* Allocate two blocks of RAM for use by the heap.  The first is a block of
0x10000 bytes starting from address 0x80000000, and the second a block of
0xa0000 bytes starting from address 0x90000000.  The block starting at
0x80000000 has the lower start address so appears in the array fist. */
const HeapRegion_t xHeapRegions[] =
{
    { ( uint8_t * ) 0x80000000UL, 0x10000 },
    { ( uint8_t * ) 0x90000000UL, 0xa0000 },
    { NULL, 0 } /* Terminates the array. */
};

/* Pass the array into vPortDefineHeapRegions(). */
vPortDefineHeapRegions( xHeapRegions );

Initialising heap_5 after defining the memory blocks to be used by the heap

The xPortGetFreeHeapSize() API function returns the total amount of heap space that remains unallocated when the function is called, and the xPortGetMinimumEverFreeHeapSize() API function returns lowest amount of free heap space that has existed system the FreeRTOS application booted. Neither function provides information on how the unallocated memory is fragmented into smaller blocks.

The vPortGetHeapStats() API function provides additional information on the heap status.