μC/OS-II下通用驅動(dòng)框架的設計與實(shí)現

摘要：在μC/OS-II下，設計了一個(gè)通用的設備管理模型，稱(chēng)為通用驅動(dòng)框架，通過(guò)該驅動(dòng)框架，可以實(shí)現對硬件設備的統一、一致的管理，同時(shí)，也為上層應用程序提供了統一、一致的設備訪(fǎng)問(wèn)接口，并在以ARM7TDMI-S為核心的LPC2210微控制器開(kāi)發(fā)板上給出了一例實(shí)現。
關(guān)鍵詞：嵌入式實(shí)時(shí)操作系統;μC/OS-II;通用驅動(dòng)框架;驅動(dòng)程序

1、概述

在嵌入式應用系統中使用嵌入式操作系統可以提高應用系統的開(kāi)發(fā)效率和提升嵌入式應用系統的穩定可靠性，因此，在嵌入式應用系統中使用嵌入式操作系統將成為嵌入式應用系統的設計主流^[1]。μC/OS-II是由美國學(xué)者Labrosse設計的一個(gè)優(yōu)秀的嵌入式實(shí)時(shí)操作系統^[2]，它是一個(gè)源碼公開(kāi)、可移植、可固化、可裁剪、占先式的實(shí)時(shí)多任務(wù)操作系統，目前已經(jīng)得到廣泛應用。

μC/OS-II提供了操作系統必須具備的基本功能，包括：任務(wù)管理、信號量管理、郵箱管理、消息隊列管理、事件管理、時(shí)間管理、內存管理，但它不提供設備管理和文件系統管理，已有研究者對μC/OS-II進(jìn)行了文件子系統功能擴展^[3]。在實(shí)際應用中，對系統設備的有效管理也是一個(gè)非常重要的任務(wù)，因此，需要對μC/OS-II進(jìn)行擴展，以實(shí)現這一功能。本文為μC/OS-II設計了一個(gè)對系統設備進(jìn)行統一管理的通用驅動(dòng)框架，在此框架下，可以屏蔽系統硬件的差異，在無(wú)約束地發(fā)揮硬件能力的前提下，為上層應用提供了統一、一致的調用接口A(yíng)PI，從而實(shí)現了對系統設備的有效管理。

2、μC/OS-II下通用驅動(dòng)框架的基本模型

為了給上層應用提供統一、一致的系統設備調用接口，需要對上層應用程序對系統設備的訪(fǎng)問(wèn)操作進(jìn)行抽象，在這方面，Unix系統和Linux系統做得比較成功^[4][5]。本文借鑒了Unix及Linux系統的成功經(jīng)驗，同時(shí)考慮到嵌入式操作系統的特殊性，為μC/OS-II建立了如圖1所示的通用驅動(dòng)框架模型。在圖1所示的通用驅動(dòng)框架模型中，共包括三個(gè)層次：

（1）上層訪(fǎng)問(wèn)抽象接口層：在這一層，通過(guò)對設備訪(fǎng)問(wèn)操作的抽象，為上層應用提供了5個(gè)訪(fǎng)問(wèn)接口A(yíng)PI：UDFOpen、UDFRead、UDFWrite、UDFIoctrl、UDFClose，分別用于打開(kāi)設備、讀設備、寫(xiě)設備、設備控制和關(guān)閉設備。

（圖1 通用驅動(dòng)框架模型）

（2）設備管理核心數據結構層：這是通用驅動(dòng)框架的核心，在這一層，為系統中的每個(gè)硬件設備分配唯一的設備名，上層應用程序通過(guò)將設備名作為參數傳遞給UDFOpen函數實(shí)現對相應設備的核心管理數據結構的定位尋址，通過(guò)尋址，UDFOpen函數得到相應設備的核心管理數據結構，并定位到相應的設備驅動(dòng)模塊，獲得相應硬件設備的操作函數表，再通過(guò)上層訪(fǎng)問(wèn)抽象接口層的其他接口函數UDFRead、UDFWrite、UDFIoctrl和UDFClose實(shí)現對設備的統一訪(fǎng)問(wèn)控制。

（3）硬件設備驅動(dòng)模塊層：這一層是硬件設備驅動(dòng)模塊功能的實(shí)現層，對各個(gè)硬件設備的驅動(dòng)在相應的硬件設備驅動(dòng)模塊中完成。各個(gè)硬件設備驅動(dòng)模塊，原則上需要實(shí)現如下幾個(gè)函數：devOpen、devRead、devWrite、devIoctrl和 devClose分別完成相應設備的打開(kāi)、讀、寫(xiě)、控制和關(guān)閉，當然，可以根據具體設備的特性，只實(shí)現5個(gè)驅動(dòng)函數的其中一部分，例如，如果某設備不支持寫(xiě)操作，那么就不用實(shí)現devWrite函數。

下面，對該模型的工作原理進(jìn)行簡(jiǎn)單描述：首先，在上層應用程序可以訪(fǎng)問(wèn)硬件設備之前，需要首先打開(kāi)欲操作的設備，這可以通過(guò)調用“上層訪(fǎng)問(wèn)抽象接口層”的UDFOpen函數實(shí)現。上層應用程序將欲打開(kāi)的設備的設備名傳遞給UDFOpen函數，UDFOpen函數通過(guò)該設備名從“設備管理核心數據結構”中得到相應設備的核心數據結構，進(jìn)而得到相應設備的操作函數表，并調用設備驅動(dòng)模塊的devOpen函數對設備進(jìn)行初始化，當完成相應設備的初始化后，UDFOpen函數返回給上層應用程序一個(gè)句柄，這個(gè)句柄是上層應用程序進(jìn)行后續設備操作的基礎?，F在假設上層應用程序需要從設備中讀取數據，這是通過(guò)調用“上層訪(fǎng)問(wèn)抽象接口層”的UDFRead函數完成的：上層應用程序將UDFOpen函數返回的設備句柄和相關(guān)的讀取參數傳遞給UDFRead函數，UDFRead函數通過(guò)該句柄從“設備管理核心數據結構”中得到相應設備的核心數據結構，進(jìn)而得到相應設備的操作函數表，并調用設備驅動(dòng)模塊的devRead函數對設備進(jìn)行讀取操作，當完成讀取操作后，將讀取到的數據返回給上層應用程序。其它的操作如UDFWrite、UDFIoctrl和UDFClose是類(lèi)似的。

3、μC/OS-II下通用驅動(dòng)框架的實(shí)現

3.1 實(shí)現環(huán)境

本文在以下的環(huán)境中實(shí)現了所設計的通用驅動(dòng)框架：開(kāi)發(fā)工具采用ARM公司的ADS 1.2，目標板采用周立功公司開(kāi)發(fā)設計的以L(fǎng)PC2210為微控制器的SmartARM2210開(kāi)發(fā)板^[6]。LPC2210是一顆以ARM7TDMI-S為核心的微控制器，支持8位、16位、32位總線(xiàn)，具有豐富的片內外設，其中就包括兩個(gè)具有16Bytes FIFO的UART接口和高速I(mǎi)²C接口。開(kāi)發(fā)主機通過(guò)EasyJTAG連接目標板以建立交叉開(kāi)發(fā)調試環(huán)境。

3.2 設備管理核心設計數據結構的設計實(shí)現

如上文所述：通用驅動(dòng)框架以“設備管理核心數據結構”為核心，它在模型中起著(zhù)承上啟下的作用。設備管理核心數據結構包括兩個(gè)結構：UDFFramework和UDFOperations，定義如下：

typedef struct {

INT8U deviceName[UDF_MAX_NAME]; //設備名

INT8U deviceType; //1―塊設備, 2―字符設備;

INT8U canShared; //0---不可共享使用, 1―可共享使用

INT16U openCount; //對于共享設備，此字段為打開(kāi)次數計數;

UDFOperations op; //設備驅動(dòng)模塊提供的設備操作函數表；

} UDFFramework;

該結構描述了系統設備的特性，包括：設備名、設備類(lèi)型、共享設備的打開(kāi)計數、設備操作函數表等，通過(guò)建立UDFFramework結構的一個(gè)數組來(lái)描述系統中的所有設備，并通過(guò)設備名字段deviceName實(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í)現在相應的設備驅動(dòng)模塊中提供，通過(guò)使用通用驅動(dòng)框架的設備驅動(dòng)安裝函數可以將設備驅動(dòng)模塊安裝到UDFFramework結構中。

3.3 上層訪(fǎng)問(wèn)抽象接口層設計實(shí)現

基于設備管理核心數據結構，上層訪(fǎng)問(wèn)抽象接口層為上層應用提供了5個(gè)API函數：UDFOpen、UDFRead、UDFWrite、UDFIoctrl、UDFClose。本文以UDFOpen和UDFRead為例說(shuō)明這些API函數的實(shí)現邏輯。UDFOpen函數的實(shí)現邏輯如下：

INT32S UDFOpen(char *deviceName, void *pd)

{

在UDFFramework結構數組中查找名為deviceName的設備；

if (找到名為deviceName的設備) {

if (設備已被其它應用打開(kāi)) {

if (設備不可共享)

返回出錯信息并返回；

else

將設備的打開(kāi)計數器openCount加1

}

else {

從UDFFramework結構中得到該設備的UDFOperations結構數據并調用該設備的devOpen函數初始化該設備；

將UDFFramework結構的數組下標作為句柄handle返回給上層應用程序；

}

}

else {

提示設備驅動(dòng)未安裝并返回；

}

}

UDFRead函數的實(shí)現邏輯如下：

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 硬件設備驅動(dòng)模塊的設計實(shí)現

本文在該通用驅動(dòng)框架下實(shí)現了UART0設備和I²C接口設備CAT1025JI-30的E²PROM設備的驅動(dòng)模塊。LPC2210的UART0設備滿(mǎn)足16C550工業(yè)標準，具有16Bytes的接收FIFO和16Bytes的發(fā)送FIFO，本文采用中斷方式接收數據、查詢(xún)方式發(fā)送數據，按照通用驅動(dòng)框架設備驅動(dòng)模塊的設計要求，為UART0實(shí)現了以下驅動(dòng)函數：UART0Open、UART0Read、UART0Write、UART0Ioctrl、UART0Close，并通過(guò)通用驅動(dòng)框架的設備驅動(dòng)程序安裝函數InstallDriver將UART0驅動(dòng)模塊安裝到UDFFramework結構數組中。對CAT1025JI-30設備的驅動(dòng)模塊的實(shí)現是類(lèi)似的。

4、結束語(yǔ)

本文在μC/OS-II下設計了一個(gè)通用驅動(dòng)框架模型以實(shí)現對系統硬件設備的統一、一致的管理，并在以ARM7TDMI-S為核心、以L(fǎng)PC2210為微控制器的開(kāi)發(fā)板上進(jìn)行了實(shí)現，結果表明，該框架實(shí)現簡(jiǎn)單但效率和可靠性方面都有比較好的表現。同時(shí)，雖然該框架是在LPC2210開(kāi)發(fā)板上實(shí)現的，但代碼是用ANSI C編寫(xiě)的，可以較容易地移植到其它類(lèi)型的目標板上。

本文作者創(chuàng )新點(diǎn)：在μC/OS-II下，提出并設計了一個(gè)簡(jiǎn)單但是高效的通用驅動(dòng)框架，它一方面擴展了μC/OS-II的功能，另一方面在該通用驅動(dòng)框架的管理下，可實(shí)現對系統硬件設備的統一管理，并為上層應用提供了統一、一致的調用接口，方便了上層應用對硬件設備的訪(fǎng)問(wèn)控制。

參考文獻

[1] 鐘堅文，蔡旭，基于μC/OS-II的CAN總線(xiàn)驅動(dòng)程序設計，微計算機信息[J]，2005（21）：29-31。
[2] Labrosse J J. 嵌入式實(shí)時(shí)操作系統μC/OS2-Ⅱ[M ]，第2版， 北京:北京航空航天大學(xué)出版社, 2003：116-281。
[3] 戴立成，葉曉俊，基于μC/OS-II的文件系統設計，微計算機信息[J]，2005（21）：60-62。
[4] Daniel P. Bovet, Marco Cesati, Understanding the Linux Kernel [M], O'Reilly, 2000:349-388
[5] 周慶喜,劉　強，基于嵌入式Linux系統的DVB2CI設備驅動(dòng)程序開(kāi)發(fā)，計算機應用[J]，2005（25）：1698-1700。
[6] 周立功，ARM嵌入式系統基礎教程[M]，北京：北京航空航天大學(xué)出版社，2005：216-229。