版權聲明：本文爲博主原創文章，未經博主允許不得轉載。
1.MDK中的char類型的取值範圍是？
在MDK中，默認情況下，char 類型的數據項是無符號的，所以它的取值範圍是0～255。它們可以顯式地聲明爲signed char 或 unsigned。因此，定義有符號char類型變量，必須用signed顯式聲明。我曾讀過一本書，其中有一句話：“signed關鍵字也是很寬宏大量，你也可以完全當它不存在，在缺省狀態下，編譯器默認數據位signed類型”，這句話便是有異議的，我們應該對自己所用的CPU構架以及編譯器熟練掌握。
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.最新的keil MDK（V4.54）在編輯界面中已經可以支持中文編碼了，所以可以在編輯器中直接輸入漢字和中文標點符號，再也不會顯示亂碼或者不顯示了。雖然亂寫漢字和中文標點在編譯時依然會報錯，但好歹能顯示，也從側面說明中國市場的崛起。開啓方法見http://blog.csdn.net/zhzht19861011/article/details/7741928 不再貼了。
我還清楚的記得自己在大學剛開始用Keil C51那會，一次不小心在一行代碼後面用了箇中文分號，在當時這個中文分號是不被顯示的，然後編譯，編譯器報錯，我雙擊報錯信息定位到報錯的代碼行，卻怎麼也檢查不出來錯誤來，當時着急的心情現在想想還很好笑的，那個時候只能將錯誤代碼行用雙斜槓註釋掉，才能看到那個中文分號。但從V4.54之後，就應該再不會遇到我當時的情況了。
4.不知道從什麼版本開始,keil MDK的標題欄可以顯示工程路徑了,我是從V4.10直接升級到V4.54,V4.10的標題欄還是下圖的這個樣子:
如果你同一個工程有多個備份,你有同時打開了多個備份工程,要想識別出那個工程是那個備份,可是件不容易的事情,還好,keil更新較快.
5.這一條真僞未知,因爲我搜索了很久都沒有查證.
在一個論壇上看到的,Keil原來是一個人名,住在德國,最初的keil C51編譯器就是他開發的.爲人低調,話不多,但超級認真.當然,也超級厲害.
6.Stack分配到RAM的哪個地方?
keil MDK中，我們只需要定義各個模式下的堆棧大小，編譯器會自動在RAM的空閒區域選擇一塊合適的地方來分配給我們定義的堆棧，這個地方位於RAM的那個地方呢？通過查看編譯列表文件，原來MDK將堆棧放到程序使用到的RAM空間的後面，比如你的RAM空間從0x4000 0000開始，你的程序用掉了0x200字節RAM，那麼堆棧空間就從0x4000 0200處開始。具體的RAM分配，其實你可以從編譯後生成的列表文件“工程名.map”文件中查看。
7.有多少RAM會被初始化？
大家可能都已經知道，在進入main（）函數之前，MDK會把未初始化的RAM給清零的（在程序中自己定義變量初值的見第二條），但MDK會不會把所有RAM都初始化呢？答案是否定的，MDK只是把你的程序用到的RAM以及堆棧RAM給初始化，其它RAM的內容是不管的。如果你要使用絕對地址訪問MDK未初始化的RAM，那就要小心翼翼的了，因爲這些RAM的內容很可能是隨機的，每次上電都不同。至少，NXP的LPC2000系列就是這樣。
8.還是一個新版本的變化,還是關於版本V4.10和V4.54
V4.10版本,只要你重新打開工程,點擊"Build target files"(就這個圖標:
),編譯器就會將所有文件都編譯一次,不管你的文件在這之前有沒改動.但V4.54就不一樣了,再次打開文件,點擊"Build
target files"它會只編譯改過的文件的.早該這麼做了,每次打開工程都要編譯個十幾秒鐘,着實等的難受.
9.好個一絲不苟的編譯器
這是個十分奇葩的問題，碰巧被我遇到了，我承認是我代碼寫的不夠規範，但正是這個不規範的代碼，才得以發現這個奇葩的事件。實在忍不住用了兩個奇葩來形容。把過程簡化一下，如下所述：
假如你的工程至少有兩個.c文件，其中一個爲timer.c，裏面有個定時器中斷程序，每10ms中斷一次，定義一個變量來統計定時器中斷次數：
- unsigned int unIdleCount；
- extern unsigned int unIdleCount；
在main.c函數中，包含timer.h文件，並利用定時器變量unIdleCount來精確延時2秒，代碼如下：
- unIdleCount=0;
- while(unIdleCount!=200); //延時2S鍾
- 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
看到這裏，也許你已經笑翻了：你這個小白，這很明顯是沒用volatile修飾變量unIdleCount造成的！！！不錯，比起從RAM中讀寫數據，ARM或其它硬件從寄存器讀取數據要快的多的多的多...因此編譯器會“自作主張”的將某些變量讀到寄存器中，再次運算時也優先從寄存器中讀取，上面的例子就是這樣。解決這樣的方法是用關鍵字volatile修飾你不想讓編譯器優化的變量，明白的告訴編譯器：你不準優化我，每次使用我你都要本本分分的從RAM中讀取或寫入RAM。
所以先不要笑，我是不會犯這種錯誤的，之所以從這裏說起，是爲了照顧下還不知道volatile關鍵字的。。。
其實在timer.c中我是這樣定義統計定時器中斷次數變量的：
- unsigned int volatile unIdleCount；
- extern unsigned int unIdleCount；
- 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關鍵字修飾，即便定義這個變量的時候使用了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
其實如果好好看看編譯原理的書,是不會犯這麼低級的錯誤的,編譯器是分文件編譯,然後鏈接,文件A使用了文件B中定義的變量,在編譯的時候,文件A是完全不知道文件B裏面有什麼東西的,只能通過文件B的接口文件(.h文件)來獲得使用變量的屬性.
以這個爲例子，着重說明下關鍵字volatile，同時也要掌握編譯原理的知識,用好手中的工具.
10.關於float類型
在keil中,在不選擇"Optimize for time"編譯選項時,局部float變量佔用8個字節(編譯器默認自動擴展成double類型),如果你從Flash中讀取一個float類型常量並放在局部float型變量中時,有可能發生意想不到的錯誤:Cortex-M3中可能會出現硬fault.因爲字節對齊問題.
但有趣的是,一旦你使用"Optimize for time"編譯選項,局部float變量只會佔用4個字節.
11.默認情況下,從按下復位到執行你編寫的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
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屬性的區，將不希望零初始化的變量定義到這個區即可。
12.關於新版本V4.70
期盼已久的功能終於在V4.7實現了！！IDE升級到了<strong>µVision V4.70.00 ，</strong>增加了代碼和參數自動補全以及動態語法檢驗,增加了兩個性能分析命令。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運行庫，才能看到這個設置。
另外V4.70自帶的動態語法校驗我也非常喜歡,在輸入的時候就可以檢查出我輸入的變量名稱,標點,函數名等等對不對了.推薦升級測試一下。