今天，我們就來分析一下上次生成的CubeIDE點燈工程的源碼，看看跟我們拿來“逆向”的開發(fā)板例程源碼有什么異同。

1. 工程視圖下源碼文件夾

上圖中，Binaries和Includes文件夾我們不用去理它們，硬盤工程目錄下并沒有這兩個文件夾，是在編譯后產生的。另外3個文件夾是工程目錄里實際上有的，其中Debug文件夾是在Debug工程配置下編譯生成的，如果選擇Release工程配置并編譯，則會生成一個Release文件夾。

下面主要講一下Core和Drivers文件夾以及工程根目錄下的幾個文件。

其中Core文件夾是用戶代碼的存放地，包括源文件和頭文件。當然，你想重新建個文件夾放自己的代碼也是沒問題的。Core文件夾全打開后見下圖。頭文件和源文件是分開存放的，這跟硬盤上工程目錄是一致的。

Keil MDK就不一樣了，不會根據(jù)硬盤上工程目錄下的文件位置去自動生成工程目錄，需要手動去添加，哪怕你后期往工程目錄里添加文件，也照樣要在Keil里添加才出現(xiàn)在工程里。Eclipse就智能多了，自動識別硬盤上工程目錄里的文件，自動添加。

上圖中Inc目錄里前兩個頭文件就不說了，stm32f7xx_hal_conf.h的作用是要不要包含各種外設的頭文件，如果你手動添加了一個外設，就算把HAL庫里的外設驅動加進來了，也要在這個頭文件里打開這個外設功能。

當然，也可以直接在用戶代碼里包含新添加的外設頭文件，但是不推薦這樣做。另外要注冊自己的中斷回調函數(shù)，也在這個頭文件里開啟相應的開關，這個回調函數(shù)的事情以后也可以說一說。

stm32f7xx_it.h里放的都是中斷服務函數(shù)的申明，包括異常和中斷。

源文件里stm32f7xx_hal_msp.c里放的是與MCU相關的初始化代碼，msp也即MCU Specific Package，一般外設的msp代碼都放在外設對應的源文件中，stm32f7xx_hal_msp.c基本上沒什么東西。在CubeMX生成代碼時也可以選擇把外設的msp代碼都放在stm32f7xx_hal_msp.c中。

stm32f7xx_it.c里放的都是中斷服務函數(shù)，建議用戶中斷都放在這里，然后在相應的中斷函數(shù)里調用自己寫的中斷服務函數(shù)或是HAL庫提供的中斷服務函數(shù)。

syscalls.c里是系統(tǒng)調用的一些函數(shù)，可以改寫。例如想用printf函數(shù)通過串口發(fā)送消息，則可以把串口發(fā)送代碼添加進_write()函數(shù)里。

sysmem.c里有一個用來分配系統(tǒng)堆空間的函數(shù)。我們設置工程的時候只需要確定堆的大小即可，默認堆大小是512字節(jié)，如果在用戶代碼中不用malloc分配內存就不用改，完全夠用。

系統(tǒng)內存在運行時，內存空間是按下圖這樣分配的。其中newlib heap那一段就是堆空間。未使用的RAM空間在bbs段與堆之間。

system_stm32f7xx.c里包含系統(tǒng)初始化，時鐘初始化函數(shù)。其中系統(tǒng)初始化函數(shù)是系統(tǒng)啟動后，進入main函數(shù)之前執(zhí)行的。

Startup文件夾下只有一個MCU對應的啟動文件，以后可以具體分析一下這個啟動文件，看一看系統(tǒng)啟動后要執(zhí)行哪些操作，然后才進入main函數(shù)。

Drivers文件夾展開后如下圖。

基本上沒什么好說的，一個是ARM提供的CMSIS標準軟件接口，另一個是必要的HAL庫函數(shù)。

2. 工程根目錄下的文件分析

上圖中，第一個ioc文件不必多說，CubeMX生成的文件，后續(xù)可以改，重新生成代碼。第二個launch文件是我們上次配置工程運行選項時生成的，要下載代碼或調試代碼都得有這個文件。如果用的是Release工程配置，則會生成一個Release.launch。

后邊兩個文件是鏈接文件，gcc里需要鏈接文件告訴編譯器，各段要分別鏈接到什么地址上。其中FLASH.ld是我們常用的，生成的代碼要下載到FLASH中運行。RAM.ld會把代碼鏈接進RAM，調試的時候可以用，斷電后內容就消失了。

更改鏈接文件的方法如下：

好了，今天就講這么多，基本上CubeIDE工程里所有源文件的作用都講到了，具體怎么實現(xiàn)的還需要自己去看源代碼。接下來有時間講講啟動代碼。