對許多嵌入式項目來說，系統設計師都傾向於選擇實時操作系統(RTOS)。但RTOS總是必要的嗎?答案是取決於具體的應用，因此瞭解我們要達到什麼目標是決定RTOS是必要的還是花瓶的關鍵。
一般來說，在採用非實時操作系統(non-RTOS)的任何場合，也都可採用RTOS。但是，要找到一款具有完全相同應用編程接口(API)的匹配RTOS就相當困難了。因此，許多傳統的操作系統(OS)在其內嵌入了一個RTOS。例如，Lynux-Works LynxOS和Bluecat Linux共享一個Linux API。LynxOS是一款硬RTOS，而Bluecat是Linux的一個衍生產品。
Linux繼續在努力改善其實時性能，但其最長中斷時延仍無法滿足對RTOS來說至關重要的硬(hard)實時要求。這些問題最後都會歸結爲服務質量(QoS)。像RTLinux Free這樣的平臺補充了Linux，因爲它們可提供硬實時級別的QoS。
要指出的很重要一點是：這類補充常常是在原始OS上集成一個RTOS編程環境。與傳統臺式或服務器OS相比，RTOS通常要小很多。RTOS常常針對更小和資源有限的MCU。例如，CMX的CMX-RTX和CMX-Tiny+可運行在8位MCU到64位處理器上。歡迎轉載,本文來自電子發燒友網(http://www.elecfans.com )
8位處理器不斷增加的計算能力和存儲容量正使得RTOS對這些平臺具有更大吸引力。但是，通常16位或以上平臺才需要OS或RTOS，常見的RTOS選擇有Express Logic的ThreadX、Wind River的VxWorks、Micrium的uCOS-II、以及Green Hills Software的velOSity。取決於需求，MontaVista的Linux可在幾個微秒的水平上滿足16位和32位平臺的要求。
RTOS核心：調度和分割
大多數程序員不熟悉RTOS的限制和要求。大多數人通常因其性能選擇RTOS。大多數RTOS產品代碼少和速度快，現在RTOS還提升了一致性。RTOS除能很快完成任務外，還能保證很好地完成任務。
在許多應用中，一個遲到的結果可以是災難性的。因此，人們寧願在一個要求的時限內獲得較差的結果。這些應用通常被稱爲硬實時系統。硬實時不是指系統響應有多快或多快一個系統能響應，而是指系統能多可靠地滿足特定的要求。
一個硬實時系統可能有一個一分鐘的固定週期時間，它要求的響應時間爲一秒。理論上，這樣的要求幾乎所有的操作系統都能實現。但事實並非總是如此，正如任何一個人都能證明等待臺式計算機應用在一分鐘之內做出響應需要等多久。
硬實時系統通常具有更短的週期時間和更緊苛的響應要求。更快的處理器速度總是有幫助的，多內核平臺也能改善響應速度。對開發人員來說，竅門在於把系統需求與硬件和軟件匹配起來，然後纔是RTOS在嵌入式應用中的重要性。
一個RTOS可以實現一系列調度策略，但應用經常會制約一個程序員的選擇(見表)。非優先式調度(non-preemptive scheduling)的實現雖不重要，但在一些應用中很有用。另一方面，任務內的非優先式調度可在優先式系統的頂部實現。
不應該輕忽非優先式調度，特別在新型多內核處理器出現以後。這裏，硬件可被調整到處理一個基於事件的操作，其中線程將等待外部事件的發生。對處理多線程的單核處理器來說，該方法一般不適用。但對有許多內核的多核系統說，典型情況是爲一個外設指定一個核。所以，在等待事件發生期間，使該核空閒起來是有意義的。
其結果是，優先式、中斷驅動的RTOS架構佔據了業已部署的大部分平臺。雖然藉助硬件手段(多個寄存器組合、硬件調度、任務切換、以及分層中斷優先級系統等)可顯著縮短中斷時延，但該時延永遠是一個問題。
優先式處理會帶來若干問題。它們大多是與時序關聯的，如競爭條件、死循環、空耗等待和優先級轉換，它們發生在低優先級任務A擁有更高優先級任務B的同步資源，而優先級比A高的任務C正在運行。
如果沒有像優先級置頂(priority ceilings)這樣的特性，任務C就可以阻止任務A和任務C運行。優先級置頂特性可以把任務A的優先級改變成與任務C的優先級一樣，從而允許任務A運行並最終釋放任務C所需的資源。至此，任務A的優先級復原，任務C就可以繼續運行。
程序員必須解決的其它與時序相關的問題通常是難以定位和糾正的缺陷源。在定位這些缺陷時跟蹤工具就變成了很有價值的手段，因爲諸如受阻的任務等症候是這些問題的唯一表現形式。
就操作系統所需的特性來看，重入庫(reentrant library)特性在RTOS環境下是可有可無的。但在一個典型的操作系統中，由於任務和程序常常是隨機的和變化的，而且常公用庫，因此重入庫是一個必須的特性。
在嵌入式環境中，對在系統中運行的程序和任務一般會有更多的控制要求。通常，除操作系統接口(可以是重入也可能是非重入的)外，各任務從不共享任何代碼。程序員(特別是那些負責設備驅動程序的)需要注意這一重入性問題。
現在業內已有很多的任務同步機制，從互斥(mutex)到消息系統。從RTOS的角度，這些機制在諸如競爭條件此類的同步問題上，沒有什麼差異。
在MCU和操作系統中，定時器很常見。至少，一個定時器可被用作時鐘。但由於定時器是如此的有用，以至於它常以一種特殊方式實現出來。POSIX規範甚至把定時器定義爲組件。定時器還可當作看門狗來用。
在許多MCU中，一個定時器可以設置用來喚醒處在休眠模式的系統。一些實現允許操作系統把其用作一個通用定時器，儘管這一喚醒特性獨立於操作系統。
一些系統具有帶不同特性的多種定時器來滿足不同的要求。一些定時器可被同步用以爲電機控制應用提供同時的脈寬調製(PWM)流。對RTOS來說，一個定時器通常可用以實現時鐘和提供時間切片支持。
定時器也支持時間切片。時間切片常見於時間共享系統，它給每種應用一個合理的時間片斷來執行。可在任一中斷層級上實現這種輪詢調度。
通常，由時鐘提供的時間切片是固定時長的，每個任務在獲得優先權前將被給予同樣長度的時間切片來執行。當然，該策略是隨機的且可有多種實現。例如，可變的時間切片寬度將允許時間以每個任務爲單位進行分配，其中一些任務獲得的時間會比另一些長;而若採用任務優先級方法，則有可能使低優先級任務得不到響應。
許多RTOS採用固定調度器。其它RTOS則允許替換或定製，但RTOS中的另一部分支持各種策略。這一靈活方法使得像Linux這樣的操作系統能夠提供實時支持，與此同時，它們還能在時間切片環境下運行多種應用。實時任務具有高優先級，且在一般用戶任務前得到執行。
Linux實際上具有一個更復雜的調度系統，它對任務是通過輪詢方法把控制權轉交給具有相同優先級的其它任務還是一直運行到結束做出了具體約定。像Open Kernel Labs的OKL4虛擬化RTOS平臺解決了該問題。
基本通信
一些文獻把任務同步和通信分開來說，但總的來說，它們是一回事。實際上就是講信息是如何交換的。基於消息傳遞的RTOS最清楚地體現出這點。這裏，消息系統處理所有通信且不區分通信和同步。
至少，RTOS必須提供一個相互排斥的本原，如互斥。其它東西可構建在該本原上。在許多場合，如消息傳遞系統，對相互排斥的支持隱藏在操作系統內。只有更高級別的消息功能顯露於外。
消息系統有各種名稱，從管道到隊列。其實現可橫跨從單處理器、單存儲器模式到多內核羣集系統。Enea的OSE RTOS和QNX的Neutrino是基於消息傳遞的兩個主線RTOS。
不管選擇了什麼方法或API，通信系統必須在某一程度上被整合進操作系統。因此，若主動隊列中的任務必須等待一個事件，則該任務可被移走。類似，引發一個事件從而導致另一個任務活動的任務將產生一個調度行爲。
通信、事件和調度可與硬件關聯起來，這是RTOS必須處理的其它一些事。TI的DSP/BIOS是一款RTOS，它設計用於運行在像TI的DaVinci雙核系統的DSP上。DSP/BIOS的一個主要功能是處理 ARM 核和DSP 核間的通信。
向更多大內核的發展將很可能會保留RTOS或OS。不過，小內核阻止或限制了採用RTOS的可能性。Intellasys的SEAforth 40C18芯片帶有40個運行Forth的小型18位內核。指令很精簡，每個字包含四條指令。
每個內核有64個字的 ROM和RAM，該芯片只能容納10,000指令。當然，這隻夠裝下一個程序，安裝RTOS是不可能的。不過，整個芯片上有足夠空間安裝一個操作環境的特定部分。同樣，適於該平臺的應用常常是特定的。於是，由於硬件可處理內核之間通信和任務調度，因此RTOS類的支持並不需要。
資源管理
使RTOS脫穎而出的是其管理資源(包括時間和存儲器)的能力。時序問題與中斷響應時間有關，但資源管理時序問題也會出現。雖然中斷解決了一系列時序問題，但各應用仍必須利用資源。
考慮存儲器分配情況。許多實時應用不採用動態存儲器分配，以確保存儲器分配和回收時所產生的不同不會變成一個問題。需要動態存儲器分配的應用常把存儲器劃分爲實時和非實時。後者處理動態存儲器分配。典型情況下，在使用前，實時部分必須被分配有足夠的存儲器。
在實時嵌入式應用中採用C和C++是因爲存儲器和其它資源的用法是顯式的。實時任務需要避免採用C和C++。特別是，當存儲器分配和回收更容易隱藏時採用C++是很困難的。
像Java和C#這樣的語言帶來的挑戰更大，它們與生俱來地採用動態存儲器分配。程序員可控制存儲器分配和回收。在某些情況下，編程環境可以強化存儲器分配和回收。
Java實時規範(RTSJ)定義了創建不需要垃圾回收的Java應用的方法。RTSJ是在Java框架內這樣做的，從而使程序員在不被存儲器分配限制的條件下享有Java的好處。
Sun和DDC-I都實現了RTSJ。DDC-I的實現支持x86和PowerPC平臺。Aonix有一個稱爲PERC的類似平臺。這些平臺以實時、同時的垃圾回收爲特徵，從而使在不受存儲器分配限制的情況下，在Java內編寫實時應用成爲可能。
但因系統必須允許線程爲垃圾回收器進行轉換，所以實時要求並非那麼緊迫。另一方面，垃圾回收器將耗費時序資源，所以，只有實時任務方可保證滿足一定的期限要求。快是好事，但及時纔是RTOS的天條。
考察實時平臺時，考慮之一是存儲器分配對系統的整體影響。許多系統可工作在從不改變的靜態分配環境，但更多的動態系統可從實時垃圾回收中獲益。研究表明，垃圾回收的效益與確定的存儲器分配是可比的。
圍繞諸如Java和C#等虛擬機類型平臺的另一個問題是對just-in-time(JIT)編譯器的使用限制。基於這些系統的實時系統必須採用類似C和C++等所用的提前(ahead-of time，AOT)編譯器。
設計師會因其更高的生產力、更低的出錯率以及安全性等特點選用Java 或C#。所以，對制定一個稱爲 JSR-302的用於對安全有至高要求應用的Java規範就不足爲奇了。
保護RTOS
RTOS受到其運行的硬件平臺的限制。可對缺少存儲器保護的硬件加以保護，但安全級別會受到限制。但存儲器和虛擬機可以更高水平的安全性支持引導。諸如SE Linux、Green Hills Integrity和 LynuxWorks LynxSecure Embedded Hypervisor以及 LynxOS-SE RTOS內的安全策略可比典型RTOS提供可靠得多的保護。但成本也高，所以開發者需對此進行權衡。
實時系統開發者不得不應對策略實現和邊界問題。取決於信息的來所去處，安全支持會花很長時間。正是爲此引入了分區系統，所以，可在邊界採取安全措施且把應用的非實時部分放在這部分空間內。 可感知OS的調試器
當考慮選用操作系統時，對調試器的支持是個關鍵。這種支持體現在兩個方面：內核和設備驅動器調試以及操作系統感知。
內核調試對設備驅動器的創建和支持以及內核強化很重要。在許多情況，爲處理RTOS的內核，需要專用調試器。它也要求能理解內核環境以及應用環境。
OS感知可更深入地瞭解操作系統。支持方式可以是從提供有關OS服務狀態的信息到調整任務調度等方方面面。同樣，能感知OS的調試器可在停止其它應用或線程的同時允許其它應用或線程的運行。