Linux 暴風雨般占領了嵌入式系統市場。分析家指出，大約有1/3到1/2的32/64位新的嵌入式系統設計采用了Linux。嵌入式 Linux 已經在很多應用領域顯示出優勢，比如SOHO家庭網絡和成像/多功能外設。在（NAS/SAN）存儲，家庭數字娛樂（HDTV/PVR/DVR /STB），和手持設備/無線設備，特別是數字移動電話更獲得大幅度發展。

嵌 入式Linux新應用不會憑空從開發者的頭腦中冒出來，大部分項目都是由成千上萬行，甚至數百萬行的代碼組成。成千上百的嵌入式項目已經成功地將現有的其 它平臺的代碼移植到Linux下，比如Wind River VxWorks 和 pSOS， VRTX， Nucleus 和其它RTOS。這些移植工作有著重要的價值和現實意義。

到 目前為止，大多數關于移植已有的RTOS應用到嵌入式Linux的文獻，關注RTOS 接口（API）、任務、調度模式以及怎樣將他們映射到相應得用戶空間去。同樣重要的是，在I/O調用密集的嵌入式程序中如何將RTOS的硬件接口代碼移植 到更加規范的Linux設備驅動程序中去。

本 文將概述幾種常用的經常出現于現有嵌入式應用中的內存映射I/O方法。它們涵蓋的范圍從對中斷服務例程的特殊使用及用戶線程對硬件訪問到出現于有些 ROTS中的半規范化驅動程序模型。這對于移植RTOS 代碼到規范化的Linux設備啟動程序具有一定啟發作用，并且介紹了一些移植方法。特別地，本文會重點討論RTOS和Linux中的內存映射，基于I/O 調度隊列的移植，將RTOS I/O重定義到Linux下的驅動程序和守護進程里。

RTOS I/O 概念

“ 不規范”是描述大多數RTOS系統I/O的最佳詞語。多數RTOS是針對較早的無MMU的CPU而設計，所以忽略了內存管理部分，即使當MMU問世后也是 這樣：不區分物理地址和邏輯地址。大多數 RTOS還全部運行在特權模式，雖然表面上看來是增強了性能。全部的RTOS 應用和系統代碼都能夠訪問整個地址空間、內存映射過的設備、以及其他I/O操作。這樣，即使存在差別，也是很難把RTOS應用程序代碼同驅動程序代碼區分 開來。

不規范的結構導致了I/O實現的特殊性。在很多情況下，缺乏設備驅動程序模型的認同。根據這種無層次的特性，回顧一下基于RTOS軟件中使用的一些重要概念和習慣用法非常有指導意義。

內嵌的內存訪問

上 個世紀八十年代中期商業化的RTOS產品中，多數嵌入式軟件都有一個對執行時間有嚴格需求的，采用I/O查詢和中斷服務例程的大循環。開發人員在項目采用 RTOS和執行程序，主要為了加強并行性和多任務同步，繞開其它有礙實現該目標的程序結構。這樣，即使RTOS提供了I/O 調用形式化方法，嵌入式程序員繼續使用直接的I/O操作：

#define DATA_REGISTER 0xF00000F5

char getchar（void） {

return （*（（char *） DATA_REGISTER））; /* read from port */

}

void putchar（char c） {

*（（char *） DATA_REGISTER） = c; /* write to port */

}

多數受過訓練的開發者常會將這樣的直接I/O代碼從硬件代碼中分離開來。但是我還是經常看到諸如此類的I/O調用代碼。

當 開始使用直接內存映射I/O的時候，新接觸Linux的嵌入式開發人員總是想把這類代碼移到用戶空間，通過mmap（）調用來替代定義寄存器地址 的#define 語句。這種處理方法對于一些原型是可以的，但不能支持中斷處理，限制了實時響應，特別不安全，不適合商業化產品的發布。

RTOS 中斷服務例程

在 Linux里， 中斷服務屬于內核層; 在一個 RTOS里， 中斷服務例程代碼沒有特殊規定且常與應用程序代碼沒什么區別（不外乎返回序列異同）。很多 RTOS提供系統調用或者宏來讓代碼自己檢測它自己的切換狀態（比如 Wind River VxWorks的 intContext（））。中斷服務例程通常也使用標準的庫函數，隨之而來也有可重入性和移植性等問題。

大多數RTOS支持注冊中斷服務例程代碼、中斷判斷和中斷服務調用。一些簡單的嵌入式程序，僅僅支持在硬件矢量表里插入中斷服務例程的起始地址。

如果試圖直接在用戶程序空間執行讀和寫操作，你不得不將Linux中斷服務例程放入內核程序空間。