v-ray 常见问题.doc

USB控制端点数据结构 *********************** * USB控制端点数据结构 * *********************** 2007/10/20 asdjf@163.com ----------------------------- usbs_control_endpoint数据结构 ----------------------------- 设备驱动程序应该为每个USB设备提供一个usbs_control_endpoint数据结构。这个结构对应着用于主机和设备之间全部控制消息交互的端点0，当然它也用于内部管理目的，例如：跟踪当前状态。在一个典型的设备里整个系统一般只有一个这样的数据结构，不过，如果设备存在多个连接到几个主机的USB从设备端口，那么每一个端口都需要对应一个独立的此数据结构。数据结构名称由设备驱动决定，如：SA11x0的USB设备驱动提供了一个叫“usbs_sa11x0_ep0”的数据结构。 端点0不太适合open/read/write这种便利的I/O模式。例如：当主机发送控制消息给外设时，可能是这四种类型之一：标准、类、厂商和保留。某些或者全部标准控制消息将自动被USB公共驱动包或者设备驱动自己处理掉。其他标准控制消息和其他种类的控制消息可能被USB类驱动包或者应用程序代码处理掉。虽然有可能提供如/dev/usbs_ep0/standard和/dev/usbs_ep0/class的设备文件名给端点0使用，然后在上面进行读写操作，但是这样会显著增加CPU开销和代码复杂性。取而代之，所有控制端点数据结构里的字段都是公开的，能够直接被高层代码使用，如果需要的话。 控制端点涉及一系列的回调函数，这些回调函数是由高层代码将合适的函数指针安装在控制端点的数据结构里的。例如：如果设备涉及到厂商自定义控制消息，那么对应这些消息的一个合适的处理器应该被高层代码事先安装好。虽然精确的细节依赖于具体设备驱动，但通常来说，这些回调函数将在DSR级而非线程级被调用。因而，只有部分ecos函数能被调用，也就是特指那些保证不被阻塞的函数。如果回调函数内部潜在调用了引起阻塞的函数，如：等待信号量、互斥体锁定等，那么结果不可预测，并且整个系统可能发生致命错误。另外，如果某个回调函数处理时间过长将非常不利于系统的实时特性。ecos内核文档有关于DSR处理的详细说明。 ------ 初始化 ------ usbs_control_endpoint数据结构包含了如下和初始化相关的字段： typedef struct usbs_control_endpoint { … const usbs_enumeration_data* enumeration_data; void (*start_fn)(usbs_control_endpoint*); … }; 枚举数据定义由高层代码负责，通常是指应用程序。这些枚举数据需要在系统启动期间，在USB设备真正启动及与主机有任何可能的交互前被安装在控制端点数据结构里。枚举数据的细节在前面《USB枚举数据》章节里介绍过。通常，枚举数据对一个给定设备是固定不变的，当然如果需要的话也可以动态组织，然而，枚举数据在设备连接上主机前是不能改变的，外设不能一会声明自己是键盘，一会又声明自己是打印机。 start_fn成员函数一般通过usbs_start()函数访问而不是直接调用。该成员函数由设备驱动提供且一旦系统初始化完成并可能存在和主机交互时应该调用这个成员函数。一个典型的实现是将USB数据引脚从三态改变到激活态。如果设备已经插在了主机上，那么主机随后将检测到这个改变并开始和外设交互，包括请求枚举数据。 ---- 状态 ---- 有三个usbs_control_endpoint字段和USB从设备当前状态有关，加上一些状态常量和可能的状态改变枚举，如下所示： typedef struct usbs_control_endpoint { … int state; void (*state_change_fn)(struct usbs_control_endpoint*, void*, usbs_state_change, int); void* state_change_data;