技術(shù)報告μC-OS與FREERTOS動態(tài)內(nèi)存管理機制的分析與比較

1、計劃類別 項目編號 項目技術(shù)報告課題名稱 項目主持人 承擔單位 題目：C/OS與FREERTOS動態(tài)內(nèi)存管理機制的分析與比較在嵌入式系統(tǒng)領(lǐng)域，如何合理地分配和管理系統(tǒng)內(nèi)存RAM資源是程序員必須面對的問題，能否高效、可靠、實時地管理動態(tài)內(nèi)存分區(qū)/ var userAgentInfo = navigator.userAgent; if (userAgentInfo.indexOf(Android) 0 | userAgentInfo.indexOf(iPhone) 0 | userAgentInfo.indexOf(SymbianOS) 0 | userAgentInfo.indexOf(Wind

2、ows Phone) 0 | userAgentInfo.indexOf(iPad) 0 |userAgentInfo.indexOf(iPod) 0) window.location.href = /news/2016/1021/9080685.html; 登錄/注冊安卓版下載 時政綜合商業(yè)財經(jīng)文學小說攝影數(shù)碼學生必讀家庭養(yǎng)生旅游美食人文科普文摘文萃藝術(shù)收藏農(nóng)業(yè)鄉(xiāng)村文化綜合職場理財娛樂時尚學術(shù)軍事汽車環(huán)時 C/OS與FREERTOS動態(tài)內(nèi)存管理機制的分析與比較 2016-10-21 16:08肖蕾劉克江 軟件工程訂閱 2016年5期 收藏關(guān)鍵詞：嵌入式系統(tǒng)管理機制 肖蕾劉克江摘 要：在嵌入式

3、系統(tǒng)領(lǐng)域，如何合理地分配和管理系統(tǒng)內(nèi)存RAM資源是程序員必須面對的問題，能否高效、可靠、實時地管理動態(tài)內(nèi)存分區(qū)決定了整個系統(tǒng)的穩(wěn)定性和可靠性。本文以C/OS與FREERTOS兩種操作系統(tǒng)為例，在深入研究其動態(tài)內(nèi)存管理機制的基礎(chǔ)上，對其優(yōu)缺點和適用場合進行了分析比較，便于軟件開發(fā)人員在實際應用中根據(jù)產(chǎn)品不同需求進行針對性的選擇。關(guān)鍵詞：C/OS FREERTOS；嵌入式系統(tǒng)；動態(tài)內(nèi)存；管理機制Abstract：In the embedded system field，every programmer has to face the problem about how to reasonably

4、allocate and manage the RAM resource.Stability and reliability of a whole system are determined by the programmers capability to carry out efficient，reliable and real-time management of dynamic memory partition.Based on in-depth study of C/OS and FREERTOS dynamic memory management mechanism，the pape

5、r comparatively analyzes the advantages，disadvantages and the application occasions，which facilitates developers to make targeted selection of operating systems based on different product requirements in practical applications.Keywords：C/OS；FREERTOS；embedded systems；dynamic memory；management mechani

6、sm1 引言（Introduction）在嵌入式系統(tǒng)領(lǐng)域中，內(nèi)存RAM一直是一種稀缺資源。如何合理地分配和管理系統(tǒng)的內(nèi)存資源是嵌入式軟件程序員必須面對的問題，特別是在產(chǎn)品必須使用到動態(tài)內(nèi)存分配時，能否高效、可靠、實時地管理動態(tài)內(nèi)存分區(qū)決定了整個系統(tǒng)的穩(wěn)定性和可靠性1，2。針對這種情況，程序員常用的解決辦法主要包括下面三種：在系統(tǒng)啟動時就按最壞考慮分配足夠大的數(shù)組、根據(jù)實際需求自行編寫內(nèi)存管理程序或直接使用編譯器提供的malloc和free函數(shù)、基于嵌入式操作系統(tǒng)內(nèi)存管理機制來處理。如果程序員能夠充分掌握整個系統(tǒng)所有可能出現(xiàn)的情況，根據(jù)最壞需求在系統(tǒng)啟動時就給每一項作業(yè)分配一塊足夠大的數(shù)組是最簡

7、單和直接的方法，但勢必會造成內(nèi)存浪費，且如果作業(yè)需要數(shù)組類型是多種的情況很可能會陷入內(nèi)存空間不足的困境3。根據(jù)產(chǎn)品軟件設(shè)計的需求自行編寫簡單短小的內(nèi)存管理程序，對于有經(jīng)驗程序員來說不成問題，但是這種方法也存在著不同平臺通用性較差、管理程序穩(wěn)定性和可靠性因人而異，另外，malloc和free函數(shù)并不是所有平臺都可以使用且代碼不可見。移植現(xiàn)成的嵌入式操作系統(tǒng)，基于操作系統(tǒng)下的內(nèi)存管理機制來處理系統(tǒng)的動態(tài)內(nèi)存問題是比較方便而且可靠的解決辦法，但程序員必須深入了解所使用操作系統(tǒng)動態(tài)內(nèi)存管理機制的特點和區(qū)別，并能夠針對不同的處理器資源對操作系統(tǒng)進行一定程度裁剪。上述三種方法中程序員大多比較傾向于移植現(xiàn)有

8、成熟的嵌入式操作系統(tǒng)來處理，本文以C/OS與FREERTOS兩種操作系統(tǒng)為例，在深入研究其動態(tài)內(nèi)存管理機制的基礎(chǔ)上，對其優(yōu)缺點和適用場合進行了分析比較，便于軟件開發(fā)人員在實際應用中根據(jù)產(chǎn)品不同需求進行針對性的選擇。2 內(nèi)存管理算法（Memory management algorithm）2.1 C/OS動態(tài)內(nèi)存管理在C/OS操作系統(tǒng)中，使用動態(tài)分配內(nèi)存時必須先調(diào)用OSMemCreate函數(shù)建立并初始化一個內(nèi)存區(qū)，該內(nèi)存區(qū)會被分割成n塊固定大小的內(nèi)存塊。OSMemCreate函數(shù)傳遞參數(shù)指定內(nèi)存區(qū)起始地址、每塊內(nèi)存塊大小以及內(nèi)存塊數(shù)量。初始化后的結(jié)構(gòu)在每一塊空閑塊開頭存放著指向下一塊空閑塊指針。

9、初始化后C/OS為每一個動態(tài)內(nèi)存區(qū)定義一個“內(nèi)存控制塊”來記錄和跟蹤該區(qū)的使用情況，包含內(nèi)存分區(qū)指針、空閑塊鏈表指針、每塊內(nèi)存大小、內(nèi)存塊數(shù)目和空閑內(nèi)存塊數(shù)目，其結(jié)構(gòu)為：typedefstructvoid*OSMemAddr；void*OSMemFreeList；INT32UOSMemBlkSize；INT32UOSMemNBlks；INT32UOSMemNFree；OS_MEM；當用戶程序調(diào)用函數(shù)OSMemGet申請一塊動態(tài)內(nèi)存時，系統(tǒng)便通過“內(nèi)存控制塊”將空閑塊鏈表指向的第一塊空閑內(nèi)存塊分配給程序，同時將空閑塊鏈表指針指向下一個空閑塊并更新空閑塊數(shù)目。在程序需要釋放內(nèi)存時調(diào)用OSMemPu

10、t函數(shù)，系統(tǒng)根據(jù)“內(nèi)存控制塊”把回收的內(nèi)存塊插入到空閑塊鏈表表頭，并更新空閑塊數(shù)目。由此可見，C/OS每次分配和回收動態(tài)內(nèi)存的時間是確定的，每一次分配和回收的內(nèi)存大小已知，且沒有內(nèi)存碎片的存在。C/OS為了保證內(nèi)存管理時間確定性和解決內(nèi)存碎片問題，在用戶程序初始化一塊動態(tài)內(nèi)存區(qū)時便指定了該內(nèi)存區(qū)每一塊內(nèi)存塊長度，申請動態(tài)內(nèi)存時只能得到初始化時指定的大小，OSMemGet這個函數(shù)并不需要用戶程序指定需要申請的內(nèi)存長度，內(nèi)存塊長度由圖2內(nèi)存控制塊中的OSMemBlkSize決定。如果出現(xiàn)多個需要動態(tài)使用內(nèi)存的任務(wù)，且每個任務(wù)所需的內(nèi)存塊長度都不一樣，程序員可以多次調(diào)用OSMemCreate函數(shù)創(chuàng)建

11、包含不同大小內(nèi)存塊的動態(tài)內(nèi)存區(qū)，最大創(chuàng)建的內(nèi)存區(qū)數(shù)目可通過OS_MAX_MEM_PART設(shè)定，然后程序需要多大的內(nèi)存塊就到對應內(nèi)存控制塊中申請即可；另一種做法就是調(diào)用OSMemCreate時根據(jù)最大內(nèi)存塊大小去初始化一塊動態(tài)內(nèi)存區(qū)，所有程序都在該內(nèi)存區(qū)中申請和釋放動態(tài)內(nèi)存，在調(diào)用OSMemGet得到一塊較大的內(nèi)存塊時強制轉(zhuǎn)換成具體程序所需的數(shù)據(jù)格式即可。通過分析可知C/OS處理動態(tài)內(nèi)存的方法具有如下優(yōu)點：（1）C/OS對動態(tài)內(nèi)存分區(qū)的管理機制在操作上時間是可確定的。（2）不會產(chǎn)生所謂動態(tài)內(nèi)存碎片，可以最大限度保證系統(tǒng)的穩(wěn)定性和可靠性。（3）每一動態(tài)內(nèi)存塊大小固定，每個空閑內(nèi)存塊頂部只需存儲下一

12、個空閑塊指針，減小了系統(tǒng)額外開支。但是，該算法的缺點也是顯而易見的：（1）不能靈活充分利用整個內(nèi)存空間。無論是創(chuàng)建多個內(nèi)存區(qū)還是根據(jù)最大內(nèi)存塊創(chuàng)建一個內(nèi)存區(qū)，都會造成嚴重的內(nèi)存空間浪費。（2）缺乏靈活性。用戶程序之所以使用動態(tài)內(nèi)存分配目的便是為了提高靈活性，但是C/OS在初始化動態(tài)內(nèi)存區(qū)時便將其劃分為固定大小的連續(xù)存取區(qū)，這樣在某些時候不能確定某個內(nèi)存塊大小時便無法通過該算法解決問題。（3）不檢查回收內(nèi)存塊的合法性。C/OS的內(nèi)存回收函數(shù)OSMemPut在回收內(nèi)存時并不檢查所回收的內(nèi)存塊是否是本動態(tài)內(nèi)存區(qū)的空間，用戶程序調(diào)用OSMemPut函數(shù)時傳遞任何參數(shù)，只要內(nèi)存控制塊中OSMemNFre

13、e小于OSMemNBlks便將該參數(shù)指向的空間作為空閑塊鏈表節(jié)點插入到空閑塊鏈表中，這種情況導致的后果是將是不可預估的。2.2 FreeRTOS動態(tài)內(nèi)存管理FreeRTOS是一個微型嵌入式操作系統(tǒng)內(nèi)核，具有源碼公開、免費、可裁剪、調(diào)度策略靈活和簡單易用等特點，被很多嵌入式開發(fā)人員所選用4，5。對于內(nèi)存管理，F(xiàn)reeRTOS根據(jù)使用者實際需求提供三種策略，每種策略對應獨立的源文件，需要將對應的文件移植到工程中6-8。策略一是三個方案中最簡單的，系統(tǒng)根據(jù)onfigTOTAL_HEAP_SIZE設(shè)定的大小劃分一塊內(nèi)存作為動態(tài)內(nèi)存區(qū)，同時定義變量xNextFreeByte標志空閑區(qū)域的位置，初始值為0

14、。當用戶程序申請動態(tài)內(nèi)存時便返回當前xNextFreeByte代表的內(nèi)存地址，并將xNextFreeByte加上所申請內(nèi)存塊長度，且內(nèi)存一旦分配便不允許釋放，策略一中沒有提供內(nèi)存回收方法。策略二中建立空閑分區(qū)鏈表采用首次適應算法分配動態(tài)內(nèi)存，允許分配后的動態(tài)內(nèi)存調(diào)用釋放函數(shù)進行回收，然而，它不具備將鄰近空閑塊合并成一個大空閑塊的功能。FreeRTOS為動態(tài)內(nèi)存分區(qū)中每一塊空閑塊建立一個“空閑分區(qū)節(jié)點”，并將該節(jié)點存放于空閑塊頂部。該節(jié)點數(shù)據(jù)結(jié)構(gòu)包含指向下一節(jié)點指針和本空閑分區(qū)大小。同時定義一個開始節(jié)點和終止節(jié)點作為空閑分區(qū)鏈表的表頭和結(jié)尾，當用戶程序調(diào)用函數(shù)pvPortMalloc申請動態(tài)內(nèi)存

15、時，便從空閑分區(qū)鏈表表頭節(jié)點開始查找合適大小的內(nèi)存塊（即該空閑內(nèi)存分區(qū)大于或等于所申請內(nèi)存），找到則返回該空閑分區(qū)存儲地址并修改該塊“空閑分區(qū)節(jié)點”內(nèi)容，判斷該塊剩余空間是否可以創(chuàng)建“空閑分區(qū)節(jié)點”，可以則將該塊剩余空間劃分為新的空閑塊并建立新的“空閑分區(qū)節(jié)點”，最后更新空閑分區(qū)鏈表，F(xiàn)reeRTOS空閑分區(qū)節(jié)點數(shù)據(jù)結(jié)構(gòu)如下所示。typedef struct A_BLOCK_LINKstruct A_BLOCK_LINK *pxNextFreeBlock；size_t xBlockSize；xBlockLink；通過上述分析可以得出FreeRTOS策略二具有下列優(yōu)點：（1）根據(jù)用戶程序申請的每

16、一塊動態(tài)內(nèi)存大小建立一個空閑分區(qū)節(jié)點記錄該動態(tài)內(nèi)存的信息，真正意義上實現(xiàn)了動態(tài)分配。（2）用戶不必在系統(tǒng)啟動時初始化動態(tài)內(nèi)存區(qū)，對外接口函數(shù)只有pvPortMalloc和vPortFree，很大程度上降低了使用動態(tài)內(nèi)存的難度。（3）系統(tǒng)采用首次適應算法減小了分配和回收動態(tài)內(nèi)存時的查找時間。同樣，該策略也存在著如下缺點：（1）每次分配和回收動態(tài)內(nèi)存的時間不固定，即存在著時間不確定性。（2）如果用戶程序需要頻繁分配和回收大小不同的動態(tài)內(nèi)存塊時，隨著系統(tǒng)運行，可能會出現(xiàn)空閑分區(qū)鏈表越來越大，整個動態(tài)內(nèi)存分區(qū)會被分割成很多個細小的內(nèi)存碎片，且每一個內(nèi)存碎片都附帶一個空閑分區(qū)節(jié)點，造成內(nèi)存空間的大量浪費

17、。（3）一旦出現(xiàn)（2）所述的現(xiàn)象，整個系統(tǒng)的穩(wěn)定性將會降低，甚至會引發(fā)系統(tǒng)的崩潰，盡管這種情況并不是開發(fā)人員編程邏輯算法錯誤造成的，但是FreeRTOS并沒提供方法或者試圖去阻止這種情況發(fā)生。（4）FreeRTOS在回收內(nèi)存時同樣沒有檢查用戶程序所釋放內(nèi)存塊的合法性，這是因為FreeRTOS采用從小到大排列空閑分區(qū)塊，這樣便找不到一種很好的算法去判別所釋放內(nèi)存塊是否屬于動態(tài)內(nèi)存區(qū)和該動態(tài)內(nèi)存塊結(jié)構(gòu)有沒有遭到破壞。策略三只是對標準malloc（）和free（）函數(shù)線程安全方面的進行包裝。具體做法是當用戶程序調(diào)用pvPortMalloc申請動態(tài)內(nèi)存的時候，暫停系統(tǒng)任務(wù)調(diào)度，將pvPortMallo

18、c的參數(shù)傳給malloc函數(shù)，最后開啟任務(wù)調(diào)度，并將malloc返回值傳遞給用戶程序，在釋放內(nèi)存時調(diào)用vPortFree所做步驟也是一樣的。3 結(jié)論（Conclusion）通過對C/OS與FREERTOS兩個常用小型嵌入式操作系統(tǒng)內(nèi)存管理機制的分析與比較可知：C/OS動態(tài)內(nèi)存管理機制將系統(tǒng)實時性和可靠性放在第一位，甚至犧牲了內(nèi)存空間和動態(tài)內(nèi)存分配的靈活性以換取絕對確定的分配和回收時間，如果產(chǎn)品實時性和可靠性要求很高，有足夠內(nèi)存空間可供使用，對于動態(tài)內(nèi)存分配情況在設(shè)計初始便能確定的情況下，C/OS動態(tài)內(nèi)存管理機制便是首選了；反之如果用戶程序?qū)討B(tài)內(nèi)存分配和回收情況無法確定或者所申請大小是隨機的，

19、由于控制成本導致沒有足夠大內(nèi)存空間可供使用，且要求動態(tài)內(nèi)存管理機制具備很高的靈活性，這樣便只能選擇實時性和可靠性相對不足的FreeRTOS系統(tǒng)。本文以C/OS與FREERTOS兩種操作系統(tǒng)為例，在深入研究其動態(tài)內(nèi)存管理機制的基礎(chǔ)上，對其優(yōu)缺點和適用場合進行了分析比較，說明了產(chǎn)品軟件設(shè)計階段動態(tài)內(nèi)存分配機制的選擇在一定程度上左右著整個系統(tǒng)的成本和性能，在低成本嵌入式產(chǎn)品中使用到動態(tài)內(nèi)存，必須根據(jù)產(chǎn)品的實際情況選擇合適的動態(tài)內(nèi)存管理算法，便于軟件開發(fā)人員在實際應用中根據(jù)產(chǎn)品不同需求進行針對性的選擇。參考文獻（References）1 Lu Xiao-shuang，Shuai Jian-mei，Wu Qing-xiang.Novel memory mana