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)變量，初值被放在什么地方？ unsigned int g_unRunFlag=0xA5； static unsigned int s_unCountFlag=0x5A； 這兩行代碼中，全局變量和靜態(tài)變量在定義時被賦了初值，MDK編譯環(huán)境下，你知道這個初值保存在那里嗎？ 對于在程序中賦初值的全局變量和靜態(tài)變量，程序編譯后，MDK將這些初值放到Flash中，緊靠在可執(zhí)行代碼的后面。在程序進(jìn)入main函數(shù)前，會運行一段庫代碼，將這部分?jǐn)?shù)據(jù)拷貝至相應(yīng)RAM位置。若是你不小心將這些位置的數(shù)據(jù)擦除掉，嘿嘿...反正我是碰到了。 PS：后來看ARM的鏈接器，才知道ARM映象文件各組成部分在存儲系統(tǒng)中的地址有兩種：一種是在映象文件位于存儲器中時（也就是該映象文件開始運行之前，通俗的說就是下載到Flash中的二進(jìn)制代碼）的地址，稱為加載地址；一種是在映象文件運行時（通俗的說就是給板子上電，開始運行Flash中的程序了）的地址，稱為運行時地址。賦初值的全局變量和靜態(tài)變量在程序還沒運行的時候，初值是被放在Flash中的，這個時候他們的地址稱為加載地址，當(dāng)程序運行后，這些初值會從Flash中拷貝到RAM中，這時候就是運行時地址了。 3、最新的keil MDK（V4.54）在編輯界面中已經(jīng)可以支持中文編碼了，所以可以在編輯器中直接輸入漢字和中文標(biāo)點符號，再也不會顯示亂碼或者不顯示了。雖然亂寫漢字和中文標(biāo)點在編譯時依然會報錯，但好歹能顯示，也從側(cè)面說明中國市場的崛起。開啟方法見 不再貼了。 我還清楚的記得自己在大學(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)知道，在進(jìn)入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ù)： unsigned int unIdleCount； 還有一個timer.h文件，里面是一些timer.c模塊的封裝，其中變量unIdleCount就被封裝在里面： extern unsigned int unIdleCount； 在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: 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是當(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造成的?。?！不錯，比起從RAM中讀寫數(shù)據(jù)，ARM或其它硬件從寄存器讀取數(shù)據(jù)要快的多的多的多...因此編譯器會???自作主張”的將某些變量讀到寄存器中，再次運算時也優(yōu)先從寄存器中讀取，上面的例子就是這樣。解決這樣的方法是用關(guān)鍵字volatile修飾你不想讓編譯器優(yōu)化的變量，明白的告訴編譯器：你不準(zhǔn)優(yōu)化我，每次使用我你都要本本分分的從RAM中讀取或?qū)懭隦AM。