1、概述 在嵌入式應用系統(tǒng)中使用嵌入式操作系統(tǒng)可以提高應用系統(tǒng)的開發(fā)效率和提升嵌入式應用系統(tǒng)的穩(wěn)定可靠性，因此，在嵌入式應用系統(tǒng)中使用嵌入式操作系統(tǒng)將成為嵌入式應用系統(tǒng)的設計主流[1]。μC/OS-II是由美國學者Labrosse設計的一個優(yōu)秀的嵌入式實時操作系統(tǒng)[2]，它是一個源碼公開、可移植、可固化、可裁剪、占先式的實時多任務操作系統(tǒng)，目前已經(jīng)得到廣泛應用。 μC/OS-II提供了操作系統(tǒng)必須具備的基本功能，包括：任務管理、信號量管理、郵箱管理、消息隊列管理、事件管理、時間管理、內存管理，但它不提供設備管理和文件系統(tǒng)管理，已有研究者對μC/OS-II進行了文件子系統(tǒng)功能擴展[3]。在實際應用中，對系統(tǒng)設備的有效管理也是一個非常重要的任務，因此，需要對μC/OS-II進行擴展，以實現(xiàn)這一功能。本文為μC/OS-II設計了一個對系統(tǒng)設備進行統(tǒng)一管理的通用驅動框架，在此框架下，可以屏蔽系統(tǒng)硬件的差異，在無約束地發(fā)揮硬件能力的前提下，為上層應用提供了統(tǒng)一、一致的調用接口API，從而實現(xiàn)了對系統(tǒng)設備的有效管理。 2、μC/OS-II下通用驅動框架的基本模型 為了給上層應用提供統(tǒng)一、一致的系統(tǒng)設備調用接口，需要對上層應用程序對系統(tǒng)設備的訪問操作進行抽象，在這方面，Unix系統(tǒng)和Linux系統(tǒng)做得比較成功[4][5]。本文借鑒了Unix及Linux系統(tǒng)的成功經(jīng)驗，同時考慮到嵌入式操作系統(tǒng)的特殊性，為μC/OS-II建立了如圖1所示的通用驅動框架模型。在圖1所示的通用驅動框架模型中，共包括三個層次： （1）上層訪問抽象接口層：在這一層，通過對設備訪問操作的抽象，為上層應用提供了5個訪問接口API：UDFOpen、UDFRead、UDFWrite、UDFIoctrl、UDFClose，分別用于打開設備、讀設備、寫設備、設備控制和關閉設備。 （2）設備管理核心數(shù)據(jù)結構層：這是通用驅動框架的核心，在這一層，為系統(tǒng)中的每個硬件設備分配唯一的設備名，上層應用程序通過將設備名作為參數(shù)傳遞給UDFOpen函數(shù)實現(xiàn)對相應設備的核心管理數(shù)據(jù)結構的定位尋址，通過尋址，UDFOpen函數(shù)得到相應設備的核心管理數(shù)據(jù)結構，并定位到相應的設備驅動模塊，獲得相應硬件設備的操作函數(shù)表，再通過上層訪問抽象接口層的其他接口函數(shù)UDFRead、UDFWrite、UDFIoctrl和UDFClose實現(xiàn)對設備的統(tǒng)一訪問控制。 （3）硬件設備驅動模塊層：這一層是硬件設備驅動模塊功能的實現(xiàn)層，對各個硬件設備的驅動在相應的硬件設備驅動模塊中完成。各個硬件設備驅動模塊，原則上需要實現(xiàn)如下幾個函數(shù)：devOpen、devRead、devWrite、devIoctrl和 devClose分別完成相應設備的打開、讀、寫、控制和關閉，當然，可以根據(jù)具體設備的特性，只實現(xiàn)5個驅動函數(shù)的其中一部分，例如，如果某設備不支持寫操作，那么就不用實現(xiàn)devWrite函數(shù)。 下面，對該模型的工作原理進行簡單描述：首先，在上層應用程序可以訪問硬件設備之前，需要首先打開欲操作的設備，這可以通過調用“上層訪問抽象接口層”的UDFOpen函數(shù)實現(xiàn)。上層應用程序將欲打開的設備的設備名傳遞給UDFOpen函數(shù)，UDFOpen函數(shù)通過該設備名從“設備管理核心數(shù)據(jù)結構”中得到相應設備的核心數(shù)據(jù)結構，進而得到相應設備的操作函數(shù)表，并調用設備驅動模塊的devOpen函數(shù)對設備進行初始化，當完成相應設備的初始化后，UDFOpen函數(shù)返回給上層應用程序一個句柄，這個句柄是上層應用程序進行后續(xù)設備操作的基礎?，F(xiàn)在假設上層應用程序需要從設備中讀取數(shù)據(jù)，這是通過調用“上層訪問抽象接口層”的UDFRead函數(shù)完成的：上層應用程序將UDFOpen函數(shù)返回的設備句柄和相關的讀取參數(shù)傳遞給UDFRead函數(shù)，UDFRead函數(shù)通過該句柄從“設備管理核心數(shù)據(jù)結構”中得到相應設備的核心數(shù)據(jù)結構，進而得到相應設備的操作函數(shù)表，并調用設備驅動模塊的devRead函數(shù)對設備進行讀取操作，當完成讀取操作后，將讀取到的數(shù)據(jù)返回給上層應用程序。其它的操作如UDFWrite、UDFIoctrl和UDFClose是類似的。 3、μC/OS-II下通用驅動框架的實現(xiàn) 3.1 實現(xiàn)環(huán)境 本文在以下的環(huán)境中實現(xiàn)了所設計的通用驅動框架：開發(fā)工具采用ARM公司的ADS 1.2，目標板采用周立功公司開發(fā)設計的以LPC2210為微控制器的SmartARM2210開發(fā)板[6]。LPC2210是一顆以ARM7TDMI-S為核心的微控制器，支持8位、16位、32位總線，具有豐富的片內外設，其中就包括兩個具有16Bytes FIFO的UART接口和高速I2C接口。開發(fā)主機通過EasyJTAG連接目標板以建立交叉開發(fā)調試環(huán)境。 3.2 設備管理核心設計數(shù)據(jù)結構的設計實現(xiàn) 如上文所述：通用驅動框架以“設備管理核心數(shù)據(jù)結構”為核心，它在模型中起著承上啟下的作用。設備管理核心數(shù)據(jù)結構包括兩個結構： UDFFramework和UDFOperations，定義如下： typedef struct ｛ INT8U deviceName[UDF_MAX_NAME]; //設備名 INT8U deviceType; //1—塊設備, 2—字符設備; INT8U canShared; //0——-不可共享使用, 1—可共享使用 INT16U openCount; //對于共享設備，此字段為打開次數(shù)計數(shù); UDFOperations op; //設備驅動模塊提供的設備操作函數(shù)表； ｝ UDFFramework; 該結構描述了系統(tǒng)設備的特性，包括：設備名、設備類型、共享設備的打開計數(shù)、設備操作函數(shù)表等，通過建立UDFFramework結構的一個數(shù)組來描述系統(tǒng)中的所有設備，并通過設備名字段deviceName實現(xiàn)對設備操作函數(shù)表UDFOperations結構的尋地定位。UDFOperations結構定義如下： typedef struct ｛ INT32S （＊devOpen）（void ＊pd）; INT32S （＊devRead）（INT8S ＊buffer, INT32U blen, INT32U lenToRead, INT8U waitType）; INT32S （＊devWrite）（INT8S ＊buffer, INT32U lenToWrite, INT8U waitType）; INT32S （＊devIoctl）（INT32U too, void ＊pd）; INT32S （＊devClose）（void ＊pd）; ｝ UDFOperations; 該結構定義了相應設備的操作函數(shù)表，具體的操作函數(shù)的實現(xiàn)在相應的設備驅動模塊中提供，通過使用通用驅動框架的設備驅動安裝函數(shù)可以將設備驅動模塊安裝到UDFFramework結構中。 3.3 上層訪問抽象接口層設計實現(xiàn) 基于設備管理核心數(shù)據(jù)結構，上層訪問抽象接口層為上層應用提供了5個API函數(shù)：UDFOpen、UDFRead、UDFWrite、UDFIoctrl、UDFClose。本文以UDFOpen和UDFRead為例說明這些API函數(shù)的實現(xiàn)邏輯。UDFOpen函數(shù)的實現(xiàn)邏輯如下： INT32S UDFOpen（char ＊deviceName, void ＊pd） ｛ 在UDFFramework結構數(shù)組中查找名為deviceName的設備； if （找到名為deviceName的設備） ｛ if （設備已被其它應用打開） ｛ if （設備不可共享） 返回出錯信息并返回； else 將設備的打開計數(shù)器openCount加1 ｝ else ｛ 從UDFFramework結構中得到該設備的UDFOperations結構數(shù)據(jù)并調用該設備的devOpen函數(shù)初始化該設備； 將UDFFramework結構的數(shù)組下標作為句柄handle返回給上層應用程序； ｝ ｝ else ｛ 提示設備驅動未安裝并返回； ｝ ｝ UDFRead函數(shù)的實現(xiàn)邏輯如下： INT32S UDFRead（INT32U handle, INT8S ＊buffer, INT32U blen, INT32U lenToRead, INT8U waitType） ｛ 判斷參數(shù)handle句柄是否合法； if （handle合法） return UDFF[handle].op.devRead（buffer, blen, lenToRead, waitType）; else 返回出錯信息并返回； ｝ 3.4 硬件設備驅動模塊的設計實現(xiàn) 本文在該通用驅動框架下實現(xiàn)了UART0設備和I2C接口設備CAT1025JI-30的E2PROM設備的驅動模塊。LPC2210的UART0設備滿足16C550工業(yè)標準，具有16Bytes的接收FIFO和16Bytes的發(fā)送FIFO，本文采用中斷方式接收數(shù)據(jù)、查詢方式發(fā)送數(shù)據(jù)，按照通用驅動框架設備驅動模塊的設計要求，為UART0實現(xiàn)了以下驅動函數(shù)：UART0Open、UART0Read、UART0Write、UART0Ioctrl、UART0Close，并通過通用驅動框架的設備驅動程序安裝函數(shù)InstallDriver將UART0驅動模塊安裝到UDFFramework結構數(shù)組中。對CAT1025JI-30設備的驅動模塊的實現(xiàn)是類似的。 4、結束語 本文在μC/OS-II下設計了一個通用驅動框架模型以實現(xiàn)對系統(tǒng)硬件設備的統(tǒng)一、一致的管理，并在以ARM7TDMI-S為核心、以LPC2210為微控制器的開發(fā)板上進行了實現(xiàn)，結果表明，該框架實現(xiàn)簡單但效率和可靠性方面都有比較好的表現(xiàn)。同時，雖然該框架是在LPC2210開發(fā)板上實現(xiàn)的，但代碼是用ANSI C編寫的，可以較容易地移植到其它類型的目標板上。 本文作者創(chuàng)新點：在μC/OS-II下，提出并設計了一個簡單但是高效的通用驅動框架，它一方面擴展了μC/OS-II的功能，另一方面在該通用驅動框架的管理下，可實現(xiàn)對系統(tǒng)硬件設備的統(tǒng)一管理，并為上層應用提供了統(tǒng)一、一致的調用接口，方便了上層應用對硬件設備的訪問控制。