編輯：黃工 公眾號(hào)：strongerHuang 素材來源：FreeRTOS網(wǎng)站 + 網(wǎng)絡(luò) 前兩年FreeRTOS被亞馬遜收購之后，變化不大，應(yīng)該是在規(guī)劃物聯(lián)網(wǎng)這一塊。 前段時(shí)間FreeRTOS官網(wǎng)的界面發(fā)生了變化，接下來可能會(huì)有大的動(dòng)作，感興趣的朋友可以去看一下。 網(wǎng)址：

https://www.freertos.org

回讀之前文章：談?wù)凢reeRTOS_V10版本FreeRTOS更新至V10.2.1 言歸正傳，回來說FreeRTOS的內(nèi)存管理和堆的問題。從 V9.0.0 開始，F(xiàn)reeRTOS 應(yīng)用程序可以完全靜態(tài)分配，這意味著無需包含堆內(nèi)存管理器。 FreeRTOS內(nèi)存管理地址：
https://www.freertos.org/a00111.html 一、拓展知識(shí)動(dòng)態(tài)內(nèi)存分配及其與 FreeRTOS 的關(guān)聯(lián)性：要讓 FreeRTOS 對象（如任務(wù)、隊(duì)列、信號(hào)量和事件組）變得盡可能易于使用，這些內(nèi)核對象不是在編譯時(shí)靜態(tài)分配，而是在運(yùn)行時(shí)動(dòng)態(tài)分配。每次創(chuàng)建內(nèi)核對象時(shí)，F(xiàn)reeRTOS 都會(huì)分配 RAM；

每次刪除內(nèi)核對象時(shí)，都會(huì)釋放 RAM。此策略可減少設(shè)計(jì)和規(guī)劃工作量，簡化了 API，并最大程度地減少 RAM 開銷。

動(dòng)態(tài)內(nèi)存分配是一個(gè) C 語言編程概念。它不是特定于 FreeRTOS 或多任務(wù)處理的概念。它與 FreeRTOS 相關(guān)，因?yàn)閮?nèi)核對象是動(dòng)態(tài)分配的，通用編譯器提供的動(dòng)態(tài)內(nèi)存分配方案并非始終適合實(shí)時(shí)應(yīng)用程序。

可以使用標(biāo)準(zhǔn) C 語言庫函數(shù) malloc() 和 free() 分配內(nèi)存，但由于以下一個(gè)或多個(gè)原因，這些函數(shù)可能不適合或不適用：

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

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

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

當(dāng) FreeRTOS 需要 RAM 時(shí)，它調(diào)用 pvPortMalloc() 而不是 malloc()。釋放 RAM 時(shí)，內(nèi)核調(diào)用 vPortFree()，而不是 free()。pvPortMalloc() 與標(biāo)準(zhǔn) C 語言庫函數(shù) malloc() 具有相同的原型。vPortFree() 與標(biāo)準(zhǔn) C 語言庫函數(shù) free() 具有相同的原型。

pvPortMalloc() 和 vPortFree() 是公共函數(shù)，因此，也可以從應(yīng)用程序代碼中調(diào)用它們。

FreeRTOS 附帶了 pvPortMalloc() 和 vPortFree() 的五個(gè)示例實(shí)現(xiàn)，本指南將一一介紹。FreeRTOS 應(yīng)用程序可以使用其中一個(gè)示例實(shí)現(xiàn)或提供自己的實(shí)現(xiàn)。

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

三、5種內(nèi)存分配實(shí)現(xiàn)

heap_1：最簡單，不允許釋放內(nèi)存。

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

heap_3：簡單包裝標(biāo)準(zhǔn)的malloc（）和free（）以確保線程安全。

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

heap_5：按照heap_4，具有跨多個(gè)不相鄰的內(nèi)存區(qū)域擴(kuò)展堆的能力。

Heap_1

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

Heap_1.c 實(shí)現(xiàn) pvPortMalloc() 的一個(gè)非?；镜陌姹尽Ｋ粚?shí)現(xiàn) vPortFree()。從不刪除任務(wù)或其他內(nèi)核對象的應(yīng)用程序可以使用 heap_1。

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

當(dāng)調(diào)用 pvPortMalloc() 時(shí)，heap_1 分配方案將一個(gè)簡單的數(shù)組細(xì)分成更小的塊。此數(shù)組稱為 FreeRTOS堆。

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

每個(gè)創(chuàng)建的任務(wù)都要求從堆中分配一個(gè)任務(wù)控制塊 (TCB) 和一個(gè)堆棧。

下圖顯示了在創(chuàng)建任務(wù)時(shí) heap_1 如何細(xì)分簡單的數(shù)組。每次創(chuàng)建任務(wù)時(shí)，都會(huì)從 heap_1 數(shù)組分配 RAM。

A 顯示創(chuàng)建任何任務(wù)之前的數(shù)組。整個(gè)數(shù)組都可用。

B 顯示已創(chuàng)建一個(gè)任務(wù)后的數(shù)組。

C 顯示已創(chuàng)建三個(gè)任務(wù)后的數(shù)組。

Heap_2

Heap_2 包含在 FreeRTOS 發(fā)行版中以保持向后兼容性。建議不要用于新設(shè)計(jì)，而是考慮使用 heap_4，因?yàn)槠渲刑峁┝烁喙δ堋?/p>

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

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

? 堆包含三個(gè)可用內(nèi)存塊，大小分別為 5 字節(jié)、25 字節(jié)和 100 字節(jié)。 ? 調(diào)用 pvPortMalloc() 以請求 20 字節(jié)的 RAM。

適合所請求字節(jié)數(shù)的最小可用 RAM 塊是 25 字節(jié)塊，因此，pvPortMalloc() 將 25 字節(jié)塊拆分成一個(gè) 20 字節(jié)塊和一個(gè) 5 字節(jié)塊，然后返回一個(gè)指向 20 字節(jié)塊的指針。（上面是過于簡化了，因?yàn)?heap_2 要存儲(chǔ)堆區(qū)域中塊大小的信息，因此兩個(gè)拆分塊的總和實(shí)際上將小于 25。） 新的 5 字節(jié)塊保持可用于將來對pvPortMalloc() 的調(diào)用。

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

下圖顯示在創(chuàng)建和刪除任務(wù)時(shí)從 heap_2 數(shù)組中分配和釋放 RAM 的過程。

圖中顯示當(dāng)創(chuàng)建、刪除以及后續(xù)再次創(chuàng)建任務(wù)時(shí)，最適合算法的工作原理。

? A顯示已創(chuàng)建三個(gè)任務(wù)后的數(shù)組。大型可用塊保持在數(shù)組的頂部。

? B顯示已刪除其中一個(gè)任務(wù)后的數(shù)組。這些區(qū)域有：

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

? C顯示已創(chuàng)建另一個(gè)任務(wù)后的數(shù)組。創(chuàng)建任務(wù)導(dǎo)致兩次調(diào)用 pvPortMalloc()：一次是分配新的 TCB，一次是分配任務(wù)堆棧。使用 xTaskCreate() API 函數(shù)創(chuàng)建任務(wù)，如創(chuàng)建任務(wù) (p. 23)中所述。在 xTaskCreate() 內(nèi)部發(fā)生兩次 pvPortMalloc() 調(diào)用。

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

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

數(shù)組頂部的較大的未分配塊保持不變。Heap_2 是非確定性的，但它比 malloc() 和 free() 的大多數(shù)標(biāo)準(zhǔn)庫實(shí)現(xiàn)都要快。

Heap_3

Heap_3.c 使用標(biāo)準(zhǔn)庫函數(shù) malloc() 和 free()，因此堆大小由鏈接器配置定義。configTOTAL_HEAP_SIZE 設(shè)置不起作用。

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

Heap_4

與 heap_1 和 heap_2 一樣，heap_4 將數(shù)組細(xì)分成較小的塊。數(shù)組是靜態(tài)聲明的并由configTOTAL_HEAP_SIZE 確定大小，因此應(yīng)用程序看起來會(huì)消耗大量 RAM，甚至在從數(shù)組中分配任何內(nèi)存之前就是如此。

Heap_4 使用首個(gè)適合算法分配內(nèi)存。與 heap_2 不同，它會(huì)將相鄰的可用內(nèi)存塊組合（合并）成一個(gè)較大的塊。這樣可以最大程度地減小內(nèi)存碎片化風(fēng)險(xiǎn)。

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

? 堆包含三個(gè)可用內(nèi)存塊。它們在數(shù)組中以下面的順序顯示：5 字節(jié)、200 字節(jié)和 100 字節(jié)。 ? 調(diào)用 pvPortMalloc() 以請求 20 字節(jié)的 RAM。

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

Heap_4 會(huì)將相鄰的可用內(nèi)存塊組合（合并）成一個(gè)較大的塊，同時(shí)最大限度地降低碎片化風(fēng)險(xiǎn)。Heap_4 適用于反復(fù)分配和釋放不同大小的 RAM 塊的應(yīng)用程序。

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

A顯示已創(chuàng)建三個(gè)任務(wù)后的數(shù)組。大型可用塊保持在數(shù)組頂部。

B顯示已刪除其中一個(gè)任務(wù)后的數(shù)組。

C顯示已創(chuàng)建一個(gè) FreeRTOS 隊(duì)列后的數(shù)組。

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

E顯示刪除隊(duì)列后的數(shù)組，此時(shí)會(huì)自動(dòng)釋放分配給已刪除隊(duì)列的內(nèi)存。此時(shí)，用戶分配的塊的兩側(cè)都有可用內(nèi)存。

F顯示的也是已釋放用戶分配的內(nèi)存之后的數(shù)組。用戶分配的塊所用的內(nèi)存已與兩側(cè)的可用內(nèi)存組合成一個(gè)更大的可用塊。

Heap_4 是非確定性的，但比 malloc() 和 free() 的大多數(shù)標(biāo)準(zhǔn)庫實(shí)現(xiàn)都要快。

Heap_5

heap_5 用來分配和釋放內(nèi)存的算法與 heap_4 的完全相同。與 heap_4 不同，heap_5 不限于從單個(gè)靜態(tài)聲明的數(shù)組分配內(nèi)存。Heap_5 可以從多個(gè)單獨(dú)的內(nèi)存空間分配內(nèi)存。當(dāng)運(yùn)行 FreeRTOS 的系統(tǒng)提供的 RAM在系統(tǒng)的內(nèi)存映射中未作為單個(gè)鄰接的（沒有空間）塊出現(xiàn)時(shí)，Heap_5 很有用。

Heap_5 是唯一一個(gè)必須在調(diào)用 pvPortMalloc() 之前顯式初始化的內(nèi)存分配方案。它使用 vPortDefineHeapRegions() API 函數(shù)進(jìn)行初始化。當(dāng)使用 heap_5 時(shí)，必須先調(diào)用vPortDefineHeapRegions()，然后才可創(chuàng)建任何內(nèi)核對象（任務(wù)、隊(duì)列、信號(hào)等）。