【正文】 (3) 網(wǎng)上的資源，非常多。 linux站點(diǎn)。 申請(qǐng)是在： (4) 采用以上開發(fā)模式，軟件的可維護(hù)性，可移植性和可擴(kuò)展性都不錯(cuò)。 (6) 方案提供商的素質(zhì)嗎?? ..還算可以吧 :) 根據(jù)以上考慮和目前的開發(fā)情況，這套方案還是比較令人滿意。 2．開發(fā)環(huán)境的建立。因?yàn)榭偸怯腥嗽趩?wèn)是不是一定要用操作系統(tǒng)，我的 CPU能不能移植操作系統(tǒng)，可以移植 什么 操作系統(tǒng)，有了操作系統(tǒng)可不可以運(yùn)行某些程序。說(shuō)白了，操作系統(tǒng)就是一段設(shè)計(jì)非常巧妙的程序，和你自己的程序從本 質(zhì)講沒(méi)有區(qū)別，于是，以上問(wèn)題轉(zhuǎn)為，我是不是一定要用這段程序，我的 CPU能不能運(yùn)行這 段程序，可以跑什么樣的程序。另一方面，現(xiàn)代操作系統(tǒng)大多需要一些 硬件的支持，（像保護(hù)模式的實(shí)現(xiàn)），反過(guò)來(lái)說(shuō)，高端 CPU中專門有針對(duì)支持操作系統(tǒng)的體 系結(jié)構(gòu)，這樣，許多操作系統(tǒng)的實(shí)現(xiàn)是挑剔硬件平臺(tái)的。這就是話粗理不粗。 編譯的最 主要的工作就在將你的程序轉(zhuǎn)化成運(yùn)行該程序的 CPU所能識(shí)別的機(jī)器代碼，不同的 CPU有相應(yīng)的編譯器，另一方面。于是交叉編譯的交叉點(diǎn)就在那個(gè)編譯器本身是 CPU1 上的一個(gè)程序，卻在為CPU2編譯代碼 （整個(gè)一個(gè)吃里扒外?。．?dāng)然，假如在你的 ARM系統(tǒng)上，操作系統(tǒng) 已經(jīng) 正常運(yùn)行，并且你的資源足夠多，你可以把 PC機(jī)上運(yùn)行的 ARM編譯工具移植到ARM上，然后 所有該系統(tǒng)的應(yīng)用程序都直接在 ARM系統(tǒng)上編譯，這就不算交叉編譯，但如果有條件這么作 ，程序的開發(fā)或者移植就方便多了，因?yàn)檎麄€(gè)開發(fā)過(guò)程又回到在自己 PC機(jī)上編應(yīng)用程序的 那種模式了，那就是在自己的地盤上用自己的編譯器編自己的應(yīng)用程序。比如 uClinux 提供的uClibc。（唉，跟目標(biāo)板沒(méi)什 么關(guān)系，卻要幫它背這么多東西，真是上輩子欠它的 ?。。＿@些多是因?yàn)榇蠹乙? 經(jīng)遠(yuǎn)離了刀耕火種的年代（需要告訴編譯器需要的 include 路徑， lib 路徑，以及 lib的名稱 ），集成的編譯環(huán)境讓我們編譯鏈接的所有繁瑣工作化作對(duì) BUILD按鈕的瀟灑一擊。 但嘗試將 /usr/lib 目錄改一個(gè)名字，你就會(huì)知道你不能無(wú)視他們的存在，因?yàn)椴僮飨到y(tǒng)的功能都是通過(guò)這些 庫(kù)來(lái)交給應(yīng)用層程序使用的。 以上的東西一般時(shí)候是沒(méi)有必要仔細(xì)研究，但交叉環(huán)境下開發(fā)或移植比較大的程序時(shí)，你 可能就需要了解編譯器，鏈接器等開發(fā)工具的幾乎所有重要參數(shù)。 在我的系統(tǒng)上 ，建立基本的開發(fā)環(huán)境過(guò)程如下。包括 arm－ elf－ gcc， arm－ elf－ ld等 (2) 將 uClinux源代碼源代碼解壓到相應(yīng)路徑下，按照編譯內(nèi)核的步鄹編譯一遍（此時(shí)使用 的編譯工具已經(jīng)是上面提到的 ARM編譯工具了，因?yàn)樗?ARM CPU上運(yùn)行，另外，和編譯 linux內(nèi)核一樣，此 時(shí)可以通過(guò) menuconfig來(lái)對(duì)內(nèi)核提供的功能進(jìn)行裁減 (3) 將庫(kù)（ uClibc）解壓到相應(yīng)路徑下，用以上工具編譯一遍。 以上工作對(duì)于做過(guò)的人來(lái)說(shuō)比較簡(jiǎn)單，這里介紹一下幫助沒(méi)有使用或剛開始使用這種開發(fā) 模式的弟兄們理清一下思路。另一個(gè)不易覺(jué)察的差異在于 uClinux提供的庫(kù) uClibc是經(jīng)過(guò)裁減的。 于是基于這種開發(fā)模式的應(yīng)用程序開發(fā)變成了 linux下的程序開發(fā)。 以上也是為什么我認(rèn)為開發(fā)嵌入式 linux程序主機(jī)應(yīng)該選用 linux環(huán)境。所以編程序時(shí)應(yīng)該選一款優(yōu)秀的編輯器， linux下，我當(dāng)然選 emacs，雖然剛看見它的 感覺(jué)是外表丑陋，使用復(fù)雜。（將你的程序用兩 個(gè)編輯器完成，一半是用 emacs的，一半是不用 emacs的，看看效果：－） 對(duì)具體的 linux編程我就不板門弄斧了，需要提個(gè)醒的是咱硬件出身的人作軟件應(yīng)該養(yǎng)成良 好的編程習(xí)慣，別讓作軟件的笑話咱。 unix 網(wǎng)絡(luò)編程 第一卷 . 這可是 linux 網(wǎng)絡(luò)編程的圣經(jīng)級(jí)的書籍 還有 IBM中國(guó)上關(guān)于 linux的教程和文章，都是翻譯過(guò)來(lái)的，有很多寫非常不錯(cuò)。 重點(diǎn)想說(shuō)些關(guān)于編譯器的東西，不了解它，在交叉編譯環(huán)境下編譯程序就寸步難行了，這 無(wú)非是因?yàn)榻徊婢幾g環(huán)境下目標(biāo)板編譯器所處的寄人籬下的悲慘環(huán)境。（其實(shí)在諸如 VC下你也可以找到類似的命令，集成開發(fā)環(huán)境只不過(guò)替你來(lái)調(diào) 用它了）。 但試著把 /usr/include路徑改一個(gè)名字（比如改成 stupid_include），再這樣編譯一下， 會(huì)發(fā)現(xiàn)程序中被 引用的頭文件（比如 include）都找不到了。針對(duì)以上情況，不將路徑名字改回去，但是給編譯器加一個(gè)參數(shù) 如下： gcc – I/usr/stupid_include – o myprogram 會(huì)發(fā)現(xiàn)錯(cuò)誤信息沒(méi)了，一切又 恢復(fù)了往日的寧?kù)o，頓時(shí)明白，不用環(huán)境變量，通過(guò)參數(shù)，同樣可以將這些信息告訴編譯 器?？磥?lái)只有兩種辦法，一個(gè)是搶占了主機(jī)的環(huán)境變量改成自己的（整個(gè) 兒一個(gè)土匪） ,或者在編譯時(shí)加上必要參數(shù)（還是這樣紳士一些），告訴編譯器需要的文件 的位置。 從源程序到可執(zhí)行文件根據(jù)情況不同可能分好幾步，一般每一步可能都會(huì)有一個(gè)應(yīng)用程序 實(shí)現(xiàn)，像 gnu提供的 arm開發(fā)工具鏈其實(shí)就是這么一組程序。你可以用 arm－ elf－ gcc命令一步到底直接產(chǎn)生可執(zhí)行文件（其實(shí)也是在自己 的任務(wù)完成后調(diào)用下一個(gè)程序），也可以每一步加上自己的參數(shù)，只作自己的事。這里想說(shuō)一下編譯器產(chǎn)生應(yīng)用程序的 幾個(gè)主要步鄹，講這個(gè)問(wèn)題的原因還是很多人無(wú)法區(qū)分諸如編譯和鏈接，不用問(wèn)，這一切 還是 IDE 集成開發(fā)環(huán)境惹的禍。其實(shí)不然，首先以 上說(shuō)的東西一般在 IDE的 project菜單下的 option或 build option中找到，只是一般不用管 罷了。但如果 要做攝影師的話，你就少不了要對(duì)每一 個(gè)細(xì)節(jié)都了解。（你可以 對(duì)優(yōu)化，警告級(jí)，宏定義等諸多選項(xiàng)進(jìn)行自己的選擇）。 (1) 預(yù)編譯。以前搞不清頭文件和可執(zhí)行 文件有沒(méi)有什么聯(lián)系（因?yàn)榭偪匆妰蓚€(gè)文件名字取一樣的），現(xiàn)在知道，他們之間沒(méi)有任