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