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