ARM/uClinux應用程序的開發(fā)

　　因為目標板上用uClinux，它提供的程序接口和linux下的基本一致，不一致的部分主要在于uClinux不支持MMU（應該說是uClinux是為不帶MMU的cpu定制的），最明顯的就是fork函數要用vfork函數替代，這也是編程時，感覺最不爽的一點(沒辦法，誰讓咱們的CPU有生理缺陷)。另一個不易覺察的差異在于uClinux提供的庫uClibc是經過裁減的。更適合于資源緊張的嵌入式系統(tǒng)（上回分解已經說了，應用程序很大一部分是在和庫函數打交道，而且大家最終是鏈在一起，所以庫函數大了，你的程序也小不了）。

　　于是基于這種開發(fā)模式的應用程序開發(fā)變成了linux下的程序開發(fā)。而且在實際中一般是編好了程序先在主機上拿主機平臺上的編譯器編譯并且調試一下（linux下的編譯器就是gcc了），當然前提是被調試的程序中需要的硬件條件主機具備，例如我的程序中有一段是針對串口的，于是先在主機編一個串口程序，調通以后拿目標板的編譯器重新編譯一下（如果看了上一章“交叉編譯環(huán)境”，這里就不會暈了），下載到目標板上運行，一般來說就可以直接用了。

　　以上也是為什么我認為開發(fā)嵌入式linux程序主機應該選用linux環(huán)境。對于以前沒用過linux的人來說（比如我），開發(fā)程序前應該花3，4天時間熟悉linux環(huán)境，尤其是它的編輯器，用慣集成編譯環(huán)境的人有時連編譯器和編輯器的概念都模糊了，所以一般是直接進入集成編譯環(huán)境，連寫帶編一氣呵成，殊不知有些集成編譯器提供的編輯器弱智的一塌胡涂，如果用熟了linux下的emacs，你就會發(fā)現他們之間的差距大概……要像我和蓋茨那么大吧。所以編程序時應該選一款優(yōu)秀的編輯器，linux下，我當然選emacs，雖然剛看見它的感覺是外表丑陋，使用復雜。但只要多用多練，對提高效率很有幫助。（將你的程序用兩個編輯器完成，一半是用emacs的，一半是不用emacs的，看看效果：－）
對具體的linux編程我就不板門弄斧了，需要提個醒的是咱硬件出身的人作軟件應該養(yǎng)成良好的編程習慣，別讓作軟件的笑話咱。因為作了些網絡應用，所以介紹一些網絡編程時要用到的網站和書籍;

　　>w.Richard.Stevens. 這可是linux網絡編程的圣經級的書籍

　　http://www.fanqiang.com/a4/b7/ 適合于網絡編程的入門。

　　還有IBM中國上關于linux的教程和文章，都是翻譯過來的，有很多寫非常不錯。

　　其實類似的資源不計其數，遇到問題時應該先到google上狂搜一圈。

　　重點想說些關于編譯器的東西，不了解它，在交叉編譯環(huán)境下編譯程序就寸步難行了，這無非是因為交叉編譯環(huán)境下目標板編譯器所處的寄人籬下的悲慘環(huán)境。想想在linux下將myprogram.c編譯鏈接成應用程序myprogram，最簡單的一句gcc –o myprogram myprogram.c 就可以了。（其實在諸如VC下你也可以找到類似的命令，集成開發(fā)環(huán)境只不過替你來調用它了）。一切看起來天經地義。

但試著把/usr/include路徑改一個名字（比如改成stupid_include），再這樣編譯一下，會發(fā)現程序中被 >引用的頭文件（比如#include）都找不到了。因為編譯器看見這樣的頭文件會到系統(tǒng)指定的路徑下尋找，而這個路徑是由環(huán)境變量保存的（linux和windows下都是這樣的）。針對以上情況，不將路徑名字改回去，但是給編譯器加一個參數如下：

　　gcc –I/usr/stupid_include –o myprogram myprogram.c 會發(fā)現錯誤信息沒了，一切又恢復了往日的寧靜，頓時明白，不用環(huán)境變量，通過參數，同樣可以將這些信息告訴編譯器。 返回來說說你的目標編譯器，雖然占用了人家的地盤，編譯器，頭文件，庫文件，一個都不少，但你要編一個程序編譯器照樣發(fā)暈，因為沒有環(huán)境變量告訴它自己需要的頭文件和庫文件在哪里?？磥碇挥袃煞N辦法，一個是搶占了主機的環(huán)境變量改成自己的（整個兒一個土匪）,或者在編譯時加上必要參數（還是這樣紳士一些），告訴編譯器需要的文件的位置。（除此之外，還有其他一些參數也是如此）。

　　從源程序到可執(zhí)行文件根據情況不同可能分好幾步，一般每一步可能都會有一個應用程序實現，像gnu提供的arm開發(fā)工具鏈其實就是這么一組程序。提供從編譯到鏈接到格式轉化的全套服務。你可以用arm－elf－gcc命令一步到底直接產生可執(zhí)行文件（其實也是在自己的任務完成后調用下一個程序），也可以每一步加上自己的參數，只作自己的事。

　　編譯器的主要參數的使用下次將程序的移植時再講。這里想說一下編譯器產生應用程序的幾個主要步鄹，講這個問題的原因還是很多人無法區(qū)分諸如編譯和鏈接，不用問，這一切還是IDE集成開發(fā)環(huán)境惹的禍。有人會說，IDE招你惹你了，你老貶它。其實不然，首先以上說的東西一般在IDE的project菜單下的option或build option中找到，只是一般不用管罷了。另一個方面，IDE就像是傻瓜照相機，很多工作他都幫你完成了，使用簡單。但如果要做攝影師的話，你就少不了要對每一個細節(jié)都了解。其實編譯程序也是一樣。（你可以對優(yōu)化，警告級，宏定義等諸多選項進行自己的選擇）。以下是幾個主要步鄹：（以下有些我也不確認，如發(fā)現問題，請及時糾正。

　　(1) 預編譯。 主要工作就是處理所有＃開頭的，包括頭文件。以前搞不清頭文件和可執(zhí)行文件有沒有什么聯系（因為總看見兩個文件名字取一樣的），現在知道，他們之間沒有任何聯系。在預編譯結束后，頭文件的使命就結束了。在下一次介紹不同平臺程序移植時可以看到，預編譯有時非常有用。

　　(2) 編譯。編譯應該是最主要的一步，就是將源文件生成CPU能識別的語言，一般是 后綴為.o的目標文件，應該說，此時的文件就已經可以執(zhí)行了。當然這個時候外部函數等外部符號都沒有引入，對于被編譯程序來說，這些外部符號還只是留一個倩影，壓根兒不知它在不在。你可以在你的程序里調用一個不存在的函數，甚至都不用聲明，在編譯階段，很多編譯器只是給個警告。只有在鏈接時才會報錯。（呵呵，夠弱智！）

　　(3) 鏈接：鏈接才是清帳的時候，以前在程序里用到的外部符號都要把真正的東西交出來。你可以指定需要連接在一起的目標文件，也可以告訴編譯器庫文件的名字和路徑（指定方法下次講）。編譯器會去找，需要注意的是，庫的指定需要注意順序。首先，如果不同的庫里有同名函數，并且該函數被調用，那么在前面的就被鏈接進去了，這一點對于頭文件路徑的指定也適用，如果你自己的頭文件和系統(tǒng)頭文件相同，并且你的頭文件路徑在系統(tǒng)頭文件路徑前面，你的頭文件就會代替頭文件。庫文件是由相應的程序（linux下是ar命令）將需要被添加到庫里的目標文件（該文件是編譯階段生成的）組織起來生成檔案文件，同時可以建立一個檢索，檢索內容為所包含的目標文件中定義的符號。也就是說，庫文件并不是必須的，但它為經常使用的目標文件中的函數提供了快速的檢索機制。
以上就是主要的步鄹，當然除此之外，還有一些用于格式轉換的工具等。不一一介紹。知道編譯器的細節(jié)對于程序的開發(fā)和移植都是很有好處的。
　
　　程序開發(fā)過程中調試也是至關重要，因為可以先在主機上調試，所以可以使用linux下的gdb，（有點像dos 下的debug）。但是只是用到了皮毛，還有一個專用于宿主機模式的調試工具gdbserver，一直沒時間研究，希望用過的大俠多發(fā)些文章鋪路。
另外還會遇到如何作ramdisk，如何讓系統(tǒng)啟動自己的程序，這些都太linux了，沒接觸過linux的人會暈，為了大家的健康，就不講了，遇到問題可以給我email，大家一起討論。

　　4.不同平臺間程序的移植--簡單程序的移植

　　研究程序移植的那兩周是最痛苦的兩周，沒有太多可以借鑒的東西，只能摸黑向前走，于是更加堅定決心要整理些東西給后來的弟兄。不過話說回來，各位弟兄別被我前面說的嚇倒，只要搞清你要作什么，程序移植其實是比較簡單的事情。
首先列出一些問題：

　　(1) X86上運行的程序能不能在51單片機上運行，為什么，有沒有可能，如果可以，應該做哪些工作才可以實現。

　　(2) 相同CPU平臺，DOS的程序為什么可以在windows下運行，能不能在linux下運行，為什么，作什么工作可能實現。

　　為什么可以移植程序，為什么要移植程序?

　　程序可以移植首先要感謝開發(fā)出高級語言的大牛們，記住，無論多么漂亮的代碼經過編譯以后都要變成CPU可以識別的機器語言，而幾乎一千種CPU說著一千種語言。為保證大家有共同語言，規(guī)定一種高級語言――高級語言。每一個CPU派出自己的翻譯――編譯器。這個翻譯精通兩國語言，高級語言和自己的語言。（由此已經可以看出編譯工具在程序移植中的重要性）。只要程序沒有硬件上的約束，可以說這種溝通是無極限的，甚至于不同操作系統(tǒng)平臺。（操作系統(tǒng)也是程序，也可以移植嘍）舉例：在x86的windows下用VC（或TC，BC）編一個c程序實現i=i+1，絲毫不改就可以用51的C編譯器重新編譯并在51單片機上運行。一次小型的移植就結束了。