前幾個月針對公司自己的芯片寫了個程序，這個程序有個硬性要求，就是能用的FLASH空間只有4KB，之前已經(jīng)寫得差不多了，最終占用空間3.6KB。這不，最近又得加需求，還剩一點點FLASH空間可以使用，這該如何是好。需求已經(jīng)加過來了，不行也得行啊。所以就得去優(yōu)化之前的代碼了，這就得研究比較底層的東西了。

我們的芯片與其它的MCU芯片用起來都差不多一樣。我們在用ST的時候，編譯完成，會生成很多文件，其中有一個.map文件，里面包含的信息就是工程 ROM/FLASH 和 RAM 的占用情況 。之前只是關心.map文件的最后幾行的 ROM/FLASH占用信息，如：

這次就得認真的學習一下這個文件了，只有清楚的知道這些信息才可以很好的進行代碼優(yōu)化 。下面我們來一起學習一下STM32的.map文件。（以下內容來自于野火及安富萊教程文檔）

map文件

要生成 map 文件，MDK 中如下選項要選上：

將工程全編譯，且沒有錯誤后，雙擊這里就可以看到生成的 map 文件了：

map文件的內容可分為如下幾部分：

1、節(jié)區(qū)的跨文件引用（Section Cross References） 2、刪除無用節(jié)區(qū)（Removing Unused input sections from the image） 3、符號映像表（Image Symbol Table (Local Symbols Global Symbols) 4、存儲器映像索引（Memory Map of the image） 5、映像組件大小（Image component sizes）

1、節(jié)區(qū)的跨文件引用

這部分主要是不同文件中函數(shù)的調用關系。在這部分中，詳細列出了各個.o 文件之間的符號引用。由于.o 文件是由 asm 或 c/c++源文件編譯后生成的，各個文件及文件內的節(jié)區(qū)間互相獨立，鏈接器根據(jù)它們之間的互相引用鏈接起來，鏈接的詳細信息在這個Section Cross References一一列出。

例如，開頭部分說明的是 startup_stm32f429_439xx.o 文件中的“RESET”節(jié)區(qū)分為它使用的__initial_sp符號引用了同文件“STACK”節(jié)區(qū)。也許我們對啟動文件不熟悉，不清楚這究竟是什么，那我們繼續(xù)瀏覽，可看到 main.o文件的引用說明，如說明 main.o 文件的 i.main 節(jié)區(qū)為它使用的 LED_GPIO_Config 符號引用了 bsp_led.o 文件的 i.LED_GPIO_Config 節(jié)區(qū)。

有時在構建工程的時候，編譯器會輸出 “Undefined symbol xxx (referred from xxx.o)” 這樣的提示，該提示的原因就是在鏈接過程中，某個文件無法在外部找到它引用的標號，因而產(chǎn)生鏈接錯誤。

2、刪除無用節(jié)區(qū)

map 文件的第二部分是刪除無用節(jié)區(qū)的說明，見代碼清單 51-11。

這部分列出了在鏈接過程它發(fā)現(xiàn)工程中未被引用的節(jié)區(qū)，這些未被引用的節(jié)區(qū)將會被刪除(指不加入到.axf 文件，不是指在.o 文件刪除)，這樣可以防止這些無用數(shù)據(jù)占用程序空間。

例如，上面的信息中說明 startup_stm32f429_439xx.o 中的 HEAP(在啟動文件中定義的用于動態(tài)分配的“堆”區(qū))以及 stm32f4xx_adc.o 的各個節(jié)區(qū)都被刪除了，因為在我們這個工程中沒有使用動態(tài)內存分配，也沒有引用任何 stm32f4xx_adc.c 中的內容。由此也可以知道，雖然我們把 STM32 標準庫的各個外設對應的 c 庫文件都添加到了工程，但不必擔心這會使工程變得臃腫，因為未被引用的節(jié)區(qū)內容不會被加入到最終的機器碼文件中。

對于這個部分功能，用戶最好將 MDK 中這個選項勾上，然后全編譯工程，效果會比較好：

3、符號映像表

map 文件的第三部分是符號映像表(Image Symbol Table)， 見代碼清單 51-12。

這個表列出了被引用的各個符號在存儲器中的具體地址、占據(jù)的空間大小等信息。如我們可以查到LED_GPIO_Config 符號存儲在 0x080002a5 地址，它屬于 Thumb Code 類型，大小為 106 字節(jié)，它所在的節(jié)區(qū)為 bsp_led.o 文件的 i.LED_GPIO_Config 節(jié)區(qū)。

4、存儲器映像索引

map 文件的第四部分是存儲器映像索引(Memory Map of the image)， 見代碼清單：

映像文件可以分為加載域（Load Region）和運行域（Execution Region） 。簡單的說，加載域就是程序在 Flash 中的實際存儲，而運行域是芯片上電后的運行狀態(tài)，通過下面的框圖可以有一個感性的認識：

通過上面的框圖可以看出，RW 區(qū)也是要存儲到 ROM/Flash 里面的，在執(zhí)行映像之前，必須將已初始化的 RW 數(shù)據(jù)從 ROM 中復制到 RAM 中的執(zhí)行地址并創(chuàng)建 ZI Section（初始化為 0 的變量區(qū)）。

本工程的存儲器映像索引分為 ER_IROM1 及 RW_IRAM1 部分，它們分別對應 STM32內部 FLASH 及 SRAM 的空間。相對于符號映像表，這個索引表描述的單位是節(jié)區(qū)，而且它描述的主要信息中包含了節(jié)區(qū)的類型及屬性，由此可以區(qū)分 Code、 RO-data、 RW-data及 ZI-data。

例如，從上面的表中我們可以看到 i.LED_GPIO_Config 節(jié)區(qū)存儲在內部 FLASH 的0x080002a4 地址，大小為 0x00000074，類型為 Code，屬性為 RO。而程序的 STACK 節(jié)區(qū)(棧空間)存儲在 SRAM 的 0x20000000 地址，大小為 0x00000400，類型為 Zero，屬性為RW（即 RW-data） 。

5、映像組件大小

map 文件的最后一部分是包含映像組件大小的信息(Image component sizes)，這也是最常查詢的內容，見代碼清單 ：

這部分包含了各個使用到的*.o 文件的空間匯總信息、整個工程的空間匯總信息以及占用不同類型存儲器的空間匯總信息，它們分類描述了具體占據(jù)的 Code、 RO-data、 RW-data及 ZI-data 的大小，并根據(jù)這些大小統(tǒng)計出占據(jù)的 ROM 總空間。

綜合整個 map 文件的信息，可以分析出，當程序下載到 STM32 的內部 FLASH 時，需要使用的內部 FLASH 是從 0x0800 0000 地址開始的大小為 1456 字節(jié)的空間；當程序運行時，需要使用的內部 SRAM 是從 0x20000000 地址開始的大小為 1024 字節(jié)的空間。

總結

對照著這個map文件再看看我的程序，就可以知道哪里占的flash空間多了。硬件相關的部分已經(jīng)用寄存器來操作，協(xié)議處理部分占用的flash空間最多。

最后，對于.map文件，我們一般只需要了解最后幾行即可。如果想要深入學習，可以參照野火及安富萊的教程文檔進行學習。