FreeRTOS系列第25篇---FreeRTOS內存管理分析

關注、星標公眾號，直達精彩內容

ID：技術讓夢想更偉大

整理：李肖遙

內存管理對應用程序和操作系統(tǒng)來說都非常重要?，F(xiàn)在很多的程序漏洞和運行崩潰都和內存分配使用錯誤有關。

FreeRTOS操作系統(tǒng)將內核與內存管理分開實現(xiàn)，操作系統(tǒng)內核僅規(guī)定了必要的內存管理函數(shù)原型，而不關心這些內存管理函數(shù)是如何實現(xiàn)的。

這樣做大有好處，可以增加系統(tǒng)的靈活性：不同的應用場合可以使用不同的內存分配實現(xiàn)，選擇對自己更有利的內存管理策略。

比如對于安全型的嵌入式系統(tǒng)，通常不允許動態(tài)內存分配，那么可以采用非常簡單的內存管理策略，一經(jīng)申請的內存，甚至不允許被釋放。

在滿足設計要求的前提下，系統(tǒng)越簡單越容易做的更安全。

再比如一些復雜應用，要求動態(tài)的申請、釋放內存操作，那么也可以設計出相對復雜的內存管理策略，允許動態(tài)分配和動態(tài)釋放。

「FreeRTOS內核規(guī)定的幾個內存管理函數(shù)原型為：」

void *pvPortMalloc( size_t xSize )?：內存申請函數(shù)
void vPortFree( void *pv )?：內存釋放函數(shù)
void vPortInitialiseBlocks( void )?：初始化內存堆函數(shù)
size_t xPortGetFreeHeapSize( void )?：獲取當前未分配的內存堆大小
size_t xPortGetMinimumEverFreeHeapSize( void )：獲取未分配的內存堆歷史最小值
FreeRTOS提供了5種內存管理實現(xiàn)，有簡單也有復雜的，可以應用于絕大多數(shù)場合。

它們位于下載包目錄*...\FreeRTOS\Source\portable\MemMang*中,文件名分別為：heap_1.c、heap_2.c、heap_3.c、heap_4.c、heap_5.c。

我在《FreeRTOS系列第8篇---FreeRTOS內存管理》這篇文章中介紹了這5種內存管理的特性以及各自應用的場合，今天我們要分析它們的實現(xiàn)方法。

FreeRTOS提供的內存管理都是從內存堆中分配內存的。默認情況下，F(xiàn)reeRTOS內核創(chuàng)建任務、隊列、信號量、事件組、軟件定時器都是借助內存管理函數(shù)從內存堆中分配內存。

最新的FreeRTOS版本（V9.0.0及其以上版本）可以完全使用靜態(tài)內存分配方法，也就是不使用任何內存堆。

對于heap_1.c、heap_2.c和heap_4.c這三種內存管理策略，內存堆實際上是一個很大的數(shù)組，定義為：

static?uint8_t?ucHeap[?configTOTAL_HEAP_SIZE?];
其中宏configTOTAL_HEAP_SIZE用來定義內存堆的大小，這個宏在FreeRTOSConfig.h中設置。

對于heap_3.c，這種策略只是簡單的包裝了標準庫中的malloc()和free()函數(shù)，包裝后的malloc()和free()函數(shù)具備線程保護。因此，內存堆需要通過編譯器或者啟動文件設置堆空間。

heap_5.c比較有趣，它允許程序設置多個非連續(xù)內存堆，比如需要快速訪問的內存堆設置在片內RAM，稍微慢速訪問的內存堆設置在外部RAM。每個內存堆的起始地址和大小由應用程序設計者定義。

1. heap_1.c

這是5個內存管理策略中最簡單的一個，我們稱為第一個內存管理策略，它簡單到只能申請內存。

是的，跟你想的一樣，一旦申請成功后，這塊內存再也不能被釋放。

對于大多數(shù)嵌入式系統(tǒng)，特別是對安全要求高的嵌入式系統(tǒng)，這種內存管理策略很有用，因為對系統(tǒng)軟件來說，邏輯越簡單越容易兼顧安全。

實際上，大多數(shù)的嵌入式系統(tǒng)并不需要動態(tài)刪除任務、信號量、隊列等，而是在初始化的時候一次性創(chuàng)建好，便一直使用，永遠不用刪除。

所以這個內存管理策略實現(xiàn)簡潔、安全可靠，使用的非常廣泛。我對這個對內存管理策略也情有獨鐘。

我們可以將第一種內存管理看作是切面包：初始化的內存就像一根完整的長棍面包，每次申請內存，就從一端切下適當長度的面包返還給申請者，直到面包被分配完畢，就這么簡單。

這個內存管理策略使用兩個局部靜態(tài)變量來跟蹤內存分配，變量定義為：

static?size_t?xNextFreeByte?=?(?size_t?)?0;
static?uint8_t?*pucAlignedHeap?=?NULL;
其中，變量xNextFreeByte記錄已經(jīng)分配的內存大小，用來定位下一個空閑的內存堆位置。

因為內存堆實際上是一個大數(shù)組，我們只需要知道已分配內存的大小，就可以用它作為偏移量找到未分配內存的起始地址。

變量xNextFreeByte被初始化為0，然后每次申請內存成功后，都會增加申請內存的字節(jié)數(shù)目。

變量pucAlignedHeap指向對齊后的內存堆起始位置。「為什么要對齊？」

這是因為大多數(shù)硬件訪問內存對齊的數(shù)據(jù)速度會更快。

為了提高性能，F(xiàn)reeRTOS會進行對齊操作，不同的硬件架構對齊操作也不盡相同，對于Cortex-M3架構，進行8字節(jié)對齊。

我們來看一下第一種內存管理策略對外提供的API函數(shù)。

1.1內存申請：pvPortMalloc()

「函數(shù)源碼為：」

void?*pvPortMalloc(?size_t?xWantedSize?)
{
void?*pvReturn?=?NULL;
static?uint8_t?*pucAlignedHeap?=?NULL;
?
????/*?確保申請的字節(jié)數(shù)是對齊字節(jié)數(shù)的倍數(shù)?*/
????#if(?portBYTE_ALIGNMENT?!=?1?)
????{
????????if(?xWantedSize?