1.MDK中的char類型的取值范圍是？ 

在MDK中，默認(rèn)情況下，char 類型的數(shù)據(jù)項(xiàng)是無符號的，所以它的取值范圍是0～255。它們可以顯式地聲明為signed char 或 unsigned。因此，定義有符號char類型變量，必須用signed顯式聲明。我曾讀過一本書，其中有一句話：“signed關(guān)鍵字也是很寬宏大量，你也可以完全當(dāng)它不存在，在缺省狀態(tài)下，編譯器默認(rèn)數(shù)據(jù)位signed類型”，這句話便是有異議的，我們應(yīng)該對自己所用的CPU構(gòu)架以及編譯器熟練掌握。

2.賦初值的全局變量和靜態(tài)變量，初值被放在什么地方？

這兩行代碼中，全局變量和靜態(tài)變量在定義時(shí)被賦了初值，MDK編譯環(huán)境下，你知道這個(gè)初值保存在那里嗎？

對于在程序中賦初值的全局變量和靜態(tài)變量，程序編譯后，MDK將這些初值放到Flash中，緊靠在可執(zhí)行代碼的后面。在程序進(jìn)入main函數(shù)前，會運(yùn)行一段庫代碼，將這部分?jǐn)?shù)據(jù)拷貝至相應(yīng)RAM位置。若是你不小心將這些位置的數(shù)據(jù)擦除掉，嘿嘿...反正我是碰到了。

PS：后來看ARM的鏈接器，才知道ARM映象文件各組成部分在存儲系統(tǒng)中的地址有兩種：一種是在映象文件位于存儲器中時(shí)（也就是該映象文件開始運(yùn)行之前，通俗的說就是下載到Flash中的二進(jìn)制代碼）的地址，稱為加載地址；一種是在映象文件運(yùn)行時(shí)（通俗的說就是給板子上電，開始運(yùn)行Flash中的程序了）的地址，稱為運(yùn)行時(shí)地址。賦初值的全局變量和靜態(tài)變量在程序還沒運(yùn)行的時(shí)候，初值是被放在Flash中的，這個(gè)時(shí)候他們的地址稱為加載地址，當(dāng)程序運(yùn)行后，這些初值會從Flash中拷貝到RAM中，這時(shí)候就是運(yùn)行時(shí)地址了。

3.最新的keil MDK（V4.54）在編輯界面中已經(jīng)可以支持中文編碼了，所以可以在編輯器中直接輸入漢字和中文標(biāo)點(diǎn)符號，再也不會顯示亂碼或者不顯示了。雖然亂寫漢字和中文標(biāo)點(diǎn)在編譯時(shí)依然會報(bào)錯(cuò)，但好歹能顯示，也從側(cè)面說明中國市場的崛起。開啟方法見http://blog.csdn.net/zhzht19861011/article/details/7741928 不再貼了。

我還清楚的記得自己在大學(xué)剛開始用Keil C51那會，一次不小心在一行代碼后面用了個(gè)中文分號，在當(dāng)時(shí)這個(gè)中文分號是不被顯示的，然后編譯，編譯器報(bào)錯(cuò)，我雙擊報(bào)錯(cuò)信息定位到報(bào)錯(cuò)的代碼行，卻怎么也檢查不出來錯(cuò)誤來，當(dāng)時(shí)著急的心情現(xiàn)在想想還很好笑的，那個(gè)時(shí)候只能將錯(cuò)誤代碼行用雙斜杠注釋掉，才能看到那個(gè)中文分號。但從V4.54之后，就應(yīng)該再不會遇到我當(dāng)時(shí)的情況了。

4.不知道從什么版本開始,keil MDK的標(biāo)題欄可以顯示工程路徑了,我是從V4.10直接升級到V4.54,V4.10的標(biāo)題欄還是下圖的這個(gè)樣子:

如果你同一個(gè)工程有多個(gè)備份,你有同時(shí)打開了多個(gè)備份工程,要想識別出那個(gè)工程是那個(gè)備份,可是件不容易的事情,還好,keil更新較快.

5.這一條真?zhèn)挝粗?因?yàn)槲宜阉髁撕芫枚紱]有查證.

  在一個(gè)論壇上看到的,Keil原來是一個(gè)人名,住在德國,最初的keil C51編譯器就是他開發(fā)的.為人低調(diào),話不多,但超級認(rèn)真.當(dāng)然,也超級厲害.

6.Stack分配到RAM的哪個(gè)地方?

   keil MDK中，我們只需要定義各個(gè)模式下的堆棧大小，編譯器會自動在RAM的空閑區(qū)域選擇一塊合適的地方來分配給我們定義的堆棧，這個(gè)地方位于RAM的那個(gè)地方呢？通過查看編譯列表文件，原來MDK將堆棧放到程序使用到的RAM空間的后面，比如你的RAM空間從0x4000 0000開始，你的程序用掉了0x200字節(jié)RAM，那么堆?？臻g就從0x4000 0200處開始。具體的RAM分配，其實(shí)你可以從編譯后生成的列表文件“工程名.map”文件中查看。

7.有多少RAM會被初始化？

大家可能都已經(jīng)知道，在進(jìn)入main（）函數(shù)之前，MDK會把未初始化的RAM給清零的（在程序中自己定義變量初值的見第二條），但MDK會不會把所有RAM都初始化呢？答案是否定的，MDK只是把你的程序用到的RAM以及堆棧RAM給初始化，其它RAM的內(nèi)容是不管的。如果你要使用絕對地址訪問MDK未初始化的RAM，那就要小心翼翼的了，因?yàn)檫@些RAM的內(nèi)容很可能是隨機(jī)的，每次上電都不同。至少，NXP的LPC2000系列就是這樣。

8.還是一個(gè)新版本的變化,還是關(guān)于版本V4.10和V4.54

V4.10版本,只要你重新打開工程,點(diǎn)擊"Build target files"(就這個(gè)圖標(biāo):),編譯器就會將所有文件都編譯一次,不管你的文件在這之前有沒改動.但V4.54就不一樣了,再次打開文件,點(diǎn)擊"Build target files"它會只編譯改過的文件的.早該這么做了,每次打開工程都要編譯個(gè)十幾秒鐘,著實(shí)等的難受.

9.好個(gè)一絲不茍的編譯器

這是個(gè)十分奇葩的問題，碰巧被我遇到了，我承認(rèn)是我代碼寫的不夠規(guī)范，但正是這個(gè)不規(guī)范的代碼，才得以發(fā)現(xiàn)這個(gè)奇葩的事件。實(shí)在忍不住用了兩個(gè)奇葩來形容。把過程簡化一下，如下所述：

假如你的工程至少有兩個(gè).c文件，其中一個(gè)為timer.c，里面有個(gè)定時(shí)器中斷程序，每10ms中斷一次，定義一個(gè)變量來統(tǒng)計(jì)定時(shí)器中斷次數(shù)：

在main.c函數(shù)中，包含timer.h文件，并利用定時(shí)器變量unIdleCount來精確延時(shí)2秒，代碼如下：

看到這里，也許你已經(jīng)笑翻了：你這個(gè)小白，這很明顯是沒用volatile修飾變量unIdleCount造成的！??！不錯(cuò)，比起從RAM中讀寫數(shù)據(jù)，ARM或其它硬件從寄存器讀取數(shù)據(jù)要快的多的多的多...因此編譯器會“自作主張”的將某些變量讀到寄存器中，再次運(yùn)算時(shí)也優(yōu)先從寄存器中讀取，上面的例子就是這樣。解決這樣的方法是用關(guān)鍵字volatile修飾你不想讓編譯器優(yōu)化的變量，明白的告訴編譯器：你不準(zhǔn)優(yōu)化我，每次使用我你都要本本分分的從RAM中讀取或?qū)懭隦AM。

所以先不要笑，我是不會犯這種錯(cuò)誤的，之所以從這里說起，是為了照顧下還不知道volatile關(guān)鍵字的。。。

其實(shí)在timer.c中我是這樣定義統(tǒng)計(jì)定時(shí)器中斷次數(shù)變量的：

現(xiàn)在，應(yīng)該知道我要表達(dá)的意思了吧，如果引用的變量聲明中沒有使用volatile關(guān)鍵字修飾，即便定義這個(gè)變量的時(shí)候使用了volatile關(guān)鍵字修飾，MDK編譯器照樣優(yōu)化掉它！

將timer.h中的聲明更改為：

其實(shí)如果好好看看編譯原理的書,是不會犯這么低級的錯(cuò)誤的,編譯器是分文件編譯,然后鏈接,文件A使用了文件B中定義的變量,在編譯的時(shí)候,文件A是完全不知道文件B里面有什么東西的,只能通過文件B的接口文件(.h文件)來獲得使用變量的屬性.

以這個(gè)為例子，著重說明下關(guān)鍵字volatile，同時(shí)也要掌握編譯原理的知識,用好手中的工具.

10.關(guān)于float類型

在keil中,在不選擇"Optimize for time"編譯選項(xiàng)時(shí),局部float變量占用8個(gè)字節(jié)(編譯器默認(rèn)自動擴(kuò)展成double類型),如果你從Flash中讀取一個(gè)float類型常量并放在局部float型變量中時(shí),有可能發(fā)生意想不到的錯(cuò)誤:Cortex-M3中可能會出現(xiàn)硬fault.因?yàn)樽止?jié)對齊問題.

但有趣的是,一旦你使用"Optimize for time"編譯選項(xiàng),局部float變量只會占用4個(gè)字節(jié).

11.默認(rèn)情況下,從按下復(fù)位到執(zhí)行你編寫的C代碼main函數(shù),keil mdk做了些什么?

硬件復(fù)位后,第一步是執(zhí)行復(fù)位處理程序,這個(gè)程序的入口在啟動代碼里(默認(rèn)),摘錄一段cortex-m3的復(fù)位處理入口代碼:

其中，__main函數(shù)執(zhí)行代碼和數(shù)據(jù)復(fù)制、解壓縮以及 ZI 數(shù)據(jù)的零初始化。解釋一下，C代碼中，已經(jīng)賦值的全局變量被放在RW屬性的輸入節(jié)中，這些變量的初值被keil mdk壓縮后放到ROM或Flash中（RO屬性輸入節(jié)）。什么是賦值的全局變量呢？如果你在代碼中這樣定義一個(gè)全局變量：int nTimerCount=20；變量nTimerCount就是已經(jīng)賦值的變量，如果是這樣定義：int nTimerCount；變量nTimerCount就是一個(gè)非賦值的變量，keil默認(rèn)將它放到屬性為ZI的輸入節(jié)。為什么要壓縮呢？這是因?yàn)槿绻x值變量較多，會占用較多的Flash存儲空間，keil 默認(rèn)用自己的壓縮算法。這個(gè)“解壓縮”就是將存放在RO輸入?yún)^(qū)（一般為ROM或Flash）的變量初值，按照一定算法解壓縮后，拷貝到相應(yīng)RAM區(qū)。ZI數(shù)據(jù)清零是指將ZI區(qū)的變量所在的RAM區(qū)清零。使用 UNINIT 屬性對執(zhí)行區(qū)進(jìn)行標(biāo)記可避免 __main 對該區(qū)域中的 ZI 數(shù)據(jù)進(jìn)行零初始化。這句話很重要，比如我有一些變量，保存一些重要信息，不希望復(fù)位后就被清零，這時(shí)就可以用分散加載文件定義一塊UNINIT屬性的區(qū)，將不希望零初始化的變量定義到這個(gè)區(qū)即可。

12.關(guān)于新版本V4.70

期盼已久的功能終于在V4.7實(shí)現(xiàn)了！！IDE升級到了μVision V4.70.00 ，增加了代碼和參數(shù)自動補(bǔ)全以及動態(tài)語法檢驗(yàn),增加了兩個(gè)性能分析命令。J-LINK驅(qū)動更新到V4.62，編譯器版本更新到5.03.其中我是最喜歡的是代碼和參數(shù)自動補(bǔ)全以及動態(tài)語法檢驗(yàn)。剛回答了一個(gè)百度知道提問，提問者問到V4.70a為什么不能自動代碼和參數(shù)補(bǔ)全，這里也說一下，這并不是4.70a的問題,4.70a相對于4.70只是修正了"linking in MDK-ARM user guides"問題,使能自動補(bǔ)全的功能要設(shè)置一下:點(diǎn)擊Edit-Configuration...,在打開的對話框中選中Text Completion標(biāo)簽欄,在此頁面中選中symbols after復(fù)選框即可完全開啟(安裝后默認(rèn)并沒有選中這個(gè)框).補(bǔ)充，你的系統(tǒng)至少要有vc++2010運(yùn)行庫，才能看到這個(gè)設(shè)置。

另外V4.70自帶的動態(tài)語法校驗(yàn)我也非常喜歡,在輸入的時(shí)候就可以檢查出我輸入的變量名稱,標(biāo)點(diǎn),函數(shù)名等等對不對了.推薦升級測試一下。