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