對許多嵌入式項目來說,，系統(tǒng)設(shè)計師都傾向于選擇實時操作系統(tǒng)(RTOS),。但RTOS總是必要的嗎?答案是取決于具體的應(yīng)用，因此了解我們要達到什么目標是決定RTOS是必要的還是花瓶的關(guān)鍵,。

一般來說,，在采用非實時操作系統(tǒng)(non-RTOS)的任何場合，也都可采用RTOS,。但是,，要找到一款具有完全相同應(yīng)用編程接口(API)的匹配RTOS就相當困難了。因此,，許多傳統(tǒng)的操作系統(tǒng)(OS)在其內(nèi)嵌入了一個RTOS,。例如，Lynux-Works LynxOS和Bluecat Linux共享一個Linux API,。LynxOS是一款硬RTOS,，而Bluecat是Linux的一個衍生產(chǎn)品。

Linux繼續(xù)在努力改善其實時性能,，但其最長中斷時延仍無法滿足對RTOS來說至關(guān)重要的硬(hard)實時要求,。這些問題最后都會歸結(jié)為服務(wù)質(zhì)量(QoS)。像RTLinux Free這樣的平臺補充了Linux,，因為它們可提供硬實時級別的QoS,。

要指出的很重要一點是：這類補充常常是在原始OS上集成一個RTOS編程環(huán)境,。與傳統(tǒng)臺式或服務(wù)器OS相比，RTOS通常要小很多,。RTOS常常針對更小和資源有限的MCU,。例如，CMX的CMX-RTX和CMX-Tiny+可運行在8位MCU到64位處理器上,。

8位處理器不斷增加的計算能力和存儲容量正使得RTOS對這些平臺具有更大吸引力,。但是，通常16位或以上平臺才需要OS或RTOS,，常見的RTOS選擇有Express Logic的ThreadX,、Wind River的VxWorks、Micrium的uCOS-II,、以及Green Hills Software的velOSity,。取決于需求，MontaVista的Linux可在幾個微秒的水平上滿足16位和32位平臺的要求,。

RTOS核心：調(diào)度和分割

大多數(shù)程序員不熟悉RTOS的限制和要求,。大多數(shù)人通常因其性能選擇RTOS。大多數(shù)RTOS產(chǎn)品代碼少和速度快,，現(xiàn)在RTOS還提升了一致性,。RTOS除能很快完成任務(wù)外，還能保證很好地完成任務(wù),。

在許多應(yīng)用中,，一個遲到的結(jié)果可以是災(zāi)難性的。因此,，人們寧愿在一個要求的時限內(nèi)獲得較差的結(jié)果,。這些應(yīng)用通常被稱為硬實時系統(tǒng)。硬實時不是指系統(tǒng)響應(yīng)有多快或多快一個系統(tǒng)能響應(yīng),，而是指系統(tǒng)能多可靠地滿足特定的要求,。

一個硬實時系統(tǒng)可能有一個一分鐘的固定周期時間，它要求的響應(yīng)時間為一秒,。理論上,，這樣的要求幾乎所有的操作系統(tǒng)都能實現(xiàn)。但事實并非總是如此,，正如任何一個人都能證明等待臺式計算機應(yīng)用在一分鐘之內(nèi)做出響應(yīng)需要等多久。

硬實時系統(tǒng)通常具有更短的周期時間和更緊苛的響應(yīng)要求,。更快的處理器速度總是有幫助的,，多內(nèi)核平臺也能改善響應(yīng)速度。對開發(fā)人員來說,，竅門在于把系統(tǒng)需求與硬件和軟件匹配起來,，然后才是RTOS在嵌入式應(yīng)用中的重要性,。

一個RTOS可以實現(xiàn)一系列調(diào)度策略，但應(yīng)用經(jīng)常會制約一個程序員的選擇(見表),。非優(yōu)先式調(diào)度(non-preemptive scheduling)的實現(xiàn)雖不重要,，但在一些應(yīng)用中很有用。另一方面,，任務(wù)內(nèi)的非優(yōu)先式調(diào)度可在優(yōu)先式系統(tǒng)的頂部實現(xiàn),。

不應(yīng)該輕忽非優(yōu)先式調(diào)度，特別在新型多內(nèi)核處理器出現(xiàn)以后,。這里,，硬件可被調(diào)整到處理一個基于事件的操作，其中線程將等待外部事件的發(fā)生,。對處理多線程的單核處理器來說,，該方法一般不適用。但對有許多內(nèi)核的多核系統(tǒng)說,，典型情況是為一個外設(shè)指定一個核,。所以，在等待事件發(fā)生期間,，使該核空閑起來是有意義的,。

其結(jié)果是，優(yōu)先式,、中斷驅(qū)動的RTOS架構(gòu)占據(jù)了業(yè)已部署的大部分平臺,。雖然借助硬件手段(多個寄存器組合、硬件調(diào)度,、任務(wù)切換,、以及分層中斷優(yōu)先級系統(tǒng)等)可顯著縮短中斷時延，但該時延永遠是一個問題,。

優(yōu)先式處理會帶來若干問題,。它們大多是與時序關(guān)聯(lián)的，如競爭條件,、死循環(huán),、空耗等待和優(yōu)先級轉(zhuǎn)換，它們發(fā)生在低優(yōu)先級任務(wù)A擁有更高優(yōu)先級任務(wù)B的同步資源,，而優(yōu)先級比A高的任務(wù)C正在運行,。

如果沒有像優(yōu)先級置頂(priority ceilings)這樣的特性，任務(wù)C就可以阻止任務(wù)A和任務(wù)C運行,。優(yōu)先級置頂特性可以把任務(wù)A的優(yōu)先級改變成與任務(wù)C的優(yōu)先級一樣,，從而允許任務(wù)A運行并最終釋放任務(wù)C所需的資源。至此，任務(wù)A的優(yōu)先級復(fù)原,，任務(wù)C就可以繼續(xù)運行,。

程序員必須解決的其它與時序相關(guān)的問題通常是難以定位和糾正的缺陷源。在定位這些缺陷時跟蹤工具就變成了很有價值的手段,，因為諸如受阻的任務(wù)等癥候是這些問題的唯一表現(xiàn)形式,。

就操作系統(tǒng)所需的特性來看，重入庫(reentrant library)特性在RTOS環(huán)境下是可有可無的,。但在一個典型的操作系統(tǒng)中,，由于任務(wù)和程序常常是隨機的和變化的，而且常公用庫,，因此重入庫是一個必須的特性,。

在嵌入式環(huán)境中，對在系統(tǒng)中運行的程序和任務(wù)一般會有更多的控制要求,。通常,，除操作系統(tǒng)接口(可以是重入也可能是非重入的)外，各任務(wù)從不共享任何代碼,。程序員(特別是那些負責設(shè)備驅(qū)動程序的)需要注意這一重入性問題,。

現(xiàn)在業(yè)內(nèi)已有很多的任務(wù)同步機制，從互斥(mutex)到消息系統(tǒng),。從RTOS的角度,，這些機制在諸如競爭條件此類的同步問題上，沒有什么差異,。

在MCU和操作系統(tǒng)中,，定時器很常見。至少,，一個定時器可被用作時鐘,。但由于定時器是如此的有用，以至于它常以一種特殊方式實現(xiàn)出來,。POSIX規(guī)范甚至把定時器定義為組件,。定時器還可當作看門狗來用。

在許多MCU中,，一個定時器可以設(shè)置用來喚醒處在休眠模式的系統(tǒng),。一些實現(xiàn)允許操作系統(tǒng)把其用作一個通用定時器，盡管這一喚醒特性獨立于操作系統(tǒng),。

一些系統(tǒng)具有帶不同特性的多種定時器來滿足不同的要求,。一些定時器可被同步用以為電機控制應(yīng)用提供同時的脈寬調(diào)制(PWM)流。對RTOS來說,，一個定時器通?？捎靡詫崿F(xiàn)時鐘和提供時間切片支持,。

定時器也支持時間切片。時間切片常見于時間共享系統(tǒng),，它給每種應(yīng)用一個合理的時間片斷來執(zhí)行?？稍谌我恢袛鄬蛹壣蠈崿F(xiàn)這種輪詢調(diào)度,。

通常，由時鐘提供的時間切片是固定時長的,，每個任務(wù)在獲得優(yōu)先權(quán)前將被給予同樣長度的時間切片來執(zhí)行,。當然，該策略是隨機的且可有多種實現(xiàn),。例如,，可變的時間切片寬度將允許時間以每個任務(wù)為單位進行分配，其中一些任務(wù)獲得的時間會比另一些長;而若采用任務(wù)優(yōu)先級方法,，則有可能使低優(yōu)先級任務(wù)得不到響應(yīng),。

許多RTOS采用固定調(diào)度器。其它RTOS則允許替換或定制,，但RTOS中的另一部分支持各種策略,。這一靈活方法使得像Linux這樣的操作系統(tǒng)能夠提供實時支持，與此同時,，它們還能在時間切片環(huán)境下運行多種應(yīng)用,。實時任務(wù)具有高優(yōu)先級，且在一般用戶任務(wù)前得到執(zhí)行,。

Linux實際上具有一個更復(fù)雜的調(diào)度系統(tǒng),，它對任務(wù)是通過輪詢方法把控制權(quán)轉(zhuǎn)交給具有相同優(yōu)先級的其它任務(wù)還是一直運行到結(jié)束做出了具體約定。像Open Kernel Labs的OKL4虛擬化RTOS平臺解決了該問題,。

基本通信

一些文獻把任務(wù)同步和通信分開來說,，但總的來說，它們是一回事,。實際上就是講信息是如何交換的,。基于消息傳遞的RTOS最清楚地體現(xiàn)出這點,。這里,，消息系統(tǒng)處理所有通信且不區(qū)分通信和同步。

至少,，RTOS必須提供一個相互排斥的本原,，如互斥。其它東西可構(gòu)建在該本原上,。在許多場合,，如消息傳遞系統(tǒng),，對相互排斥的支持隱藏在操作系統(tǒng)內(nèi)。只有更高級別的消息功能顯露于外,。

消息系統(tǒng)有各種名稱,，從管道到隊列。其實現(xiàn)可橫跨從單處理器,、單存儲器模式到多內(nèi)核群集系統(tǒng),。Enea的OSE RTOS和QNX的Neutrino是基于消息傳遞的兩個主線RTOS。

不管選擇了什么方法或API,，通信系統(tǒng)必須在某一程度上被整合進操作系統(tǒng),。因此，若主動隊列中的任務(wù)必須等待一個事件,，則該任務(wù)可被移走,。類似，引發(fā)一個事件從而導(dǎo)致另一個任務(wù)活動的任務(wù)將產(chǎn)生一個調(diào)度行為,。

通信,、事件和調(diào)度可與硬件關(guān)聯(lián)起來，這是RTOS必須處理的其它一些事,。TI的DSP/BIOS是一款RTOS,，它設(shè)計用于運行在像TI的DaVinci雙核系統(tǒng)的DSP上。DSP/BIOS的一個主要功能是處理 ARM 核和DSP 核間的通信,。

向更多大內(nèi)核的發(fā)展將很可能會保留RTOS或OS,。不過，小內(nèi)核阻止或限制了采用RTOS的可能性,。Intellasys的SEAforth 40C18芯片帶有40個運行Forth的小型18位內(nèi)核,。指令很精簡，每個字包含四條指令,。

每個內(nèi)核有64個字的 ROM和RAM,，該芯片只能容納10,000指令。當然,，這只夠裝下一個程序,，安裝RTOS是不可能的。不過,，整個芯片上有足夠空間安裝一個操作環(huán)境的特定部分,。同樣，適于該平臺的應(yīng)用常常是特定的,。于是,，由于硬件可處理內(nèi)核之間通信和任務(wù)調(diào)度，因此RTOS類的支持并不需要,。

資源管理

使RTOS脫穎而出的是其管理資源(包括時間和存儲器)的能力,。時序問題與中斷響應(yīng)時間有關(guān),，但資源管理時序問題也會出現(xiàn)。雖然中斷解決了一系列時序問題,，但各應(yīng)用仍必須利用資源,。

考慮存儲器分配情況。許多實時應(yīng)用不采用動態(tài)存儲器分配,，以確保存儲器分配和回收時所產(chǎn)生的不同不會變成一個問題,。需要動態(tài)存儲器分配的應(yīng)用常把存儲器劃分為實時和非實時。后者處理動態(tài)存儲器分配,。典型情況下，在使用前,，實時部分必須被分配有足夠的存儲器,。

在實時嵌入式應(yīng)用中采用C和C++是因為存儲器和其它資源的用法是顯式的。實時任務(wù)需要避免采用C和C++,。特別是,，當存儲器分配和回收更容易隱藏時采用C++是很困難的。

像Java和C#這樣的語言帶來的挑戰(zhàn)更大,，它們與生俱來地采用動態(tài)存儲器分配,。程序員可控制存儲器分配和回收。在某些情況下,，編程環(huán)境可以強化存儲器分配和回收,。

Java實時規(guī)范(RTSJ)定義了創(chuàng)建不需要垃圾回收的Java應(yīng)用的方法。RTSJ是在Java框架內(nèi)這樣做的,，從而使程序員在不被存儲器分配限制的條件下享有Java的好處,。

Sun和DDC-I都實現(xiàn)了RTSJ。DDC-I的實現(xiàn)支持x86和PowerPC平臺,。Aonix有一個稱為PERC的類似平臺,。這些平臺以實時、同時的垃圾回收為特征,，從而使在不受存儲器分配限制的情況下,，在Java內(nèi)編寫實時應(yīng)用成為可能。

但因系統(tǒng)必須允許線程為垃圾回收器進行轉(zhuǎn)換,，所以實時要求并非那么緊迫,。另一方面，垃圾回收器將耗費時序資源,，所以,，只有實時任務(wù)方可保證滿足一定的期限要求?？焓呛檬?，但及時才是RTOS的天條,。

考察實時平臺時，考慮之一是存儲器分配對系統(tǒng)的整體影響,。許多系統(tǒng)可工作在從不改變的靜態(tài)分配環(huán)境,，但更多的動態(tài)系統(tǒng)可從實時垃圾回收中獲益。研究表明,，垃圾回收的效益與確定的存儲器分配是可比的,。

圍繞諸如Java和C#等虛擬機類型平臺的另一個問題是對just-in-time(JIT)編譯器的使用限制?；谶@些系統(tǒng)的實時系統(tǒng)必須采用類似C和C++等所用的提前(ahead-of time,，AOT)編譯器。

設(shè)計師會因其更高的生產(chǎn)力,、更低的出錯率以及安全性等特點選用Java 或C#,。所以，對制定一個稱為 JSR-302的用于對安全有至高要求應(yīng)用的Java規(guī)范就不足為奇了,。

保護RTOS

RTOS受到其運行的硬件平臺的限制,。可對缺少存儲器保護的硬件加以保護,，但安全級別會受到限制,。但存儲器和虛擬機可以更高水平的安全性支持引導(dǎo)。諸如SE Linux,、Green Hills Integrity和 LynuxWorks LynxSecure Embedded Hypervisor以及 LynxOS-SE RTOS內(nèi)的安全策略可比典型RTOS提供可靠得多的保護,。但成本也高，所以開發(fā)者需對此進行權(quán)衡,。

實時系統(tǒng)開發(fā)者不得不應(yīng)對策略實現(xiàn)和邊界問題,。取決于信息的來所去處，安全支持會花很長時間,。正是為此引入了分區(qū)系統(tǒng),，所以，可在邊界采取安全措施且把應(yīng)用的非實時部分放在這部分空間內(nèi),。

可感知OS的調(diào)試器

當考慮選用操作系統(tǒng)時,，對調(diào)試器的支持是個關(guān)鍵。這種支持體現(xiàn)在兩個方面：內(nèi)核和設(shè)備驅(qū)動器調(diào)試以及操作系統(tǒng)感知,。

內(nèi)核調(diào)試對設(shè)備驅(qū)動器的創(chuàng)建和支持以及內(nèi)核強化很重要,。在許多情況，為處理RTOS的內(nèi)核,，需要專用調(diào)試器,。它也要求能理解內(nèi)核環(huán)境以及應(yīng)用環(huán)境。

OS感知可更深入地了解操作系統(tǒng),。支持方式可以是從提供有關(guān)OS服務(wù)狀態(tài)的信息到調(diào)整任務(wù)調(diào)度等方方面面,。同樣,，能感知OS的調(diào)試器可在停止其它應(yīng)用或線程的同時允許其它應(yīng)用或線程的運行。