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