在剛剛涉足嵌入式開(kāi)發(fā)的時(shí)候，總想找到這樣一本書(shū)，它可以解決我一些這樣那樣的疑惑。但是遺憾的是，到現(xiàn)在也沒(méi)有這樣一本書(shū)面世，而且我想永遠(yuǎn)也不可能面世了。因?yàn)槲业囊苫筇嗵s了。

這些疑惑在教科書(shū)中又難以尋找到答案。C 教程注重講C的語(yǔ)法，編譯原理注重講語(yǔ)法，語(yǔ)義的分析。每一門(mén)教科書(shū)都是有它的注重，所以那些交叉的問(wèn)題便成了三不管。市場(chǎng)上的那些自稱為《XX 寶典》、《XX 圣經(jīng)》的書(shū)卻總是說(shuō)一些可能連作者自己也沒(méi)搞清楚的問(wèn)題。于是我想，我想了解的也許是大家都想了解的吧，那么把我學(xué)到的一點(diǎn)東西寫(xiě)出來(lái)，大家也許就可以少花點(diǎn)時(shí)間在上面，留出寶貴的腦力資源去做更有意義的事。

語(yǔ)言選擇，C 還是其他

剛剛涉及嵌入式開(kāi)發(fā)者總是先閱讀一些指導(dǎo)類型文章，然后就開(kāi)始對(duì)開(kāi)發(fā)語(yǔ)言的選擇躊躇不決。是C還是C++?還是好像更熱門(mén)的JAVA?不用猶豫，至少目前看來(lái)C還是你的選擇。嵌入式開(kāi)發(fā)的本質(zhì)是訂制開(kāi)發(fā)，硬件平臺(tái)林林總總，處理能力高下不同，如果想保護(hù)你學(xué)習(xí)精力投資的話，C是最好的“優(yōu)績(jī)股”。C++的優(yōu)點(diǎn)在于它的代碼重用，但是效率比C低很多，最重要的是，并非所有芯片的編譯器都能支持C++。JAVA就更不用提及，在一個(gè)虛擬平臺(tái)上開(kāi)發(fā)的優(yōu)點(diǎn)是不用關(guān)心具體的硬件細(xì)節(jié)，但這不是一個(gè)嵌入式開(kāi)發(fā)者的作風(fēng)，換一種說(shuō)法，這種開(kāi)發(fā)不能稱之為嵌入式開(kāi)發(fā)。

C被稱為高級(jí)語(yǔ)言中的低級(jí)語(yǔ)言，低級(jí)語(yǔ)言中的高級(jí)語(yǔ)言，這是因?yàn)槠湟环矫嬗懈呒?jí)語(yǔ)言所具有的接近于人類思想的語(yǔ)言體系，另一方面同時(shí)支持地址與位操作?？梢苑奖愕呐c硬件打交道。嵌入式開(kāi)發(fā)必然要操作IO、硬件地址，沒(méi)有位操作和指針你又如何方便做到?

嵌入式開(kāi)發(fā)一般流程

嵌入式開(kāi)發(fā)的流程與高層開(kāi)發(fā)大體類似，編碼——編譯、鏈接——運(yùn)行。中間當(dāng)然可以有聯(lián)機(jī)調(diào)試，重新編碼等遞歸過(guò)程。但有一些不同之處。

首先，開(kāi)發(fā)平臺(tái)不同。受嵌入式平臺(tái)處理能力所限，嵌入式開(kāi)發(fā)一般都采用交叉編譯環(huán)境開(kāi)發(fā)。所謂交叉編譯就是在A平臺(tái)上編譯B平臺(tái)上運(yùn)行的目標(biāo)程序。在A平臺(tái)上運(yùn)行的B平臺(tái)程序編譯器就被稱為交叉編譯器。一個(gè)初入門(mén)者，建立一套這樣的編譯環(huán)境也許就要花掉幾天的時(shí)間。

其次，調(diào)試方式不同。我們?cè)赪indows或者Linux上開(kāi)發(fā)的程序可以馬上運(yùn)行察看運(yùn)行結(jié)果，也可以利用IDE來(lái)調(diào)試運(yùn)行過(guò)程，但是嵌入式開(kāi)發(fā)者卻至少需要作一系列工作才能達(dá)到這種地步。

目前最流行的是采用JTAG方式連接到目標(biāo)系統(tǒng)上，將編譯成功的代碼下載運(yùn)行，高級(jí)的調(diào)試器幾乎可以像VC環(huán)境一樣任意的調(diào)試程序。再者，開(kāi)發(fā)者所了解層次結(jié)構(gòu)不同。高層軟件開(kāi)發(fā)者把工作的重點(diǎn)放在對(duì)應(yīng)用需求的理解和實(shí)現(xiàn)上。

嵌入式開(kāi)發(fā)者對(duì)整個(gè)過(guò)程細(xì)節(jié)必須比高層開(kāi)發(fā)者有更深的認(rèn)識(shí)。最大不同之處在于有操作系統(tǒng)支持的程序不需要你關(guān)心程序的運(yùn)行地址以及程序鏈接后各個(gè)程序塊最后的位置。像Windows，Linux這類需要MMU支持的操作系統(tǒng)，其程序都是放置在虛擬地址空間的一個(gè)固定的內(nèi)存地址。不管程序在真正RAM空間的地址位置在哪里，最后都由MMU映射到虛擬地址空間的一個(gè)固定的地址。

為什么程序的運(yùn)行與存放的地址要相關(guān)呢?學(xué)過(guò)匯編原理，或者看過(guò)最后編譯成機(jī)器碼程序的人就知道，程序中的變量、函數(shù)最后都在機(jī)器碼中體現(xiàn)為地址，程序的跳轉(zhuǎn)，子程序的調(diào)用，以及變量調(diào)用最后都是CPU通過(guò)直接提取其地址來(lái)實(shí)現(xiàn)的。嵌入式學(xué)習(xí)企鵝意義氣嗚嗚吧久零就易。編譯時(shí)指定的TEXT_BASE就是所有一切地址的參考值。如果你指定的地址與最后程序放置的地址不一致顯然不能正常運(yùn)行。

但也有例外，不過(guò)不尋常的用法當(dāng)然要付出不尋常的努力。有兩種方法可以解決這個(gè)問(wèn)題。

一種方法是在程序的最起始編寫(xiě)與地址無(wú)關(guān)的代碼，最后將后面的程序自搬移到你真正指定的TEXT_BASE然后跳轉(zhuǎn)到你將要運(yùn)行的代碼處。

另一種方法是，TEXT_BASE指定為你程序的存放地址，然后將程序搬移到真正運(yùn)行的地址，有一個(gè)變量將后者的地址記錄下來(lái)作為參考值，在以后的符號(hào)表地址都以此值作為參考與偏移值合成為其真正的地址。

聽(tīng)起來(lái)很拗口，實(shí)現(xiàn)起來(lái)也很難，在后面的內(nèi)容中有更好的解決辦法——用一個(gè)BootLoader支持。另外，一個(gè)完整的程序必然至少有三個(gè)段TEXT (正文，也就是最后用程序編譯后的機(jī)器指令)段、BSS(未初始變量)段DATA(初始化變量)段。前面講到的TEXT_BASE只是TEXT段的基址，對(duì)于另外的BSS段和DATA段，如果最后的整個(gè)程序放在RAM中，那么三個(gè)段可以連續(xù)放置，但是，如果程序是放置在ROM或者FLASH這種只讀存儲(chǔ)器中，那么你還需要指定你的其他段的地址，因?yàn)榇a在運(yùn)行中是不改變的，而后兩者卻不同。這些工作都是在鏈接的時(shí)候完成，編譯器必然為你提供了一些手段讓你完成這些工作。

還是那句話，有操作系統(tǒng)支持的編程屏蔽了這些細(xì)節(jié)，讓你完全不用考慮這些頭痛的問(wèn)題。但是嵌入式開(kāi)發(fā)者沒(méi)有那么幸運(yùn)，他們總是在一個(gè)冷冰冰的芯片上從頭做起。CPU上電復(fù)位總是從一個(gè)固定的地址去找程序，開(kāi)始其繁忙的工作。對(duì)于我們的PC來(lái)說(shuō)這個(gè)地址就是我們的BIOS程序，對(duì)于嵌入式系統(tǒng)，一般沒(méi)有BIOS支持，RAM不能在掉電情況下保留你的程序，所以必須將程序存放在ROM或FLASH中，但是一般來(lái)講，這些存儲(chǔ)器的寬度和速度都無(wú)法與RAM相提并論。

程序在這些存儲(chǔ)器上運(yùn)行會(huì)降低運(yùn)行速率。大多數(shù)的方案是在此處存放一個(gè)BootLoader，BootLoader所完成的功能可多可少，一個(gè)基本的BootLoader只完成一些系統(tǒng)初始化并將用戶程序搬移到一定地址，然后跳轉(zhuǎn)到用戶程序即交出CPU控制權(quán)，功能強(qiáng)大的BootLoad還可以支持網(wǎng)絡(luò)、串口下載，甚至調(diào)試功能。但不要指望有一個(gè)像PC BIOS那樣通用的BootLoader供你使用，至少你需要作一些移植工作使其符合你的系統(tǒng)，這個(gè)移植工作也是你開(kāi)發(fā)的一個(gè)部分，作為嵌入式開(kāi)發(fā)個(gè)入門(mén)者來(lái)講，移植或者編寫(xiě)一個(gè)BootLoader會(huì)使你受益匪淺。

沒(méi)有BootLoader行不行?當(dāng)然可以，要么你就犧牲效率直接從ROM中運(yùn)行，要么你就自己編寫(xiě)程序搬移代碼去RAM運(yùn)行，最主要的是，開(kāi)發(fā)過(guò)程中你要有好的調(diào)試工具支持在線調(diào)試，否則你就得在改動(dòng)哪怕一個(gè)變量的情況下都要去重新燒片驗(yàn)證。繼續(xù)程序入口的話題，不管過(guò)程如何，程序最后在執(zhí)行時(shí)都是變成了機(jī)器指令，一個(gè)純的執(zhí)行程序就是這些機(jī)器指令的集合。像我們?cè)诓僮飨到y(tǒng)上的可運(yùn)行程序都不是純的執(zhí)行程序，而是帶有格式的。一般除了包含上面提到的幾個(gè)段以外，還有程序的長(zhǎng)度，校驗(yàn)以及程序入口——就是從哪兒開(kāi)始執(zhí)行用戶程序。

為什么有了程序地址還需要有程序的入口呢?這是因?yàn)槟阋嬲_(kāi)始執(zhí)行的代碼并非一定放置在一個(gè)文件的最開(kāi)始，就算放在最開(kāi)始，除非你去控制鏈接，否則在多文件的情況下，編譯器也不一定將你的這段程序放置在最后程序的最頂端。像我們一般有操作系統(tǒng)支持的程序，只需在你的代碼中有一個(gè)main作為程序入口——注意這個(gè)main只是大多數(shù)編譯器約成定俗的入口，除非你利用了別人的初始化庫(kù)，否則程序入口可以自行設(shè)定——即可。顯然，帶有格式的這種執(zhí)行文件使用更加靈活，但需要BootLoader的支持。有關(guān)執(zhí)行文件格式的內(nèi)容可以看看ELF文件格式。

編譯預(yù)處理

首先看看文件包含，從我們的第一個(gè)C程序Hello World!開(kāi)始，我們就使用頭文件包含，但是另人驚奇的是，很多人在做了很長(zhǎng)時(shí)間的開(kāi)發(fā)以后仍然對(duì)文件的包含沒(méi)有正確的認(rèn)識(shí)或者是概念不清，有更多的人卻把頭文件和與之相關(guān)聯(lián)的庫(kù)混淆。

為了照顧這些初學(xué)者，這里羅嗦一下，其實(shí)文件包含的本質(zhì)就是把一個(gè)大的文件截成幾個(gè)小文件便于管理和閱讀，如果你包含了那個(gè)文件，那么你把這個(gè)文件的所有內(nèi)容原封不動(dòng)的復(fù)制到你包含其的文件中，效果是完全一樣的，另一方面，如果你編譯了一些中間代碼，如庫(kù)文件，可以通過(guò)提供頭文件來(lái)告知調(diào)用者你的庫(kù)包含的函數(shù)和調(diào)用格式，但是真正的代碼已經(jīng)變成了目標(biāo)代碼以庫(kù)文件形式存在了。至于包含文件的后綴如.h只是告訴使用者，這是一個(gè)頭文件，你用任何別的名字，編譯器都一般不會(huì)在意。

那些對(duì)頭文件和庫(kù)還混淆的朋友應(yīng)該恍然大悟了吧，其實(shí)頭文件只能保證你的程序編譯不出現(xiàn)語(yǔ)法錯(cuò)誤，但是直到最后鏈接的時(shí)候才會(huì)真正使用到庫(kù)，那些只把一個(gè)頭文件拷貝來(lái)就想擁有一個(gè)庫(kù)的人再也不要犯這樣的錯(cuò)誤了。如果你的工程中源程序數(shù)目繁多令你覺(jué)得管理困難，把他們?nèi)堪谝粋€(gè)文件中也未嘗不可。

另一個(gè)初學(xué)者常常遇到的問(wèn)題就是由于重復(fù)包含引起的困惑。如果一個(gè)文件中包含了另一個(gè)文件兩次或兩次以上很可能引起重復(fù)定義的問(wèn)題，但是沒(méi)有人蠢到會(huì)重復(fù)包含兩次同一個(gè)文件的，這種問(wèn)題都是隱式的重復(fù)包含，比如A文件中包含了B文件和C文件，B文件中又包含了C文件，這樣，A文件實(shí)際上已經(jīng)包含了C文件兩次。不過(guò)一個(gè)好的頭文件巧妙的利用編譯預(yù)處理避免了這種情況。在頭文件中你可能發(fā)現(xiàn)這樣的一些預(yù)處理：

#ifndef __TEST_H__

#define __TEST_H__

… …

#endif /* __TEST_H__ */

這三行編譯預(yù)處理前兩行一般位于文件最頂端，最后文件位于文件最末端，它的意思是，如果沒(méi)有定義__TEST_H__那么就定義__TEST_H__同時(shí)下面的代碼一直到#endif前參與編譯，反之不參與編譯。多么巧妙的設(shè)計(jì)，有了這三行簡(jiǎn)潔的預(yù)處理，這個(gè)文件即使被包含幾萬(wàn)次也只能算一次。

我們?cè)賮?lái)看看宏的使用。初學(xué)者在看別人代碼的時(shí)候總是想，為什么用那么多宏呢?看得人一頭霧水，的確，有時(shí)候宏的使用會(huì)降低代碼的可讀性。但有時(shí)宏也可以提高代碼的可讀性，看看下邊這兩段代碼：

1)

#define SCC_GSMRH_RSYN 0x00000001 /* receive sync timing */

#define SCC_GSMRH_RTSM 0x00000002 /* RTS* mode */

#define SCC_GSMRH_SYNL 0x0000000c /* sync length */

#define SCC_GSMRH_TXSY 0x00000010 /* transmitter/receiver sync*/

#define SCC_GSMRH_RFW 0x00000020 /* Rx FIFO width */

#define SCC_GSMRH_TFL 0x00000040 /* transmit FIFO length */

#define SCC_GSMRH_CTSS 0x00000080 /* CTS* sampling */

#define SCC_GSMRH_CDS 0x00000100 /* CD* sampling */

#define SCC_GSMRH_CTSP 0x00000200 /* CTS* pulse */

#define SCC_GSMRH_CDP 0x00000400 /* CD* pulse */

#define SCC_GSMRH_TTX 0x00000800 /* transparent transmitter */

#define SCC_GSMRH_TRX 0x00001000 /* transparent receiver */

#define SCC_GSMRH_REVD 0x00002000 /* reverse data */

#define SCC_GSMRH_TCRC 0x0000c000 /* transparent CRC */

#define SCC_GSMRH_GDE 0x00010000 /* glitch detect enable */

*(int *)0xff000a04 = SCC_GSMRH_REVD | SCC_GSMRH_TRX | SCC_GSMRH_TTX |

SCC_GSMRH_CDP | SCC_GSMRH_CTSP | SCC_GSMRH_CDS | SCC_GSMRH_CTSS;

2)

*(int *)0xff000a04 = 0x00003f80;

這是對(duì)某一個(gè)寄存器的賦值程序，兩者完成的是完全相同的工作。第一段代碼略顯冗長(zhǎng)，第二段代碼很簡(jiǎn)潔，但是如果你如果想改動(dòng)此寄存器的設(shè)置的時(shí)候顯然更喜歡看到的是第一段代碼，因?yàn)樗F(xiàn)有的值已經(jīng)很清楚，要對(duì)那些位賦值只要用相應(yīng)得宏定義即可，不必每次改變都拿筆再重新計(jì)算一次。這一點(diǎn)對(duì)于嵌入式開(kāi)發(fā)者很重要，有時(shí)我們調(diào)試一個(gè)設(shè)備的時(shí)候，一個(gè)關(guān)鍵寄存器的值也許會(huì)被我們修改很多次，每一次都計(jì)算每一位所對(duì)應(yīng)得值是一件很頭疼的事。

另外利用宏也可以提高代碼的運(yùn)行效率，子程序的調(diào)用需要壓棧出棧，這一過(guò)程如果過(guò)于頻繁會(huì)耗費(fèi)掉大量的CPU運(yùn)算資源。所以一些代碼量小但運(yùn)行頻繁的代碼如果采用帶參數(shù)宏來(lái)實(shí)現(xiàn)會(huì)提高代碼的運(yùn)行效率，比如我們常常用到的對(duì)外部IO賦值的操作，你可以寫(xiě)一個(gè)類似下邊的函數(shù)來(lái)實(shí)現(xiàn)：

void outb(unsigned char val, unsigned int *addr)

{

*addr = val;

}

僅僅是一句語(yǔ)句的函數(shù)，卻要調(diào)用一個(gè)函數(shù)，如果不用函數(shù)呢，重復(fù)寫(xiě)上面的語(yǔ)句又顯得羅嗦。不如用下面的宏實(shí)現(xiàn)。

#define outb(b, addr) (*(volatile unsigned char *)(addr) = (b))

由于不需要調(diào)用子函數(shù)，宏提高了運(yùn)行效率，但是浪費(fèi)了程序空間，這是由于凡是用到此宏的地方，都要替換為一句其代替的語(yǔ)句。開(kāi)發(fā)者需要根據(jù)系統(tǒng)需求取舍時(shí)間與空間。