μC/OS-II下通用驅動框架的設計方案解析

　在μC/OS-II下，設計了一個通用的設備管理模型，稱為通用驅動框架，通過該驅動框架，可以實現對硬件設備的統一、一致的管理，同時，也為上層應用程序提供了統一、一致的設備訪問接口，并在以ARM7TDMI-S為核心的LPC2210微控制器開發板上給出了一例實現。
　　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所示的通用驅動框架模型中，共包括三個層次：
　?。?）上層訪問抽象接口層：在這一層，通過對設備訪問操作的抽象，為上層應用提供了5個訪問接口API：UDFOpen、UDFRead、UDFWrite、UDFIoctrl、UDFClose，分別用于打開設備、讀設備、寫設備、設備控制和關閉設備。
　　
　?。▓D1 通用驅動框架模型）
　?。?）設備管理核心數據結構層：這是通用驅動框架的核心，在這一層，為系統中的每個硬件設備分配唯一的設備名，上層應用程序通過將設備名作為參數傳遞給UDFOpen函數實現對相應設備的核心管理數據結構的定位尋址，通過尋址，UDFOpen函數得到相應設備的核心管理數據結構，并定位到相應的設備驅動模塊，獲得相應硬件設備的操作函數表，再通過上層訪問抽象接口層的其他接口函數UDFRead、UDFWrite、UDFIoctrl和UDFClose實現對設備的統一訪問控制。
　?。?）硬件設備驅動模塊層：這一層是硬件設備驅動模塊功能的實現層，對各個硬件設備的驅動在相應的硬件設備驅動模塊中完成。各個硬件設備驅動模塊，原則上需要實現如下幾個函數：devOpen、devRead、devWrite、devIoctrl和 devClose分別完成相應設備的打開、讀、寫、控制和關閉，當然，可以根據具體設備的特性，只實現5個驅動函數的其中一部分，例如，如果某設備不支持寫操作，那么就不用實現devWrite函數。
　　下面，對該模型的工作原理進行簡單描述：首先，在上層應用程序可以訪問硬件設備之前，需要首先打開欲操作的設備，這可以通過調用“上層訪問抽象接口層”的UDFOpen函數實現。上層應用程序將欲打開的設備的設備名傳遞給UDFOpen函數，UDFOpen函數通過該設備名從“設備管理核心數據結構”中得到相應設備的核心數據結構，進而得到相應設備的操作函數表，并調用設備驅動模塊的devOpen函數對設備進行初始化，當完成相應設備的初始化后，UDFOpen函數返回給上層應用程序一個句柄，這個句柄是上層應用程序進行后續設備操作的基礎。
　　現在假設上層應用程序需要從設備中讀取數據，這是通過調用“上層訪問抽象接口層”的UDFRead函數完成的：上層應用程序將UDFOpen函數返回的設備句柄和相關的讀取參數傳遞給UDFRead函數，UDFRead函數通過該句柄從“設備管理核心數據結構”中得到相應設備的核心數據結構，進而得到相應設備的操作函數表，并調用設備驅動模塊的devRead函數對設備進行讀取操作，當完成讀取操作后，將讀取到的數據返回給上層應用程序。其它的操作如UDFWrite、UDFIoctrl和UDFClose是類似的。