摘要 uClinux和eCos操作系統(tǒng)是兩種性能優(yōu)良、源碼公開(kāi)且被廣泛應(yīng)用的免費(fèi)嵌入式操作系統(tǒng)。本文通過(guò)對(duì)uclinux和eCos的對(duì)比，分析和總結(jié)了嵌入式操作系統(tǒng)應(yīng)用中的若干重要問(wèn)題，歸納出嵌入式系統(tǒng)開(kāi)發(fā)中操作系統(tǒng)的選型依據(jù)。 　　 關(guān)鍵詞 嵌入式 操作系統(tǒng) eC0s uClinux 1 兩種開(kāi)源嵌入式操作系統(tǒng)介紹 　　 uClinux是一種優(yōu)秀的嵌入式Linux版本。uClinux是micro-Conrol-linux的縮寫(xiě)。與標(biāo)準(zhǔn)Linux相比，它集成了標(biāo)準(zhǔn)Linux操作系統(tǒng)的穩(wěn)定性、強(qiáng)大網(wǎng)絡(luò)功能和出色的文件系統(tǒng)等主要優(yōu)點(diǎn)。但是由于沒(méi)有MMU（內(nèi)存管理單元），故其多任務(wù)的實(shí)現(xiàn)需要一定技巧。 eCos（embedded Configurable operating system），即嵌入式可配置操作系統(tǒng)，是RedHat的產(chǎn)品，但eCos并不是Linux或Linux的派生。eCos彌補(bǔ)了Linux在嵌入式應(yīng)用領(lǐng)域的不足，是一個(gè)源碼開(kāi)放的可配置、可移植、無(wú)版稅、面向深嵌入式應(yīng)用的實(shí)時(shí)操作系統(tǒng)。eCos的核心部分是由不同的組件組成的，包括內(nèi)核、C語(yǔ)言庫(kù)和底層運(yùn)行包等。每個(gè)組件能提供大量的可配置選項(xiàng)，利用eCos提供的配置工具可以很方便地進(jìn)行配置。通過(guò)不同的配置使得eCos能夠滿(mǎn)足不同的嵌入式應(yīng)用。 對(duì)于以上兩種源碼公開(kāi)的實(shí)時(shí)操作系統(tǒng)，主要從以下幾個(gè)方面進(jìn)行比較。通過(guò)比較，能夠?yàn)榇蠹疫x擇適合自己系統(tǒng)的RTOS提供參考。 2 基本操作性能的比較 　　 2.1 應(yīng)用程序的運(yùn)算能力 　　 在Linux和uClinux操作系統(tǒng)啟動(dòng)的時(shí)候，都會(huì)有這樣一句話(huà)——Calibrating delay 1oop．．0k—xxx BogoMips，這一過(guò)程叫作BogoMips（讀作bogumips）。Linus Torvalds引入BogoMips主要有兩個(gè)目的：①給用戶(hù)一個(gè)大概的系統(tǒng)運(yùn)算能力的概念；②由于系統(tǒng)中有許多代碼需要精確的軟件延時(shí)，通過(guò)BogoMips來(lái)獲得軟件延時(shí)每個(gè)周期消耗的時(shí)間。BogoMips的過(guò)程就是一個(gè)簡(jiǎn)單計(jì)數(shù)循環(huán)，看ls可以循環(huán)多少次，然后除以500000就得到了BogoMips的數(shù)值。 表1是分別在目標(biāo)硬件平臺(tái)上運(yùn)行eCos和uClinux下的BogoMips應(yīng)用程序得到的結(jié)果。我們使用了不同的測(cè)試條件，激活和非激活A(yù)T76C120的存儲(chǔ)器緩沖控制器。 從表1可知，打開(kāi)緩沖存儲(chǔ)器。對(duì)eCos的應(yīng)用程序性能影響較uClinux的大；反之，關(guān)閉緩沖，eCos的應(yīng)用程序的性能就下降很多。 2．2 存儲(chǔ)器訪(fǎng)問(wèn)能力 　　 采用一種同時(shí)能夠測(cè)試緩沖控制器和標(biāo)準(zhǔn)存儲(chǔ)器訪(fǎng)問(wèn)函數(shù)的測(cè)試方法來(lái)測(cè)試存儲(chǔ)器訪(fǎng)問(wèn)能力。在這里，選用田納西大學(xué)的Philip J．Mucci等人提出的CacheBench方法。其工作原理是，重復(fù)順序讀／寫(xiě)一定長(zhǎng)度的存儲(chǔ)器塊的數(shù)據(jù)，記錄重復(fù)n次所用的時(shí)問(wèn)，用總的讀／寫(xiě)數(shù)據(jù)除以耗時(shí)，得到讀／寫(xiě)每一字節(jié)所用的時(shí)間；同時(shí)，通過(guò)調(diào)整數(shù)據(jù)塊的長(zhǎng)度和不同的讀寫(xiě)方法（使用標(biāo)準(zhǔn)函數(shù)或者使用直接代碼讀寫(xiě)），獲得不同條件對(duì)存儲(chǔ)器讀／寫(xiě)的影響。 在實(shí)驗(yàn)中，對(duì)于每一種測(cè)試模式使用4種不同的塊長(zhǎng)度（分別為256、512、1024、2048字節(jié)），以觀(guān)察不同的抉長(zhǎng)度對(duì)存儲(chǔ)器訪(fǎng)問(wèn)性能的影響。表2是實(shí)驗(yàn)的結(jié)果：橫向比較，eCos的存儲(chǔ)器訪(fǎng)問(wèn)性能從總體上都優(yōu)于uClinux；縱向比較，5種模式下性能關(guān)系大致為緩沖讀>緩沖讀，改寫(xiě)／寫(xiě)>緩沖寫(xiě)>mcmset>mcmcpy。在同一種測(cè)試模式下，對(duì)于緩沖讀，越大的塊長(zhǎng)度，其表現(xiàn)的存儲(chǔ)器訪(fǎng)問(wèn)性能越好；而其他模式下，存儲(chǔ)器訪(fǎng)問(wèn)性能基本與塊長(zhǎng)度無(wú)關(guān)。 基于以上結(jié)果的分析如下：①造成eCos存儲(chǔ)器訪(fǎng)問(wèn)能力優(yōu)于uClinux的原因是，eCos的應(yīng)用程序獲得的處理器時(shí)間較長(zhǎng)；②造成讀緩沖模式下，存儲(chǔ)器訪(fǎng)問(wèn)性能隨塊長(zhǎng)度增長(zhǎng)而變好，而其他模式下不變的原因是，與AT76C120的緩沖控制器的回寫(xiě)模式有關(guān)。由于A(yíng)T76C120的緩沖控制器采用了直接回寫(xiě)的緩沖回寫(xiě)模式，緩沖控制器對(duì)存儲(chǔ)器寫(xiě)操作沒(méi)有任何緩沖作用，因此當(dāng)處理器寫(xiě)存儲(chǔ)器時(shí)基本不會(huì)享受到由緩沖控制器帶來(lái)的好處，相當(dāng)于直接訪(fǎng)問(wèn)外部存儲(chǔ)器。 2．3 驅(qū)動(dòng)程序性能測(cè)試 　　 為了測(cè)試系統(tǒng)的驅(qū)動(dòng)程序性能，選擇CF卡驅(qū)動(dòng)程序作為測(cè)試對(duì)象。我們的測(cè)試方法簡(jiǎn)單，就是在應(yīng)用程序中打開(kāi)一個(gè)大文件（10MB），然后調(diào)用fread讀文件，每次讀512字節(jié)到緩沖中，直至將文件讀完。 表3是測(cè)試結(jié)果：uClinux的性能優(yōu)于eCos。這主要是由于uClinux的塊驅(qū)動(dòng)有一個(gè)叫集簇的功能，它可以將對(duì)塊設(shè)備的多個(gè)請(qǐng)求歸并在一起執(zhí)行，這樣對(duì)于像磁盤(pán)這樣反應(yīng)較慢的設(shè)備可以提高整體的讀／寫(xiě)速度。 3 綜合應(yīng)用性能比較 我們知道，一個(gè)圖像壓縮和解壓縮的程序往往需要大塊的存儲(chǔ)器訪(fǎng)問(wèn)操作、密集的數(shù)學(xué)運(yùn)算和大量的磁盤(pán)訪(fǎng)問(wèn)。由于現(xiàn)在手持的嵌入式設(shè)備大多需要有這方面的應(yīng)用需求，因此一個(gè)圖像壓縮和解壓縮的應(yīng)用程序既符合理論研究的要求，又符合實(shí)際應(yīng)用的需求。為此我們選擇gif圖片的編解碼的程序作為綜合性能測(cè)試的測(cè)試程序。測(cè)試結(jié)果如表4所列。 我們看到，eCos和uClinux解碼速度都很低，主要是因?yàn)橥耆褂昧塑浖鈮嚎s；而且由于A(yíng)T76C120的圖像顯示格式是YCrCb的，而giflib的解壓縮結(jié)果是RGB的，因此必須使用浮點(diǎn)運(yùn)算將RGB的數(shù)據(jù)轉(zhuǎn)換到Y(jié)CrCb。AT76C120的ARM7TDMI不支持浮點(diǎn)指令，因此不得不使用軟件仿真來(lái)完成浮點(diǎn)運(yùn)算，這其中大部分時(shí)間被用在了從RGB到Y(jié)CrCb的轉(zhuǎn)換上。測(cè)試結(jié)果基本與前面基本操作系統(tǒng)測(cè)試的結(jié)果是一致的——eCos在整體上是優(yōu)于uClinux的。 4 可移植性 　　 eCos的系統(tǒng)一J移植性應(yīng)該明顯比uClinux的好。在eCos系統(tǒng)中，每一個(gè)硬件平臺(tái)都用一個(gè)單獨(dú)的目錄存放針對(duì)這一硬件平臺(tái)的硬件抽象層的代碼和配置信息，較容易讓用戶(hù)理解。而uClinux的硬件抽象層的代碼分布在好幾個(gè)目錄中，而且各個(gè)平臺(tái)的代碼混合在一個(gè)源文件中，通過(guò)#ifdef+#end的方式來(lái)選擇不同的硬件平臺(tái)的代碼。另外，eCos在移植時(shí)所要更改的源代碼文件數(shù)少于uClinux。 可移植性不應(yīng)僅僅是操作系統(tǒng)的移植，還應(yīng)該包含應(yīng)用程序的移植性。程序的可移植性，是由兩方面決定的。首先，應(yīng)用程序必須被編寫(xiě)得可以移植。關(guān)于這方面，A．Dolenc，A．Lemmke和D.Keppel在其N(xiāo)otes On WritingPortable Programs In C一文中給出了很好的解釋。其次是嵌入式操作系統(tǒng)提供較豐富的系統(tǒng)函數(shù)和標(biāo)準(zhǔn)函數(shù)庫(kù)。一個(gè)系統(tǒng)提供的函數(shù)庫(kù)越豐富，則越多的應(yīng)用程序不用進(jìn)行較大的更改就能直接在其上運(yùn)行。在標(biāo)準(zhǔn)函數(shù)方面，eCos只提供了較為簡(jiǎn)單的C標(biāo)準(zhǔn)函數(shù)庫(kù)和IEEE浮點(diǎn)運(yùn)算數(shù)學(xué)庫(kù)，uClinux則提供了，與Linux下的glibc相兼容的函數(shù)庫(kù)，而glibc是大部分開(kāi)放源代碼項(xiàng)目的構(gòu)建基礎(chǔ)。由此可以看出，在應(yīng)用程序的可移植性上，uClinux的兼容性更好。 5 開(kāi)發(fā)模式和開(kāi)發(fā)難易度 　　 eCos的開(kāi)發(fā)模式是一套更接近傳統(tǒng)單片機(jī)的開(kāi)發(fā)模式（如應(yīng)用程序靜態(tài)鏈接），uClinux的開(kāi)發(fā)模式則更接近Linux的開(kāi)發(fā)模式。因此可以預(yù)見(jiàn)，eCos更受一批從8位單片機(jī)系統(tǒng)開(kāi)發(fā)轉(zhuǎn)到32位嵌入式系統(tǒng)開(kāi)發(fā)設(shè)計(jì)人員的歡迎．而uClinux更受熟悉Linux的設(shè)計(jì)人員的青睞。 6 總 結(jié) 　　 通過(guò)以上比較可知，由于eCos從一開(kāi)始設(shè)汁時(shí)就是以嵌入式系統(tǒng)為目標(biāo)的，因此在性能上，有較大優(yōu)勢(shì)；反之，uClinux則是由Linux進(jìn)化而來(lái)的，因此在以速度和優(yōu)化為主題的嵌入式系統(tǒng)環(huán)境中，并不占優(yōu)勢(shì)。但是由于有Linux的強(qiáng)大后盾，其功能的強(qiáng)大和兼容性是非常突出的。如果應(yīng)用程序是從其他系統(tǒng)中移植過(guò)來(lái)的，或者開(kāi)發(fā)人員有Linux的背景，或者開(kāi)發(fā)成本占總成本的比例較高，則uClinux比較適合；反之，eCos比較適合。