USB固件开发总结1-2.docVIP

说明： - 此文档包括四部分： ? - USB固件开发（通用部分） ? - USB固件开发（HID设备） ? - USB固件开发（Mass Storage设备） ? - USB固件开发（复合设备：HID+Mass Storage） - 由于不同的USB接口芯片在固件编写时会有不同的具体操作及特性，所以此文档不描述编程细节。 ?/u3/98810/showart_1971637.html USB固件开发（通用部分）  1. 基本概念 1.1 工作机制 USB的通信是主从式通信。即USB主机发送请求，USB设备（从机）做出应答。设备无法主动请求主机。这样，设备的工作主要就是正确响应主机发来的请求。主机为了识别不同功能的设备，必然要求设备在投入具体使用前先报告一些特征数据给主机，这些特征数据的格式遵循着主机和设备之间制定的协议，所以如果设备正确返回了这些特征数据，那么主机就能够确定设备的功能。在此之后，主机就会按照设备的具体功能发出具体请求了，它们之间的正常工作由此展开。 以上表述中，所谓的“特征数据”就是“描述符”，主要包括设备描述符、配置描述符、接口描述符、端点描述符和字符串描述符，以及对应于设备具体功能的类描述符（譬如HID描述符）。 1.2? USB系统的层次结构 ??? 如下图所示，主机与设备的通信分为3层，一般的开发只关心上两层。具体来讲，设备固件的开发会关心上两层，而主机还有可能只关心第一层，即客户软件的开发。从图上也可以开出，对具体“应用”来说，对设备来说只有“接口”是可见的，对主机客户软件来说，只有“管道”（图中的“通道”）可见。 ? ?  2. 主机对设备的识别 这里的识别仅指设备插入后所进行的软件识别，不包括主机对设备硬件插入的识别。 主机检测到有USB设备插入后，会依次进行如下动作： !--[if !supportLists]--1、????? !--[endif]-- !--[if !supportLists]--2、????? !--[endif]--0向设备发出读取设备描述符的请求，以取得缺省控制管道所支持的最大数据包长度，此时主机只会读取描述符的前8个字节。 !--[if !supportLists]--3、????? !--[endif]--SetAddress请求，为其分配一个唯一的设备地址。 !--[if !supportLists]--4、????? !--[endif]--2步不同，此时是读取整个描述符。 !--[if !supportLists]--5、????? !--[endif]--USB设备可能有多个配置，由设备描述符相关字段指出）。值得注意的是，这里的配置信息包括了配置描述符本身、接口描述符和端点描述符，以及相关类描述符。所以，每读取一个配置，主机会分为两步：首先发出请求读取配置描述符本身（9字节），以得到配置信息的长度；然后再次发出请求读取整个配置信息。这两步中的请求都是“读取配置描述符”，只是指明读取的数据长度不同。 !--[if !supportLists]--6、????? !--[endif]--SetConfiguration请求为设备选择合适的配置。 ? 在实际的开发的开发中，程序员很有可能觉察不到有这么多的请求，因为USB接口芯片很可能封装了一些控制管道的标准请求如SET_ADDRESS等，对这些请求芯片会自动做出反应，不需程序员干预。这是对开发过程的一种简化。譬如Sunplus公司MCU上集成的USB接口，一般就只将读取/设定描述符的请求暴露给程序员，而将GET_STATUS，CLEAR_FEATURE，SET_FEATURE，SET_ADDRESS，GET_CONFIGURATION，SET_CONFIGURATION，GET_INTERFACE，SET_INTERFACE这些请求全部封装了。 在以上表述中，有几处提到主机在发送同一个请求时，要求读取的数据长度会不一样。如读取设备描述符时，是先读8字节，而后再读取整个；读取配置信息时，是先读取9字节，然后读取整个。所以，固件程序必须处理这些情况。有的时候，设备要求读取的数据长度比实际描述符的长度要长，例如读取字符串描述符时，它一律发出0xFF这样的长度，对这种情况固件也必须处理。一个通用的做法就是，对于所有的请求，都把描述符长度与主机请求读取的长度做个比较，取其中较小者为实际处理的长度。 ? 3. 开发中的细节问题 3.1各描述符详解 各描述符字段的具体意义，可以参考USB规范第9章“设备架构”。这里主要是举例说明各描述符的用法和它们在实际编程中的表现形式，以及一些注意事项。 总的一点：不管是何种描述符，其前两个字节必定是指明该描述符的长度及描述符类型。 ? 设备描述符： _Device_Descripto