STM32 FreeRTOS内存管理简介

在使用 FreeRTOS 创建任务、队列、信号量等对象时，通常都有动态创建和静态创建的方式。动态方式提供了更灵活的内存管理，而静态方式则更注重内存的静态分配和控制。

如果是1·的，那么标准 C 库 malloc() 和 free() 函数有时可用于此目的，但是有以下缺点：

它们在嵌入式系统上并不总是可用。

它们占用了宝贵的代码空间。

它们不是线程安全的。

它们不是确定性的 （执行函数所需时间将因调用而异）。

所以更多的时候需要的不是一个替代的内存分配实现。一个嵌入式/实时系统的 RAM 和定时要求可能与另一个非常不同，所以单一的 RAM 分配算法将永远只适用于一个应用程序子集。为了避免此问题，FreeRTOS 将内存分配 API 保留在其可移植层，提供了五种内存管理算法： 

heap_1：最简单，不允许释放内存。

heap_2：允许释放内存，但不会合并相邻的空闲块。

heap_3：简单包装了标准 malloc() 和 free()，以保证线程安全。

heap_4：合并相邻的空闲块以避免碎片化。包含绝对地址放置选项。

heap_5：如同 heap_4，能够跨越多个不相邻内存区域的堆。

FreeRTOS内存管理算法

heap_1算法

heap_1 是最简单的实现方式。内存一经分配，它不允许内存再被释放。尽管如此，heap_1.c 还是适用于大量嵌入式应用程序。这是因为许多小型和深度嵌入的应用程序在系统启动时创建了所需的所有任务、队列、信号量等，并在程序的生命周期内使用所有这些对象（直到应用程序再次关闭或重新启动）。任何内容都不会被删除。

heap_2算法

heap_2 使用最佳适应算法，并且与方案 1 不同，它允许释放先前分配的块，它不将相邻的空闲块组合成一个大块。------空闲块不会合并

heap_2.c 适用于许多必须动态创建对象的小型实时系统 。

1、如果动态地创建和删除任务，且分配给正在创建任务的堆栈大小总是相同的，那么 heap2.c 可以在大多数情况下使用。

2、但是，如果分配给正在创建任务的堆栈的大小不是总相同，那么可用的空闲内存可能会被碎片化成许多小块，最终导致分配失败。

heap_2 使用最佳适应算法，该算法在空闲内存中选择与请求的内存大小最接近的块来分配内存。下面是一个简单的例子来说明最佳适应算法：

假设有一个空闲内存，其中包含以下块：

大小为 20 字节的空闲块。

大小为 15 字节的空闲块。

大小为 25 字节的空闲块。

现在有一个任务请求分配 18 字节的内存。最佳适应算法将选择大小为 20 字节的块，因为它与请求的大小最接近。在选择这个块后，分配器可能会将该块分割为两部分，一部分大小为 18 字节，用于任务的内存，另一部分大小为 2 字节，留作未分配的块。

heap_3算法

heap_3使用 C 库的 malloc 和 free 函数来进行内存分配和释放。它通过分配固定大小的块来管理内存，这些块的大小在配置 FreeRTOS 时进行定义，不会动态改变。

假设我们使用 Heap_3 管理内存，其中块的大小固定为 32 字节。初始时，整个内存被分割成大小为 32 字节的块：

块 1（32 字节）。

块 2（32 字节）。

块 3（32 字节）。

现在，有一个任务请求分配 20 字节的内存。Heap_3 算法将选择块 1，并将其分割成两部分：

分配给任务的内存块（20 字节）。

剩余未分配的块（12 字节）。

再假设另一个任务请求分配 40 字节的内存。由于没有足够大的块可供分配，heap_3 将返回分配失败的状态。

heap_3 的特点是块大小固定，这样可以简化内存管理。然而，也因为块大小不可变，可能导致内存碎片问题，即一些块可能无法完全被利用，从而浪费了一些内存。

heap_4算法

heap_4使用第一适应算法，并且会将相邻的空闲内存块合并成大内存块，减少内存碎片。

第一适应算法会在可用内存块中选择第一个足够大的内存块进行分配。

假设有一个内存块链表，其中包含以下顺序的内存块：

大小为 40 字节的块。

大小为 30 字节的块。

大小为 15 字节的块。

大小为 20 字节的块。

如果一个任务需要申请 25 字节的内存，第一适应算法将选择大小为 40 字节的块，因为它是第一个足够大以容纳任务需求的内存块。（如果是heap_2的最佳适应算法，会选择30字节的块）

heap_5算法

heap_5使用与 heap_4 相同的第一适应和内存合并算法，允许堆跨越多个不相邻（非连续）内存区域。适用于内存地址不连续的复杂场景。

reeRTOS内存管理相关API函数介绍

内存管理相关函数如下：