嵌入式操作系統(tǒng)uClinux和eCos的比較

 1 兩種開源嵌入式操作系統(tǒng)介紹

uClinux是一種優(yōu)秀的嵌入式Linux版本。uClinux是micro-Conrol-linux的縮寫。與標準Linux相比，它集成了標準Linux操作系統(tǒng)的穩(wěn)定性、強大網(wǎng)絡(luò)功能和出色的文件系統(tǒng)等主要優(yōu)點。但是由于沒有MMU(內(nèi)存管理單元)，故其多任務(wù)的實現(xiàn)需要一定技巧。

eCos(embedded Configurable operating system)，即嵌入式可配置操作系統(tǒng)，是RedHat的產(chǎn)品，但eCos并不是Linux或Linux的派生。eCos彌補了Linux在嵌入式應(yīng)用領(lǐng)域的不足，是一個源碼開放的可配置、可移植、無版稅、面向深嵌入式應(yīng)用的實時操作系統(tǒng)。eCos的核心部分是由不同的組件組成的，包括內(nèi)核、C語言庫和底層運行包等。每個組件能提供大量的可配置選項，利用eCos提供的配置工具可以很方便地進行配置。通過不同的配置使得eCos能夠滿足不同的嵌入式應(yīng)用。

對于以上兩種源碼公開的實時操作系統(tǒng)，主要從以下幾個方面進行比較。通過比較，能夠為大家選擇適合自己系統(tǒng)的RTOS提供參考。

　　2 基本操作性能的比較

2.1 應(yīng)用程序的運算能力

在Linux和uClinux操作系統(tǒng)啟動的時候，都會有這樣一句話——Calibrating delay 1oop．．0k—xxx BogoMips，這一過程叫作BogoMips(讀作bogumips)。Linus Torvalds引入BogoMips主要有兩個目的：①給用戶一個大概的系統(tǒng)運算能力的概念；②由于系統(tǒng)中有許多代碼需要精確的軟件延時，通過BogoMips來獲得軟件延時每個周期消耗的時間。BogoMips的過程就是一個簡單計數(shù)循環(huán)，看ls可以循環(huán)多少次，然后除以500000就得到了BogoMips的數(shù)值。

表1是在目標硬件平臺上運行eCos和uClinux下的BogoMips應(yīng)用程序得到的結(jié)果。我們使用了不同的測試條件，激活和非激活AT76C120的存儲器緩沖控制器。

打開緩沖存儲器。對eCos的應(yīng)用程序性能影響較uClinux的大；反之，關(guān)閉緩沖，eCos的應(yīng)用程序的性能就下降很多。

2．2 存儲器訪問能力

采用一種同時能夠測試緩沖控制器和標準存儲器訪問函數(shù)的測試方法來測試存儲器訪問能力。在這里，選用田納西大學的Philip J．Mucci等人提出的CacheBench方法。其工作原理是，重復順序讀／寫一定長度的存儲器塊的數(shù)據(jù)，記錄重復n次所用的時問，用總的讀／寫數(shù)據(jù)除以耗時，得到讀／寫每一字節(jié)所用的時間；同時，通過調(diào)整數(shù)據(jù)塊的長度和不同的讀寫方法(使用標準函數(shù)或者使用直接代碼讀寫)，獲得不同條件對存儲器讀／寫的影響。

在實驗中，對于每一種測試模式使用4種不同的塊長度(分別為256、512、1024、2048字節(jié))，以觀察不同的抉長度對存儲器訪問性能的影響。表2是實驗的結(jié)果：橫向比較，eCos的存儲器訪問性能從總體上都優(yōu)于uClinux；縱向比較，5種模式下性能關(guān)系大致為緩沖讀>緩沖讀，改寫／寫>緩沖寫>mcmset>mcmcpy。在同一種測試模式下，對于緩沖讀，越大的塊長度，其表現(xiàn)的存儲器訪問性能越好；而其他模式下，存儲器訪問性能基本與塊長度無關(guān)。

基于以上結(jié)果的分析如下：①造成eCos存儲器訪問能力優(yōu)于uClinux的原因是，eCos的應(yīng)用程序獲得的處理器時間較長；②造成讀緩沖模式下，存儲器訪問性能隨塊長度增長而變好，而其他模式下不變的原因是，與AT76C120的緩沖控制器的回寫模式有關(guān)。由于AT76C120的緩沖控制器采用了直接回寫的緩沖回寫模式，緩沖控制器對存儲器寫操作沒有任何緩沖作用，因此當處理器寫存儲器時基本不會享受到由緩沖控制器帶來的好處，相當于直接訪問外部存儲器。

2．3 驅(qū)動程序性能測試

為了測試系統(tǒng)的驅(qū)動程序性能，選擇CF卡驅(qū)動程序作為測試對象。我們的測試方法簡單，就是在應(yīng)用程序中打開一個大文件(10MB)，然后調(diào)用fread讀文件，每次讀512字節(jié)到緩沖中，直至將文件讀完。

表3是測試結(jié)果：uClinux的性能優(yōu)于eCos。這主要是由于uClinux的塊驅(qū)動有一個叫集簇的功能，它可以將對塊設(shè)備的多個請求歸并在一起執(zhí)行，這樣對于像磁盤這樣反應(yīng)較慢的設(shè)備可以提高整體的讀／寫速度。

　　3 綜合應(yīng)用性能比較

我們知道，一個圖像壓縮和解壓縮的程序往往需要大塊的存儲器訪問操作、密集的數(shù)學運算和大量的磁盤訪問。由于現(xiàn)在手持的嵌入式設(shè)備大多需要有這方面的應(yīng)用需求，因此一個圖像壓縮和解壓縮的應(yīng)用程序既符合理論研究的要求，又符合實際應(yīng)用的需求。為此我們選擇gif圖片的編解碼的程序作為綜合性能測試的測試程序。測試結(jié)果如表4所列。

我們看到，eCos和uClinux解碼速度都很低，主要是因為完全使用了軟件解壓縮；而且由于AT76C120的圖像顯示格式是YCrCb的，而giflib的解壓縮結(jié)果是RGB的，因此必須使用浮點運算將RGB的數(shù)據(jù)轉(zhuǎn)換到Y(jié)CrCb。AT76C120的arm7TDMI不支持浮點指令，因此不得不使用軟件仿真來完成浮點運算，這其中大部分時間被用在了從RGB到Y(jié)CrCb的轉(zhuǎn)換上。測試結(jié)果基本與前面基本操作系統(tǒng)測試的結(jié)果是一致的——eCos在整體上是優(yōu)于uClinux的。

　　4 可移植性

eCos的系統(tǒng)一J移植性應(yīng)該明顯比uClinux的好。在eCos系統(tǒng)中，每一個硬件平臺都用一個單獨的目錄存放針對這一硬件平臺的硬件抽象層的代碼和配置信息，較容易讓用戶理解。而uClinux的硬件抽象層的代碼分布在好幾個目錄中，而且各個平臺的代碼混合在一個源文件中，通過#ifdef+#end的方式來選擇不同的硬件平臺的代碼。另外，eCos在移植時所要更改的源代碼文件數(shù)少于uClinux。

可移植性不應(yīng)僅僅是操作系統(tǒng)的移植，還應(yīng)該包含應(yīng)用程序的移植性。程序的可移植性，是由兩方面決定的。首先，應(yīng)用程序必須被編寫得可以移植。關(guān)于這方面，A．Dolenc，A．Lemmke和D.Keppel在其Notes On WritingPortable Programs In C一文中給出了很好的解釋。其次是嵌入式操作系統(tǒng)提供較豐富的系統(tǒng)函數(shù)和標準函數(shù)庫。一個系統(tǒng)提供的函數(shù)庫越豐富，則越多的應(yīng)用程序不用進行較大的更改就能直接在其上運行。在標準矯媯琫Cos只提供了較為簡單的C標準函數(shù)庫和IEEE浮點運算數(shù)學庫，uClinux則提供了，與Linux下的glibc相兼容的函數(shù)庫，而glibc是大部分開放源代碼項目的構(gòu)建基礎(chǔ)。由此可以看出，在應(yīng)用程序的可移植性上，uClinux的兼容性更好。

　　5 開發(fā)模式和開發(fā)難易度

eCos的開發(fā)模式是一套更接近傳統(tǒng)單片機的開發(fā)模式(如應(yīng)用程序靜態(tài)鏈接)，uClinux的開發(fā)模式則更接近Linux的開發(fā)模式。因此可以預見，eCos更受一批從8位單片機系統(tǒng)開發(fā)轉(zhuǎn)到32位嵌入式系統(tǒng)開發(fā)設(shè)計人員的歡迎．而uClinux更受熟悉Linux的設(shè)計人員的青睞。

　　6 總 結(jié)

通過以上比較可知，由于eCos從一開始設(shè)汁時就是以嵌入式系統(tǒng)為目標的，因此在性能上，有較大優(yōu)勢；反之，uClinux則是由Linux進化而來的，因此在以速度和優(yōu)化為主題的嵌入式系統(tǒng)環(huán)境中，并不占優(yōu)勢。但是由于有Linux的強大后盾，其功能的強大和兼容性是非常突出的。如果應(yīng)用程序是從其他系統(tǒng)中移植過來的，或者開發(fā)人員有Linux的背景，或者開發(fā)成本占總成本的比例較高，則uClinux比較適合；反之，eCos比較適合。