VxWorks下的同类USB设备管理方法

引言

VxWoAs是美国Wind River System(WRS)公司开发的嵌入式实时操作系统。VxWorks中的I／O子系统为应用程序提供了简单、统一、与设备无关的访问接口。I／O系统内部采用设备列表、驱动程序列表和文件描述符表来实现对不同设备的管理与访问，从而为开发通用外部设备驱动程序提供了便利。然而在一些专用系统上，为了缩短设备的响应时间，提高设备的读取速度，有必要将设备与I／O系统独立起来。由于VxWorks属于微内核，所有的程序均运行在同一线性地址空间，这也为设备与I/O系统的独立提供了条件。基于VxWorks的I／O子系统设备管理的思想，本文提出了一种在VxWorks下对多个同类USB设备进行管理的设计方案。该方案可使得对设备的访问独立于I／O子系统。

1 VxW0rks的I／O子系统设备管理

VxWorks I／O系统内部对设备的管理主要通过三张表来实现，即驱动程序列表、设备列表和文件描述符表。其中驱动程序列表用来管理已注册的设备驱动程序，它的大小是固定的，有NUM DRIVERS项，每一项对应驱动程序的入口点，当应用程序调用标准I／O接口函数时，I／O子系统便可通过驱动程序列表检索到设备的驱动程序，从而实现对指定设备的访问、发送、接收等操作。系统可利用iosDrvInstall()注册设备驱动程序，并将设备的人口函数加入到驱动程序列表。同时返回一个drvnum驱动程序号，并将其作为设备描述符的一部分，从而以此把设备与其驱动程序联系起来。I／O子系统采用链表对所有设备进行管理，该链表称之为设备列表。调用iosDevAdd ()可向系统添加设备，添加设备时，应指明设备名称及驱动程序索引号，该索引号就是iosDrvInstall ()返回的索引号。在VxWorks中，一个设备可以被多次打开，但对于每一次打开，系统将利用一个文件描述符来区分，本系统将会维持一张文件描述符表，该表的每一项记录了与设备对应的驱动程序号和设备ID，这样，就会文件描述符与驱动程序、以及设备之间建立一种联系。这样，在利用标准I／O函数进行读写时，就可以根据文件描述符从文件描述符表中找到对应的驱动程序的人口与设备ID。VxWorks中的这三张表的关系如图1所示。

2 USB设备管理方案设计

设计独立于I／O系统的USB设备驱动程序的设计思想主要基于两点，第一是用户自己管理设备。第二是通过驱动程序直接向应用程序提供可用于读写设备的接口函数。由于设备独立于I／O系统，用户需要自己设计一种设备管理方法，以便对多个接入的USB设备进行合理的管理。然而由于不存在设备驱动程序列表，故在设计时还需要有一种方法来解决设备的访问问题。

2．1 USB设备描述符

设备描述符实际上是一个数据结构，可在系统中作为一个逻辑结构体。它是一个具体设备的抽象。可与一个物理设备相对应，是参与设备管理、访问的主要结构体。鉴于I／O子系统对设备的管理，在对多个USB设备进行管理时，对于设备的存储，可采用双向链表来进行管理，称之为设备列表。链表对USB设备的管理主要通过设备头(USB_BEV_HDR)来实现。USB设备头是一个与具体设备无关的数据结构，它由一个链表节点和设备名称组成。节点中包含指向有前一个和下一个USB设备的设备头的链表节点。实际上，每一个USB设备都会有更多的数据存储在更大的数据结构中。这个结构就是设备描述符，而USB设备头只是做为USB设备描述符的起始部分。设备头的数据结构(USB_DEV_HDR)如下：

其中，USB_DL_NODE是一个链表节点，它由两个链表节点指针域组成。分别指向前一个和下一个设备的链表节点。其数据结构如下：

这样，就可以把USB设备的描述符划分为两部分，其中一部分与具体设备无关，称为设备头：另外一部分是与具体设备相关的设备特殊数据，设备相关部分包括USB设备的Node ID、USB管道句柄、端点地址、状态等信息。其结构如图2所示。设备无关部分主要用于设备管理，而设备相关部分则用于对设备的访问。

2．2设备列表设计

为了方便对设备的管理，USB设备列表可采用双向链表结构，其作用是将所有USB设备的有关信息组织起来，从而实现对多个设备的链式管理。前面提到的设备描述符就是一个存储了设备信息的数据结构。而所有USB设备描述符都是以设备头数据结构开始的，这样，就可以很方便地将设备描述符组成一个链表形式的设备列表。通常链表的数据结构如下：

图3所示是一个空设备列表，而非空设备列表则如图4所示。

对于同类USB设备，通常程序只维护一张设备列表，在注册该USB设备驱动程序时，初始化设备列表为空，驱动程序只能被真正的注册一次，因此，设备列表也只初始化一次。当驱动程序中的回调函数检测到有设备动态接人时，系统会在创建设备、分配设备资源的同时将设备描述符加入到设备列表，而且只将其加入到设备列表的尾部。而在有设备动态移除时，驱动程序回调函数会捕获移除动作，并根据设备的标识遍历设备列表，以查找出移除的设备，然后将其描述符从设备列表中删除。遍历设备列表其实就是一个查找设备的过程。查找设备时，每一个设备都需要用唯一的一个标识来与其它设备区别，从而引出了设备的唯一标识问题。

2．3 USB设备的标识问题

同I／O系统标识设备一样，对于USB设备的标识。也可以采用设备名来标识。这样可以给用户一个直观的概念，而且便于记忆。利用设备头(USB_DEV_HDR)中的name指针域可以为每一个接入的设备起一个名字。这样，对于不同的设备，就可以用名字字符串来唯一区分，但这不利于快速访问设备，因为在每次查找设备的时候对于每一个设备链表节点都要进行一次字符串比较，这样便延长了查找设备的时间。针对USB设备及VxWorks下USB协议栈的特点，充分利用USBD对USB设备的标识，在设计中可采用USBD_NODEjD来标识设备。在VxWorks中的USB协议栈中。对每一个USB设备为其分配一个唯一的USBD_NODE_ID号。事实上，VxWorks USBD并不关心设备与哪一个USB主控制器相连，也不关心物理设备的连接细节以及地址分配，USBD通常只是采用USBD_NODE_ID来定位设备。因此，基于USBD对USB设备的定位方法，在采用链表对USB设备进行管理时，也可以采用USBD_NODE_ID来唯一标识一个USB设备。在用该方法标识设备时，可将USBD_NODE_ID nodeld作为USB设备描述符结构体的一个成员，其设备描述符结构改造如下：

由于USBD_NODE_ID是一个32位无符号整型数，因此，在查找设备时，可以用switch case语句来完成。

2．4设备访问技术

由于设备是独立于I／O系统的，因此不存在驱动程序列表和文件描述符表。设计时，可采用驱动程序直接向应用程序提供可访问设备的接口函数，以替代驱动程序列表，而采用USBD_NODE_ID数组来存放多个USB设备的标识，以替代文件描述符表，如：USBD_NODE_ID usbd_node_id[MAX_DEV_NUM]。

对于同类USB设备，根据其Product ID的不同，可将其记为O、l、2……MAX_DEV_NUM号设备，并分别将其USBD_NODE_ID存放于数组的对应位置。这样，在访问设备时，就可利用设备号来代替文件描述符，例如在读取0号设备时，由其索引值0，就可得到其USBD_NODE_ID为USBD_NODE_ID usbd_node_id[O]，再从设备列表中查找出nodeld为usbd_node_id[O]的设备结构体，就可最终得到设备资源。通过USBD_NODE_ID数组来管理多个设备的nodeld如图5所示。

在读写设备时。可以设备号作为设备的标识，并通过设备号在nodeld数组中得到设备的nodeId，再从设备列表中查找到具体的物理设备的描述符。从而得到设备资源并对设备进行访问。以LM9833读设备为例，其读设备原型代码如下：

其中，usbScanRead()是驱动程序向用户应用程序提供的接口函数，直接调用该函数即可读取设备，其它的设备函数也是如此，其中设备号dev是由用户根据不同设备的不同Product ID(PID)号制定的，这样，当设备接入系统时，驱动程序就会根据其PID号判断其设备号，并将该设备的nodeld值存放于数组的特定位置。由于此时设备始终处于就绪状态，用户可以随时对设备进行读写操作，而并不存在打开设备的操作。

读写设备时，首先要根据设备号dev从设备列表中查找出设备，并将其定位到具体的设备描述符上。在查找设备时，遍历设备列表，就可找到节点设备描述符中nodeId与usbd_node_id[dev]相匹配的设备描述符结构体，并返回该结构体，然后再由设备描述符结构体得到设备的资源信息，从而实现对设备的读写。图6所示是查找设备的一个简单流程。

该方法屏蔽了复杂的驱动程序列表和文件描述符表，从而提供了一种快速定位和访问设备的方法。这种方法在专用的系统中，对同类USB设备的访问是非常高效的，但不具有通用性，也就是说，对于不同类别的设备。则需要另外一套同样的机制来实现。

3 结束语

本文提出了一种独立于VxWorks I／O系统的USB设备管理方法。该方法也是一种独立于I／O系统的USB设备驱动程序设计模式，它对于在专用系统中同类USB设备的管理是非常有效的。通过对USB设备描述符、设备列表、以及应用程序访问设备流程的设计，可以成功实现独立于I／O系统的设备管理方法。这一种方法可以利用驱动程序直接向应用系统提供接口函数和nodeld数组。从而摒弃了I／O系统中复杂的驱动程序列表和文件描述符等概念。目前，这种独立于VxWorks I／O系统的USB设备管理方法已在某大型扫描仪中得到应用，并取得了一定的经济效益。