語言選擇，C語言還是其他
剛剛涉及嵌入式開發(fā)者總是先閱讀一些指導類型文章，然后就開始對開發(fā)語言的選擇躊躇不決。是C 還是C++?還是好像更熱門的JAVA?不用猶豫，至少目前看來C 還是你的選擇。嵌入式開發(fā)的本質是訂制開發(fā)，硬件平臺林林總總，處理能力高下不同，如果想保護你學習精力投資的話，C 是的“優(yōu)績股”。C++的優(yōu)點在于它的代碼重用，但是效率比C低很多，重要的是，并非所有芯片的編譯器都能支持C++。JAVA 就更不用提及，在一個虛擬平臺上開發(fā)的優(yōu)點是不用關心具體的硬件細節(jié)，但這不是一個嵌入式開發(fā)者的作風，換一種說法，這種開發(fā)不能稱之為嵌入式開發(fā)。
C被稱為語言中的低級語言，低級語言中的語言，這是因為其一方面有語言所具有的接近于人類思想的語言體系，另一方面同時支持地址與位操作。可以方便的與硬件打交道。嵌入式開發(fā)必然要操作IO、硬件地址，沒有位操作和指針你又如何方便做到?
嵌入式開發(fā)一般流程
嵌入式開發(fā)的流程與高層開發(fā)大體類似，編碼——編譯、鏈接——運行。中間當然可以有聯(lián)機調試，重新編碼等遞歸過程。但有一些不同之處。首先，開發(fā)平臺不同。受嵌入式平臺處理能力所限，嵌入式開發(fā)一般都采用交叉編譯環(huán)境開發(fā)。所謂交叉編譯就是在A 平臺上編譯B 平臺上運行的目標程序。在A 平臺上運行的B 平臺程序編譯器就被稱為交叉編譯器。一個初入門者，建立一套這樣的編譯環(huán)境也許就要花掉幾天的時間。
其次，調試方式不同。我們在Windows 或者Linux 上開發(fā)的程序可以馬上運行察看運行結果，也可以利用IDE 來調試運行過程，但是嵌入式開發(fā)者卻至少需要作一系列工作才能達到這種地步。目前的是采用JTAG 方式連接到目標系統(tǒng)上，將編譯成功的代碼下載運行，的調試器幾乎可以像VC 環(huán)境一樣任意的調試程序。再者，開發(fā)者所了解層次結構不同。高層軟件開發(fā)者把工作的重點放在對應用需求的理解和實現(xiàn)上。
嵌入式開發(fā)者對整個過程細節(jié)必須比高層開發(fā)者有更深的認識。不同之處在于有操作系統(tǒng)支持的程序不需要你關心程序的運行地址以及程序鏈接后各個程序塊的位置。像Windows，Linux 這類需要MMU 支持的操作系統(tǒng)，其程序都是放置在虛擬地址空間的一個固定的內存地址。不管程序在真正RAM空間的地址位置在哪里，都由MMU映射到虛擬地址空間的一個固定的地址。為什么程序的運行與存放的地址要相關呢?學過匯編原理，或者看過編譯成機器碼程序的人就知道，程序中的變量、函數(shù)都在機器碼中體現(xiàn)為地址，程序的跳轉，子程序的調用，以及變量調用都是CPU通過直接提取其地址來實現(xiàn)的。編譯時指定的TEXT_BASE 就是所有一切地址的參考值。如果你指定的地址與程序放置的地址不一致顯然不能正常運行。
但也有例外，不過不尋常的用法當然要付出不尋常的努力。有兩種方法可以解決這個問題。一種方法是在程序的起始編寫與地址無關的代碼，將后面的程序自搬移到你真正指定的TEXT_BASE 然后跳轉到你將要運行的代碼處。另一種方法是，TEXT_BASE 指定為你程序的存放地址，然后將程序搬移到真正運行的地址，有一個變量將后者的地址記錄下來作為參考值，在以后的符號表地址都以此值作為參考與偏移值合成為其真正的地址。
聽起來很拗口，實現(xiàn)起來也很難，在后面的內容中有更好的解決辦法——用一個BootLoader 支持。另外，一個完整的程序必然至少有三個段TEXT (正文，也就是用程序編譯后的機器指令)段、BSS(未初始變量)段DATA(初始化變量)段。前面講到的TEXT_BASE 只是TEXT 段的基址，對于另外的BSS 段和DATA 段，如果的整個程序放在RAM 中，那么三個段可以連續(xù)放置，但是，如果程序是放置在ROM 或者FLASH 這種只讀存儲器中，那么你還需要指定你的其他段的地址，因為代碼在運行中是不改變的，而后兩者卻不同。這些工作都是在鏈接的時候完成，編譯器必然為你提供了一些手段讓你完成這些工作。
還是那句話，有操作系統(tǒng)支持的編程屏蔽了這些細節(jié)，讓你完全不用考慮這些頭痛的問題。但是嵌入式開發(fā)者沒有那么幸運，他們總是在一個冷冰冰的芯片上從頭做起。CPU 上電復位總是從一個固定的地址去找程序，開始其繁忙的工作。對于我們的PC來說這個地址就是我們的BIOS程序，對于嵌入式系統(tǒng)，一般沒有BIOS支持，RAM不能在掉電情況下保留你的程序，所以必須將程序存放在ROM或FLASH中，但是一般來講，這些存儲器的寬度和速度都無法與RAM 相提并論。
程序在這些存儲器上運行會降低運行速率。大多數(shù)的方案是在此處存放一個BootLoader，BootLoader 所完成的功能可多可少，一個基本的BootLoader 只完成一些系統(tǒng)初始化并將用戶程序搬移到一定地址，然后跳轉到用戶程序即交出CPU 控制權，功能強大的BootLoad 還可以支持網(wǎng)絡、串口下載，甚至調試功能。但不要指望有一個像PC BIOS 那樣通用的BootLoader 供你使用，至少你需要作一些移植工作使其符合你的系統(tǒng)，這個移植工作也是你開發(fā)的一個部分，作為嵌入式開發(fā)個入門者來講，移植或者編寫一個BootLoader 會使你受益匪淺。
沒有BootLoader 行不行?當然可以，要么你就犧牲效率直接從ROM 中運行，要么你就自己編寫程序搬移代碼去RAM運行，主要的是，開發(fā)過程中你要有好的調試工具支持在線調試，否則你就得在改動哪怕一個變量的情況下都要去重新燒片驗證。繼續(xù)程序入口的話題，不管過程如何，程序在執(zhí)行時都是變成了機器指令，一個純的執(zhí)行程序就是這些機器指令的集合。像我們在操作系統(tǒng)上的可運行程序都不是純的執(zhí)行程序，而是帶有格式的。一般除了包含上面提到的幾個段以外，還有程序的長度，校驗以及程序入口——就是從哪兒開始執(zhí)行用戶程序。
為什么有了程序地址還需要有程序的入口呢?這是因為你要真正開始執(zhí)行的代碼并非一定放置在一個文件的開始，就算放在開始，除非你去控制鏈接，否則在多文件的情況下，編譯器也不一定將你的這段程序放置在程序的頂端。像我們一般有操作系統(tǒng)支持的程序，只需在你的代碼中有一個main 作為程序入口——注意這個main 只是大多數(shù)編譯器約成定俗的入口，除非你利用了別人的初始化庫，否則程序入口可以自行設定——即可。顯然，帶有格式的這種執(zhí)行文件使用更加靈活，但需要BootLoader 的支持。有關執(zhí)行文件格式的內容可以看看ELF 文件格式。
編譯預處理
首先看看文件包含，從我們的個C 程序Hello World! 開始，我們就使用頭文件包含，但是另人驚奇的是，很多人在做了很長時間的開發(fā)以后仍然對文件的包含沒有正確的認識或者是概念不清，有更多的人卻把頭文件和與之相關聯(lián)的庫混淆。為了照顧這些初學者，這里羅嗦一下，其實文件包含的本質就是把一個大的文件截成幾個小文件便于管理和閱讀，如果你包含了那個文件，那么你把這個文件的所有內容原封不動的復制到你包含其的文件中，效果是完全一樣的，另一方面，如果你編譯了一些中間代碼，如庫文件，可以通過提供頭文件來告知調用者你的庫包含的函數(shù)和調用格式，但是真正的代碼已經(jīng)變成了目標代碼以庫文件形式存在了。至于包含文件的后綴如.h 只是告訴使用者，這是一個頭文件，你用任何別的名字，編譯器都一般不會在意。
那些對頭文件和庫還混淆的朋友應該恍然大悟了吧，其實頭文件只能保證你的程序編譯不出現(xiàn)語法錯誤，但是直到鏈接的時候才會真正使用到庫，那些只把一個頭文件拷貝來就想擁有一個庫的人再也不要犯這樣的錯誤了。如果你的工程中源程序數(shù)目繁多令你覺得管理困難，把他們全部包含在一個文件中也未嘗不可。
另一個初學者常常遇到的問題就是由于重復包含引起的困惑。如果一個文件中包含了另一個文件兩次或兩次以上很可能引起重復定義的問題，但是沒有人蠢到會重復包含兩次同一個文件的，這種問題都是隱式的重復包含，比如A 文件中包含了B 文件和C 文件，B 文件中又包含了C 文件，這樣，A 文件實際上已經(jīng)包含了C 文件兩次。不過一個好的頭文件巧妙的利用編譯預處理避免了這種情況。在頭文件中你可能發(fā)現(xiàn)這樣的一些預處理：
#ifndef __TEST_H__
#define __TEST_H__
… …
#endif /* __TEST_H__ */
這三行編譯預處理前兩行一般位于文件頂端，文件位于文件末端，它的意思是，如果沒有定義__TEST_H__那么就定義__TEST_H__同時下面的代碼一直到#endif 前參與編譯，反之不參與編譯。多么巧妙的設計，有了這三行簡潔的預處理，這個文件即使被包含幾萬次也只能算一次。
我們再來看看宏的使用。初學者在看別人代碼的時候總是想，為什么用那么多宏呢?看得人一頭霧水，的確，有時候宏的使用會降低代碼的可讀性。但有時宏也可以提高代碼的可讀性，看看下邊這兩段代碼：
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;
這是對某一個寄存器的賦值程序，兩者完成的是完全相同的工作。段代碼略顯冗長，第二段代碼很簡潔，但是如果你如果想改動此寄存器的設置的時候顯然更喜歡看到的是段代碼，因為它現(xiàn)有的值已經(jīng)很清楚，要對那些位賦值只要用相應得宏定義即可，不必每次改變都拿筆再重新計算一次。這一點對于嵌入式開發(fā)者很重要，有時我們調試一個設備的時候，一個關鍵寄存器的值也許會被我們修改很多次，每一次都計算每一位所對應得值是一件很頭疼的事。
另外利用宏也可以提高代碼的運行效率，子程序的調用需要壓棧出棧，這一過程如果過于頻繁會耗費掉大量的CPU 運算資源。所以一些代碼量小但運行頻繁的代碼如果采用帶參數(shù)宏來實現(xiàn)會提高代碼的運行效率，比如我們常常用到的對外部IO 賦值的操作，你可以寫一個類似下邊的函數(shù)來實現(xiàn)：
void outb(unsigned char val, unsigned int *addr)
{
*addr = val;
}
僅僅是一句語句的函數(shù)，卻要調用一個函數(shù)，如果不用函數(shù)呢，重復寫上面的語句又顯得羅嗦。不如用下面的宏實現(xiàn)。
#define outb(b, addr) (*(volatile unsigned char *)(addr) = (b))
由于不需要調用子函數(shù)，宏提高了運行效率，但是浪費了程序空間，這是由于凡是用到此宏的地方，都要替換為一句其代替的語句。開發(fā)者需要根據(jù)系統(tǒng)需求取舍時間與空間。