編輯：黃工 公眾號：strongerHuang 素材來源：FreeRTOS網站 + 網絡 前兩年FreeRTOS被亞馬遜收購之后，變化不大，應該是在規劃物聯網這一塊。 前段時間FreeRTOS官網的界面發生了變化，接下來可能會有大的動作，感興趣的朋友可以去看一下。 網址：

https://www.freertos.org

回讀之前文章：談談FreeRTOS_V10版本FreeRTOS更新至V10.2.1 言歸正傳，回來說FreeRTOS的內存管理和堆的問題。從 V9.0.0 開始，FreeRTOS 應用程序可以完全靜態分配，這意味著無需包含堆內存管理器。 FreeRTOS內存管理地址：
https://www.freertos.org/a00111.html 一、拓展知識動態內存分配及其與 FreeRTOS 的關聯性：要讓 FreeRTOS 對象（如任務、隊列、信號量和事件組）變得盡可能易于使用，這些內核對象不是在編譯時靜態分配，而是在運行時動態分配。每次創建內核對象時，FreeRTOS 都會分配 RAM；

每次刪除內核對象時，都會釋放 RAM。此策略可減少設計和規劃工作量，簡化了 API，并最大程度地減少 RAM 開銷。

動態內存分配是一個 C 語言編程概念。它不是特定于 FreeRTOS 或多任務處理的概念。它與 FreeRTOS 相關，因為內核對象是動態分配的，通用編譯器提供的動態內存分配方案并非始終適合實時應用程序。

可以使用標準 C 語言庫函數 malloc() 和 free() 分配內存，但由于以下一個或多個原因，這些函數可能不適合或不適用：

?它們并非始終適用于小型嵌入式系統。?它們的實現可能相當大，占用寶貴的代碼空間。?它們極少是線程安全的。?它們不是確定性的。執行函數所花的時間量將因調用不同而異。?它們可能會碎片化。如果堆中的可用 RAM 被拆分為若干較小且彼此分離的塊，則認為堆已碎片化。當堆已碎片化時，如果堆中沒有一個可用塊的大小足以包含某個數據塊，則嘗試分配此數據塊時將失敗，即使堆中所有單獨塊的總大小比無法分配的數據塊大小大很多倍，也是如此。?它們可能使鏈接器配置變得更復雜。?如果允許堆空間增長而占用了其他變量使用的內存，則這些函數可能成為一些難以調試的錯誤的來源。 二、動態內存分配的選項

早期版本的 FreeRTOS 使用內存池分配方案，在編譯時預分配由不同大小的內存塊組成的池，然后由內存分配函數返回。雖然這是實時系統中常用的方案，但它產生了大量支持請求。由于該方案使用 RAM 的效率無法滿足非常小型的嵌入式系統的需要，因此已被放棄。

FreeRTOS 現在將內存分配視為可移植層的一部分（而不是核心代碼庫的一部分）。這樣做的原因是我們已認識到嵌入式系統具有變化多端的動態內存分配和計時要求。單個動態內存分配算法僅適用于一部分應用程序。此外，通過從核心代碼庫中刪除動態內存分配，應用程序編寫者可以適時提供其自己的特定實現。

當 FreeRTOS 需要 RAM 時，它調用 pvPortMalloc() 而不是 malloc()。釋放 RAM 時，內核調用 vPortFree()，而不是 free()。pvPortMalloc() 與標準 C 語言庫函數 malloc() 具有相同的原型。vPortFree() 與標準 C 語言庫函數 free() 具有相同的原型。

pvPortMalloc() 和 vPortFree() 是公共函數，因此，也可以從應用程序代碼中調用它們。

FreeRTOS 附帶了 pvPortMalloc() 和 vPortFree() 的五個示例實現，本指南將一一介紹。FreeRTOS 應用程序可以使用其中一個示例實現或提供自己的實現。

這五個示例在 heap_1.c、heap_2.c、heap_3.c、heap_4.c 和 heap_5.c 源文件中定義，這些源文件位于FreeRTOS/Source/portable/MemMang 目錄中。

三、5種內存分配實現

heap_1：最簡單，不允許釋放內存。

heap_2：允許釋放內存，但不能合并相鄰的空閑塊。

heap_3：簡單包裝標準的malloc（）和free（）以確保線程安全。

heap_4：合并相鄰的空閑塊以避免碎片。包括絕對地址放置選項。

heap_5：按照heap_4，具有跨多個不相鄰的內存區域擴展堆的能力。

Heap_1

它常用于小型專用嵌入式系統，以便僅在啟動計劃程序之前創建任務和其他內核對象。在應用程序開始執行任何實時功能之前，內核動態分配內存，并且內存在應用程序的生命周期內保持已分配狀態。這意味著所選分配方案不必考慮任何更復雜的內存分配問題（例如確定性和碎片化），而是可以考慮如代碼大小和簡單性等屬性。

Heap_1.c 實現 pvPortMalloc() 的一個非常基本的版本。它不實現 vPortFree()。從不刪除任務或其他內核對象的應用程序可以使用 heap_1。

某些商業關鍵和安全關鍵型系統可能禁止動態內存分配，這些系統也可能能夠使用 heap_1。由于存在與非確定性、內存碎片化以及分配失敗等相關的不確定性，因此，關鍵系統通常禁止動態內存分配，但 heap_1 始終是確定性的且無法對內存進行碎片化。

當調用 pvPortMalloc() 時，heap_1 分配方案將一個簡單的數組細分成更小的塊。此數組稱為 FreeRTOS堆。

數組的總大小（以字節為單位）由定義 configTOTAL_HEAP_SIZE 在 FreeRTOSConfig.h 中設置。以這種方式定義大型數組可能讓應用程序看起來會消耗大量 RAM，甚至從數組中分配任何內存之前就是如此。

每個創建的任務都要求從堆中分配一個任務控制塊 (TCB) 和一個堆棧。

下圖顯示了在創建任務時 heap_1 如何細分簡單的數組。每次創建任務時，都會從 heap_1 數組分配 RAM。

A 顯示創建任何任務之前的數組。整個數組都可用。

B 顯示已創建一個任務后的數組。

C 顯示已創建三個任務后的數組。

Heap_2

Heap_2 包含在 FreeRTOS 發行版中以保持向后兼容性。建議不要用于新設計，而是考慮使用 heap_4，因為其中提供了更多功能。

也可以使用 Heap_2.c，但要細分由 configTOTAL_HEAP_SIZE 確定大小的數組。它使用最適合算法分配內存。與 heap_1 不同，它允許釋放內存。再次說明，數組是靜態聲明的，因此應用程序看起來會消耗大量RAM，甚至在從數組中分配任何內存之前就是如此。

最適合算法可確保 pvPortMalloc() 使用的可用內存塊在大小方面與所要求的字節數最接近。例如，考慮以下情形：

? 堆包含三個可用內存塊，大小分別為 5 字節、25 字節和 100 字節。 ? 調用 pvPortMalloc() 以請求 20 字節的 RAM。

適合所請求字節數的最小可用 RAM 塊是 25 字節塊，因此，pvPortMalloc() 將 25 字節塊拆分成一個 20 字節塊和一個 5 字節塊，然后返回一個指向 20 字節塊的指針。（上面是過于簡化了，因為 heap_2 要存儲堆區域中塊大小的信息，因此兩個拆分塊的總和實際上將小于 25。） 新的 5 字節塊保持可用于將來對pvPortMalloc() 的調用。

與 heap_4 不同，heap_2 不將相鄰的可用塊合并為單個更大的塊。因此，它更容易碎片化。但是，如果分配的塊與后續釋放的塊大小始終相同，則碎片化不是問題。Heap_2 適合反復創建和刪除任務的應用程序，但前提是分配給所創建的任務的堆棧大小不發生變化。

下圖顯示在創建和刪除任務時從 heap_2 數組中分配和釋放 RAM 的過程。

圖中顯示當創建、刪除以及后續再次創建任務時，最適合算法的工作原理。

? A顯示已創建三個任務后的數組。大型可用塊保持在數組的頂部。

? B顯示已刪除其中一個任務后的數組。這些區域有：

數組頂部的大型可用塊保持原樣。此外，目前有兩個較小的可用塊，它們之前分配給了已刪除任務的TCB 和堆棧。

? C顯示已創建另一個任務后的數組。創建任務導致兩次調用 pvPortMalloc()：一次是分配新的 TCB，一次是分配任務堆棧。使用 xTaskCreate() API 函數創建任務，如創建任務 (p. 23)中所述。在 xTaskCreate() 內部發生兩次 pvPortMalloc() 調用。

每個 TCB 的大小完全相同，因此，最適合算法可確保之前分配給已刪除任務的 TCB 的 RAM 塊可重用于分配新任務的 TCB。

分配給新創建任務的堆棧大小與分配給以前被刪除任務的堆棧大小完全相同，因此，最適合算法可確保之前分配給已刪除任務的堆棧的 RAM 塊可重用于分配新任務的堆棧。

數組頂部的較大的未分配塊保持不變。Heap_2 是非確定性的，但它比 malloc() 和 free() 的大多數標準庫實現都要快。

Heap_3

Heap_3.c 使用標準庫函數 malloc() 和 free()，因此堆大小由鏈接器配置定義。configTOTAL_HEAP_SIZE 設置不起作用。

Heap_3 通過臨時暫停 FreeRTOS 計劃程序使 malloc() 和 free() 成為線程安全的。

Heap_4

與 heap_1 和 heap_2 一樣，heap_4 將數組細分成較小的塊。數組是靜態聲明的并由configTOTAL_HEAP_SIZE 確定大小，因此應用程序看起來會消耗大量 RAM，甚至在從數組中分配任何內存之前就是如此。

Heap_4 使用首個適合算法分配內存。與 heap_2 不同，它會將相鄰的可用內存塊組合（合并）成一個較大的塊。這樣可以最大程度地減小內存碎片化風險。

首個適合算法可確保 pvPortMalloc() 使用第一個大小足以容納所要求的字節數的可用內存塊。例如，考慮以下情形：

? 堆包含三個可用內存塊。它們在數組中以下面的順序顯示：5 字節、200 字節和 100 字節。 ? 調用 pvPortMalloc() 以請求 20 字節的 RAM。

適合所請求字節數的第一個可用 RAM 塊是 200 字節塊，因此，pvPortMalloc() 將 200 字節塊拆分成一個 20字節塊和一個 180 字節塊，然后返回一個指向 20 字節塊的指針。（上面是過于簡化了，因為 heap_4 要存儲堆區域中塊大小的信息，因此兩個拆分塊的總和將小于 200 字節。） 新的 180 字節塊保持可用于將來對pvPortMalloc() 的調用。

Heap_4 會將相鄰的可用內存塊組合（合并）成一個較大的塊，同時最大限度地降低碎片化風險。Heap_4 適用于反復分配和釋放不同大小的 RAM 塊的應用程序。

下圖顯示從 heap_4 數組中分配和釋放 RAM 的過程。它演示 heap_4 首個適合算法（帶內存合并）在分配和釋放內存時的工作方式。

A顯示已創建三個任務后的數組。大型可用塊保持在數組頂部。

B顯示已刪除其中一個任務后的數組。

C顯示已創建一個 FreeRTOS 隊列后的數組。

D顯示在從應用程序代碼中直接調用 pvPortMalloc()（而不是通過間接調用 FreeRTOS API 函數）后的數組。

E顯示刪除隊列后的數組，此時會自動釋放分配給已刪除隊列的內存。此時，用戶分配的塊的兩側都有可用內存。

F顯示的也是已釋放用戶分配的內存之后的數組。用戶分配的塊所用的內存已與兩側的可用內存組合成一個更大的可用塊。

Heap_4 是非確定性的，但比 malloc() 和 free() 的大多數標準庫實現都要快。

Heap_5

heap_5 用來分配和釋放內存的算法與 heap_4 的完全相同。與 heap_4 不同，heap_5 不限于從單個靜態聲明的數組分配內存。Heap_5 可以從多個單獨的內存空間分配內存。當運行 FreeRTOS 的系統提供的 RAM在系統的內存映射中未作為單個鄰接的（沒有空間）塊出現時，Heap_5 很有用。

Heap_5 是唯一一個必須在調用 pvPortMalloc() 之前顯式初始化的內存分配方案。它使用 vPortDefineHeapRegions() API 函數進行初始化。當使用 heap_5 時，必須先調用vPortDefineHeapRegions()，然后才可創建任何內核對象（任務、隊列、信號等）。