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是类似的。
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的功能,另一方面在该通用驱动框架的管理下,可实现对系统硬件设备的统一管理,并为上层应用提供了统一、一致的调用接口,方便了上层应用对硬件设备的访问控制。