Linux暴風雨般占領了嵌入式系統(tǒng)市場。分析家指出，大約有1/3到1/2的32/64位新的嵌入式系統(tǒng)設計采用了Linux。嵌入式Linux已經(jīng)在很多應用領域顯示出優(yōu)勢，比如SOHO家庭網(wǎng)絡和成像/多功能外設。在(NAS/SAN)存儲，家庭數(shù)字娛樂(HDTV/PVR/DVR/STB)，和手持設備/無線設備，特別是數(shù)字移動電話更獲得大幅度發(fā)展。
嵌入式Linux新應用不會憑空從開發(fā)者的頭腦中冒出來，大部分項目都是由成千上萬行，甚至數(shù)百萬行的代碼組成。成千上百的嵌入式項目已經(jīng)成功地將現(xiàn)有的其它平臺的代碼移植到Linux下，比如WindRiverVxWorks和pSOS，VRTX，Nucleus和其它RTOS。這些移植工作有著重要的價值和現(xiàn)實意義。
到目前為止，大多數(shù)關于移植已有的RTOS應用到嵌入式Linux的文獻，關注RTOS接口（API）、任務、調度模式以及怎樣將他們映射到相應得用戶空間去。同樣重要的是，在I/O調用密集的嵌入式程序中如何將RTOS的硬件接口代碼移植到更加規(guī)范的Linux設備驅動程序中去。
本文將概述幾種常用的經(jīng)常出現(xiàn)于現(xiàn)有嵌入式應用中的內存映射I/O方法。它們涵蓋的范圍從對中斷服務例程的特殊使用及用戶線程對硬件訪問到出現(xiàn)于有些ROTS中的半規(guī)范化驅動程序模型。這對于移植RTOS代碼到規(guī)范化的Linux設備啟動程序具有一定啟發(fā)作用，并且介紹了一些移植方法。特別地，本文會重點討論RTOS和Linux中的內存映射，基于I/O調度隊列的移植，將RTOSI/O重定義到Linux下的驅動程序和守護進程里。
RTOSI/O概念
“不規(guī)范”是描述大多數(shù)RTOS系統(tǒng)I/O的最佳詞語。多數(shù)RTOS是針對較早的無MMU的CPU而設計，所以忽略了內存管理部分，即使當MMU問世后也是這樣：不區(qū)分物理地址和邏輯地址。大多數(shù)RTOS還全部運行在特權模式，雖然表面上看來是增強了性能。全部的RTOS應用和系統(tǒng)代碼都能夠訪問整個地址空間、內存映射過的設備、以及其他I/O操作。這樣，即使存在差別，也是很難把RTOS應用程序代碼同驅動程序代碼區(qū)分開來。
不規(guī)范的結構導致了I/O實現(xiàn)的特殊性。在很多情況下，缺乏設備驅動程序模型的認同。根據(jù)這種無層次的特性，回顧一下基于RTOS軟件中使用的一些重要概念和習慣用法非常有指導意義。
內嵌的內存訪問
上個世紀八十年代中期商業(yè)化的RTOS產(chǎn)品中，多數(shù)嵌入式軟件都有一個對執(zhí)行時間有嚴格需求的，采用I/O查詢和中斷服務例程的大循環(huán)。開發(fā)人員在項目采用RTOS和執(zhí)行程序，主要為了加強并行性和多任務同步，繞開其它有礙實現(xiàn)該目標的程序結構。這樣，即使RTOS提供了I/O調用形式化方法，嵌入式程序員繼續(xù)使用直接的I/O操作：
#defineDATA_REGISTER0xF00000F5
chargetchar(void){
return(*((char*)DATA_REGISTER));/*readfromport*/
}
voidputchar(charc){
*((char*)DATA_REGISTER)=c;/*writetoport*/
}
多數(shù)受過訓練的開發(fā)者常會將這樣的直接I/O代碼從硬件代碼中分離開來。但是我還是經(jīng)常看到諸如此類的I/O調用代碼。
當開始使用直接內存映射I/O的時候，新接觸Linux的嵌入式開發(fā)人員總是想把這類代碼移到用戶空間，通過mmap()調用來替代定義寄存器地址的#define語句。這種處理方法對于一些原型是可以的，但不能支持中斷處理，限制了實時響應，特別不安全，不適合商業(yè)化產(chǎn)品的發(fā)布。
RTOS中斷服務例程
在Linux里，中斷服務屬于內核層;在一個RTOS里，中斷服務例程代碼沒有特殊規(guī)定且常與應用程序代碼沒什么區(qū)別（不外乎返回序列異同）。很多RTOS提供系統(tǒng)調用或者宏來讓代碼自己檢測它自己的切換狀態(tài)（比如WindRiverVxWorks的intContext()）。中斷服務例程通常也使用標準的庫函數(shù)，隨之而來也有可重入性和移植性等問題。
大多數(shù)RTOS支持注冊中斷服務例程代碼、中斷判斷和中斷服務調用。一些簡單的嵌入式程序，僅僅支持在硬件矢量表里插入中斷服務例程的起始地址。
如果試圖直接在用戶程序空間執(zhí)行讀和寫操作，你不得不將Linux中斷服務例程放入內核程序空間。
RTOSI/O子系統(tǒng)
大多數(shù)RTOS會提供一個定制的標準C運行庫(比如pSOS的pREPC)，或者修改編譯器提供商的C庫(libc)或修改glibc。在盡量最小化情況下，多數(shù)的RTOS支持標準C的I/O子集(open/close/read/write/ioctl)。大多數(shù)情況下，這些調用和從衍生出來的調用轉化為基本I/O簡單封裝。有趣的是，因為大多數(shù)的RTOS不支持文件系統(tǒng)，這些平臺不提供針對flash和其他存儲介質的文件存儲，常采用完全不同的代碼實現(xiàn)或者其他應用程序接口(API)(比如pSOS的pHILE)。
WindRiverVxWorks在這方面比其它RTOS做得好些，它提供功能豐富的I/O子集，有效廣泛集成網(wǎng)絡接口及網(wǎng)絡媒體。
延時處理
很多RTOS也支持一種叫”下半部“("bottomhalf")的機制，把I/O處理放到可中斷或者可搶占切換上下文中執(zhí)行。其他RTOS提供類似機制比如中斷嵌套來獲得同樣的效果。
典型RTOS應用的I/O架構
下面描述一個典型的I/O圖解(僅輸入)和它向主應用程序傳遞數(shù)據(jù)的路徑，處理過程如下：
·一個硬件中斷觸發(fā)一個中斷服務例程執(zhí)行。
·中斷服務例程做基本處理，完成本地輸入操作，或者讓RTOS調度延時處理。在一些情況下，延時處理過程由Linux里的用戶進程來處理，在這里就是普通的RTOS任務。
·當獲取到數(shù)據(jù)(中斷服務例程或者延時切換)，準備好的數(shù)據(jù)被放進隊列(RTOS中斷服務例程能夠訪問應用程序隊列通過應用程序接口(API)和其它進程間通信(IPC)，請看下面的API表)。
·一個或者多個應用任務從隊列讀消息取出數(shù)據(jù)
傳統(tǒng)的RTOS和Linux的典型I/O比較
輸出常常由類似的機制來完成-代替write()或者相似的系統(tǒng)調用，一個或者多個RTOS任務，將數(shù)據(jù)放進隊列。隊列中的數(shù)據(jù)由以下幾種過程取出：一個I/O程序或者響應“準備好發(fā)送”中斷的中斷服務例程，一個系統(tǒng)時鐘，或者其它阻塞在取數(shù)據(jù)隊列中的應用任務，然后執(zhí)行I/O操作(可以是輪詢，也可以是通過DMA)。[!--empirenews.page--]
將RTOSI/O映射到Linux中
上面描述的基于隊列的生產(chǎn)者/消費者I/O模型，僅僅是傳統(tǒng)多種設計中所采用的特別方法的一種。讓我們繼續(xù)用這個直接的例子，來討論幾種在嵌入式Linux下的實現(xiàn)方法：
大規(guī)模移植到用戶空間
對于只是初步了解Linux設備驅動設計，或者沒有經(jīng)驗的開發(fā)者，可能將大多數(shù)這種基于隊列的程序原封不動地移植到用戶空間。在這種驅動程序映射中，內存映射通過函數(shù)mmap()提供的指針可以在用戶空間操作物理I/O接口。
#include
#defineREG_SIZE0x4/*deviceregistersize*/
#defineREG_OFFSET0xFA400000
/*physicaladdressofdevice*/
void*mem_ptr;/*de-referenceformemory-mappedaccess*/
intfd;
fd=open("/dev/mem"，O_RDWR);/*openphysicalmemory(mustberoot)*/
mem_ptr=mmap((void*)0x0，REG_AREA_SIZE，PROT_READ+PROT_WRITE，
MAP_SHARED，fd，REG_OFFSET);
/*actualcalltommap()*/
一個進程下的用戶線程運行類似RTOS的中斷服務例程或延時任務一樣的操作，然后使用SVR4進程間通信函數(shù)msgsnd()將消息放進隊列，等待被另一個本地線程或者另一個進程利用函數(shù)msgrcv()獲取。
這種快速缺乏技巧的處理方法是一種較好的原型，但同時給代碼模型建立帶來了巨大的挑戰(zhàn)。首先重要的是要在用戶空間掃描中斷。象DOSEMU項目提供基于信號的I/O中斷方式，但用戶空間的中斷處理過程非常慢(一般毫秒級中斷延時相較內核中斷服務例程數(shù)十微秒中斷延時)。進一步講，即使采用可搶占Linux內核，和實時調度策略，用戶空間的切換調度不能保證I/O線程100%的及時得到執(zhí)行。
下載文檔
