1.MDK中的char類型的取值范圍是？
在MDK中，默認情況下，char 類型的數據項是無符號的，所以它的取值范圍是0～255。它們可以顯式地聲明為signed char 或 unsigned。因此，定義有符號char類型變量，必須用signed顯式聲明。我曾讀過一本書，其中有一句話：“signed關鍵字也是很寬宏大量，你也可以完全當它不存在，在缺省狀態下，編譯器默認數據位signed類型”，這句話便是有異議的，我們應該對自己所用的CPU構架以及編譯器熟練掌握。
關於keil MDK工程項目設置可參考：https://blog.csdn.net/ybhuangfugui/article/details/51655502，https://blog.csdn.net/ybhuangfugui/article/details/53131141
2.賦初值的全局變量和靜態變量，初值被放在什么地方？
unsigned int g_unRunFlag=0xA5； static unsigned int s_unCountFlag=0x5A；
這兩行代碼中，全局變量和靜態變量在定義時被賦了初值，MDK編譯環境下，你知道這個初值保存在那里嗎？
對於在程序中賦初值的全局變量和靜態變量，程序編譯后，MDK將這些初值放到Flash中，緊靠在可執行代碼的后面。在程序進入main函數前，會運行一段庫代碼，將這部分數據拷貝至相應RAM位置。若是你不小心將這些位置的數據擦除掉，嘿嘿...反正我是碰到了。
PS：后來看ARM的鏈接器，才知道ARM映象文件各組成部分在存儲系統中的地址有兩種：一種是在映象文件位於存儲器中時（也就是該映象文件開始運行之前，通俗的說就是下載到Flash中的二進制代碼）的地址，稱為加載地址；一種是在映象文件運行時（通俗的說就是給板子上電，開始運行Flash中的程序了）的地址，稱為運行時地址。賦初值的全局變量和靜態變量在程序還沒運行的時候，初值是被放在Flash中的，這個時候他們的地址稱為加載地址，當程序運行后，這些初值會從Flash中拷貝到RAM中，這時候就是運行時地址了。
3.Stack分配到RAM的哪個地方?
keil MDK中，我們只需要定義各個模式下的堆棧大小，編譯器會自動在RAM的空閑區域選擇一塊合適的地方來分配給我們定義的堆棧，這個地方位於RAM的那個地方呢？通過查看編譯列表文件，原來MDK將堆棧放到程序使用到的RAM空間的后面，比如你的RAM空間從0x4000 0000開始，你的程序用掉了0x200字節RAM，那么堆棧空間就從0x4000 0200處開始。具體的RAM分配，其實你可以從編譯后生成的列表文件“工程名.map”文件中查看。
4.有多少RAM會被初始化？
大家可能都已經知道，在進入main（）函數之前，MDK會把未初始化的RAM給清零的（在程序中自己定義變量初值的見第二條），但MDK會不會把所有RAM都初始化呢？答案是否定的，MDK只是把你的程序用到的RAM以及堆棧RAM給初始化，其它RAM的內容是不管的。如果你要使用絕對地址訪問MDK未初始化的RAM，那就要小心翼翼的了，因為這些RAM的內容很可能是隨機的，每次上電都不同。至少，NXP的LPC2000系列就是這樣
5.好個一絲不苟的編譯器
這是個十分奇葩的問題，碰巧被我遇到了，我承認是我代碼寫的不夠規范，但正是這個不規范的代碼，才得以發現這個奇葩的事件。實在忍不住用了兩個奇葩來形容。把過程簡化一下，如下所述：
假如你的工程至少有兩個.c文件，其中一個為timer.c，里面有個定時器中斷程序，每10ms中斷一次，定義一個變量來統計定時器中斷次數
unsigned int unIdleCount；
還有一個timer.h文件，里面是一些timer.c模塊的封裝，其中變量unIdleCount就被封裝在里面：
extern unsigned int unIdleCount；
在main.c函數中，包含timer.h文件，並利用定時器變量unIdleCount來精確延時2秒，代碼如下：
unIdleCount=0; while(unIdleCount!=200); //延時2S鍾
keil MDK V5.54下編譯，默認優化級別，編譯后下載到硬件平台。你會發現，代碼在
while(unIdleCount!=200);
處陷入了死循環。反匯編，代碼如下：
122: unIdleCount=0; 123: 0x00002E10 E59F11D4 LDR R1,[PC,#0x01D4] 0x00002E14 E3A05000 MOV R5,#key1(0x00000000) 0x00002E18 E1A00005 MOV R0,R5 0x00002E1C E5815000 STR R5,[R1] 124: while(unIdleCount!=200); //延時2S鍾 125: 0x00002E20 E35000C8 CMP R0,#0x000000C8 0x00002E24 1AFFFFFD BNE 0x00002E20
重點看最后兩句匯編代碼，寄存器R0是當前變量unIdleCount的值，匯編指令CMP為比較指令，如果R0中的內容與0xC8不等，則循環。但是這里並沒有更新寄存器R0的代碼，也就是說變量unIdleCount的值雖然在變化，但跟0xC8一直比較的卻是內容不變的R0。因為之前變量unIdleCount被清零，所以R0的內容也是0，永遠不等於0xC8，永遠不會跳出循環。
看到這里，也許你已經笑翻了：你這個小白，這很明顯是沒用volatile修飾變量unIdleCount造成的！！！不錯，比起從RAM中讀寫數據，ARM或其它硬件從寄存器讀取數據要快的多的多的多...因此編譯器會“自作主張”的將某些變量讀到寄存器中，再次運算時也優先從寄存器中讀取，上面的例子就是這樣。解決這樣的方法是用關鍵字volatile修飾你不想讓編譯器優化的變量，明白的告訴編譯器：你不准優化我，每次使用我你都要本本分分的從RAM中讀取或寫入RAM。
所以先不要笑，我是不會犯這種錯誤的，之所以從這里說起，是為了照顧下還不知道volatile關鍵字的。。。
其實在timer.c中我是這樣定義統計定時器中斷次數變量的：
unsigned int volatile unIdleCount；
但是，在timer.h中，我確偷了個懶，聲明這個變量的代碼如下：
extern unsigned int unIdleCount；
沒有使用關鍵字volatile，在keil MDK V5.54下編譯，默認優化級別，然后查看代碼的反匯編，如下所示：
122: unIdleCount=0; 123: 0x00002E10 E59F11D4 LDR R1,[PC,#0x01D4] 0x00002E14 E3A05000 MOV R5,#key1(0x00000000) 0x00002E18 E1A00005 MOV R0,R5 0x00002E1C E5815000 STR R5,[R1] 124: while(unIdleCount!=200); //延時2S鍾 125: 0x00002E20 E35000C8 CMP R0,#0x000000C8 0x00002E24 1AFFFFFD BNE 0x00002E20
可以看出，這個反匯編代碼居然和沒加volatile關鍵字的時候一模一樣！！代碼還是會在while出陷入死循環。
現在，應該知道我要表達的意思了吧，如果引用的變量聲明中沒有使用volatile關鍵字修飾，即便定義這個變量的時候使用了volatile關鍵字修飾，MDK編譯器照樣優化掉它！
將timer.h中的聲明更改為：
extern unsigned int volatile unIdleCount；
同樣環境下編譯，查看反匯編代碼，如下所示：
122: unIdleCount=0; 123: 0x00002E10 E59F01D4 LDR R0,[PC,#0x01D4] 0x00002E14 E3A05000 MOV R5,#key1(0x00000000) 0x00002E18 E5805000 STR R5,[R0] 124: while(unIdleCount!=200); //延時2S鍾 125: 0x00002E1C E5901000 LDR R1,[R0] 0x00002E20 E35100C8 CMP R1,#0x000000C8 0x00002E24 1AFFFFFC BNE 0x00002E1C
看最后三句匯編代碼，發現多了一個載入匯編指令LDR，這個指令在每次循環中都將變量unIdleCount從RAM中讀出到寄存器R1中，然后R1的值再和0xC8比較。這才是符合邏輯的需要的代碼。
其實如果好好看看編譯原理的書,是不會犯這么低級的錯誤的,編譯器是分文件編譯,然后鏈接,文件A使用了文件B中定義的變量,在編譯的時候,文件A是完全不知道文件B里面有什么東西的,只能通過文件B的接口文件(.h文件)來獲得使用變量的屬性.
以這個為例子，着重說明下關鍵字volatile，同時也要掌握編譯原理的知識,用好手中的工具.
6.關於float類型
在keil中,在不選擇"Optimize for time"編譯選項時,局部float變量占用8個字節(編譯器默認自動擴展成double類型),如果你從Flash中讀取一個float類型常量並放在局部float型變量中時,有可能發生意想不到的錯誤:Cortex-M3中可能會出現硬fault.因為字節對齊問題.但有趣的是,一旦你使用"Optimize for time"編譯選項,局部float變量只會占用4個字節.
7.默認情況下,從按下復位到執行你編寫的C代碼main函數,keil mdk做了些什么?
硬件復位后,第一步是執行復位處理程序,這個程序的入口在啟動代碼里(默認),摘錄一段cortex-m3的復位處理入口代碼:
Reset_Handler PROC ;PROC等同於FUNCTION,表示一個函數的開始,與ENDP相對?
EXPORT Reset_Handler [WEAK]
IMPORT SystemInit
IMPORT __main
LDR R0, =SystemInit
BLX R0
LDR R0, =__main
BX R0
ENDP
這里SystemInit函數是我自己用C代碼寫的硬件底層時鍾初始化代碼,這個可不算是keil mdk給代勞的.初始化堆棧指針、執行完用戶定義的底層初始化代碼后,發現接下來的代碼是調用了__main函數,這里之所以有__main函數，是因為在C代碼中定義了main函數，函數標簽 main() 具有特殊含義。main() 函數的存在強制鏈接器鏈接到 __main 和 __rt_entry 中的初始化代碼。
其中，__main函數執行代碼和數據復制、解壓縮以及 ZI 數據的零初始化。解釋一下，C代碼中，已經賦值的全局變量被放在RW屬性的輸入節中，這些變量的初值被keil mdk壓縮后放到ROM或Flash中（RO屬性輸入節）。什么是賦值的全局變量呢？如果你在代碼中這樣定義一個全局變量：int nTimerCount=20；變量nTimerCount就是已經賦值的變量，如果是這樣定義：int nTimerCount；變量nTimerCount就是一個非賦值的變量，keil默認將它放到屬性為ZI的輸入節。為什么要壓縮呢？這是因為如果賦值變量較多，會占用較多的Flash存儲空間，keil 默認用自己的壓縮算法。這個“解壓縮”就是將存放在RO輸入區（一般為ROM或Flash）的變量初值，按照一定算法解壓縮后，拷貝到相應RAM區。ZI數據清零是指將ZI區的變量所在的RAM區清零。使用 UNINIT 屬性對執行區進行標記可避免 __main 對該區域中的 ZI 數據進行零初始化。這句話很重要，比如我有一些變量，保存一些重要信息，不希望復位后就被清零，這時就可以用分散加載文件定義一塊UNINIT屬性的區，將不希望零初始化的變量定義到這個區即可。
8.關於新版本V4.70
期盼已久的功能終於在V4.7實現了！！IDE升級到了µVision V4.70.00 ，增加了代碼和參數自動補全以及動態語法檢驗,增加了兩個性能分析命令。J-LINK驅動更新到V4.62，編譯器版本更新到5.03.其中我是最喜歡的是代碼和參數自動補全以及動態語法檢驗。剛回答了一個百度知道提問，提問者問到V4.70a為什么不能自動代碼和參數補全，這里也說一下，這並不是4.70a的問題,4.70a相對於4.70只是修正了"linking in MDK-ARM user guides"問題,使能自動補全的功能要設置一下:點擊Edit-Configuration...,在打開的對話框中選中Text Completion標簽欄,在此頁面中選中symbols after復選框即可完全開啟(安裝后默認並沒有選中這個框).補充，你的系統至少要有vc++2010運行庫，才能看到這個設置。
文章裁剪自：https://blog.csdn.net/zhzht19861011/article/details/7745151