姓名：朱碩雅
學號：14020120008
轉載自http://mp.weixin.qq.com/s?__biz=MzAxNDAyMzc0Mg==&mid=2683462191&idx=2&sn=6ffbc07273f118be97e265e21ec5cb26&chksm=819f6f7eb6e8e668f4ae3f11090a3ddc4e984b0217d40590a9b4e6128d66ec903eebbb53cc5e&scene=21#wechat_redirect有修改
【嵌牛導讀】：公司里做項目，嵌入式系統大大小小，到處都是，便需要對實時操作系統（RTOS）引入選擇有初步認識
【嵌牛鼻子】：嵌入式，實時操作系統
【嵌牛提問】：（1）引入RTOS？
? ? ? ? ? ? ? ? ? ? ? ? ?（2）是否需要RTOS？
? ? ? ? ? ? ? ? ? ? ? ? ? （3）如何選擇RTOS？
【嵌牛正文】：
成本主要是 RTOS 的版費、學習成本。這個差別可大了，有些操作系統，如商業的VxWorks、QNX、Lynx、uC/OS，貴啊，但拍了銀子，人家肯定會教您上手的。但很多操作系統，如 FreeRTOS、 RTEMS、ecos、RT-Thread，商業使用幾乎是沒有成本的，也沒有任何的版權問題。撇開這些商業收費的 RTOS 不談，就談這些開源免費的 RTOS，成本主要是學習成本了。如RTEMS這種操作系統就不太好學，資料少，本身的復雜度也高；如 FreeRTOS，小巧，研究的人也多，本身代碼也不復雜，學習曲線不陡峭，很容易爬上去。
可靠性是靠時間沉淀的。市場上不乏一些后起之秀，如rt-thread，相比 rtems 這種鼻祖類的 rtos，還稍顯稚嫩。這并不意味這我們什么都選擇 rtems， 那 rt-thread 怎么發展？對于小型的項目，可以試一試。大型項目，為了減少技術上的風險，還是謹慎為妙。
實時性，這個應該是 RTOS 的看家本領，我初學 rtos 的時候，好喜歡看牛人搞得 RTOS 對比表格。上下文切換時間啊，中斷響應時延啊……總喜歡挑那些時間最小的系統……但后來我知道了，事實上不是幾個對比表格就能說清楚問題的。下面會詳細說到這些問題。
工具鏈，它往往決定我們開發的效率，和最終產品交付的質量。有一些 RTOS 沒那么幸運，沒有讓你選擇工具鏈的權利，就算有，也需要付出很大的代價。如 RTEMS 采用GNU的工具鏈，gnu 的工具鏈不好用，我就嘗試過把 rtems 移到 iar ewarm 下。后來，搞到一半的時候，不得不放棄，付出的精力已經超出了我的承受范圍。但 freeRTOS、uC/OS 這類小 RTOS，只要編譯器支持編譯可重入代碼就可以，這條只有老掉牙的編譯器不行。所以基本上是個C編譯器都可以做Free RTOS、uC/OS的編譯。
模塊豐富，有沒有TCP/IP協議棧、文件系統、CAN協議棧、圖形界面等。當然這個都不是必須的，對于簡單的產品，可能這些模塊都用不到。對于復雜的系統，這些集成好的模塊，會大大節省開發時間。自己也可以移植相關的模塊，可能會有幾個切實的問題不好解決：模塊因為不符合 rtos 的設計思想，會對整體的實時性造成損害；也可能因為模塊使用的庫，和 rtos 使用的庫相沖突……
內核 RAM、ROM 的占用量實際上要求 Rtos 高度可裁剪。不是所有內核裁剪到最后都能滿足要求，RTOS 都有個最低的 RAM、ROM 要求，只剩一些最基本的服務。每加一個特性會增加一些資源，可以查閱相關資料得到這方面信息，確定系統資源可以保證順暢的使用該 RTOS。
支持，如果是商業系統，那不用擔心，既然付了銀子，人家肯定保證實施過程的順暢。如果是開源系統，開發團隊沒有像樣的 rtos 專家可不行。雖然 rtos 系統都是相通的，了解另外一個 rtos 很快，但有時候也不盡然。RTEMS 這么復雜的 RTOS 搞懂了，去弄 freeRTOS、uC/OS、rt-Thread 小麻雀，自然沒問題；要是弄 QNX、VxWorks、Lynx，還是要費點功夫。 RTOS 在開發過程中會遇到很多問題，比如棧的估算、任務優先級的設計、內存的設計、實時性的設計等，都是很不好弄的問題。最好團隊內有相關 RTOS 的專家，要是學習的話無所謂，研發產品和系統的話，那就是大問題了。
（4）幾種嵌入式RTOS的分析與比較
VxWorks是美國WindRiver公司的產品，是目前嵌入式系統領域中應用很廣泛，市場占有率比較高的嵌入式操作系統。VxWorks實時操作系統由400多個相對獨立、短小精悍的目標模塊組成，用戶可根據需要選擇適當的模塊來裁剪和配置系統；提供基于優先級的任務調度、任務間同步與通信、中斷處理、定時器和內存管理等功能，內建符合POSIX(可移植操作系統接口)規范的內存管理，以及多處理器控制程序；并且具有簡明易懂的用戶接口，在核心方面甚至可以微縮到8 KB。
μC/OS-II是美國嵌入式系統專家Jean J．Labrosse用C語言編寫的一個結構小巧、搶占式的多任務實時內核。μC/OS-II能管理64個任務，并提供任務調度與管理、內存管理、任務間同步與通信、時間管理和中斷服務等功能，具有執行效率高、占用空間小、實時性能優良和可擴展性強等特點。
μClinux是一種優秀的嵌入式Linux版本，其全稱為micro-control Linux，從字面意思看是指微控制Linux。同標準的Linux相比，μClinux的內核非常小，但是它仍然繼承了Linux操作系統的主要特性，包括良好的穩定性和移植性、強大的網絡功能、出色的文件系統支持、標準豐富的API，以及TCP／IP網絡協議等。因為沒有MMU內存管理單元，所以其多任務的實現需要一定技巧。
eCos(embedded Configurable operating system)，即嵌入式可配置操作系統。它是一個源代碼開放的可配置、可移植、面向深度嵌入式應用的實時操作系統。最大特點是配置靈活，采用模塊化設計，核心部分由小的組件構成，包括內核、C語言庫和底層運行包等。每個組件可提供大量的配置選項(實時內核也可作為可選配置)，使用eCos提供的配置工具可以很方便地配置，并通過不同的配置使得eCos能夠滿足不同的嵌入式應用要求。
1.5FreeRTOS：
以前對FreeRTOS的印象還不錯，就因為免費，最近上官網仔細看過以后發現它用的是修改版GPL2，商用確實是免費的，但是必須告知用戶你的產品用了FreeRTOS，并且如果用戶要求就必須提供源代碼。
如果要不談我用的什么系統，也不想提供源代碼，就的付費給它，改授權變成OpenRTOS。
還有更好的呢！如果想要更多的功能，更全的協議棧，更完善完整的安全性，請付更多的錢得到SafeRTOS！看個API文檔都要收錢，要其他模塊也要收錢（FS，TCP）。要不就自己費點勁移植吧。另外，功能也比較簡單，只能支持：隊列，信號量和互斥。但是收費版SafeRTOS應該不錯，只是不拿錢就見不著(流明的CM3部分型號內建了SafeRTOS的API，出廠就有可以直接用，這個不錯。)
最小系統：ROM 6K RAM 2K
/*補充內容*/
FreeRTOS和OpenRTOS
FreeRTOS和OpenRTOS的共享相同的源碼，只是 OpenRTOS 為 FreeRTOS 披上’commercial and legal wrapper’‘
用戶從FreeRTOS更新到OpenRTOS主要有兩個原因：
（1）為了克服FreeRTOS修改版的GPL許可證限制。
（2）為了獲得額外的服務，如專業的技術支持，高質量的中間件，培訓，咨詢和相應的工具
FreeRTOS修改版的GPL許可證限制
修改版的GPL許可證有如下幾個缺陷（There are several reasons why developers may find the FreeRTOS modified GPL licence restrictive.）
（1）公司可能有一個全面禁止在他們的項目中使用GPL授權的軟件。
（2）他們可能需要IP賠償。
（3）他們可能更愿意在他們的產品中，避免FreeRTOS的許可證要求承認他們使用FreeRTOS的。
一個OPENRTOS許可證刪除了 修改后的GPL的限制，提供知識產權保障，并允許開發者保持匿名。
FreeRTOS和SafeRTOS
SafeRTOS也是基于FreeRTOS的，但是和FreeRTOS不同，被安全方面的專家做了重新設計。
SAFERTOSwas initially certified in 2007 by TüV SüD to IEC 61508-3 SIL 3, the highest level possible for a software only component.
Today SAFERTOShas grown to be a leading safety critical RTOS solution supporting a wide range of international design safety standards, including:
IndustrialIEC 61508 (2010)
RailwayEN 50128
MedicalIEC 62304/FDA 510K
NuclearIEC 61513, IEC 62138, ASME NQA-1 2008
ProcessIEC 61511
AutomotiveISO 26262
AerospaceDO178B
任務管理、任務及中斷間的同步與通信機制、內存管理、中斷管理、文件系統、對硬件的支持和系統移植這幾方面是實時操作系統的主要性能。下面就從這幾個方面著手對上述4種操作系統進行分析與比較。
任務管理是嵌入式實時操作系統的核心和靈魂，決定了操作系統的實時性能。它通常包含優先級設置、多任務調度機制和時間確定性等部分。
優先級設置
嵌入式操作系統支持多任務，每個任務都具有優先級，任務越重要，賦予的優先級應越高。優先級的設置分為靜態優先級和動態優先級兩種。靜態優先級指的是每個任務在運行前都被賦予一個優先級，而且這個優先級在系統運行期間正常情況下是不能改變的，但允許通過系統調函函數改變任務的優先級；動態優先級則是指每個任務的優先級(特別是應用程序的優先級)在系統運行時可以動態地改變，這種改變是調度算法決定的，而非通過系統調用人為改變的。
多任務調度機制
任務調度主要是協調任務對CPU資源的爭奪使用。對系統資源非常匱乏的嵌入式系統來說，任務調度尤為重要，它直接影響到系統的實時性能。通常，多任務調度機制分為基于優先級搶占式調度和時間片輪轉調度。
基于優先級搶占式調度（PBP，Priority Based and Preemptive）：系統中每個任務都有一個優先級，內核總是將CPU分配給處于就緒態的優先級最高的任務運行。如果系統發現就緒隊列中有比當前運行任務更高的優先級任務，就把當前運行任務置于就緒隊列中，調入高優先級任務運行。系統采用優先級搶占方式進行調度，可以保證重要的突發事件及時得到處理。
時間片輪轉調度（RR，Round Robin） ：讓優先級相同的處于就緒狀態的任務按時間片使用CPU，以防止同優先級的某一任務長時間獨占CPU。
在一般情況下，嵌入式實時操作系統采用基于優先級搶占式調度與時間片輪轉調度相結合的調度機制。
時間的可確定性
嵌入式實時操作系統函數調用與服務的執行時間應具有可確定性。系統服務的執行時間不依賴于應用程序任務的多少。基于此特征，系統完成某個確定任務的時間是可預測的。表1具體列出了4種操作系統的調度機制。
4種嵌入式實時操作系統都支持多任務，只是在支持任務數量上和任務調度機制上有所不同。VxWorks具有高效的任務管理功能，它支持多任務，可分配256個優先級，支持優先級搶占式調試和時間片輪轉調度，實時性最好。μC/OS-II內核是針對實時系統的要求設計實現的，只支持基于固定優先級搶占式調度；調度方法簡單，可以滿足較高的實時性要求。μClinux在結構上繼承了標準Linux的多任務實現方式，分為實時進程和普通進程，分別采用先來先服務和時間片輪轉調度；僅針對中低檔嵌入式CPU特點進行改良，且不支持內核搶占。eCos調度方法豐富，提供了兩種基于優先級的調度器(即位圖調度器和多級隊列調度器)，允許用戶在進行配置時選擇其中一個凋度器，適應性好。
實時操作系統的功能一般要通過若干任務和中斷服務程序共同完成。任務與任務之間、任務與中斷間任務及中斷服務程序之間必須協調動作，互相配合，這就涉及任務間的同步與通信問題。嵌入式實時操作系統通常是通過信號量Semaphere、互斥信號量Mutex、事件標志Event和異步信號Signal來實現同步，通過消息郵箱MailBox、消息隊列沒Message、管道Pipe和共享內存Share Mem來提供通信服務。由于互斥信號量的使用，帶來了實時操作系統中常見的優先級反轉問題。優先級反轉是一種不確定的延遲形式，當高優先級任務企圖訪問已被低優先級占有的共享資源時，必須等待低優先級任務釋放共享資源；如果這時低優先級任務被一個或多個中優先級任務搶占，那么高優先級任務被延遲的時間將更進一步延長，實時性難以保證。因此，應采取相關措施以盡鼉避免出現優先級反轉問題。實時系統通常采用優先級繼承和優先級置頂機制。
優先級繼承是指擁有互斥信號量的任務被提升到與下一個在等待該互斥信號量的最高優先級任務相同的優先級；優先級置頂是指獲得互斥量的任務將其優先級提升到一個事先規定好的值。表2為4種操作系統的同步與通信機制的比較。
4種系統都具有靈話的任務間同步與通信機制，都可以通過信號量、消息隊列來實現同步與通信，但是VxWorks與μClinux都不支持郵箱和事件標志，而且除了μClinux和eCos中的位圖調度器，其他操作系統都采取了措施抑制優先級反轉。
內存管理主要包括：內存分配原則，存儲保護和內存分配方式。
內存分配原則
內存分配原則包括快速性、可靠性和高效性。其中，快速性要求內存分配過程要盡可能快，所以一般采用簡單、快速的分配算法；可靠性指的是內存分配的請求必須得到滿足；系統強調高效性的要求，不僅僅是對系統成本的要求，而且由于系統本身可配置的內存容量也是很有限的，所以要盡可能地避免浪費。嵌入式系統通常會根據特定的需求對內存分配方案進行規劃，從而避免內存碎片。
存儲保護
通常在操作系統的內存中既有系統程序也有用戶程序，為了使兩者都能正常運行，避免程序間相互干擾，需要對內存中的程序和數據進行保護。存儲保護通常需要硬件支持，在很多系統中都采用MMU，并結合軟件實現；但由于嵌入式系統的成本限制內核和用戶程序通常都在相同的內存空間中。因此是否支持存儲保護一方面取決于CPU是否支持MMU及不同的運行級別，如ARM7TDMI核不支持MMU，大多數DSP都不支持MMU和運行級別；另一方面依賴于操作系統是否在軟件上進行支持，uC/OS、eCos等本身就不支持虛擬內存管理。VxWorks也有不同的版本，6.0版本以下就不支持MMU。
內存分配方式
內存分配方式可分為靜態分配和動態分配。靜態分配是在程序運行前一次性分配給相應內存，并且在程序運行期間中不允許再申請或在內存中移動；動態分配則允許在程序運行整個過程中進行內存分配。靜態分配使系統失去了靈活性，但對于實時性要求比較高的系統是必需的，通常情況下這些系統的內存有限，用戶的全局數據都會精心規劃，只有內核本身會使用一些動態內存；而動態分配賦予了系統設計者更多自主性，可以靈活地調整系統的功能。
VxWorks對內存的使用采用的是Flat Mode，可被靜態或動態鏈接。VxWorks為用戶提供了兩種內存區域Region和Partition。Region是變長的內存區，用戶可以從創建的Region中分配Segment，其特點是容易產生碎片，但靈活并且不浪費；Partition是定長的內存區，用戶可以從刨建的Partition中分配Buffer，其特點是不會產生碎片，效率高但是易浪費。VxWorks采用最先算法分配內存。
μC/OS-II把連續的大塊內存按分區來管理，每個分區中都包含整數個大小相同的內存塊，但不同分區之間內存的太小可以不同。用戶動態分配內存時，只須選擇一個適當的分區，按塊來分配內存，釋放時將該塊放回到以前所屬的分區，這樣就消除了因多次動態分配和釋放內存所引起的碎片問題。
μClinux是針對沒有MMU的處理器設計的，不能使用處理器的虛擬內存管理技術，只能采用實存儲器管理策略。系統使用分頁內存分配方式，在啟動時對實際存儲器進行分頁。系統對內存的訪問是直接的，操作系統對內存空間沒有保護，多個進程可共享一個運行空間，所以，即使是一個無特權進程調用一個無效指針也會觸發一個地址錯誤，并有可能引起程序崩潰甚至系統崩潰。
eCos對內存分配既不分段也不分頁，而是采用一種基于內存池的動態內存分配機制。通過兩種內存池來實現兩種內存管理方法：一種是變長的內存池；另一種是定長的內存池，類似于VxWorb的管理方案。表3為4種操作系統內存管理的比較。
中斷管理是實時系統中一個很重要的部分，系統經常通過中斷與外部事件交互。主要考慮是否支持中斷嵌套、中斷處理機制、中斷延時等。
VxWorks的中斷管理
VxWorks操作系統中斷管理采用中斷處理與普通任務分別在不同棧中處理的中斷處理機制，使得中斷只會引發一些關鍵寄存器的存儲，而不會導致任務的上下文切換，從而極大地縮短了中斷延時。同時，VxWorks的中斷處理程序一般在最短時間內通告中斷的發生，而將其他的非實時處理盡量放入被引發的中斷服務任務中來完成，這也縮短了中斷處理的時間，可有效減少中斷延時。所有中斷處理程序使用相同的中斷堆棧。為了能處理最壞情況下的中斷嵌套，必須分配足夠大的中斷堆棧空間。
μC/OS-II的中斷管理
μC/OS-II中斷處理比較簡單。一個中斷向量上只能掛一個中斷服務子程序ISR，而且用戶代碼必須都在ISR中完成。ISR需要做的事情越多，中斷延時也就越長。是否支持中斷嵌套取決于具體實現，如在ARM處理器上當選擇中斷嵌套時需要切換不同的處理器模式，實現起來也比較麻煩。
μClinux的中斷管理
μClinux操作系統將中斷處理分為兩部分：頂半處理和底半處理。在頂半處理中，必須關中斷運行，且僅進行必要的、非常少、速度快的處理，其他處理交給底半處理；底半處理執行那些復雜、耗時的處理，而且允許被中斷。通常在硬件中斷返回的時候會執行底半部的軟中斷，若軟中斷太多則會交給專門的內核處理任務處理，此時中斷返回，避免由于中斷運行時間過長影響其它其他進程。因此在頂半部中斷是不會嵌套的。所有的中斷服務下半部將順序執行。所有的中斷處理程序共用系統堆棧。
eCos的中斷管理
eCos使用了分層式中斷處理機制，把中斷處理分為傳統的ISR和滯后中斷服務程序DSR。類似于μClinux的處理機制，這種機制可以在中斷允許時運行DSR，因此在處理較低優先級中斷時允許高優先級的中斷和處理。為了極大地縮短中斷延時，ISR應當可以快速運行。如果中斷引起的服務量少，則ISR可以單獨處理中斷；如果中斷服務復雜，則ISR只屏蔽中斷源，然后交由DSR處理。
所謂"文件系統"是指負責存取和管理文件信息的機構，也可以說是負責文件的建立、撤銷、組織、讀寫、修改、復制，以及對文件管理所需的其他資源實施管理的軟件部分。
VxWorks操作系統在文件系統與設備驅動程序之間使用一種標準的I/O口操作接口，且支持MS-DOS、RT-11、RFS、CD-ROM、RAW等文件系統。這樣，在單個VxWorks操作系統中可以運行多個相同或不同種類的文件系統。
μC/OS-II是面向中小型嵌入式系統的，即使包含全部功能，編譯后內核也不到10 KB，所以系統本身并沒有提供對文件系統的支持。但是μC/OS-II具有良好的擴展性能，如果需要也可自行加入文件系統的內容。
μClinux繼承了Linux完善的文件系統性能，采用VFS機制，可以支持ROMFS、NFS、ext2、MS-DOS、JFFS等文件系統。但一般采用ROMFS文件系統，這種文件系統相對于一般的文件系統(如ext2)占用更少的空間。但是ROMFS文件系統不支持動態擦寫保存，對于系統需要動態保存的數據須采用虛擬RAM盤／JFFS的方法進行處理。
eCos操作系統的可配置性非常強大，用戶可以自己加入所需的文件系統。
VxWorks、μC/OS-II、μClinux和eCos這4種操作系統都支持當前流行的大部分嵌入式CPU。μC/OS-II支持從8位到32位的CPU，VxWorks、μClinux和eCos可以在16位、32位和64位等不同體系結構之間移植。
由于μClinux繼承了Linux的大部分性能，所以至少需要512KB的RAM空間，lMB的ROM／Flash空間；而μC/OS-II和eCos由于本身內核就很小，經過裁剪后的代碼最小可以分別為2 KB和10 KB，所需的最小數據RAM空間分別為4 KB和10 KB。總的來說，4種系統對硬件的要求比較低，比較經濟。具體比較如表4所列。
嵌入式操作系統移植的目的是使嵌入式操作系統能在某個微處理器或微控制器上運行。4種系統中VxWorks是商用操作系統的有很多API函數及相關技術支持，所以移植和二次開發比較容易，但是移植成本較高。其他3種系統的結構化設計便于把與處理器相關的部分分離出來，所以被移植到新的處理器上也是可能的。μC/OS-II的移植相對比較簡單，只需要修改與處理器相關的代碼就可以了。μClinux是Linux針對嵌入式系統的一種改良，其結構比較復雜。移植μClinux，目標處理器除了應滿足μC/OS-II移植所需的條件外，還需要足夠容量的外部ROM和RAM。eCos系統的可移植性明顯比μC/OS-II和μClinux好。在eCos系統中，每個硬件平臺都有一個單獨的目錄，用于存放引對這一硬件平臺的硬件抽象層的代碼和配置信息；而μClinux的硬件抽象層的代碼則分布在好幾個目錄中，通過命令來選擇不同硬件平臺的代碼。所以，修改eCos代碼相對簡單，移植也相對容易。
這4種嵌入式實時操作系統在嵌入式系統的應用非常廣泛，但是又具有各自的特點。根據上述比較，歸納出各自的適用領域。
VxWorks是一套類似于Unix的實時操作系統，它內建了符合POSIX規范的內存管理，以及多處理器控制程序，并且具有簡明易懂的用戶接口，在核心方面甚至可以微縮到8 KB。它由400多個相對獨立的、短小精悍的目標模塊組成，用戶可根據需要選擇適當模塊來裁剪和配置系統，有效地保證了系統的安全性和可靠性。它被廣泛地應用在通信、軍事、航空、航天等高尖技術及實時性要求極高的領域，尤其是在許多關鍵應用方面，VxWorks還是一枝獨秀。例如，美國波音公司就在其最新的787客機中采用了此操作系統；而在外層空間探索領域，VxWorks則一直是美國太空總署NASA的最愛。
μC/OS-II是一個結構簡單、功能完備和實時性很強的嵌入式操作系統內核，適合于廣大的嵌入式系統開發人員和愛好者入門學習，以及高校教學和科研。μC/OS-II很適合開發那些對系統要求不是很苛刻，且RAM和ROM有限的各種小型嵌入式系統設備。
μClinux最大特點在于針對無MMU處理器設計，可以利用功能強大的Linux資源，因此適合開發對時間要求不高的小容量、低成本的各類產品，特別適用于開發與網絡應用密切相關的嵌入式設備或者PDA設備。例如，CISCO公司的2500／3000／4000路由器就是基于μClinux操作系統開發的。
eCos最大特點是配置靈活，而且是面向深度嵌入式應用的，很適合用于一些商業級或工業級對成本敏感的嵌入式系統，例如消費電子類領域中的一些應用。
