1.MDK中的char類型的取值范圍是？
在MDK中，默認(rèn)情況下，char 類型的數(shù)據(jù)項是無符號的，所以它的取值范圍是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)變量，初值被放在什么地方？
unsignedintg_unRunFlag=0xA5；
staticunsignedints_unCountFlag=0x5A；
這兩行代碼中，全局變量和靜態(tài)變量在定義時被賦了初值，MDK編譯環(huán)境下，你知道這個初值保存在那里嗎？
對于在程序中賦初值的全局變量和靜態(tài)變量，程序編譯后，MDK將這些初值放到Flash中，緊靠在可執(zhí)行代碼的后面。在程序進入main函數(shù)前，會運行一段庫代碼，將這部分?jǐn)?shù)據(jù)拷貝至相應(yīng)RAM位置。若是你不小心將這些位置的數(shù)據(jù)擦除掉，嘿嘿...反正我是碰到了。
PS：后來看ARM的鏈接器，才知道ARM映象文件各組成部分在存儲系統(tǒng)中的地址有兩種：一種是在映象文件位于存儲器中時（也就是該映象文件開始運行之前，通俗的說就是下載到Flash中的二進制代碼）的地址，稱為加載地址；一種是在映象文件運行時（通俗的說就是給板子上電，開始運行Flash中的程序了）的地址，稱為運行時地址。賦初值的全局變量和靜態(tài)變量在程序還沒運行的時候，初值是被放在Flash中的，這個時候他們的地址稱為加載地址，當(dāng)程序運行后，這些初值會從Flash中拷貝到RAM中，這時候就是運行時地址了。
3.最新的keil MDK（V4.54）在編輯界面中已經(jīng)可以支持中文編碼了，所以可以在編輯器中直接輸入漢字和中文標(biāo)點符號，再也不會顯示亂碼或者不顯示了。雖然亂寫漢字和中文標(biāo)點在編譯時依然會報錯，但好歹能顯示，也從側(cè)面說明中國市場的崛起。開啟方法見http://blog.csdn.net/zhzht19861011/article/details/7741928不再貼了。
我還清楚的記得自己在大學(xué)剛開始用Keil C51那會，一次不小心在一行代碼后面用了個中文分號，在當(dāng)時這個中文分號是不被顯示的，然后編譯，編譯器報錯，我雙擊報錯信息定位到報錯的代碼行，卻怎么也檢查不出來錯誤來，當(dāng)時著急的心情現(xiàn)在想想還很好笑的，那個時候只能將錯誤代碼行用雙斜杠注釋掉，才能看到那個中文分號。但從V4.54之后，就應(yīng)該再不會遇到我當(dāng)時的情況了。
4.不知道從什么版本開始,keil MDK的標(biāo)題欄可以顯示工程路徑了,我是從V4.10直接升級到V4.54,V4.10的標(biāo)題欄還是下圖的這個樣子:
如果你同一個工程有多個備份,你有同時打開了多個備份工程,要想識別出那個工程是那個備份,可是件不容易的事情,還好,keil更新較快.
5.這一條真?zhèn)挝粗?因為我搜索了很久都沒有查證.
在一個論壇上看到的,Keil原來是一個人名,住在德國,最初的keil C51編譯器就是他開發(fā)的.為人低調(diào),話不多,但超級認(rèn)真.當(dāng)然,也超級厲害.
6.Stack分配到RAM的哪個地方?
keil MDK中，我們只需要定義各個模式下的堆棧大小，編譯器會自動在RAM的空閑區(qū)域選擇一塊合適的地方來分配給我們定義的堆棧，這個地方位于RAM的那個地方呢？通過查看編譯列表文件，原來MDK將堆棧放到程序使用到的RAM空間的后面，比如你的RAM空間從0x4000 0000開始，你的程序用掉了0x200字節(jié)RAM，那么堆棧空間就從0x4000 0200處開始。具體的RAM分配，其實你可以從編譯后生成的列表文件“工程名.map”文件中查看。
7.有多少RAM會被初始化？
大家可能都已經(jīng)知道，在進入main（）函數(shù)之前，MDK會把未初始化的RAM給清零的（在程序中自己定義變量初值的見第二條），但MDK會不會把所有RAM都初始化呢？答案是否定的，MDK只是把你的程序用到的RAM以及堆棧RAM給初始化，其它RAM的內(nèi)容是不管的。如果你要使用絕對地址訪問MDK未初始化的RAM，那就要小心翼翼的了，因為這些RAM的內(nèi)容很可能是隨機的，每次上電都不同。至少，NXP的LPC2000系列就是這樣。
8.還是一個新版本的變化,還是關(guān)于版本V4.10和V4.54
V4.10版本,只要你重新打開工程,點擊"Build target files"(就這個圖標(biāo):),編譯器就會將所有文件都編譯一次,不管你的文件在這之前有沒改動.但V4.54就不一樣了,再次打開文件,點擊"Build target files"它會只編譯改過的文件的.早該這么做了,每次打開工程都要編譯個十幾秒鐘,著實等的難受.
9.好個一絲不茍的編譯器
這是個十分奇葩的問題，碰巧被我遇到了，我承認(rèn)是我代碼寫的不夠規(guī)范，但正是這個不規(guī)范的代碼，才得以發(fā)現(xiàn)這個奇葩的事件。實在忍不住用了兩個奇葩來形容。把過程簡化一下，如下所述：
假如你的工程至少有兩個.c文件，其中一個為timer.c，里面有個定時器中斷程序，每10ms中斷一次，定義一個變量來統(tǒng)計定時器中斷次數(shù)：
unsignedintunIdleCount；
還有一個timer.h文件，里面是一些timer.c模塊的封裝，其中變量unIdleCount就被封裝在里面：
externunsignedintunIdleCount；
在main.c函數(shù)中，包含timer.h文件，并利用定時器變量unIdleCount來精確延時2秒，代碼如下：
unIdleCount=0;
while(unIdleCount!=200);//延時2S鐘
keil MDK V5.54下編譯，默認(rèn)優(yōu)化級別，編譯后下載到硬件平臺。你會發(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);//延時2S鐘
125:
0x00002E20E35000C8CMPR0,#0x000000C8
0x00002E241AFFFFFDBNE0x00002E20
重點看最后兩句匯編代碼，寄存器R0是當(dāng)前變量unIdleCount的值，匯編指令CMP為比較指令，如果R0中的內(nèi)容與0xC8不等，則循環(huán)。但是這里并沒有更新寄存器R0的代碼，也就是說變量unIdleCount的值雖然在變化，但跟0xC8一直比較的卻是內(nèi)容不變的R0。因為之前變量unIdleCount被清零，所以R0的內(nèi)容也是0，永遠(yuǎn)不等于0xC8，永遠(yuǎn)不會跳出循環(huán)。
看到這里，也許你已經(jīng)笑翻了：你這個小白，這很明顯是沒用volatile修飾變量unIdleCount造成的?。。〔诲e，比起從RAM中讀寫數(shù)據(jù)，ARM或其它硬件從寄存器讀取數(shù)據(jù)要快的多的多的多...因此編譯器會“自作主張”的將某些變量讀到寄存器中，再次運算時也優(yōu)先從寄存器中讀取，上面的例子就是這樣。解決這樣的方法是用關(guān)鍵字volatile修飾你不想讓編譯器優(yōu)化的變量，明白的告訴編譯器：你不準(zhǔn)優(yōu)化我，每次使用我你都要本本分分的從RAM中讀取或?qū)懭隦AM。
所以先不要笑，我是不會犯這種錯誤的，之所以從這里說起，是為了照顧下還不知道volatile關(guān)鍵字的。。。
其實在timer.c中我是這樣定義統(tǒng)計定時器中斷次數(shù)變量的：
unsignedintvolatileunIdleCount；
但是，在timer.h中，我確偷了個懶，聲明這個變量的代碼如下：
externunsignedintunIdleCount；
沒有使用關(guān)鍵字volatile，在keil MDK V5.54下編譯，默認(rèn)優(yōu)化級別，然后查看代碼的反匯編，如下所示：
122:unIdleCount=0;
123:
0x00002E10E59F11D4LDRR1,[PC,#0x01D4]
0x00002E14E3A05000MOVR5,#key1(0x00000000)
0x00002E18E1A00005MOVR0,R5
0x00002E1CE5815000STRR5,[R1]
124:while(unIdleCount!=200);//延時2S鐘
125:
0x00002E20E35000C8CMPR0,#0x000000C8
0x00002E241AFFFFFDBNE0x00002E20
可以看出，這個反匯編代碼居然和沒加volatile關(guān)鍵字的時候一模一樣??！代碼還是會
下載文檔
