在μ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所示的通用驱动框架模型中,共包括三个层次:
(1)上层访问抽象接口层:在这一层,通过对设备访问操作的抽象,为上层应用提供了5个访问接口API:UDFOpen、UDFRead、UDFWrite、UDFIoctrl、UDFClose,分别用于打开设备、读设备、写设备、设备控制和关闭设备。
(图1 通用驱动框架模型)
(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是类似的。
声明:本文内容及配图由入驻作者撰写或者入驻合作网站授权转载。文章观点仅代表作者本人,不代表电子发烧友网立场。文章及其配图仅供工程师学习之用,如有内容侵权或者其他违规问题,请联系本站处理。 举报投诉