USB枚举流程分析

                                                            图2 USB总线逻辑结构
     在usb设备的逻辑组织中，包含设备，配置，接口，端点4个层次。
     设备通常有一个或多个配置，配置通常有一个或多个接口，接口有零或多个端点。
     每个usb设备都可以包含一个或多个配置，不同的配置使设备表现出不同的功能组合（在探测，连接期间需从其中选定一个），配置由多个接口组成。在usb协议中，接口由多个端点组成，代表一个基本的功能，是usb设备驱动程序控制的对象，一个功能复杂的usb设备可以具有多个接口，而接口是端点的汇集
例子
      一个usb播放器带有音频，视频功能，还有旋钮和按钮
     配置1 音频（接口）+旋钮（接口）
     配置2 视频（接口）+音频（接口）+按钮（接口）
    每个接口对应需要一个驱动程序

     usb设备中的唯一可寻址部分是设备的端点。它是位于usb设备或主机上的一个数据缓冲区，用来存放和发送usb的各种数据。主机和设备的通信最终作用于设备上的各个端点，它是主机与设备间通信流的一个逻辑终端

      每个usb设备有一个唯一的地址，这个地址是在设备连上主机时，由主机分配的，而设备中的每个端点在设备内部有唯一的端点号，这个端点号是在设计设备时给定的。每个端点都是一个简单的连接点，或者支持数据流进设备，或者支持其流出设备，两者不可兼得。

      基于PnP机制，设备被枚举时，它必须向主机报告各个端点的特性，包括端点号，通信方向，端点支持的最大包大小，带宽要求等（其中端点支持的最大包大小叫做数据有效负载）。每个设备必须有端点0，它用于设备枚举和对设备进行一些基本的控制功能。除了端点0，其余的端点在设备配置之前不能与主机通信，只有向主机报告这些端点的特性并被确认后才能被激活。

LInux USB枚举过程 

     USB架构中， hub负责检测设备的连接和断开，利用其中断IN端点(Interrupt IN Endpoint)来向主机（Host）报告。在系统启动时，主机轮询它的根hub（Root Hub）的状态看是否有设备（包括子hub和子hub上的设备）连接。USB总线拓扑结构见上图（最顶端为主机的Root Hub）

      一旦获悉有新设备连接上来，主机就会发送一系列的请求(Resqusts)给设备所挂载到的hub，再由hub建立起一条连接主机（Host）和设 备（Device）之间的通信通道。然后主机以控制传输(ControlTransfer)的方式，通过端点0(Endpoint 0)对设备发送各种请求，设备收到主机发来的请求后回复相应的信息，进行枚举（Enumerate）操作。所有的USB设备必须支持标准请求 （StandardRequests），控制传输方式（ControlTransfer）和端点0（Endpoint 0）。

       从用户角度来看，枚举过程是自动完成并不可见的。但很多初次使用的设备连接时，系统会弹出说新硬件检测到，设备安装成功，可以使用之类的消息提示框，而且有时还需要用户配合选择安装相关的驱动。

       当枚举完成后，这个新添加的设备可在Windows的设备管理器里面看到，当用户删除这个设备/硬件时，系统把这个设备从设备管理器里删除。

     对于一般的设备，固件（Firmware）内包含主机所要请求的信息，而有些设备则是完全由硬件来负责响应主机的请求。在主机方面则是由操作系统而非应用程序负责处理相关枚举操作。

枚举步骤
      USB协议定义了设备的6种状态，仅在枚举过程种，设备就经历了4个状态的迁移：上电状态(Powered)，默认状态(Default)，地址状态(Address)和配置状态(Configured)（其他两种是连接状态和挂起状态（Suspend））。

      下面步骤是Windows系统下典型的枚举过程，但是固件不能依此就认为所有的枚举操作都是按照这样一个流程行进。设备必须在任何时候都能正确处理所有的主机请求。

1、用户把USB设备插入USB端口或给系统启动时设备上电
    这里指的USB端口指的是主机下的根hub或主机下行端口上的hub端口。Hub给端口供电，连接着的设备处于上电状态。

2、Hub监测它各个端口数据线上(D+/D-)的电压
    在hub端，数据线D+和D-都有一个阻值在14.25k到24.8k的下拉电阻Rpd，而在设备端，D+（全速，高速）和D-（低速）上有一个1.5k 的上拉电阻Rpu。当设备插入到hub端口时，有上拉电阻的一根数据线被拉高到幅值的90%的电压（大致是3V）。hub检测到它的一根数据线是高电平， 就认为是有设备插入，并能根据是D+还是D-被拉高来判断到底是什么设备（全速/低速）插入端口。 检测到设备后，hub继续给设备供电，但并不急于与设备进行USB传输。

3、Host了解连接的设备
      每个hub利用它自己的中断端点向主机报告它的各个端口的状态（对于这个过程，设备是看不到的，也不必关心），报告的内容只是hub端口的设备连接／断开 的事件。如果有连接／断开事件发生，那么host会发送一个 Get_Port_Status请求(request)以了解更多hub上的信息。Get_Port_Status等请求属于所有hub都要求支持的 hub类标准请求（standard hub-classrequests）。

4、Hub检测所插入的设备是高速还是低速设备
    hub通过检测USB总线空闲(Idle)时差分线的高低电压来判断所连接设备的速度类型，当host发来Get_Port_Status请求时，hub 就可以将此设备的速度类型信息回复给host。（USB 2.0规范要求速度检测要先于复位（Reset）操作）。

5、hub复位设备
    当主机获悉一个新的设备后，主机控制器就向hub发出一个 Set_Port_Feature请求让hub复位其管理的端口。hub通过驱动数据线到复位状态(D+和D-全为低电平 )，并持续至少10ms。当然，hub不会把这样的复位信号发送给其他已有设备连接的端口，所以其他连在该hub上的设备自然看不到复位信号，不受影响。

6、Host检测所连接的全速设备是否是支持高速模式
     因为根据USB 2.0协议，高速（High Speed）设备在初始时是默认全速（Full Speed ）状态运行，所以对于一个支持USB 2.0的高速hub，当它发现它的端口连接的是一个全速设备时，会进行高速检测，看看目前这个设备是否还支持高速传输，如果是，那就切到高速信号模式，否 则就一直在全速状态下工作。

    同样的，从设备的角度来看，如果是一个高速设备，在刚连接bub或上电时只能用全速信号模式运行（根据USB 2.0协议，高速设备必须向下兼容USB 1.1的全速模式）。随后hub会进行高速检测，之后这个设备才会切换到告诉模式下工作。假如所连接的hub不支持USB 2.0，即不是高速hub，不能进行高速检测，设备将一直以全速工作。

7、Hub建立设备和主机之间的信息通道
    主机不停得向hub发送 Get_Port_Status请求，以查询设备是否复位成功。Hub返回的报告信息中有专门的一位用来标志设备的复位状态。
    当hub撤销了复位信号，设备就处于默认／空闲状态（Default state），准备着主机发来的请求。设备和主机之间的通信通过控制传输，默认地址0，端点号0进行。在此时，设备能从总线上得到的最大电流是100mA。(所有的USB设备在总线复位后其地址都为0，这样主机就可以跟那些刚刚插入的设备通过地址0通信。)

8、主机发送Get_Descriptor请求获取默认管道的最大包长度
    默认管道（Default Pipe）在设备一端来看就是端点0。主机此时发送的请求是默认地址0，端点0，虽然所有位分配地址的设备都是通过地址0来获取主机发来的信息，但由于枚 举过程不是多个设备并行处理，而是一次枚举一个设备的方式进行，所以不会发生多个设备同时响应主机发来的请求。
    设备描述符的第8字节代表设备端点0的最大包大小。对于Windows系统来说，Get_Descriptor请求中的wLength一项都会设为64， 虽然说设备所返回的设备描述符（DeviceDescriptor）长度只有18字节，但系统也不在乎，此时，描述符的长度信息对它来说是最重要的，其他 的瞄一眼就过了。Windows系统还有个怪癖，当完成第一次的控制传输后，也就是完成控制传输的状态阶段，系统会要求hub对设备进行再一次的复位操作 （USB规范里面可没这要求）。再次复位的目的是使设备进入一个确定的状态。

9、主机给设备分配一个地址
    主机控制器通过Set_Address请求向设备分配一个唯一的地址。在完成这次传输之后，设备进入地址状态（Address state），之后就启用新地址继续与主机通信。这个地址对于设备来说是终生制的，设备在，地址在；设备消失（被拔出，复位，系统重启），地址被收回。同 一个设备当再次被枚举后得到的地址不一定是上次那个了。

10、主机获取设备的信息
    主机发送 Get_Descriptor请求到新地址读取设备描述符，这次主机发送Get_Descriptor请求可算是诚心，它会认真解析设备描述符的内容。设 备描述符内信息包括端点0的最大包长度，设备所支持的配置（Configuration）个数，设备类型，VID（Vendor ID，由USB-IF分配）， PID（Product ID，由厂商自己定制）等信息。Get_Descriptor请求(Device type)和设备描述符（已抹去VID，PID等信息）见下图：

    之后主机发送Get_Descriptor请求，读取配置描述符（ConfigurationDescriptor），字符串等，逐一了解设备更详细的信 息。事实上，对于配置描述符的标准请求中，有时wLength一项会大于实际配置描述符的长度（9字节），比如255。这样的效果便是：主机发送了一个 Get_Descriptor_Configuration的请求，设备会把接口描述符，端点描述符等后续描述符一并回给主机，主机则根据描述符头部的标 志判断送上来的具体是何种描述符。

     接下来，主机就会获取配置描述符。配置描述符总共为9字节。主机在获取到配置描述符后，根据里面的配置集合总长度，再获取配置集合。配置集合包括配置描述符，接口描述符，端点描符等等。
      如果有字符串描述符的话，还要获取字符串描述符。另外HID设备还有HID描述符等。

11、主机给设备挂载驱动（复合设备除外）
       主机通过解析描述符后对设备有了足够的了解，会选择一个最合适的驱动给设备。在驱动的选择过程中，Windows系统会和系统inf文件里的厂商 ID，产品ID，有时甚至用到设备返回来的产品版本号进行匹配。如果没有匹配的选项，Windows会根据设备返回来的类，子类，协议值信息选择。如果该 设备以前在系统上成功枚举过，操作系统会根据以前记录的登记信息而非inf文件挂载驱动。当操作系统给设备指定了驱动之后，就由驱动来负责对设备的访问。
    对于复合设备，通常应该是不同的接口（Interface）配置给不同的驱动，因此，需要等到当设备被配置并把接口使能后才可以把驱动挂载上去。
    设备-配置-接口-端点关系见下图：

    实际情况没有上述关系复杂。一般来说，一个设备就一个配置，一个接口，如果设备是多功能符合设备，则有多个接口。端点一般都有好几个，比如Mass Storage设备一般就有两个端点（控制端点0除外）。

12. 设备驱动选择一个配置
    驱动（注意，这里是驱动，之后的事情都是有驱动来接管负责与设备的通信）根据前面设备回复的信息，发送Set_Configuration请求来正式确定 选择设备的哪个配置（Configuration）作为工作配置（对于大多数设备来说，一般只有一个配置被定义）。至此，设备处于配置状态，当然，设备也 应该使能它的各个接口（Interface）。
   对于复合设备，主机会在这个时候根据设备接口信息，给它们挂载驱动。