USB设备驱动概述 分类： USB OTG驱动 windows驱动程序WDM 2015-06-10 18:15 426人阅读 评论(0) 收藏

时间  2019-12-20
标签 usb 设备 驱动 概述 分类 otg windows 驱动程序 wdm 阅读 评论 收藏 栏目 USB 繁體版
原文   原文链接

 

第17章  USB设备驱动

USB设备驱动和PCI设备驱动是PC中最主要的两种设备驱动程序。与PCI协议相比，USB协议更复杂，涉及面较多。本章将介绍USB设备驱动开发。首先介绍USB协议，使读者对USB协议有个总体认识。而后介绍USB设备在WDM中的开发框架。因为操做系统的USB总线驱动程序提供了丰富的功能调用，所以开发USB驱动开发变得相对简单，只须要调用USB总线驱动接口。

17.1  USB总线协议

USB总线协议比PCI协议复杂的多，涉及USB物理层协议，又涉及USB传输层协议等。对于USB驱动程序开发者来讲，不须要对USB协议的每一个细节都很清楚。本节概要地介绍USB总线协议，并对驱动开发者须要了解的地方进行详细介绍。

17.1.1  USB设备简介

USB即通用串行总线（UniversalSerial Bus），是一种支持即插即用的新型串行接口。也有人称之为“菊链（daisy－chaining）”，是由于在一条“线缆”上有连接127 个设备的能力。USB要比标准串行口快得多，其数据传输率可达每秒4Mb~12Mb（而老式的串行口最可能是每秒115Kb）。除了具备较高的传输率外，它还能给外围设备提供支持。

须要注意的是，这不是一种新的总线标准，而是计算机系统链接外围设备（如键盘、鼠标、打印机等）的输入/输出接口标准。到如今为止，计算机系统链接外围设备的接口尚未统一的标准，例如，键盘的插口是圆的、链接打印机要用9针或25针的并行接口、鼠标则要用9针或25针的串行接口。USB能把这些不一样的接口统一块儿来，仅用一个4针插头做为标准插头，如图17-1所示。经过这个标准插头，采用菊花链形式能够把全部的外设链接起来，而且不会损失带宽。USB正在取代当前PC上的串口和并口。

 

图17-1  USB的四条传输线

以USB方式链接设备时，全部的外设都在机箱外链接，链接外设没必要再打开机箱；容许外设热插拔，而没必要关闭主机电源。USB采用“级联”方式，即每一个USB设备用一个USB 插头链接到另外一个外设的USB插座上，而其自己又提供一个USB插座供下一个USB外设链接用。经过这种相似菊花链式的链接，一个USB控制器能够链接多达127个外设，而每一个外设间距离（线缆长度）可达5米。USB能智能识别USB链上外围设备的插入或拆卸。

它可以使多个设备在一个端口上运行，速度也比如今的串行口或并行口快得多，并且其总的连线在理论上说能够无限延长。对PC来讲，以上这些都是一些可贵的优势，由于再也不须要PS/2端口、MIDI端口等各类不一样的端口了，还能够随时随地在各类设备上任意插拔。能够在一个端口上运行鼠标、控制手柄、键盘以及其余输入装置（例如数码相机），并且，也没必要从新启动系统去作这些工做。如今USB设备正在快速增多，且因为操做系统已内置支持USB的功能，于是用户如今就能够方便地使用。显然，USB为PC的外设扩充提供了一个很好的解决方案。

目前USB技术的发展，已经容许用户在不使用网卡、HUB的状况下，直接经过USB技术将几台计算机链接起来组成小型局域网，用户只须要给各台计算机起个名字就能够开始工做。这种网络具有Ethernet网络的各类优势，同时少了Ethernet网络的许多限制。假设一位用户上班时使用笔记本电脑，回家时使用PC机，为实现数据传输，他能够经过采用USB技术的接口将两部电脑链接起来交换资源，其数据传输速度可达12Mbps，这是传统串行口没法比拟的。并且用户在组网的时候根本无须考虑DIP、IRQ等问题。此类技术除支持兼容Ethernet的软硬件外，也支持标准的网络通讯协议，包括IPX/SPX、NetBEUI和TCP/IP，这为经过USB技术组成的小局域网链接至大型网络或Internet提供了条件。

17.1.2  USB链接拓扑结构

USB设备的链接如图17-2所示，对于每一个PC来讲，都有一个或者多个称为Host控制器的设备，该Host控制器和一个根Hub做为一个总体。这个根Hub下能够接多级的Hub，每一个子Hub又能够接子Hub。每一个USB做为一个节点接在不一样级别的Hub上。

（1）USB Host控制器：每一个PC的主板上都会有多个Host控制器，这个Host控制器其实就是一个PCI设备，挂载在PCI总线上。Host控制器的驱动由微软公司提供，如图17-3所示，这是笔者PC中的Host控制器及USB Hub的驱动。值得注意的是，这里Host分别有两种驱动，一种是1.0，另外一种是2.0，分别对应着USB协议1.0和USB协议2.0。

 

（点击查看大图）图17-2  USB链接拓扑结构

（2）USB Hub：每一个USBHost控制器都会自带一个USB Hub，被称为根(Root)Hub。这个根Hub能够接子(Sub)Hub，每一个Hub上挂载USB设备。通常PC有8个USB口，经过外接USB Hub，能够插更多的USB设备。当USB设备插入到USBHub或从上面拔出时，都会发出电信号通知系统。这样能够枚举USB设备，例如当被插入的时候，系统就会建立一个USB物理总线，并询问用户安装设备驱动。如图17-4所示为一个典型的USB Hub的示意图。

 

（点击查看大图）图17-3  USB Host和USB Hub驱动 

 

 

（点击查看大图）图17-4  USB Hub示意图

（3）USB设备：USB设备就是插在USB总线上工做的设备，广义地讲USB Hub也算是USB设备。每一个根USB Hub下能够直接或间接地链接127个设备，而且彼此不会干扰。对于用户来讲，能够当作是USB设备和USB控制器直接相连，之间通讯须要知足USB的通讯协议。

有的USB设备功能单一，直接挂载在USB Hub上。而有的USB设备功能复杂，会将多个USB功能连在一块儿，成为一个复合设备，它甚至能够本身内部带一个Hub，这个Hub下接多个USB子设备，其和多个子设备做为一个总体当作一个USB设备，如图17-5所示。

以上是USB的物理拓扑结构，但对于用户来讲，能够略去USB Hub的概念，或者说USB Hub的概念对于用户能够当作是透明的。用户只须要将USB设备理解成一个USB Host链接多个逻辑设备。可能逻辑设备1和逻辑设备2是集中在第一个物理设备里，例若有的手机链接计算机后，系统会当作多个USB设备加载。所以，做为用户须要用如图17-6所示的逻辑拓扑结构理解USB拓扑结构。

 

图17-5  符合设备

 

 

图17-6  USB逻辑拓扑结构

但对于具体USB设备来讲，每一个USB设备的传输绝对不会影响其余USB设备的传输。例如，在有USB设备传输的时候，其余USB设备的带宽不会被占用。对于USB设备来讲，每一个USB设备是直接链接到USB Host控制器上的。所以，应该用如图17-7所示的视角考虑USB设备的通讯。

 

图17-7  用户对USB设备的观察

17.1.3  USB通讯的流程

USB的链接模式是Host和Devcie的链接模式，它不一样于早期的串口和并口，全部的请求必须是Host向Device发出，这就使Host端设计相对复杂，而Device端设计相对简单。Host端会在主板的南桥设计好，而Device的厂商众多，厂商只须要遵循USB协议，重点精力能够放在设备的研发上，而与PC的通讯不用过多考虑。

在USB的通讯中，能够当作是一个分层的协议。分为三个层次，即最底层USB总线接口层、USB设备层、功能通讯层，如图17-8所示。

 

图17-8  USB协议

以USB摄像头设备为例，视频播放软件想经过USB总线获得USB摄像头捕捉的视频数据，这就至关于在功能层上。Clinet SW是视频播放软件，Function是USB摄像头。而这些数据的读取须要USB设备层提供的服务，在这一层上，主要是USB设备的驱动调度Host控制器向USB摄像头发出读请求。每一个USB设备会有多个管道，使用哪一个管道，传输的大小都须要指定。这个层次的USBSystem SW就是USB摄像头的驱动程序。而在USB设备一端通常会有小单片机或者处理芯片负责响应这种读请求，而这一层的传输又依赖于USB总线接口层的服务。在这一层，彻底是USB的物理协议，包括如何分红更小的包（packages）传输，如何保证每次包传输不丢失数据等。

对于USB设备驱动程序员，主要是工做在USB设备层，向“上”对应用程序提供读写等接口，向“下”将读取某个管道的请求发往USB Host控制器驱动程序，它实现了最底层的传输请求。

对于每一个USB设备，都有一个或者多个的接口（Interface），每一个Interface都有多个端点（Endpoints），每一个端点经过管道（Pipes）和USB Host控制器链接。每一个USB设备都会有一个特殊的端点，即Endpoint0，它负责传输设备的描述信息，同时也负责传输PC与设备之间的控制信息，如图17-9所示。

 

图17-9  USB管道与端点

17.1.4  USB四种传输模式

当USB插入USB总线时，USB控制器会自动为该USB设备分配一个数字来标示这个设备。另外，在设备的每一个端点都有一个数字来代表这个端点。
USB设备驱动向USB控制器驱动请求的每次传输被称为一个事务（Transaction），事务有四种类型，分别是Bulk Transaction、Control Transaction、Interrupt Transaction和IsochronousTransaction。每次事务都会分解成若干个数据包在USB总线上传输。每次传输必须历经两个或三个部分，第一部分是USB控制器向USB设备发出命令，第二部分是USB控制器和USB设备之间传递读写请求，其方向主要看第一部分的命令是读仍是写，第二部分有时候能够没有。第三部分是握手信号。如下针对这四种传输，分别进行讲解。

1．Bulk传输事务

顾名思义，改种事务传输主要是大块的数据，传送这种事务的管道叫作Bulk管道。这种事务传输的时候分为三部分，如图17-10所示。第一部分是Host端发出一个Bulk的令牌请求，若是令牌是IN请求则是从Device到Host的请求，若是是OUT令牌，则是从Host到Device端的请求。
第二部分是传送数据的阶段，根据先前请求的令牌的类型，数据传输有多是IN方向，也有多是OUT方向。传输数据的时候用DATA0和DATA1令牌携带着数据交替传送。

第三部分是握手信号。若是数据是IN方向，握手信号应该是Host端发出，若是是OUT方向，握手信号应该是Device端发出。握手信号能够为ACK，表示正常响应，也能够是NAK表示没有正确传送。STALL表示出现主机不可预知的错误。
在第二部分，即传输数据包的时候，数据传送由DATA0和DATA1数据包交替发送。数据传输格式DATA1和DATA0，这两个是重复数据，确保在1数据丢失时0能够补上，不至于数据丢失。如图17-11所示。

 

（点击查看大图）图17-10  Bulk传输

 

 

图17-11  Bulk传输时的令牌

2．控制传输事务

控制传输是负责向USB设置一些控制信息，传送这种事务的管道是控制管道。在每一个USB设备中都会有控制管道，也就是说控制管道在USB设备中是必须的。控制传输也分为三个阶段，即令牌阶段、数据传送阶段、握手阶段，如图17-12所示。

 

图17-12  控制传输事务

3．中断传输事务

在USB设备中，有种处理机制相似于PCI中断的机制，这就是中断事务。中断事务的数据量很小，通常用于通知Host某个事件的来临，例如USB鼠标，鼠标移动或者鼠标单击等操做都会经过中断管道来向Host传送事件。在中断事务中，也分为三个阶段，即令牌阶段、数据传输阶段、握手阶段，如图17-13所示。

 

（点击查看大图）图17-13  中断传输事务

4．同步传输事务

USB设备中还有一种事务叫同步传输事务，这种事务能保证传输的同步性。例如，在USB摄像头中传输视频数据的时候会采用这种事务，这种事务能保证每秒有固定的传输量，但与Bulk传输不一样，它容许有必定的误码率，这样符合视频会议等传输的需求，由于视频会议首先要保证明时性，在必定条件下，容许有必定的误码率。同步传输事务有只有两个阶段，即令牌阶段、数据阶段，由于不关心数据的正确性，故没有握手阶段，如图17-14所示。

 

图17-14  同步传输事务

17.2  Windows下的USB驱动

在Windows上开发USB驱动相对来讲比较简单，主要是由于微软已经提供了完备的USB总线驱动，程序员编写的设备驱动只需调用总线驱动便可。在Windows上还有一些工具软件能够帮助开发者查看USB的各种信息，包括设备描述符、配置描述符等。固然，这些描述符在驱动中也会用到。本节将介绍这些工具软件，并介绍这些描述符。

17.2.1  观察USB设备的工具

在学习编写USB驱动以前，有几个USB查看工具须要向读者介绍一下，经过用这些工具能方便地学习USB协议。

首先须要介绍的就是DDK中提供的工具，该工具叫usbview，位于DDK的子目录src\wdm\usb\usbview下，须要用DDK编译环境进行编译。如图17-15所示为usbview的界面，在笔者的计算机里插入了一个USB移动硬盘，在这个软件中已经清楚地列举除了该USB设备的各个信息，如图设备描述符、管道描述符等。

 

（点击查看大图）图17-15  USBView

另外一个有用的工具是BusHound，如图17-16所示。BusHound用于监视USB设备的传输数据，它的实现原理是在USB设备驱动之上加载一层过滤驱动程序，将IRP进行拦截，所以能够观察到全部USB数据的传输。使用该软件时须要指明监视哪一种USB设备，如图17-16所示，在须要监视的设备上打钩。笔者这里监视的是一个USB移动硬盘。另外，在下面会列出该设备的基本信息，如管道0是控制管道，管道1是输出管道，管道2是输入管道。

 

（点击查看大图）图17-16  BusHound

该软件将USB的传输彻底进行监视，包括每一个USB的各个管道中的传输状况，都一一进行记录，很是有利于调试驱动。如图17-17所示，Device一栏中标识是何种设备，例如27.2意味着第27号设备的第2号管道。Phase一栏标识传输是输入仍是输出。在Data一栏中记录着一次传输的具体内容。

 

（点击查看大图）图17-17  BusHound监视数据传输

17.2.2  USB设备请求

USB的请求是经过控制管道传输的，请求是8个字节，按照如表17-1所示的排列发送：

表17-1

偏移量

变量

大小

数值

描    述

0

bmRequestType

1字节

位图

第7位: 数据方向位

0 = 主机到设备

1 = 设备到主机

第6-5位:类型

0 = 标准

1 = 类

2 = 厂商自定义

3 = 保留

第4-0位:接收者

0 = 对设备的请求

1 = 对接口的请求

2 = 对管道（端点）的请求

3 = 其余

4-31 = 保留

1

bRequest

1字节

数值

请求类别

2

wValue

2字节

数值

不一样请求含义不一样

4

wIndex

2字节

数值

不一样请求含义不一样

6

wLength

2字节

数值

表示须要有多少数据返回

其中，bRequest表明不一样的USB请求，它们分别是如下的几种请求，定义在DDK的usb100.h文件中：

#define USB_REQUEST_GET_STATUS                   0x00
#define USB_REQUEST_CLEAR_FEATURE                0x01
#define USB_REQUEST_SET_FEATURE                 0x03
#define USB_REQUEST_SET_ADDRESS                   0x05
#define USB_REQUEST_GET_DESCRIPTOR                0x06
#define USB_REQUEST_SET_DESCRIPTOR               0x07
#define USB_REQUEST_GET_CONFIGURATION           0x08
#define USB_REQUEST_SET_CONFIGURATION          0x09
#define USB_REQUEST_GET_INTERFACE                0x0A
#define USB_REQUEST_SET_INTERFACE                0x0B

17.2.3  设备描述符

在控制管道发起USB设备请求，其中很常见的请求是USB_REQUEST_GET_ DESCRIPTOR，即请求USB设备回答设备或者管道描述符。在请求描述符时，bmRequestType能够指定是针对设备仍是针对管道的。

当请求设备描述符后，设备会回答主机该设备的设备描述符，设备描述符是一种固定的数据结构，它定义在DDK中的usb100.h文件中。

typedef struct _USB_DEVICE_DESCRIPTOR {
UCHAR bLength;
UCHAR bDescriptorType;
USHORT bcdUSB;
UCHAR bDeviceClass;
UCHAR bDeviceSubClass;
UCHAR bDeviceProtocol;
UCHAR bMaxPacketSize0;
USHORT idVendor;
USHORT idProduct;
USHORT bcdDevice;
UCHAR iManufacturer;
UCHAR iProduct;
UCHAR iSerialNumber;
UCHAR bNumConfigurations;
} USB_DEVICE_DESCRIPTOR, *PUSB_DEVICE_DESCRIPTOR;

bLength：设备描述符的bLength域应等于18。

bDescriptorType：bDescriptorType域应等于1，以指出该结构是一个设备描述符。

bcdUSB：bcdUSB域包含该描述符遵循的USB规范的版本号（以BCD编码）。如今，设备可使用值0x0100或0x0110来指出它所遵循的是1.0版本仍是1.1版本的USB规范。

bDeviceClass：指出设备类型。

bDeviceSubClass：指出设备子类型。

bDeviceProtocol：指出设备类型所使用的协议。

bMaxPacketSize0：设备描述符的bMaxPacketSize0域，给出了默认控制端点（端点0）上的数据包容量的最大值。

idVendor：厂商代码。

idProduct：厂商专用的产品标识。

bcdDevice：bcdDevice指出设备的发行版本号（0x0100对应版本1.0）。

iManufacturer、iProduct、iSerialNumber：iManufacturer、iProduct和iSerialNumber域指向一个串描述符，该串描述符用人类可读的语言描述设备生产厂商、产品和序列号。这些串是可选的，0值表明没有描述串。若是在设备上放入了序列号串，Microsoft建议应使每一个物理设备的序列号惟一。

bNumConfigurations：bNumConfigurations指出该设备能实现多少种配置。Microsoft的驱动程序仅工做于设备的第一种配置（1号配置）。
如图17-18所示为笔者用BusHound截获的USB移动硬盘的请求设备描述符，前面已经介绍过，在控制管道中，传输分为三个阶段。第一阶段是令牌阶段，这里Host向设备发送“80 06 00 01 00 00 12 00”8个字节，能够参见表17-1中的解释。第二阶段是数据传输阶段，方向是由设备传给主机，这个例子中设备给主机传递了18（0x12）个字节，这18个字节对应着USB_DEVICE_DESCRIPTOR数据结构。第三阶段是握手阶段，在BusHound软件中没有体现出来。

 

（点击查看大图）图17-18  用BusHound抓取设备描述符

17.2.4  配置描述符

每一个设备有一个或多个配置描述符，它们描述了设备能实行的各类配置方式。DDK中定义的配置描述符结构以下：

typedef struct _USB_CONFIGURATION_DESCRIPTOR {
UCHAR bLength;
UCHAR bDescriptorType;
USHORT wTotalLength;
UCHAR bNumInterfaces;
UCHAR bConfigurationValue;
UCHAR iConfiguration;
UCHAR bmAttributes;
UCHAR MaxPower;
} USB_CONFIGURATION_DESCRIPTOR, *PUSB_CONFIGURATION_DESCRIPTOR;

bLength：bLength应该为9。

bDescriptorType：bDescriptorType应该为2，便是一个9字节长的配置描述符。

wTotalLength：wTotalLength域为该配置描述符长度加上该配置内全部接口和端点描述符长度的总和。一般，主机在发出一个GET_DESCRIPTOR请求并正确接收到9字节长的配置描述符后，就会再发出一个GET_DESCRIPTOR请求并指定这个总长度。第二个请求把这个大联合描述符传输回来。

bNumInterfaces：指出该配置有多少个接口。

bConfigurationValue：bConfigurationValue域是该配置的索引值。

iConfiguration：iConfiguration域是一个可选的串描述符索引，指向描述该配置的Unicode字符串。此值为0代表该配置没有串描述符。

bmAttributes：bmAttributes字节包含描述该配置中设备电源和其余特性的位掩码。

MaxPower：MaxPower域中指出要从USB总线上获取的最大电流量。

如图17-19所示为笔者用BusHound截获的USB移动硬盘的请求配置描述符。其中第一行是Host向Device发送Token令牌，而第二行是Device向Host返回的数据。

 

（点击查看大图）图17-19  用BusHound抓取设配置描述符

17.2.5  接口描述符

每一个配置有一个或多个接口描述符，它们描述了设备提供功能的接口。

 typedef struct _USB_INTERFACE_DESCRIPTOR {
UCHAR bLength;
UCHAR bDescriptorType;
UCHAR bInterfaceNumber;
UCHAR bAlternateSetting;
UCHAR bNumEndpoints;
UCHAR bInterfaceClass;
UCHAR bInterfaceSubClass;
UCHAR bInterfaceProtocol;
UCHAR iInterface;
} USB_INTERFACE_DESCRIPTOR, *PUSB_INTERFACE_DESCRIPTOR;

bLength：bLength应该为9。

bDescriptorType：bDescriptorType域应为4。

bInterfaceNumber：bInterfaceNumber是索引值。

bAlternateSetting：bAlternateSetting是索引值。用在SET_INTERFACE控制事务中以指定要激活的接口。

bNumEndpoints：bNumEndpoints域指出该接口有多少个端点，不包括端点0，端点0被认为老是存在的，而且是接口的一部分。

bInterfaceClass：bInterfaceClass为接口类。

bInterfaceSubClass：bInterfaceSubClass为子接口类。

bInterfaceProtocol：bInterfaceProtocol为协议。

iInterface：iInterface是一个串描述符的索引，0表示该接口无描述串。

如图17-20所示为笔者用BusHound截获的USB移动硬盘的请求配置描述符和接口描述符。其中第一行是Host向Device发送Token令牌，而第二行是Device向Host返回的数据。能够看出图中有一个配置描述符，后面紧接着一个接口描述符（“09 04 00 00 02 00 06 50 05”），后面还有两个接口描述符（下一节介绍）。

 

（点击查看大图）图17-20  用BusHound抓取接口描述符

17.2.6  端点描述符

接口能够没有或有多个端点描述符，它们描述了处理事务的端点。DDK中定义的端点描述符结构以下：

 typedef struct _USB_ENDPOINT_DESCRIPTOR {
UCHAR bLength;
UCHAR bDescriptorType;
UCHAR bEndpointAddress;
UCHAR bmAttributes;
USHORT wMaxPacketSize;
UCHAR bInterval;
} USB_ENDPOINT_DESCRIPTOR, *PUSB_ENDPOINT_DESCRIPTOR;

bLength：bLength应为7。

bDescriptorType：bDescriptorType应该为5。

bEndpointAddress：bEndpointAddress域编码端点的方向性和端点号。

bmAttributes：bmAttributes的低两位指出端点的类型。0表明控制端点，1表明等时端点，2表明批量端点，3表明中断端点。

wMaxPacketSize：wMaxPacketSize值指出该端点在一个事务中能传输的最大数据量。

bInterval：中断端点和等时端点描述符还有一个用于指定循检间隔时间的bInterval域。

17.3  USB驱动开发实例

本节具体介绍如何进行USB驱动的开发，本节采用的源码来源自DDK的源程序，其位置在DDK子目录的src\wdm\usb\bulkusb目录下。该示例很全面地支持了即插即用IRP的处理，也很全面地支持了电源管理，同时很好地支持了USB设备的bulk读写。若是从头开发USB驱动，每每很难达到USB驱动的稳定性，因此强烈建议读者在此驱动修改的基础上进行USB驱动开发。

17.3.1  功能驱动与物理总线驱动

DDK已经为USB驱动开发人员提供了功能强大的USB物理总线驱动（PDO），程序员须要作的事情是完成功能驱动（FDO）的开发。驱动开发人员不须要了解USB如何将请求转化成数据包等细节，程序员只须要指定何种管道，发送何种数据便可。

当功能驱动想向某个管道发出读写请求时，首先构造请求发给USB总线驱动。这种请求是标准的USB请求，被称为URB（USB Request Block），即USB请求块。这种URB被发送到USB物理总线驱动之后，被USB总线驱动所解释，进而转化成请求发往USB HOST驱动或者USB HUB驱动，如图17-21所示。

 

图17-21  总线驱动与功能驱动的关系

能够看出，USB总线驱动完成了大部分工做，并留给USB功能驱动标准的接口，即URB请求。USB驱动开发人员只须要根据不一样的USB设备的设计要求，在相应的管道中发起URB请求便可。

17.3.2  构造USB请求包

USB驱动在与USB设备通讯的时候，如在控制管道中获取设备描述符、配置描述符、端点描述符，或者在Bulk管道中获取大量数据，都是经过建立USB请求包（URB）来完成的。URB中填充须要对USB的请求，而后将URB做为IRP的一个参数传递给底层的USB总线驱动。在USB总线驱动中，可以解释不一样URB，并将其转化为USB总线上的相应数据包。

DDK提供了构造URB的内核函数UsbBuildGetDescriptorRequest，其声明以下：

VOID 
UsbBuildGetDescriptorRequest(
IN OUT PURB  Urb,
IN USHORT  Length,
IN UCHAR  DescriptorType,
IN UCHAR  Index,
IN USHORT  LanguageId,
IN PVOID  TransferBuffer  OPTIONAL,
IN PMDL  TransferBufferMDL  OPTIONAL,
IN ULONG  TransferBufferLength,
IN PURB  Link  OPTIONAL
);

Urb：用来输出的URB结构的指针。

Length：用来描述该URB结构的大小。

DescriptorType：描述该URB的类型。它能够是USB_DEVICE_DESCRIPTOR_TYPE、USB_CONFIGURATION_DESCRIPTOR_TYPE和USB_STRING_DESCRIPTOR_ TYPE。

Index：用来描述设备描述符的索引。

LanguageId：用来描述语言ID。

TransferBuffer：若是用缓冲区读取设备，TransferBuffer是缓冲区内存的指针。

TransferBufferMDL：若是用直接读取内存时，TransferBufferMDL是直接读取内存时MDL的指针。

TransferBufferLength：对于该URB所操做内存的大小。

在功能驱动中，全部与USB的通讯，都须要用这个函数建立URB，并经过IRP发送到底层USB总线驱动，如下是一个最基本的示例。

#001               UsbBuildGetDescriptorRequest(
#002                       urb, 
#003                       (USHORT) sizeof(struct _URB_
CONTROL_DESCRIPTOR_REQUEST),
#004                       USB_DEVICE_DESCRIPTOR_TYPE, 
#005                       0, 
#006                       0, 
#007                       deviceDescriptor, 
#008                       NULL, 
#009                       siz, 
#010                       NULL);

17.3.3  发送USB请求包

功能驱动将URB包构造完毕后，就能够发送到底层总线驱动上了。URB包要和一个IRP相关联起来，这就须要用IoBuildDeviceIoControlRequest建立一个IO控制码的IRP，而后将URB做为IRP的参数，用IoCallDriver将URB发送到底层总线驱动上。因为上层驱动没法知道底层驱动是同步仍是异步完成的，所以须要作一个判断。if语句判断当异步完成IRP时，用事件等待总线驱动完成这个IRP。

 #001   //该函数实现对发送URB到USB物理总线驱动
#002   NTSTATUS
#003   CallUSBD(
#004       IN PDEVICE_OBJECT DeviceObject,
#005       IN PURB           Urb
#006       )
#007   {
#008       PIRP               irp;
#009       KEVENT             event;
#010       NTSTATUS           ntStatus;
#011       IO_STATUS_BLOCK    ioStatus;
#012       PIO_STACK_LOCATION nextStack;
#013       PDEVICE_EXTENSION  deviceExtension;
#014   
#015    //首先是变量初始化
#016       irp = NULL;
#017       deviceExtension = DeviceObject->DeviceExtension;
#018       //初始化事件
#019       KeInitializeEvent(&event, NotificationEvent, FALSE);
#020    //建立IO控制码相关的IRP
#021       irp = IoBuildDeviceIoControlRequest
(IOCTL_INTERNAL_USB_SUBMIT_URB, 
#022                                           deviceExtension->
TopOfStackDeviceObject,
#023                                           NULL, 
#024                                           0, 
#025                                           NULL, 
#026                                           0, 
#027                                           TRUE, 
#028                                           &event, 
#029                                           &ioStatus);
#030   
#031       if(!irp) {
#032     //若是IRP建立失败则返回
#033           BulkUsb_DbgPrint(1, ("IoBuildDeviceIo
ControlRequest failed\n"));
#034           return STATUS_INSUFFICIENT_RESOURCES;
#035       }
#036    //获得下一层设备栈
#037       nextStack = IoGetNextIrpStackLocation(irp);
#038       ASSERT(nextStack != NULL);
#039       nextStack->Parameters.Others.Argument1 = Urb;
#040       BulkUsb_DbgPrint(3, ("CallUSBD::"));
#041       BulkUsb_IoIncrement(deviceExtension);
#042    //经过IoCallDriver将IRP发送到底层驱动
#043       ntStatus = IoCallDriver(deviceExtension->
TopOfStackDeviceObject, irp);
#044    //若是IRP是异步完成时，等待其结束
#045       if(ntStatus == STATUS_PENDING) {
#046     //等待IRP结束
#047           KeWaitForSingleObject(&event, 
#048                                 Executive, 
#049                                 KernelMode, 
#050                                 FALSE, 
#051                                 NULL);
#052           ntStatus = ioStatus.Status;
#053       }
#054       //调用结束
#055       BulkUsb_DbgPrint(3, ("CallUSBD::"));
#056       BulkUsb_IoDecrement(deviceExtension);
#057       return ntStatus;
#058   }

此段代码能够在配套光盘中本章的sys目录下找到。

17.3.4  USB设备初始化

USB驱动的初始化和通常驱动相似，首先是进入入口函数DriverEntry，在DriverEntry函数中，分别指定各个IRP的派遣函数地址、指定AddDevice例程函数地址、指定Unload例程函数地址等。

在AddDevice例程中，建立功能设备对象，而后将该对象挂载在总线设备对象之上，从而造成设备栈。另外为设备建立一个设备连接，便于应用程序能够找到这个设备。也能够根据具体须要，从注册表中读取一些必要的设置。

17.3.5  USB设备的插拔

因为USB设备驱动是基于WDM框架的，所以须要对即插即用消息进行处理。BulkUSB程序对即插即用IRP的支持很是完善，具体能够参照其代码，这里简单提一下其对插拔的处理。

插拔设备会设计4个即插即用IRP，包括IRP_MN_START_DEVICE、IRP_MN_STOP_ DEVICE、IRP_MN_EJECT和IRP_MN_SURPRISE_REMOVAL。其中，IRP_MN_START_DEVICE消息是当驱动争取加载并运行时，操做系统的即插即用管理器会将这个IRP发往设备驱动。所以，当得到这个IRP后，USB驱动须要得到USB设备类别描述符，如设备描述符、配置描述符、接口描述符、端点描述符等。并经过这些描述符，从中获取有用信息，记录在设备扩展中。

IRP_MN_STOP_DEVICE是设备关闭前，即插即用管理器发的IRP。USB驱动得到这个IRP时，应该尽快结束当前执行的IRP，并将其逐个取消掉。另外，在设备扩展中还应该有表示当前状态的变量，当IRP_MN_STOP_DEVICE来临时，将当前状态记录成中止状态。

IRP_MN_EJECT是设备被正常弹出，而IRP_MN_SURPRISE_REMOVAL则是设备非天然弹出，有可能意外掉电或者强行拔出等。在这种IRP到来的时候，应该强迫全部未完成的读写IRP结束并取消。而且将当前的设备状态设置成设备被拔掉。

17.3.6  USB设备的读写

USB设备接口主要是为了传送数据，80%的传输是经过Bulk管道。在BulkUSB驱动中，Bulk管道的读取是在IRP_MJ_READ和IRP_MJ_WRITE的派遣函数中，这样在应用程序中就能够经过ReadFile和WriteFile等API对设备进行操做了。

在IRP_MJ_READ和IRP_MJ_WRITE的派遣例程中设置了完成例程，如图17-22所示。其原理是将读写的大小分红单位为BULKUSB_MAX_TRANSFER_SIZE的若干块，依次将请求发往底层USB总线驱动。第一个块是派遣例程先设置BULKUSB_MAX_TRANSFER_SIZE大小的读写，并设置完成例程，而后将请求发往USB总线驱动。当USB总线驱动完成BULKUSB_MAX_TRANSFER_SIZE大小的读写后，会调用读写的完成例程。

这时候在完成例程中再次发起BULKUSB_MAX_TRANSFER_SIZE大小的读写，并将请求发往底层USB总线驱动，当USB总线驱动完成后，又会进入完成例程。以后发送第三个数据块，而且依此类推直到传送完毕。

 

图17-22  USB读写派遣例程与完成例程

如下是BulkUSB的读写派遣函数的部分代码：

 #001   NTSTATUS
#002   BulkUsb_DispatchReadWrite(
#003       IN PDEVICE_OBJECT DeviceObject,
#004       IN PIRP           Irp
#005       )
#006   {
#007       PMDL                    mdl;
#008       PURB                    urb;
#009       ULONG                   totalLength;
#010       ULONG                   stageLength;
#011       ULONG                  urbFlags;
#012       BOOLEAN               read;
#013       NTSTATUS               ntStatus;
#014       ULONG_PTR             virtualAddress;
#015       PFILE_OBJECT          fileObject;
#016       PDEVICE_EXTENSION     deviceExtension;
#017       PIO_STACK_LOCATION   irpStack;
#018       PIO_STACK_LOCATION   nextStack;
#019       PBULKUSB_RW_CONTEXT   rwContext;
#020       PUSBD_PIPE_INFORMATION pipeInformation;
#021   
#022    //初始化变量
#023    urb = NULL;
#024       mdl = NULL;
#025       rwContext = NULL;
#026       totalLength = 0;
#027       irpStack = IoGetCurrentIrpStackLocation(Irp);
#028       fileObject = irpStack->FileObject;
#029       read = (irpStack->MajorFunction == IRP_MJ_READ) ? TRUE : FALSE;
#030       deviceExtension = (PDEVICE_EXTENSION) DeviceObject->DeviceExtension;
#031    //....略
#032   
#033    //设置完成例程的参数
#034       rwContext = (PBULKUSB_RW_CONTEXT) ExAllocatePool(NonPagedPool,
#035                                  sizeof(BULKUSB_RW_CONTEXT));
#036    //...略 
#037       if(Irp->MdlAddress) {
#038           totalLength = MmGetMdlByteCount(Irp->MdlAddress);
#039       }
#040    //设置URB标志
#041       urbFlags = USBD_SHORT_TRANSFER_OK;
#042       virtualAddress = (ULONG_PTR) MmGetMdlVirtualAddress(Irp->MdlAddress);
#043   
#044    //判断是读仍是写
#045       if(read) {
#046           urbFlags |= USBD_TRANSFER_DIRECTION_IN;
#047       }
#048       else {
#049           urbFlags |= USBD_TRANSFER_DIRECTION_OUT;
#050       }
#051   
#052    //设置本次读写的大小
#053       if(totalLength > BULKUSB_MAX_TRANSFER_SIZE) {
#054           stageLength = BULKUSB_MAX_TRANSFER_SIZE;
#055       }
#056       else {
#057           stageLength = totalLength;
#058       }
#059   
#060    //创建MDL
#061       mdl = IoAllocateMdl((PVOID) virtualAddress,
#062                           totalLength,
#063                           FALSE,
#064                           FALSE,
#065                           NULL);
#066    //将新MDL进行映射
#067       IoBuildPartialMdl(Irp->MdlAddress,
#068                         mdl,
#069                         (PVOID) virtualAddress,
#070                         stageLength);
#071   
#072    //申请URB数据结构
#073       urb = ExAllocatePool(NonPagedPool,sizeof
(struct _URB_BULK_OR_INTERRUPT_ TRANSFER));
#074   
#075    //创建Bulk管道的URB
#076       UsbBuildInterruptOrBulkTransferRequest(
#077                               urb,
#078                               sizeof(struct _URB_BULK_OR_INTERRUPT_TRANSFER),
#079                               pipeInformation->PipeHandle,
#080                               NULL,
#081                               mdl,
#082                               stageLength,
#083                               urbFlags,
#084                               NULL);
#085   
#086    //设置完成例程参数   
#087       rwContext->Urb             = urb;
#088       rwContext->Mdl             = mdl;
#089       rwContext->Length          = totalLength - stageLength;
#090       rwContext->Numxfer         = 0;
#091       rwContext->VirtualAddress  = virtualAddress + stageLength;
#092       rwContext->DeviceExtension = deviceExtension;
#093    //设置设备堆栈
#094       nextStack = IoGetNextIrpStackLocation(Irp);
#095       nextStack->MajorFunction = IRP_MJ_INTERNAL_DEVICE_CONTROL;
#096       nextStack->Parameters.Others.Argument1 = (PVOID) urb;
#097       nextStack->Parameters.DeviceIoControl.IoControlCode = 
#098                                                IOCTL_INTERNAL_USB_SUBMIT_URB;
#099    //设置完成例程
#100       IoSetCompletionRoutine(Irp, 
#101                              (PIO_COMPLETION_ROUTINE)BulkUsb_ReadWriteCompletion,
#102                              rwContext,
#103                              TRUE,
#104                              TRUE,
#105                              TRUE);
#106    //将当前IRP阻塞
#107       IoMarkIrpPending(Irp);
#108    //将IRP转发到底层USB总线驱动
#109       ntStatus = IoCallDriver(deviceExtension->TopOfStackDeviceObject,
#110                               Irp);
#111    //...略去对不成功时的处理
#112       return STATUS_PENDING;
#113   }

此段代码能够在配套光盘中本章的sys目录下找到。

17.4  小结

本章介绍了USB总线协议的基本框架，其中包括USB总线的拓扑结构，USB通讯的流程，还有USB的四种传输模式。笔者用一些工具软件带领读者分析了各类USB令牌、设备描述符等。

USB驱动程序的主要功能就是设置这些USB令牌，和获取USB设备描述符。USB驱动程序将这些请求最终转化为USB请求包（URB包），而后发往USB总线驱动程序。USB总线驱动提供了丰富的功能，它封装了USB协议，提供了标准的接口。这使得USB驱动程序的编写变得简单，程序员没必要过多地了解USB总线协议，就能够编写出功能强大的USB驱动程序。

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程