USB在同步相量测量单元中的应用

　　4.6 标准请求处理程序

　　标准设备请求是由USB协议决定的，由主机发出，以数据包的形式传送到单片机。当单片机接收到这些标准设备请求时就转入相应的处理程序。其过程包括：①获取状态。②清除特性。③设置特性。④设置地址。⑤获取设备描述符。⑥设置配置。⑦获取配置信息。⑧获取接口信息。⑨设置接口。⑩同步帧。其中同步帧用来设置和报告一个端点的同步帧，在同步传输中才使用，如果设备不支持这个请求，返回停止标志。

　　4.7 主循环程序

　　主循环程序主要功能是设置单片机的初始化，以及设定各个相关子程序的入口。由于使用了中断服务程序和一系列的命令接口子程序，主循环程序中涉及USB接口的部分只是设定相关的寄存器。

　　5 USB驱动程序上位机部分

　　5.1 驱动程序基本概念

　　主机驱动程序的功能是将硬件与用户应用程序连接起来。编写的方法有多种，可以直接与硬件相连接，在应用程序中直接读写系统应将，或者将与硬件直接交换数据的底层工作交给操作系统自动完成，应用程序象读写普通文件一样完成对硬件设备的操作。前一种方法的代码开销少，但是编写的工作量非常大，移植性也较差。后一种方法需要大量库函数支持，但编写较为简单，且移植性好，甚至只需少许修改就可以完成对另一种硬件的支持。在本系统中使用的是由厂商提供的驱动程序，为了充分说明USB系统的工作，还是有必要对主机驱动程序的工作方式做一个介绍。

　　从驱动程序的角度出发，每个设备都被看成若干个设备对象，这些设备对象的来历各不相同，每个对象都有驱动程序与之对应。它们根据一定的规则组成设备对象堆栈，也就是对应的驱动程序堆栈。处于最底层的是物理设备对象，它一般由总线生成，驱动程序到达这里的时候，总线只是按照标准作一些动作，即可完成对设备物理上的操作。一个设备只能有一个物理设备对象，但可以有若干个其它的设备对象。功能设备对象是由所编写的驱动程序生成的，它负责从逻辑上操作设备。其它的层次设备对象可以处于功能设备对象的上面或下面，它由另一些驱动程序或者其它的系统组件生成，可以记录一些设备信息，但层次设备对象不是必须的。由于驱动程序的这种层次结构，在编写驱动程序的时候不必考虑内存分配、IO端口配置、DMA申请等。Windows将资源申请全部自动化，由总线完成，编写驱动程序时只要考虑控制设备本身即可。

　　5.2 即插即用设备状态及它们之间的转换

　　USB接口设备的一个显著特点就是接入或者拔出时不需要关闭主机和重新启动系统，而是可以在系统运行时直接插入或者拔出。这与USB接口的硬件设置有关，USB接口是通过检测接口上拉电阻来判别是否有设备存在的。当然，还必须有相应的驱动程序来完成对此功能的支持。下面就将简要描述一个设备完成即插即用的过程。

　　用户将设备插入计算机，此时设备还没有被系统检测到。要开始对设备进行软件配置，必须由即插即用管理器以及总线驱动对设备进行枚举。即插即用管理器，有时还可能要在用户模式下的组件工作，检测出设备的驱动程序，包括功能驱动程序以及其它的层次驱动程序。如果此时驱动程序尚未调入，则即插即用管理器调用设备插入例程。驱动程序完成初始化之后，接着必须对设备进行初始化。即插即用管理器调用驱动程序中添加设备的例程来初始化该驱动程序控制的每个设备。当一个驱动程序从即插即用管理器中收到开始设备的请求时，驱动程序使设备启动并且做好处理IO操作。在Windows2000及更高版本的操作系统中，和停止有关的请求只有在重新分配硬件资源的时候才会使用。意外卸载时是指硬件在物理上被卸载(热拔出)，驱动程序处理这个请求使系统的损失尽可能降低。硬件卸载时，调用相应的卸载请求，使得该设备在软件上也不可用。如果不对意外卸载进行处理，就有可能造成硬件在物理意义上已不存在，但在系统逻辑中依然存在，造成系统访问该设备的时候出现错误，严重的情况可能会造成处理器进入死循环。当在软件意义上对设备进行停止时，需要等其它请求都操作完毕后才能进行。

　　5.3 驱动程序结构

　　USB驱动程序从结构上可以分成两大部分，驱动程序入口以及处理各个事件的例程。驱动程序入口是由系统定义的一组常数，该部分主要完成两件工作：一件是将注册表项复制到一个全局变量中；另一件是给不同的设备事件指示处理例程。剩下的工作就是按照这些设备事件编写各自的例程。这些设备事件主要包括下面几个部分：

　　(1)打开文件：当用户以打开文件的名义打开设备准备读写的时候，调用该部分例程进行准备。

　　(2)关闭文件：当用户关闭文件(关闭设备)的时候，调用该例程清扫系统。

　　(3)即插即用处理：处理即插即用相关的事件，该部分例程包括许多硬件相关的子程序，具体功能见第2节。

　　(4)处理读操作：当用户读取文件时，调用该例程将接口芯片缓冲区内的信息返回主机。

　　(5)处理写操作：当用户写文件时，调用该例程将数据以包的形式发送到接口芯片。

　　(6)设备操作：该部分例程完成对设备硬件的控制，一般含有IO控制码，这些控制码在用户头文件中定义，该例程根据不同的IO控制码，完成对设备的各项控制任务。

　　(7)驱动程序初始化：当第一次安装硬件时调用该部分例程，创建物理设备对象。对所涉及的各个变量进行初始化。这部分程序一般操作系统中有自带。

　　(8)驱动程序的卸载：用于清除硬件在系统中留下的痕迹，释放全局变量中注册表路径字符串所占用的内存，将资源归还系统。

　　(9)电源管理：所有和电源相关的例程都由这里发出，它发出的请求可以是指定一种新的电源状态，或者查询更改一种状态是否可靠。此部分对于总线供电的USB设备较为重要，涉及设备的挂起和唤醒等操作。在本系统中此部分无作用，所有下位机设备都是自供电形式的，设备处于长时工作状态。

　　5.4 USB设备读写

　　USB设备的读写操作是大部分用户主要关心的内容。由于设备驱动程序的作用，用户应用程序和USB设备的读写操作变的非常简单，用户打开USB设备就像打开文件一样。这是在添加设备中申请了一个符号链接，并在启动设备例程中将此链接激活而实现的。USB中的读写操作分为四种：

　　(1)控制型：控制型传输主要为对USB本身的配置，前面所描述的USB配置实际上都是通过控制传输实现的。

　　(2)批量型：批量型传输用来处理大量的对时间要求不紧迫的数据。底层协议保证了无差错的传输，但不保证传输时延。

　　(3)中断型：中断型传输对服务时间有较强的限制，但一次传输的数据量不多，主要为一些需要实时相应的消息。

　　(4)同步型：同步传输可以保证传输时延、保证带宽和保证恒定的数据传输速率，但是在传送失败的情况下。不使用“重试”来传输数据，因而可能会有一定的出错概率。

　　对USB接口的读写是按照与数据文件读写相同的方式进行的，第一步要打开文件，即打开设备。当用户以打开文件的名义打开设备时，首先要检查设备的状态，看设备是否处于工作状态，设备的接口信息是否已经准备好。接着检查从上面传下来的文件对象的合法性(指针不为空)。然后检查文件名的长度，当为0时，说明打开的只是设备本身；不为0时说明打开的是某个管道，调用管道相关例程，将管道明转换为指向对应管道综合信息的指针即可。读写USB设备实际上是调用同一个传输例程的，所区别的是传输方向符不同，由于通讯双方遵守的都是USB协议，所有的数据包的格式都是一致的，所以这没有什么问题。驱动程序控制的上位机读写过程和单片机的情况类似，所不同的是，单片机使用的接口芯片将数据放入硬件缓冲区内，而上位机的驱动程序则会构建一个虚拟的缓冲区来完成相同的工作。当要发送的数据大于缓冲区的容量时，同单片机的情况一样，也要对数据进行分割。当数据发送完毕之后，例程返回一个发送成功的标志。

　　5.5 USB上位机应用程序设计简介

　　编写好驱动程序以后，要在应用程序中调用USB设备，其做法就与调用硬件类似，可以使用WIN32 API函数像调用程序文件一样对设备进行读写，也可以使用如同串口的mscomm那样的控件来实现。由于本系统的上位机程序是用VB开发的，显然调用成品动态链接库能减少很多工作量。这里就调用由广州周立功单片机发展有限公司开发的称为easyd12.dll的动态链接库。

　　6 结论

　　USB接口的驱动程序编写是一项繁琐的工作，由于硬件条件的限制，上述程序仅在仿真器上运行通过，无法实地调试，其中必然存在很多漏洞和不足。USB接口本身是并不是为智能仪表开发的，作为批量数据传输用的USB总线在智能仪表上使用显得有些复杂。在更高性能的通用型总线出现以前，为了实现信息的高速传输使用USB还是一个性价比较好的方案。本系统只使用了USB的部分功能，付出的软硬件资源代价却与一个完整功能的USB传输系统没有多大区别。如果能开发出一种比USB总线更简便易用的通用型总线，那一定会引起智能仪表的革命。实际上，现在用驱动程序完成的工作完全可以用纯硬件的方式来实现，不过目前而言，代价必然较大。如果能找到一个方法来直接控制USB接口各个引脚的电平，那么即使用中规模集成电路也可以完成同步串行通讯的工作，遗憾的是，在整个设计过程中，本人始终没有发现这种方法，涉及USB协议以及计算机主板上相关控制器的最底层内容仍然无法洞悉。