電子產(chǎn)業(yè)一站式賦能平臺

PCB聯(lián)盟網(wǎng)

搜索
查看: 1578|回復(fù): 0
收起左側(cè)

嵌入式培訓(xùn)是坑么_嵌入式操作系統(tǒng)FreeRTOS內(nèi)存如何管理和堆

[復(fù)制鏈接]

2607

主題

2607

帖子

7472

積分

高級會員

Rank: 5Rank: 5

積分
7472
跳轉(zhuǎn)到指定樓層
樓主
發(fā)表于 2020-7-21 14:05:12 | 只看該作者 回帖獎勵 |倒序?yàn)g覽 |閱讀模式
嵌入式培訓(xùn)是坑么_嵌入式操作系統(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ù)、隊(duì)列、信號量和事件組)變得盡可能易于使用,這些內(nèi)核對象不是在編譯時靜態(tài)分配,而是在運(yùn)行時動態(tài)分配。每次創(chuàng)建內(nèi)核對象時,F(xiàn)reeRTOS 都會分配 RAM

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

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

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

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

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

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

當(dāng) FreeRTOS 需要 RAM 時,它調(diào)用 pvPortMalloc() 而不是 malloc()。釋放 RAM 時,內(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() 的五個示例實(shí)現(xiàn),本指南將一一介紹。FreeRTOS 應(yīng)用程序可以使用其中一個示例實(shí)現(xiàn)或提供自己的實(shí)現(xiàn)。

這五個示例在 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,具有跨多個不相鄰的內(nèi)存區(qū)域擴(kuò)展堆的能力。

Heap_1

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

Heap_1.c 實(shí)現(xiàn) pvPortMalloc() 的一個非常基本的版本。它不實(shí)現(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)存進(jìn)行碎片化。

當(dāng)調(diào)用 pvPortMalloc() 時,heap_1 分配方案將一個簡單的數(shù)組細(xì)分成更小的塊。此數(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 如何細(xì)分簡單的數(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è)計(jì),而是考慮使用 heap_4,因?yàn)槠渲刑峁┝烁喙δ堋?

也可以使用 Heap_2.c,但要細(xì)分由 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é)塊的指針。(上面是過于簡化了,因?yàn)?heap_2 要存儲堆區(qū)域中塊大小的信息,因此兩個拆分塊的總和實(shí)際上將小于 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 的過程。

  

圖中顯示當(dāng)創(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ù)標(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 通過臨時暫停 FreeRTOS 計(jì)劃程序使 malloc() 和 free() 成為線程安全的。

Heap_4

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

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

首個適合算法可確保 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é)塊的指針。(上面是過于簡化了,因?yàn)?heap_4 要存儲堆區(qū)域中塊大小的信息,因此兩個拆分塊的總和將小于 200 字節(jié)。) 新的 180 字節(jié)塊保持可用于將來對pvPortMalloc() 的調(diào)用。

Heap_4 會將相鄰的可用內(nèi)存塊組合(合并)成一個較大的塊,同時最大限度地降低碎片化風(fēng)險(xiǎn)。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 隊(duì)列后的數(shù)組。

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

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

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

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

Heap_5

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

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

發(fā)表回復(fù)

您需要登錄后才可以回帖 登錄 | 立即注冊

本版積分規(guī)則


聯(lián)系客服 關(guān)注微信 下載APP 返回頂部 返回列表