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

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

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

unsignedintg_unRunFlag=0xA5；

staticunsignedints_unCountFlag=0x5A；

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

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

PS：后來看ARM的鏈接器，才知道ARM映象文件各組成部分在存儲(chǔ)系統(tǒng)中的地址有兩種：一種是在映象文件位于存儲(chǔ)器中時(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)行后，這些初值會(huì)從Flash中拷貝到RAM中，這時(shí)候就是運(yùn)行時(shí)地址了。

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

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

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

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

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

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

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

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

7.有多少RAM會(huì)被初始化？

大家可能都已經(jīng)知道，在進(jìn)入main（）函數(shù)之前，MDK會(huì)把未初始化的RAM給清零的（在程序中自己定義變量初值的見第二條），但MDK會(huì)不會(huì)把所有RAM都初始化呢？答案是否定的，MDK只是把你的程序用到的RAM以及堆棧RAM給初始化，其它RAM的內(nèi)容是不管的。如果你要使用絕對(duì)地址訪問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):),編譯器就會(huì)將所有文件都編譯一次,不管你的文件在這之前有沒改動(dòng).但V4.54就不一樣了,再次打開文件,點(diǎn)擊"Build target files"它會(huì)只編譯改過的文件的.早該這么做了,每次打開工程都要編譯個(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ù)：

unsignedintunIdleCount；

還有一個(gè)timer.h文件，里面是一些timer.c模塊的封裝，其中變量unIdleCount就被封裝在里面：

externunsignedintunIdleCount；

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

unIdleCount=0;

while(unIdleCount!=200);//延時(shí)2S鐘

keil MDK V5.54下編譯，默認(rèn)優(yōu)化級(jí)別，編譯后下載到硬件平臺(tái)。你會(huì)發(fā)現(xiàn)，代碼在

while(unIdleCount!=200);

處陷入了死循環(huán)。反匯編，代碼如下：

122:unIdleCount=0;

123:

0x00002E10E59F11D4LDRR1,[PC,#0x01D4]

0x00002E14E3A05000MOVR5,#key1(0x00000000)

0x00002E18E1A00005MOVR0,R5

0x00002E1CE5815000STRR5,[R1]

124:while(unIdleCount!=200);//延時(shí)2S鐘

125:

0x00002E20E35000C8CMPR0,#0x000000C8

0x00002E241AFFFFFDBNE0x00002E20

重點(diǎn)看最后兩句匯編代碼，寄存器R0是當(dāng)前變量unIdleCount的值，匯編指令CMP為比較指令，如果R0中的內(nèi)容與0xC8不等，則循環(huán)。但是這里并沒有更新寄存器R0的代碼，也就是說變量unIdleCount的值雖然在變化，但跟0xC8一直比較的卻是內(nèi)容不變的R0。因?yàn)橹白兞縰nIdleCount被清零，所以R0的內(nèi)容也是0，永遠(yuǎn)不等于0xC8，永遠(yuǎn)不會(huì)跳出循環(huán)。

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

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

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

unsignedintvolatileunIdleCount；

但是，在timer.h中，我確偷了個(gè)懶，聲明這個(gè)變量的代碼如下：

externunsignedintunIdleCount；

沒有使用關(guān)鍵字volatile，在keil MDK V5.54下編譯，默認(rèn)優(yōu)化級(jí)別，然后查看代碼的反匯編，如下所示：

122:unIdleCount=0;

123:

0x00002E10E59F11D4LDRR1,[PC,#0x01D4]

0x00002E14E3A05000MOVR5,#key1(0x00000000)

0x00002E18E1A00005MOVR0,R5

0x00002E1CE5815000STRR5,[R1]

124:while(unIdleCount!=200);//延時(shí)2S鐘

125:

0x00002E20E35000C8CMPR0,#0x000000C8

0x00002E241AFFFFFDBNE0x00002E20

可以看出，這個(gè)反匯編代碼居然和沒加volatile關(guān)鍵字的時(shí)候一模一樣??！代碼還是會(huì)