新聞中心

EEPW首頁 > 嵌入式系統(tǒng) > 設(shè)計應(yīng)用 > 探討選擇實時操作系統(tǒng)(RTOS)的要點

探討選擇實時操作系統(tǒng)(RTOS)的要點

作者: 時間:2013-12-27 來源:網(wǎng)絡(luò) 收藏
對許多嵌入式項目來說,系統(tǒng)設(shè)計師都傾向于選擇(RTOS)。但RTOS總是必要的嗎?答案是取決于具體的應(yīng)用,因此了解我們要達到什么目標是決定RTOS是必要的還是花瓶的關(guān)鍵。

一般來說,在采用非(non-RTOS)的任何場合,也都可采用RTOS。但是,要找到一款具有完全相同應(yīng)用編程接口(API)的匹配RTOS就相當困難了。因此,許多傳統(tǒng)的操作系統(tǒng)(OS)在其內(nèi)嵌入了一個RTOS。例如,Lynux-Works LynxOS和Bluecat 共享一個 API。LynxOS是一款硬RTOS,而Bluecat是的一個衍生產(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ū)動程序的)需要注意這一重入性問題。

linux操作系統(tǒng)文章專題:linux操作系統(tǒng)詳解(linux不再難懂)

上一頁 1 2 下一頁

評論


相關(guān)推薦

技術(shù)專區(qū)

關(guān)閉