如何選擇實時操作系統

很難作決定是買一個實時操作系統，還是自己動手做。如果要買的話,決定買哪一種、從哪家供應商買仍然充滿變數。 

嵌入式軟件工程師總是幾乎完全從零開始開發應用程序。為什么會那樣？如果從我們的朋友——硬件工程師那里取點兒經的話可能大有裨益。他們開始做一項新設計時，總是選擇現成的集成電路，只有到最后不得已時才自己設計邏輯電路。因此，對我們來說，重用他人的工作成果以達到目標的第一步就是要選擇一種實時操作系統（RTOS）。然而當你選擇RTOS時很有一些需要考慮的問題，一個清晰的思路無疑有助于成功地作出決定。 

實時操作系統對我來說真的必要嗎？ 
Do I really need a real-time operating system? 

在一頭扎進如何選擇一個實時操作系統的討論之前，大多數人應該問問自己：為什么需要實時操作系統？是否所有的嵌入式軟件系統在實時操作系統的支持下工作得最好？當然不是。有很多簡單的產品，不夠大也不夠復雜，根本負擔不起額外的開銷。 

有關是否使用RTOS的爭論非常類似于是否使用高級語言的爭論。正象高級語言一樣，RTOS使你可以更快地開發產品。它可能要求一些額外的開銷，但是隨著技術的進步，這種開銷在變小。 

正如有的應用仍推崇匯編語言，也存在這樣一些應用，它們很簡單，僅需求很少的一點操作系統服務。在這種情況下，更簡單的結構——比如輪轉調度之類以狀態機為基礎的函數——可能就足夠了。難道你能指望在你的面包機里安裝一個實時操作系統嗎？除此之外，你應該考慮RTOS。 

自建還是購買？ 
Build vs. buy 

在“嵌入式”世界里，就一個工作組該購買還是自建實時操作系統展開了生動的討論。不幸的是，我們非常缺乏有效的統計數據。我認為在大多數情況下，購買RTOS是較好的選擇。我這樣說的時候，請注意我與RTOS工業界的任何公司沒有任何私人或者職務關系。 

關于購買RTOS的爭論還有一個小小的軼聞。以前我曾在一個為醫療設備開發嵌入式軟件的項目組工作。我們使用的是CMX公司的CMX-RTX。在嵌入式開發者一系列可能的選擇中，這個RTOS的特征是很典型的。隨OS還提供了11,000行的源代碼。想想吧，用CMX公司賣得的兩千美元你能定義、設計、實現并測試完成如此的產品嗎？我看不大可能。 

然而，堅持從零開始自建RTOS的人仍與購買現成專用RTOS的擁護者爭論不休。在性能絕對至關重要的場合，寫自己的實時操作系統可能允許你花費巨大代價換取有限的百分之幾的速度提升。 

另外，特定的工業（比如醫療設備、安全系統等）對軟件有特定的規則或標準要求。在某些情況下，現成的操作系統滿足不了這些要求。這時也只能選擇自建。 

最后，在嵌入式系統中，為了使用專用代碼而安裝的基礎系統相當大。把老代碼剝離出來移植到新的操作系統上難說是個明智的主意。而將產品移植到一種新的微處理器上是說得通的。如果該專用RTOS尚未被移植到新的微處理器上，這可能是考慮使用現成RTOS的一個好時機。 

工具的相互關系 
Tool interrelationships 

一個工程師選擇實時操作系統時如果不考慮其余與之相關的工具是不行的。微處理器、在線仿真器（ICE）、編譯器、匯編器、連接器、調試器以及模擬器——都這樣或那樣地影響著操作系統。 

有些在線仿真器供應商提供其ICE與實時操作系統接口的軟件。檢查一下你的ICE是否能與你的RTOS協同工作，這在調試那些最隱蔽的小錯誤（bugs）時是很有用的。然而，重要的是要了解在線仿真器的操作對性能的影響。有時當ICE執行操作時增加了額外的開銷，比如中斷某行源代碼在某個任務中的執行。 

對給定微處理器家族上的某種操作系統來說，很可能OS供應商只支持所有可用編譯工具（包括編譯器、匯編器和連接器）的一個子集。應該確認供應商支持你所用的。你應該避免我們項目組當初選擇一種現成的實時操作系統所碰到的災難。OS供應商將我們選擇的RTOS以源代碼的形式提供給了我們，但是我們沒有考慮到的一個問題是這種RTOS與我們使用的編譯器不能合作。經過六周的艱苦努力，負責修改RTOS源代碼的工程師終于完成了任務。 

選擇準則 
Selection criteria 

除了開發工具箱中其他工具的影響之外，如果你能很好地組織在調查研究RTOS期間所搜集的信息，作出選擇就會容易一些。首先列一份可供選擇的RTOS清單。到選擇RTOS時，你可能已經選定了微處理器。據此你可以立即劃掉不支持你的MCU的RTOS從而得到較短的清單。如果你選擇了無所不在的68000或者x86系列，則需要更多的準則來幫助你作出選擇。 

有了一個短的清單之后，艱難的工作才真正開始。首先，要決定對你的應用來說哪條準則是真正重要的。本文討論了選擇時要考慮的幾條重要特征，然而每一個應用開發都有差異，需要認真考察到底什么是最重要的。應該根據各項選擇準則列一個表，針對每個項目評價每種RTOS。甚至在填完了整張表格之后，模模糊糊的仍然不知該選哪一個，這種事情確實很難干脆果斷。參與選擇過程的每個人應該對這個表格展開討論。討論之后拿出決定或者拿出作決定的計劃。 

在選擇RTOS的過程中有兩個基本的因素。第一組基本準則圍繞著一個特定產品的細節。你現在正在使用的工具哪些要與RTOS一起繼續使用？把所有的決定建立在如此簡單、短視的判斷上不可能最好。開闊視野，將眼光擴展到公司的整個產品線。這樣的話，你需要考察RTOS與整個產品線的兼容性。該RTOS在將來的幾年中仍會有所發展嗎？該RTOS與你期望選用的其他微處理器兼容嗎？ 

第二，你可以創建一個實現極少特性的框架，但這樣做有點違背購買現成RTOS的目的。當深入RTOS的結構之后，一系列問題始終困擾著開發者。這些問題包括：該RTOS可以動態地創建和刪除任務嗎？一個任務能同時等待多個事件嗎？任務有多少優先級？很難預料在整個應用的設計過程中需要RTOS的哪些服務。一般來說，很多特性可以實現你想要的大多數功能。如果有困難，要積極地資訊供應商的技術支持和應用工程師。如果你有使用其他RTOS的經驗，現在要用一種新的OS，試著在新的RTOS中找找那些你熟悉的特性。因為不同的供應商往往用不同的方式解決同一個問題。最好選擇其中與你過去熟悉的方式接近的那種。 

內核要求的最小存儲器大小 
Footprint 

實時操作系統可以裝入小得令人驚訝的內存中。盡管如此，當供應商給出一個內核要求的最小存儲器大小時，很重要的一點是要了解這個內核中包括了什么。最小的內核經常是僅僅支持很少的特性，而典型的配置可能產生大得多的內核。如果你的設計非常在乎RAM或ROM的大小，一定要澄清這個問題。有時供應商可以提供一份詳細的列表，說明了創建包含不同服務的內核分別需要多大的RAM和ROM。 

性能 
Performance 

對所有的項目來說，性能無不是個大問題。但是要了解RTOS對系統的影響卻不那么容易。當你比較供應商提供的benchmark時你要明白他們是要測試什么。供應商使用的是什么評估板？微處理器的時鐘頻率是多少？使用的什么存儲系統？存儲器訪問使用了幾個等待周期？只有弄清楚了這些你才能作出公平的對比。 

有幾種性能建模工具可以幫助你建立系統性能模型，供應商是Tri-Pacific Software和CARDtools Systems之類。隨著設計的深入還要繼續細化性能模型。 

軟件組件和設備驅動程序 
Software components and device drivers 

在1998年11月的嵌入式系統會議上，Wind River Systems的合伙創始人之一Jerry Fiddler描繪了將來十年嵌入式系統的圖景——網絡化的、無所不在的普通設備。到處都會有計算機，但計算機的外表不再是一成不變的。為了使美景成真，嵌入式系統應該通過各種標準加大開發需求的互操作性，開發者可能要依賴于他人開發的組件。假如你的應用需要通信協議、服務、庫或者其他組件（如TCP/IP、HTTP、ftp、telnet、SNMP、CORBA和圖形），現看看哪里可以獲得它們。類似的，在設計中用到現成的板卡或IC時，要確定是否可以得到設備驅動程序。 

有些操作系統供應商提供這些特性或驅動程序的方式不同，可能作為操作系統的一部分，也可能作為可選配件。另外，這些服務也可以從第三方供應商獲得。與供應商交涉時，要弄清楚你的RTOS里集成了哪些組件。 

調試工具 
Debugging tools 

RTOS供應商可能有有助于找到錯誤的調試工具，這些錯誤（比如死鎖、忘了放信號燈等等）用其他源碼級調試器更難于發現。許多工具允許開發者在任務之間相互傳遞信號燈時、在任務切換時和發生中斷時進行Watch（以增加CPU開銷為代價）。 

少數供應商提供給用戶的是集成開發環境。對主機-目標式調試器來說，應用在RAM中運行是它工作得很好。如果你希望從ROM運行代碼，看看這種調試服務還有多大用處。 

標準兼容性 
Standards compatibility 

你正在考察的RTOS支持一般的標準嗎？例如，RTOS服務有一個POSIX標準。即使大多數開發者不需要POSIX，這也可以作為一個考慮因素。如果你在開發安全性敏感的系統，應該考慮一下該行業所要求的安全標準。有些RTOS供應商已經開始認證他們的產品。 

技術支持 
Technical support 

購買了RTOS之后，你還需要技術支持。RTOS供應商提供多種支持渠道，其中都有電話和/或電子支持。但是要確認在你購買之后這種支持能持續多久。最好能感受一下供應商技術支持的質量如何。如果你對RTOS完全是新手，供應商的培訓就很有用了。這種培訓一般是上門服務。如果供應商能提供高質量的附帶幾個好實例的文檔，那么對培訓的要求就可以降低一些了。 

源代碼還是目標代碼？ 
Source vs. object code 

有些供應商當你購買了一個開發許可時會提供給你全部源代碼。而其他的僅提供目標代碼。第一次使用沒有源代碼的RTOS可能會令人不安。其實這兩種方式都能開發出優秀的產品。如果你對RTOS的源代碼大動手腳而不僅僅是作簡單的修改，趕快住手，拿起電話叫技術支持吧。若對RTOS作重大的改動，豈不是違背了購買他人現成實時操作系統的初衷？ 

對那些沒有源代碼的來說，也不必擔心無法配置內核。供應商會在頭文件中給出必要的常量使開發者可以根據需要微調內核。 

許可 
Licensing 

購買某些高級的RTOS屬于重大的商業事務，有許多費用要考慮。典型情況是開發工具的費用由實時操作系統供應商來承擔，并為RTOS發放許可證以開發產品。有的供應商一次性地收取一大筆費用，而有的供應商的收費遍及每用戶、每平臺、每產品、每位置。我干過的項目經歷了這兩個極端。不過說不上這兩種方式哪種更好，只要你明白為什么掏錢就行了。 

聲譽 
Reputation 

還有一點是要了解該RTOS供應商的聲譽。這也許有些困難，這里有一些建議也許有所幫助。 

首先，打電話了解他們。然而供應商肯定怕給你壞印象，因此與真正的用戶交流才能得到對該操作系統質量的較好的認識。下面是一個你應該問的問題清單：
技術支持如何？ 
問題得到解答要多長時間？ 
使操作系統運轉起來要多長時間？ 
你覺得對OS的投資有價值嗎？ 

其次，對該公司作一番調查。下面是一個有助于你評價該公司的問題清單： 
穩定的商務活動開始多久了？ 
公司有多少職員？ 
供應商的網站上有有價值的信息嗎？ 
這種RTOS在哪個行業表現最好？ 
該操作系統為哪些特殊的應用領域做過優化（如安全系統、VME卡、嵌入式PC等）？ 
公司的質量系統狀況如何？ 
公司通過了ISO 9001認證嗎？