电子白板的系统软件设计与实现

ARM电子白板系统是在前端电子白板信号发射和信号采集模块的基础上添加ARM信号处理模块组成的。

11.3.1 Windows CE操作系统平台构建

11.3.1.1 嵌入式操作系统概述

嵌入式系统（Embedded System）是“嵌入式计算机系统”的简称，IEEE（电气和电子工程师协会）对嵌入式系统的定义是：控制或监视机器、装置、工厂等大规模系统的设备（devices used to control，monitor，or assist the operation of equipment，machinery or plants）。国内对嵌入式系统的定义则为：以应用为中心、计算机技术为基础，并且软件硬件可裁剪，适应于应用系统对功能、可靠性、成本、体积、功耗有严格要求的专用计算机系统。

嵌入式系统不以独立设备的物理形态出现，嵌入式操作系统是与应用环境密切相关的，常见的嵌入式操作系统有Windows CE、VxWorks、嵌入式Linux、Palm OS、Symbian等。嵌入式操作系统作为一种操作系统，同样具有操作系统在进程管理、存储管理、设备管理、处理器管理和输入输出管理几方面的基本功能，但由于硬件平台和应用环境与一般操作系统不同，它又有自身的特点，最大的特点就是可定制性，即可以根据应用的需要有选择的提供或不提供某些功能以减少系统开销。本系统最终选用了微软的嵌入式Windows CE操作系统。

11.3.1.2 Windows CE操作系统概述

Windows CE（简称WinCE）操作系统是微软公司的一种嵌入式操作系统，微软1996年开始发布Windows CE 1.0版本，2004年7月发布了Windows CE.NET 5.0版本，目前用得最多的是Windows CE.NET 4.2版本，其主要应用领域有PDA市场、Polket PC、Smartphone、工业控制、医疗等。Windows CE的体系结构图如图11-15所示。大致可分为硬件层、OEM层、操作系统层和应用程序层4个层次。

图11-15　Windows CE的体系结构图

一般来说，硬件层和OEM层由厂商提供。操作系统层由微软公司提供，应用程序层由独立的软件开发商提供，把这些厂商提供的产品结合起来，才能组成完整的基于Windows CE构建的嵌入式系统。

1.硬件层

由于Windows CE是以应用为核心的嵌入式系统。其硬件通常是根据需要定制的，硬件体系结构彼此之间的差异很大，嵌入式系统中的硬件通常具有处理器体系结构不一、硬件资源有限、外部设备的种类繁多及有实时性和可靠性要求等特点。

2.OEM层

OEM层是逻辑上位于硬件和Windows CE操作系统之间的一层硬件相关的代码，其主要作用是对具体的硬件抽象出统一的接口，然后Windows CE内核使用这些接口与硬件进行通信。OEM层包括OEM抽象层（OEM Abstraction Layer，OAL）、引导程序Boot Loader、配置文件（Configuration File）和驱动程序（Device Driver）4个模块。OEM抽象层是整个OEM层的主体，它包含了高度硬件相关的代码，主要负责Windows CE内核和硬件通信。引导程序Boot Loader是在硬件开发板上执行的一段代码，其主要功能是初始化硬件，加载操作系统映像（OS Image）到内存，然后跳转到操作系统代码去执行。配置文件是包含配置信息的文本文件，与操作系统映像或源代码有关。设备驱动程序直接与硬件打交道，是应用程序或操作系统与硬件外设交互的桥梁。

3.操作系统层

操作系统层实现了Windows CE作为一个操作系统的主要功能。Windows CE的进程管理、线程管理、处理机管理、调度、物理内存和虚拟内存管理、文件系统及设备管理等功能的实现都位于这一层，由于Windows CE是微内核操作系统，操作系统的基本功能被放在多个独立的进程（EXE）里面实现，在运行的时候，这些进程大致有以下五个。

（1）内核NK.EXE。

内核是OS的核心，通过Core.dll表示，提供在所有设备中都出现的基本操作系统功能。Windows CE的任何配置都需用到Coredll模块的大多数组件。

（2）图形系统GWES.EXE。

GWES是用户、应用程序和OS之间的图形用户接口，其中心是窗口。所有应用程序都需要窗口以接收来自OS的消息，即使那些为缺少图形显示的设备创建的应用程序也是如此。GWES提供控制器、菜单、对话框以及图形显示的设备资源，还提供GDI以控制文本与图形显示。

（3）对象存储FILESYS.EXE。

FILESYS模块支持Windows CE对象存储API函数。对象存储支持的永久性存储器类型包括文件系统、系统注册表和Windows CE数据库。

（4）设备管理系统DEVICE.EXE。

DEVICE.EXE是Windows CE中的设备管理器（Device Manager），它负责加载、卸载和管理所有不被GWES.EXE管理的驱动程序，DEVICE.EXE同时向系统提供所有关于驱动的API的实现。

（5）服务SERVICES.EXE。

SERVICES.EXE是负责加载系统服务的进程，它们提供一些后台处理或者为应用程序提供高级的服务功能。在Windows CE中，FTP、HTTP和TELNET都是以系统服务形式实现的，Windows CE提供单独的API来启动、停止和操作服务，第三方开发者可以自由地向系统中添加新服务。另外，Windows CE的通信模块是唯一一个功能比桌面机强大的模块，通信组件提供对下列通信硬件和数据协议的支持：串行I/O支持、远程访问服务（RAS）、传输控制协议/Internet协议（TCP/IP）、局域网（LAN）、电话技术API（TAPI）、Windows CE的无线服务等。

4.应用软件层

应用程序层位于Windows CE层次结构的最顶层。每个应用程序都是Windows CE中的一个单独的进程，通常应用程序运行在权限较低的处理机状态下，它使用操作系统提供的API系统调用与操作系统交互。

11.3.1.3 Windows CE的注册表

注册表在Windows CE中有着重要的不可缺少的作用，它是一个数据库，存储着应用程序、驱动程序和操作系统的配置信息及操作系统调用程序的状态信息。Windows CE下注册表具有树型层次结构，是一个包含着关键字子树的集合。每个子树由更低的子树、键及键值项组成，每个键包括若干键值项，每个键值项又有键值名、数据类型和键值组成。Windows CE的注册表包含4个根键，它们的键值各保存不同的内容（如表11-1所示）。

表11-1　Windows CE操作系统注册表键值

Windows CE支持两种不同类型的注册表：基于RAM的注册表（RAM-based registry）和基于HIVE的注册表（Hive-based registry）。基于RAM的注册表用于将注册表数据全部保存在RAM中，适合频繁热启动而不冷启动的设备。

基于HIVE的注册表用于将注册表数据全部或部分保存到永久存储器上，它是从Windows CE开始采用的新技术，它使系统断电前后无须备份和恢复注册表数据，适合经常冷启动的设备，支持多用户信息分别保存。HIVE是指一组键，是保存或加载注册表数据的单位（如表11-2所示）。

表11-2　标准HIVE及其支持文件

11.3.1.4 开发环境介绍

Windows CE的开发环境主要有以下几种：Embedded Visual Basic（简称EVB）、Visual Studio.NET、Embedded Visual C++（简称EVC，用来开发应用程序）、Platform Builder（简称PB，主要用来定制系统和开发驱动程序）。

图11-16是PB的开发界面，主要包括菜单栏、工具栏、工作区、调试信息区。左边是用户自己建立的平台所包含的一些功能模块，右边是PB自带的可供选择的功能模块，可以在这里面选择需要的功能模块，然后，添加到自己所建立的平台上，而且它会自动地加入相关的依赖模块而避免由于模块添加不完整而造成的功能不能实现。

图11-16　Platform Builder开发界面

11.3.1.5 Windows CE系统平台的建立

系统用的是微软公司的Windows CE 4.2操作系统，其创建过程如图11-17所示。在Windows XP（简称XP）系统上安装开发工具，安装过程中发现了Windows CE 4.2模拟器与PAE（物理地址扩展）间存在冲突。Windows CE 4.2模拟器会在XP中安装一个名叫“Virtual PCApplication Services”的驱动程序，在安装这个驱动程序的时候XP报这个驱动会使系统产生不稳定，然后自动不让这个驱动生效。这个驱动不能用，自然也无法用Windows CE 4.2模拟器调试程序。解决这个问题的办法就是要禁用PAE，下面介绍下禁用PAE的办法。

图11-17　Windows CE平台创建过程

右击桌面“我的电脑”属性，选择“高级”，再点击“启动与恢复”下面的“设置”，再点击框中的“编辑”键，此时会打开BOOT.INI文件，然后将文件的此行“multi（0）disk（0）rdisk（0）partition（1）\WINDOWS=“Microsoft Windows XP Professional“/noexecute=optin/fastdetect”中的/noexecute=optin改成/execute后保存该文件，然后重启电脑。

在PB中建立新工程，选择相应的硬件CPU类型，本系统中用的是ARM2440X，但PB自带的ARM处理器提供了ARMINTEGRATOR、XSCIBD、SMDK2410三种BSP，没有平台选用的S3C2440X处理器，因此需要我们将该BSP添加到PB中。在File菜单下选择Manage Catalog Features选项，会出现图11-18的界面，然后选择Import选项，这里选择的是开发商提供的BSP开发包，已经做成相应的.cec文件，在工程中选择导入BSP，然后选择相应的.cec文件，添加后在PB的Catalog窗口中就可以看到添加了Samungsmdk2440：ARMV4和Samung smdk2440：ARMV4I。

图11-18　导入BSP界面图

选择系统基本特性组件，生成系统工程。这里主要用到的是音频、视频、USB口、SM501显卡等，选择需要的系统特性添加到定制的系统中，而PB会根据它们之间的依赖关系自动添加一些需要的特性，选择后的工程选项如图11-19所示。点击PB工具栏中的Build，进行系统工程编译，PB根据用户对系统工程的参数设置进行编译，在编译的过程中会自动进行错误校验，编译完成后生成操作系统的镜像，以二进制文件的形式存在。为了保证系统可以连接USB设备及USB接口的打印机，必须包含相关的USB选项，截图见图11-20所示。

图11-19　定制系统包含的相关选项

图11-20　定制系统时包含的USB选项

在项目中，用的不是S3C2440处理器自带的LCD接口驱动，而是用了带有图形加速的SM501显示芯片的驱动程序，将其添加到PB中去，它将出现在PB开发界面的Catalog里，而且是以Third Party的形式出现的。Windows CE操作系统启动起来后，需要对桌面、网络IP等进行重新设置，并希望重启Windows CE后这些设置能够保存下来，需要修改Windows CE的注册表，具体做法如下：

（1）首先在PB中的Catalog中将注册表“Rom-based Registry”换作“Hive-based Registry”。

（2）打开platform.reg，找到如下信息：

“SYSTEMHIVE”的值为系统HIVE文件的路径。“Start DevMgr”是一个布尔值，指示是否开始就执行设备管理器device.exe。在“HIVE BOOTSECTION”和“END HIVE BOOT SECTION”之间的注册表数据属于引导HIVE，所以需要将包含系统HIVE的文件系统驱动程序注册表信息和存储设备的驱动程序的注册表信息包含到这两个语句之间。

在“HIVE BOOT SECTION”和“END HIVE BOOT SECTION”之间的所有驱动程序的注册表信息中都需要加入下列标志：

在包含系统HIVE的存储设备驱动程序注册表信息中，加入如下标志：

这个标志表示这个存储设备包含系统HIVE文件。

编译完成后要导出该工程的SDK，以备应用程序开发使用。在Platform菜单下选择Configure SDK选项，导出SDK的配置，界面如图11-21所示。

图11-21　SDK配置界面

选择生成SDK的路径及名字。配置完成后Platform菜单下选择Build SDK，开始制作基于所建工程的SDK，按照提示操作即可。

最后通过JTAG线把系统镜像下载到硬件设备的存储介质中。另外，要调试开发板中的程序，需要在PC机和开发板之间建立连接，PC机与开发板连接可选择用网线和USB线，下面分别介绍：

（1）用网络进行PC机与开发板的连接，在编译内核时要包含以下几个选项：LAN和platform manager下的Transport或者把c：\program files\common\……下面的tcpipc.dll、cemgrc.exe、cetlstub.dll拷贝到开发板的Windows目录下面，本节采用的是第一种方法，在建立连接时要保证PC机和开发板在一个网段内。

（2）通过USB线建立PC机和开发板间的连接，需要用到微软公司提供的软件ActiveSync，这种方法相对比较简单，需要在编译内核镜像时包含platform manager下的ActiveSync选项，用这种方法工作时可以方便地和开发板连接，并可保证网络畅通。

11.3.2 Windows CE操作系统的驱动概述

驱动程序的目的是驱动内部和外围的硬件设备，或者为它们提供相应接口，使操作系统可以很好地识别外围设备并为应用程序提供相应服务。开发任何软件都需要对软件平台特别是操作系统进行认识、分析和研究。所以本章开头先对Windows CE操作系统的体系结构进行了简要分析，接下来就着重讨论其中的驱动程序，特别是流接口驱动程序。

11.3.2.1 Windows CE操作系统的驱动模型

根据支持的软件接口不同，Windows CE中的驱动模型分为本机驱动和流接口驱动，本机驱动主要是移植Windows CE到目标平台时为目标平台上附带的设备提供的，由CE定义了接口函数，开发人员只要实现这些函数即可，常见的有键盘驱动、鼠标驱动、显示驱动和电池驱动。流接口驱动程序实现一组固定的流接口函数，所有的CE设备皆可用此模型实现。

PB中包含的样本设备驱动程序分为两种：单片驱动程序和分层的驱动程序。如图11-22所示。

图11-22　单层驱动程序与分层驱动程序

单层驱动程序基于单片码片，它把所有的驱动程序代码，包括中断处理、I/O操作及硬件控制都放在一起了，该码片直接把硬件设备的功能传递给操作系统。分层驱动程序由上层的模型设备驱动程序（Model Device Driver，MDD）和下层的依赖平台驱动程序（Platform Dependert Driver，PDD）组成。大多数的样本设备驱动程序都配置成分层的。

微软为链接驱动程序提供了模型设备驱动程序（MDD）。对平台和函数来讲，模型设备驱动程序（MDD）是通用的，既是源代码也是库。模型设备驱动程序（MDD）执行下列任务。

（1）链接PDD层并定义它希望调用的函数，通常这些函数叫作设备驱动程序提供器接口（Device Driver Service Provider Interface，DDSI）；

（2）把不同的函数集提供给操作系统，这些函数叫作设备驱动程序接口（Device Driver Interface，DDI），相关的设备驱动能够共享一个DDI；

（3）处理像中断处理这样复杂的任务；

（4）负责与GWES模块与内核通信。

依赖平台的驱动程序（PDD）层与MDD和硬件有接口，这意味着必须适合目标平台的需要，一个PDD由针对具体硬件的函数组成。而这些函数与一个MDD相对应，但这种对应不是直接的一一对应。因为PDD是硬件相关的，因此必须生成一个设置好的PDD并输出到平台硬件。

11.3.2.2 流接口驱动程序

流接口驱动是为连接到Windows CE平台的外围设备设计的，是一个管理外围设备的用户级动态链接库（DLL），主要任务是把外设传递给应用程序，通过把设备表示为文件系统的一个特殊文件来实现的，这种在应用程序层采用标准文件操作APIS调用设备的特点是有比较统一的接口函数、设备端比较简单、以数据提供者为主，打印机、调制解调器等主要采用这种模式。

流接口驱动程序模型如图11-23所示，应用程序通过文件系统的API函数调用流接口函数，然后，流接口驱动程序调用本机驱动或者通过设备管理器与系统内核或外围设备打交道。流接口驱动从设备管理器和应用程序接收命令，应用程序是通过文件系统调用传递命令的，驱动压缩所有有用的信息然后将命令翻译成它所控制设备的具体行为。

图11-23　流接口驱动程序模型

流接口驱动程序由一个叫作设备管理程序的特殊应用程序加载、管理和卸载，所有流接口驱动程序使用同一接口并调用同一函数集：流接口函数。标准的流接口是如下的一组函数：

（1）HANDLE XXX_Init（LPCTSTR pContext，LPCVOID lpvBusContext）在设备管理程序通过ActiveDeviceEx（）激活设备时被系统调用，主要功能是初始化驱动程序中用到的资源，对I/O地址空间和内存进行映射等。

（2）BOOL XXX_Deinit（DWORD hDeviceContext）在设备管理程序通过DeactivateDevice（）卸载设备时被系统调用，主要功能是回收驱动程序中用到的资源。

（3）DWORD XXX_Open（DWORD hDeviceContext，DWORD Access Code，DWORD ShareMode）在应用程序通过CreateFile（）打开设备时被系统调用。

（4）BOOL XXX_Close（DWORD hOpenContext）在应用程序通过CloseHandle（）关闭句柄时被调用。

（5）DWORD XXX_Read（DWORD hOpenContext，LPVOID pBuffer，DWORDCount）在应用程序通过ReadFile（）函数读取设备时被调用。

（6）DWORD XXX_Write（DWORD hOpenContext，LPCVOID pBuffer，DWORD Count）在应用程序通过WriteFile（）向设备写入数据时被调用。

（7）DWORD XXX_IOControl（DWORD hOpenContext，DWORD dwCode，PBYTE pBufIn，DWORD dw LenIn，PBYTE pBuf Out，DWORD dw LenOut，PDWORD pdw ActualOut）在应用程序通过DeviceIOControl（）向设备发送控制字时被调用。

（8）void XXX_Power Up（DWORD hDeviceContext）在向设备恢复供电的时候被调用。

（9）void XXX_PowerDown（DWORD hDeviceContext）在设备断电的时候被调用。

上述函数中的XXX部分是在注册表中注册此设备驱动程序的时候Perfix注册表项的值。只要一个DLL中针对特定设备实现了上述接口并且正确在注册表中注册，那么就可以在程序中通过那些文件API函数来访问此设备。

11.3.2.3 USB通信模型及协议基础

图11-24为USB通信模型。USB（Universal Serial Bus，通用串行总线）是由Compaq、DEC、IBM、Intel、Microsoft、NEC和Northern Telecom等公司为简化PC与外设之间的互联而共同研究开发的一种免费的标准化连接器，它支持各种PC与外设之间的连接，还可实现数字多媒体集成。它具有支持即插即用、支持多达127个物理设备、实现成本较低、体积小、连接电缆轻巧、电源体积小和开放性等优点，这些特点使USB越来越多地应用在计算机的外设和我们日常的电子设备上。下面介绍几个重要的USB相关概念。

图11-24　USB主机与外围设备对应的通信关系

1.管道

一个USB管道是设备上一个端点和主机上软件之间的联系，体现了主机上缓存和端点间传送数据的能力。有两种不同的且互斥的管道通信格式。

（1）流（Stream）：指不具有USB定义的格式的数据流；

（2）消息（Message）：指具有某种USB定义的格式的数据流。

USB不解释在管道中传送的数据内容。消息管道要求数据组织成USB定义的格式，但它的内容，USB是不管的。特别地，有下列概念与管道相关。

①对USB总线访问的申请（claim）、带宽的使用情况；

②传送类型；

③与管道相连的端点的特性。

2.端点

一个端点是可唯一识别的USB设备的部分，其主机与设备间通信流的结束点。一系列相互独立的端点一起构成了USB逻辑设备。每个逻辑设备有唯一的地址，这个地址是在设备连上主机时，由主机分配的，而设备中的每个端点在设备内部有唯一的端点号。这个端点号是在设备设计时给定的。每个端点都是一个简单的连接点，或者支持数据流进设备，或者支持其流出设备，两者不可得兼。一个端点的特性决定了它与客户软件进行传送的类型。一个端点有以下特性：总线访问频率要求、总线延迟要求、带宽要求、端点号、对错误处理要求、能接收或发送包的最大长度、传送类型、与主机的数据传送方向。

所有USB设备都需要实现一个缺省的控制管道。它是将端点0作为输入端点和输出端点的。USB系统用这个缺省管道初始化和设置设备。缺省控制通道支持了对控制的传送，一旦设备接上并加电且又收到一个总线复位命令，端点0就可访问了。

设备可以有除0以外的其他端点，这取决于这些设备的实现。低速设备在0号输入及输出端点外，只能有2个额外的可选端点。而高速设备可具有的额外端点数仅受限于协议的定义（协议中规定，最多15个额外的输入端点和最多15个额外的输出端点）。其他端点只有在设备被设置后才可使用。

3.USB数据传输类型

（1）控制传送。

控制传送允许访问一个设备的不同部分。控制传送用于支持在客户软件和其应用之间的关于设置信息、命令信息、状态信息的传送。控制传送由以下几个事务组成：建立联系，把请求信息从主机传到它的应用设备、零个或多个数据传送事务，按照指明的方向传送数据和状态信息回传。当端点成功地完成了被要求的操作时，回传的状态信息为“success”。

USB设备必须实现缺省控制通道，并将它实现成一个消息通道。这个通道由USB系统软件使用。如果需要的话，一个应用设备可以为端点实现额外的控制通道。控制传送只能通过消息通道进行，所以使用控制传送的数据必须具有USB定义的数据格式。应用层和相应的客户软件不能为控制传送指定总线访问频率和带宽。这由USB系统软件从全局优化角度加以决定。USB系统软件会限制设备要求的访问频率和带宽。

（2）同步传送。

同步数据的建立、传送和使用是连续且实时的，同步数据是以稳定的速率发送和接收实时的信息，同步数据要使接收者与发送者保持相同的时间安排，除了传输速率，同步数据对传送延迟非常敏感。所以同步通道的带宽的确定，必须满足对相关功能部件的取样特性。不可避免的信号延迟与每个端口的可用缓冲区数有关。

（3）中断传送。

中断数据是少量的，且其数据延迟时间也是有限范围的。这种数据可由设备在任何时刻发送，并且以不慢于设备指定的速度在USB上传送。中断数据一般由事件通告、特征及坐标号组成，只有一个或几个字节。

（4）批量传送。

批量数据由大量的数据组成，在硬件级上可使用错误检测以保证可靠的数据传输，并在硬件级上引入了数据的多次传送。此外根据其他一些总线动作，被大量数据占用的带宽可以相应地进行改变。

4.USB描述符

USB描述符是对USB外围设备的属性说明，它们记录着USB设备的各种信息和相关的设置，包括使用的协议、接口数目、端点和传输方式等等。主机通过标准请求Get Descriptor来读取USB的描述符，从而得到设备的相关信息，根据这些信息，然后建立通信。标准的USB设备有4种必需的描述符，下面对这4种描述符进行讨论，以便对后面的程序的理解。

（1）设备描述符（device descriptor）。

它向主机提供了一系列USB设备的特征和能力的信息，用于配置设备和定位USB设备的驱动程序。这些信息确保了主机以正确的方式对设备进行访问，一个设备只有一个设备描述符，所有的USB设备都缺省控制端点，它的最大包长在设备描述符中有说明。

（2）配置描述符（configuration descriptor）。

每个设备有一个或者多个配置描述符，它们描述了设备能实行的各种配置方式。当主机请求设备的配置时，它将会连续地读取这些配置描述符，直到所有的配置已经接收完毕，在一个配置下，一个端点不会在接口之间共享。

（3）接口描述符（interface descriptor）。

每个配置都有一个或多个接口描述符，它们描述了设备提供功能的接口，指出软件应该如何访问硬件，如果一个配置支持不止一个接口，接口的描述符会跟在配置描述符后被返回。它总是作为配置描述符的一部分被返回。一个接口可能包含备选配置，使得端点或它们的特征在设备配置好后还能改变。

（4）端点描述符（endpoint descriptor）。

每个接口的端点都有自己的描述符，它被主机用来决定端点的带宽需求。每个端点的描述符总是作为配置描述符的一部分返回的，端点0无描述符。

5.USB设备枚举

当一个USB设备插入或者拔出时，主机会通过总线枚举过程来鉴别和管理设备状态可能的变化。USB设备在枚举过程中响应主机的标准设备请求，通过各种描述符向主机报告设备的属性和功能，主机分析描述符数据，并以此来配置USB设备。USB设备总线枚举过程的具体步骤如下：

（1）根集线器根据设备所接入端口状态改变，向主机报告设备插入事件；

（2）主机通过询问集线器来确定状态改变的本质，当确认有设备接入总线，主机就向该端口发送使能和复位指令；

（3）在USB设备收到一个唯一的地址前，其缺省管道仍可通过缺省地址访问，主机读取设备描述符来确定缺省管道实际可用的最大有效数据载荷；

（4）主机给USB设备分配一个唯一的地址；

（5）主机从设备读取所有的配置描述符；

（6）基于配置信息及USB设备如何被使用，主机给USB设备指派一个配置值，这时USB设备处于已配置状态，该配置中所有的端点都呈现出它们在端点描述符中所描述的特征，设备配置完成。

11.3.2.4 Windows CE下USB驱动模型

Windows CE.NET的USB系统软件分为USB Client设备驱动程序和底层的Windows CE实现的函数层。USB设备驱动程序主要负责利用系统提供的底层接口配置设备及进行通信。底层函数体又由两部分组成：通用串行总线驱动程序（USBD）模块和较低的主控制器驱动程序（HCD）模块。HCD负责最最底层的处理，USBD模块实现较高的USBD函数接口。USB设备驱动主要利用USBD接口函数和他们的外围设备打交道。USB接口函数主要包括传输、管道、框架和配置函数，同时也包括执行其他功能的多任务函数。

主要的传输函数有：Abort Transfer、IssueControl Transfer、CloseTransfer、Is-sueInterrup Transfer、GetIsochResult、IssueIsoch Transfer、transferComplete、Get-TransferStatus、IsIssueBulk Transfer、IssueVendor Transfer。传输函数用来处理USB设备数据发送和接收，所有传输函数都有一个对应可选回调函数。

主要的用于打开和关闭USBD和USB设备之间的通信通道的函数有：AbortPipeTransfers、ClosePipe、IsDefaultPipe Halted、IsPipeHalted、penPipe、ResetDefault-Pipe、ResetPipe。相应的打包函数接口有：GetFrameLength、GetFrameNumber、ReleaseFrameLengthControl、SetFrameLength、TakeFrameLengthControl。取得设置设备配置函数：ClearFeature、SetDescriptor、GetDescriptor、SetFeature、GetInterface、SyncFrame、SetInterface、GetStatus。

与USB进行交互的实现方法相关的多任务函数：TranslateStringDescr、LoadGenericInterfaceDriver、UnRegister NotificationRoutine、FindInterface、RegisterClientDeviceId、Register NotificationRoutine、OpenClientRegister Key、GetDeviceInfo、Get USBDVersion、RegisterClientSettings。

为了实现USB驱动程序和USBD之间的交互，可动态连接库中设置入口点。入口点主要有两个作用：使USBD模块能与外部设备交互和使驱动程序能创建和管理任何可能需要的注册键。USB设备驱动程序要求的入口点的相关函数有：USBDeviec Attach、USBInstallDriver和USBUninstallDriver。

11.3.3 ARM电子白板USB接口驱动的设计与实现

常见的Windows CE.NET下USB设备驱动程序的编写有三种方法：流接口函数、使用现有的Window CE.NET的应用程序接口和创建指定到特定的USBD的用户指定的API，在本文中的USB驱动设计采用的是流接口驱动程序，下面就介绍驱动开发的过程。

11.3.3.1 USB设备驱动加载

驱动加载的流程如图11-25所示。当USB设备（电子白板）接到主机（USB host，基于ARM电子白板数据处理器）上时，操作系统就会根据它的信息去从注册表里查找驱动相关信息，在HKLM\Drivers\Usb\LoadClients下面会有一些主键Group1_ID\Group2_ID\Group3_ID\DeviceID，而DeviceID下面有一个字符串Dll=DriverFile.dll，如果找到匹配的注册表信息，系统就会加载DriverFile.dll，否则就会提示用户输入一个驱动名称。

图11-25　USB驱动加载流程

在系统开发的过程中，定制系统成功后插上电子白板，弹出了要求用户输入驱动名称的对话框，说明系统没有能够根据注册表定位到驱动程序dll，所以需要输入我们自己编写的驱动程序名称，在输入名称后系统就会调用用户的驱动程序文件，下面介绍下驱动加载时必须提供的几个接口函数。

（1）首先要调用函数USBInstallDriver，主要用于创建一个驱动程序加载所需要的注册表信息，例如读写超时、设备名称等。函数如下：

在这个函数中调用了USBD.dll中的RegisterClientDriverID和RegisterClientSettings这两个函数来写注册表，要注意的一点是在RegisterClientSettings的参数中，给的USB_DRIVER_SETTINGS（内有9个ID）如果和设备的ID对不上，结果就是系统仍然不能够通过注册表信息加载你的驱动程序，所以，那个提示输入驱动程序的对话框还会继续弹出来，但是USBInstallDriver成功返回的话，其中写入注册表的信息是成功写入了的。在USBInstallDriver函数调用完后，驱动程序dll会被释放掉，然后系统再读取注册表信息去找匹配的驱动来加载，所以才会出现上述ID不匹配就会继续提示输入驱动名称的情况。因此如果写入的USB_DRIVER_SETTINGS是和设备匹配的，系统就会加载相应的驱动，然后开始下一步的工作。

（2）调用驱动DLL中的USBDeviceAttach入口函数，工作流程如图11-26所示，其作用有三个：

图11-26　USBDeviceAttach函数处理流程

①当USB设备连接到计算机上时，USBD模块就会调用此函数，这个函数主要用于初始化USB设备，取得USB设备信息，配置USB设备，并且申请必需的资源。

②调用ActiveDevice函数激活一个流接口，使应用程序可和驱动交互。

③调用RegisterNotificationRoutine函数注册一个设备状态回调函数，这里被注册的函数的主要功能是在设备移除时通知驱动程序停止设备，释放占用的资源。函数如下：

还需要一个处理注册的监控通知函数USBDeviceNotifications（），函数如下：

（3）调用ActiveDevice函数，依据参数lpszDevKey找到驱动程序文件，在注册表的HKEY_LOCAL_MACHINE\Drivers\Active键中增加这个设备，并且将USB驱动程序的上下文指针放到这里（即该函数的第2个参数），并且指定一个索引（设备序号），将驱动程序加载到Device Manager的进程空间。这时Device Manager将发送一个新设备插入的消息，调用该流接口驱动的DMW_Init函数。调用这个函数在注册表中找到USB驱动程序的上下文，并返回，这样对该流接口驱动的操作，就可以找到USB驱动的上下文，并且交换数据。函数如下：

以上这些工作完成之后，USB设备的信息被保存，并且USB驱动程序上下文也被流接口驱动所记载。流接口USB驱动的加载完成，那个输入驱动程序名称的对话框消失了。如果前面几个步骤中任何一步不成功，将不会使用这个驱动程序，会反复弹出这个对话框，提示输入驱动程序名称，直到这些过程全部正确完成。

11.3.3.2 USB数据传输功能的实现

在流接口驱动程序中，用户操作外部设备就像操作文件一样简单，在外围设备被认识后就要开始对它的读写操作了，这里要应用函数DMW_Open、DMW_Close、DMW_Read和DMW_Write以实现电子白板数据的传输，并分别与应用程序中的CreateFile、CloseFile、ReadFile和WriteFile对应。

1.DMW_Open打开USB设备（即电子白板）

当应用程序以打开文件的方式打开设备时，用这个函数。实现流程如图11-27所示。其工作有：首先检查设备是否在工作状态，设备接口是否已经准备好，传输的对象是否合法（其指针不能为NULL）。然后，检查文件名的长度，为0时表明只是打开设备本身，只需要增加打开的句柄数量，取消设备挂起即可；不为0时就要找到需要打开的管道消息，并将其打开标志设置为真，最后增加打开句柄的数量。函数如下：

图11-27　打开设备流程

2.DMW_Close关闭USB设备（电子白板）

当用户应用程序执行CloseFile时，驱动程序就会配合执行此函数，实现流程如图11-28所示。其工作是将要关闭的管道打开标志设置为假，然后减少打开句柄的数量。

函数如下：

图11-28　关闭设备流程

3.DMW_Read读USB设备（电子白板）

当应用程序要求读USB设备时就调用此函数，它的具体步骤是：首先初始化变量和检查系统是工作状态还是挂起，然后检查文件对象是否合法以及管道类型是批量还是实时，都正确的话就截取在DMW_Open函数中初始化好管道信息。然后将获取的信息填入到用户自定义的结构中以供应用程序读。处理流程见图11-29所示。部分函数如下：

图11-29　读USB流程

4.DMW_Write写USB设备（电子白板）

当应用程序要求写USB设备时就调用此函数，其工作方式和DMW_Read很相似，在此不再赘述。函数如下：

11.3.3.3 USB驱动卸载

在电子白板从ARM处理器上移出的时候，需要卸载设备，释放它占用的系统资源，这时候就需要调用USBUninstallDriver函数，它主要用于释放驱动程序所占用的资源，以及删除USBInstallDriver函数创建的注册表等。它使用自己的函数接口UnRegisterClientDriverID（）和UnRegisterClientSettings（）来做相应的处理。

卸载流程如图11-30所示。

图11-30　驱动卸载流程

在驱动加载的时候，已经注册过USBDeviceNotification回调函数，它传入的参数是驱动程序上下文，依据这个就可以向设备发送信息以停止设备，停止驱动程序正在进行的线程，关闭事件、临界区等信号，释放申请的内存。这样，就完成了驱动程序的卸载。对于流接口驱动，在卸载的时候会调用DMW_Deinit函数，这个函数的参数也是驱动程序上下文，也可以在这里完成资源释放工作，这里选择在USBDeviceNotification释放，所以DMW_Deinit就不用填写了。在设备资源释放之后，将调用USB_UninstallDriver函数，使用USBD里面的操作注册表的函数清理注册表中添加的HKEY_LOCAL_MACHINE\Drivers\Active中的项目。函数如下：

11.3.3.4 驱动调试

驱动程序是系统执行各种操作不可或缺的基石，因此其设计工作中测试一环尤其重要，为检验本文所编写驱动的可用性，本节给出实际测试结果。

在电子白板插入ARM开发板的主USB口并驱动成功后，用API函数编写一个简单的测试程序，读取从USB口传入的数据，看是否和预期的一致，以测试它的数据传输功能是否实现了。示波器测得DM4604红外发射周期为20.69 ms，即每秒发送48.33组数据，实验测得驱动程序12.96 s取到630组数据，平均每秒48.61组数据，可证明驱动程序没有丢数据，和我们预期要得的数据是一致的，说明驱动实现了预期功能，截取其中10组数据。