廣州大學(xué)嵌入式實驗_嵌入式操作系統(tǒng)FreeRTOS內(nèi)存如何管理和堆

小嵌

廣州大學(xué)嵌入式實驗_嵌入式操作系統(tǒng)FreeRTOS內(nèi)存如何管理和堆,   

  

編輯：黃工 公眾號：strongerHuang 素材來源：FreeRTOS網(wǎng)站 + 網(wǎng)絡(luò)     前兩年FreeRTOS被亞馬遜收購之后，變化不大，應(yīng)該是在規(guī)劃物聯(lián)網(wǎng)這一塊。   前段時間FreeRTOS官網(wǎng)的界面發(fā)生了變化，接下來可能會有大的動作，感興趣的朋友可以去看一下。   網(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  一、拓展知識動態(tài)內(nèi)存分配及其與 FreeRTOS 的關(guān)聯(lián)性：要讓 FreeRTOS 對象（如任務(wù)、隊列、信號量和事件組）變得盡可能易于使用，這些內(nèi)核對象不是在編譯時靜態(tài)分配，而是在運行時動態(tài)分配。每次創(chuàng)建內(nèi)核對象時，F(xiàn)reeRTOS 都會分配 RAM；

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Heap_1

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

Heap_1.c 實現(xiàn) pvPortMalloc（） 的一個非�；�本的版本。它不實現(xiàn) vPortFree（）。從不刪除任務(wù)或其他內(nèi)核對象的應(yīng)用程序可以使用 heap_1。

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

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

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

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

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

  

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

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

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

Heap_2

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

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

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

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

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

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

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

  

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

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

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

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

. C顯示已創(chuàng)建另一個任務(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)用。

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

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

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

Heap_3

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

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

Heap_4

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

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

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

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

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

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

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

  

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

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

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

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

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

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

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

Heap_5

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

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