在嵌入式裸機編程中，作為一名初級的CODER。經常要與CPU、內存等打交道。CPU作為系統的動力源，其重要程度不言而喻。

　　但是，在裸機編程中，對內存的管理也不容忽視。如果稍微不注意，輕則，可能造成內存泄漏，重則造成內存訪問異常。導致系統死機。

　　嵌入式產品，對穩定性要求及其嚴格。動不動就死機，那可就麻煩大了。以下，是我本人對嵌入式系統裸機編程的內存管理的一些簡介。

　　1、盡量不使用庫自帶的malloc和free。

　　malloc和free在PC編程中是很好用的一種內存分配手段。但是，其在嵌入式中，就未必好用了。由于嵌入式裸機編程中，無MMU，即內存管理單元。無法實現對內存進行動態映射（不明白什么叫動態映射的同學，可以參考網上的資料）。也就是說，實際上，malloc和free并不能實現動態的內存的管理。這需要在啟動階段專門給其分配一段空閑的內存區域作為malloc的內存區。如STM32中的啟動文件startup_stm32f10x_md.s中可見以下信息：

　　Heap_Size EQU 0x00000800AREA HEAP， NOINIT， READWRITE， ALIGN=3__heap_baseHeap_Mem SPACE Heap_Size__heap_limit

　　其中，Heap_Size即定義一個宏定義。數值為 0x00000800。Heap_Mem則為申請一塊連續的內存，大小為 Heap_Size。簡化為C語言版本如下：

　　#define Heap_Size 0x00000800unsigned char Heap_Mem［Heap_Size］ = {0};

　　在這里申請的這塊內存，在接下來的代碼中，被注冊進系統中給malloc和free函數所使用：

　　__user_initial_stackheapLDR R0， = Heap_Mem ; 返回系統中堆內存起始地址LDR R1， =（Stack_Mem + Stack_Size）LDR R2， = （Heap_Mem + Heap_Size）; 返回系統中堆內存的結束地址LDR R3， = Stack_MemBX LR

　　就如上面分析的那樣，其實，在裸機編程的時候，對堆內存的管理。并非是智能化的，并非你想申請多少就多少。而是使用一塊固定的內存用作堆內存的分配。這在設計的時候，往往不是最佳的方案。這塊內存，如果被多次按照不同的大小進行申請，就會造成內存碎片。最終導致無法申請到足夠的內存。導致系統運行出錯。這在原本內存就已經很少的嵌入式系統中，更是不能接受的。所以，建議是把那個Heap_Size設置成 0 吧。放棄其使用吧。

　　而更為致命的是，有些malloc，free函數，由于工程人員的偷懶。實現甚至可能如下：

　　unsigned char mem_buffer［512］;unsigned char *mem_offset = & mem_buffer;void *malloc（int size）{unsigned char *tmp = mem_offset; mem_offset += size;return （void *）tmp;}void free（void *mem）{ mem_offset = mem;}

　　2、不用malloc、free的原因

　　一般單片機的內存都比較小，而且沒有MMU，malloc 與free的使用容易造成內存碎片。而且可能因為空間不足而分配失敗，從而導致系統崩潰，因此應該慎用，或者自己實現內存管理。如：《一個簡單而強大的單片機內存管理器》

　　在函數中使用malloc，如果是大的內存分配，而且malloc與free的次數也不是特別頻繁，使用malloc與free是比較合適的，但是如果內存分配比較小，而且次數特別頻繁，那么使用malloc與free就有些不太合適了。

　　因為過多的malloc與free容易造成內存碎片，致使可使用的堆內存變小。尤其是在對單片機等沒有MMU的芯片編程時，慎用malloc與free。如果需要對內存的頻繁操作，可以自己實現一個內存管理。

　　使用動態內存分配，應分不同的應用場合。

　　對于在操作系統上運行的程序，實際的物理內存分配與釋放使用操作系統來實現的，即使程序調用了 malloc和free物理內存并不會馬上變化。物理內存的變化，直到系統的內存管理操作時才發生。

　　對于裸機跑在MCU上的程序，分配與釋放內存都會造成實際物理內存的變化。因為此時物理內存的分配是由自己實現的，而內存管理我們自己并沒有去做。這樣，盲目的使用malloc與free恰恰并不好，反而會造成內存的不恰當使用。甚至于內存溢出。

　　所以，動態內存的使用前提是有一套好的內存管理方法，這樣動態內存的使用才會合理使用內存。如果沒有合適的內存管理代碼，還是用靜態內存好一些。

　　3、 更好的替代方案：內存池。

　　可能有些同學，覺得：內存池，這是什么東西？

　　內存池，簡潔地來說，就是預先分配一塊固定大小的內存。以后，要申請固定大小的內存的時候，即可從該內存池中申請。用完了，自然要放回去。注意，內存池，每次申請都只能申請固定大小的內存。這樣子做，有很多好處：

　　（1）每次動態內存申請的大小都是固定的，可以有效防止內存碎片化。（至于為什么，可以想想，每次申請的都是固定的大小，回收也是固定的大小）

　　（2）效率高，不需要復雜的內存分配算法來實現。申請，釋放的時間復雜度，可以做到O（1）。

　　（3）實現簡單，易用。

　　（4）內存的申請，釋放都在可控的范圍之內。不會出現以后運行著，運行著，就再也申請不到內存的情況。

　　內存池，并非什么很厲害的技術。實現起來，其實可以做到很簡單。只需要一個鏈表即可。在初始化的時候，把全局變量申請來的內存，一個個放入該鏈表中。在申請的時候，只需要取出頭部并返回即可。在釋放的時候，只需要把該內存插入鏈表。以下是一種簡單的例子（使用移植來的linux內核鏈表，對該鏈表的移植，以后有時間再去分析）：

　　#define MEM_BUFFER_LEN 5 //內存塊的數量#define MEM_BUFFER_SIZE 256 //每塊內存的大小

　　//內存池的描述，使用聯合體，體現窮人的智慧。就如，我一同學說的：一個字節，恨不得掰成8個字節來用。typedef union mem {struct list_head list;unsigned char buffer［MEM_BUFFER_SIZE］;}mem_t;

　　static union mem gmem［MEM_BUFFER_LEN］;

　　LIST_HEAD（mem_pool）;

　　//分配內存void *mem_pop（）{ union mem *ret = NULL; psr_t psr;

　　psr = ENTER_CRITICAL（）; if（！list_empty（&mem_pool）） { //有可用的內存池 ret = list_first_entry（&mem_pool， union mem， list）; //printf（“mem_pool = 0x%p ret = 0x%p

　　”， &mem_pool， &ret-》list）; list_del（&ret-》list）; } EXIT_CRITICAL（psr）; return ret;//-》buffer;}

　　//回收內存void mem_push（void *mem）{ union mem *tmp = NULL; psr_t psr;

　　tmp = （void *）mem;//container_of（mem， struct mem， buffer）; psr = ENTER_CRITICAL（）; list_add（&tmp-》list， &mem_pool）; //printf（“free = 0x%p

　　”， &tmp-》list）;

　　EXIT_CRITICAL（psr）;}

　　//初始化內存池void mem_pool_init（）{ int i; psr_t psr; psr = ENTER_CRITICAL（）; for（i=0; i《MEM_BUFFER_LEN; i++） { list_add（&（gmem［i］.list）， &mem_pool）; //printf（“add mem 0x%p

　　”， &（gmem［i］.list））; } EXIT_CRITICAL（psr）;}

　　編輯：黃飛