富乎 · 地问

辗转探寻为富乎？《天问》无解向地问！

<<< 返回主页

USB 2.0协议摘要

协议原始文档

1、简介

动机：
- 电脑与电话（Telephone）的互连（注：这是最初的设定，但后来已不限于这两种角色）
- 易用性（Ease-of-Use）
- 端口扩展（Port Expansion）
本文档内容的组织：
- 第1至5章是面向所有读者的概述内容，第6至11章则是技术细节。
- 外设开发者应着重阅读第5至11章。
- USB主机控制器开发者应着重阅读第5至8章，以及第10、11章。
- USB设备驱动开发者应着重阅读第5、9、10章。
其余内容略。

2、术语和缩略词

需要关注的有：

USB：Universal Serial Bus，通用串行总线（注意其“通用”的设计理念），是一种可热插拔、支持在电脑主机（实际上所有具备类似功能的设备均可）和多种外部设备（后文简称外设）之间交换数据的总线，其通信方式的主要特点是：由主机调度（host-scheduled）、基于令牌（token-based）、挂载在同一主控上的所有外设共享该总线的带宽。
--------
EOF：End-of-(micro)Frame，（微）帧尾，与其相对应的是SOF——Start-of-(micro)Frame，（微）帧头，在本章不再单独列出。
EOP：End-of-(micro)Packet，（微）报文尾，与其相对应的是SOP——Start-of-(micro)Packet，（微）报文头，在本章不再单独列出。
--------
IRP：I/O Request Packet，输入/输出请求报文，由客户端软件（应用层）发起，传递到下层会转换成Transfer。
Transfer：由单个或多个事务组成的一次传输过程。
Transaction：事务，由1个令牌报文、0或多个数据报文、0或1个握手报文（即ACK、NAK、 HALT等状态响应）组成。
Packet：报文。注意它是更高一层的抽象——事务的组成单位。还要注意的是，原文有些地方本应使用报文，但却误用成事务。
--------
Frame：用于低速、全速总线的时基（Time Base，基本时间片段），其时长为1ms。
Microframe：用于高速总线的时基，其时长为125us。
--------
Endpoint：端点。一个USB设备（注意不是主机）可包含多个端点，每个端点具有一个在设备内部唯一的地址，而每个地址则由端点号和传输方向组成，注意将流入主机的方向定义为IN、从主机流出的方向（即流向设备）定义为OUT。
Function：功能单元、功能实体，即具有特定功能的USB设备，例如键盘、鼠标、打印机、扫描仪、摄像头等。后文简记为func。
Host Controller：主机控制器（后文会简称为主控或HC），是主机的总线（硬件）接口。
HCD：Host Controller Driver，主控驱动程序，是一个软件概念，位于USBD的下面，是系统软件（位于驱动层）和HC（位于链路层）之间的接口，真正接触硬件细节。注意：由于HCD屏蔽了硬件的复杂性并提供统一接口，所以一个USBD可以同时支持多种HCD，但对于一个具体主机，由于HC是确定不变的，因此主机厂商只需提供一种HCD。
Hub：集线器，一种用于扩充连接口的设备。
USBD：USB Driver，总线驱动程序，位于客户端软件的下面、HCD的上面，且与HCD一同位于设备层（即驱动层）。从第5.3节的通信层级关系图可以看出， USBD实际上充当着客户端操纵对侧同层的func和同侧下层的HC（需要经过HCD）的代理。

3、背景

目标（Goals）：略。
速率等级：
- 低速（Low-Speed）：10 - 100kb/s，主要用于键盘、鼠标等。
- 全速（Full-Speed）：500kb/s～12Mb/s，可用于音频、话筒等。
- 高速（High-Speed）：25-480Mb/s，可用于大容量储存设备、图像传输等。
特性列表：略。

4、架构概述

系统描述：
- 互连标准：
  - 总线拓扑：注意在层数方面最多支持7层，最顶层必须是主机上的根源集线器（Root Hub），最底层必须是功能体（func）。
  - 各个通信抽象层的功能及联系。
  - 数据流程模型：对于不同层级、不同粒度的数据载体的抽象，以及对于时序、格式/结构的规定。
  - 调度策略：处理总线复用、时间片划分、带宽分配等问题。
- 设备：包括hub和func，但复合设备可同时集成这两种。技术框架详见第9章， hub还会有额外的第11章来详细介绍其独特的技术规范。
- 主机：通信操作的主导者，默认的供电者，有且只能有1个。技术规范详见第10章。
物理接口：
- 电气特性：
  - 电源：
    - Vbus、GND
  - 数据：
    - D+、D-（即差分信号）
    - NRZI编码（接收端可凭此还原出时钟信号，所以不需要时钟线）
- 机械工艺：略。
电源：
- 供电：可通过总线供电，也可以设备自供电。
- 电源管理：研究如何让系统更省电，常见的与电源有关的事件有挂起、恢复等。除了主机提供的策略，设备也可以自己实现额外的策略。
总线协议：
- USB是一种轮询型总线，且由主机主导，目的是为了防止多个设备争抢总线，以及避免由此带来的复杂仲裁机制。
- 多数事务最多有3个报文：
  - 令牌报文用于询问。
  - 数据报文（可空）。
  - 握手报文用于汇报状态（ACK、NAK、HALT等）。
- 若是主机与hub之间的通信，则最多涉及4个报文，因为需要进行速率匹配、转换等。
- 管道：
  - 主机（缓冲区）与某个设备端点的传输路径就是一条管道。
  - 管道参数包括：带宽、传输类型（即后文的Transfer Type）、端点属性（例如传输方向、缓冲区大小等）。注意：一条管道可被同一个编号、同一种传输类型、方向相反的两个端点共享。
  - 有2种类型：
    - 消息管道（Message Pipe）：传输有特定结构的数据（只要求数据遵循特定规范，但USB并不解析内容），且在设备接上之时就配备一条默认控制管道（Default Control Pipe）。
    - 流式管道（Stream Pipe）：需要手动创建，传输无结构的数据。
健壮性：
- 通过差分信号、物理屏蔽层来保障信号完整性（Signal Integrity）。
- 使用CRC校验机制来保护控制域和数据域字段。
- 超时控制、重试。
- 流量控制。
- 资源配额、管道隔离。
系统配置：
- 热插拔
- 总线枚举
传输类型：
- 控制型传输（Control Transfer）：
  - 用于挂载期的配置，包括对于其他管道的控制；
  - 或设备自定义逻辑。
- 批量型传输（Bulk Data Transfer）：
  - 数据量较大，时机方面也有突发性，例子有打印机、扫描仪、U盘等。
  - 有硬件级别的纠错（CRC）和重试机制。
  - 对带宽的利用很灵活，允许较大的延迟，可以利用带宽空闲区。
- 中断型传输（Interrupt Data Transfer）：
  - 实际上还是依靠主机轮询，常用于键盘、鼠标等交互式设备。
  - 设备需要在一定的时间范围内作出响应。
  - 注意：数据是随机产生的（无数据也需要给出响应），但主机的轮询却是定期的。
- 等时型传输（Isochronous Data Transfer）：
  - 预先协商好带宽和最大延迟以确保传输的实时性，所以这种方式也叫流式实时传输（Streaming Real Time transfer）。
  - 传输速率必须恒定才能确保数据之间的时间关系不破坏。
  - 由于要保证实时性，所以无重试，允许丢包。
  - 应用场景多见于音视频，但却不限于此，也不要求业务一定是实时的。
- 注意：
  - 控制型传输走的是消息管道，其余类型的传输走的是流式管道。
  - 批量型传输与等时型传输的共同点是数据量较大，不同点是传输是否具有周期性、可靠性，以及对带宽和响应延迟的要求。
  - 中断型传输与等时型传输的共同点是对时间有要求（即周期性、响应延迟等），不同点是数据量。
USB设备：
- 特征（Characterization）：有标准（Standard）配置（详见第9章）、类别（Class）、厂商（Vendor）信息等。
- 分类：hub和func
- 详细介绍略。
USB主机：略。

5、数据流程模型（必读）

实现者眼中的USB：主要有4个关注点，划分成2侧如下所示：
- 设备侧：
  - 物理设备：一般看成一个整体。
- 主机侧：
  - 客户端软件：位于功能层（Function Layer，相当于应用层），专注于具体的策略。
  - 系统软件：位于设备层（USB Device Layer，可理解为驱动层），专注于通用的机制，由USBD、HCD（主机控制器的软件部分）等构成。
  - 主机控制器：即HC，主要作为一个硬件概念来使用，位于总线接口层 （USB Bus Interface Layer，相当于链路层）。
总线拓扑：
- 主机及设备：
  - 主机（详见第10章）的逻辑构成从上到下可分为3部分，在上一小节已介绍。
  - 设备（详见第9章）的逻辑构成从上到下也分为3部分：
    - func。
    - 逻辑设备：注意不同的物理设备有不同的功能，但逻辑设备却着重于向主机提供通用的基础接口。
    - 总线接口。
- 物理拓扑：
  - 连接形式为层级化的星形结构（实际上与树形结构无异），注意采用层级化的目的是为了防止环形挂载。
  - 由hub来提供挂载点（Attachment Point，也叫端口，即Port）让设备接入，每个hub有一个或多个端口。注意主机内置了一个位于最顶层的Root Hub，复合设备（Compound Device）内部也有一个hub。
  - 每个hub和func都有一个唯一地址，而且从主机视角来看，一个复合设备也当作一个hub和若干个func来处理。
  - hub在高速总线系统中扮演着一个特殊的角色，就是将低速/全速信号环境与高速信号环境隔离开来，但注意高速hub可接一个低速/全速hub，却不能接低速/全速设备，不过HC却能直接低速/全速设备。
  - 每个HC最多接127个设备。
- 逻辑拓扑：
  - 在物理拓扑基础上，省略中间节点（即hub），简化关系图，只有主机与各个func直连。
  - 但主机的内部仍需意识到hub的存在，以便在移除hub的同时也能移除接在该hub的所有func。
- 客户端软件与func的关系：
  - 虽然逻辑上可认为两者在同一层级上直接相连，
  - 但实际编程上应调用封装过的API，避免接触底层细节（例如访问特定内存区域或IO）。
通信流程：
- 若干抽象关系：
  - 设备侧功能层：Func = Interface * n
  - 设备侧设备层：Logical_Device = Endpoint * n = （功能层的）Interface
- 端点（Endpoint）：
  - 每个逻辑设备均有一个在挂载期间由系统动态分派的唯一地址。
  - 每个逻辑设备包含多个端点，每个端点均在设计之初就分配一个固定的内部唯一端口号 和方向（意味着每个端点都是单工通信）。
  - 靠(device-address, endpoint-number, direction)三元组可唯一确定一个端点。
  - 除了端口号和方向，端点还需要具备以下参数：频率/延迟要求、带宽要求、错误处理的行为要求、报文的大小限制、传输类型。
  - 0号端点（2个：1个IN，1个OUT）：
    - 需要强制支持，在上电或复位时就已处于可用状态。
    - 连接一条默认控制管道（Default Control Pipe），用来进行一些基础、通用的信息配置、状态设置。
    - 至少应支持set_{addr,config}()、get_descriptor()请求。
  - 非0号端点（可选）：
    - 低速func最多只能有2个（IN还是OUT未明确），全速func最多只能有IN和OUT各15个。
    - 在使用0号端点未对func进行正确配置之前，所有非0号端点均不可用（但已存在）。
- 管道（Pipe）：
  - 在前面第4章已有所介绍，此处为补充内容。
  - 默认控制管道：见前面对于端点的说明。
  - 非默认管道：非0号端点所使用的管道，生命周期亦与所属端点相同。
  - IRP（I/O Request Packet）：
    - 由客户端发起，具体形式因操作系统而异（类似send()、recv()、poll()等）。
    - 当一个IRP所关联的事务传输完成或出错时，客户端会收到通知，但等时型传输和非等时型传输对于错误的处理会有区别，详见后面章节。
    - 一个IRP可以把客户端数据拆分成多个载荷进行发送，除了最后一个之外， 前面的载荷均要填充至最大报文长度。至于最后一个载荷的长度要求，要由客户端指定处理方式，即：若客户端接受任意长度的载荷，则最后一个载荷不需填充，否则当最后一个载荷长度不够时会视为错误。
    - 端点可使用NAK来告知主机目前它处于繁忙状态，所以NAK不是错误。
  - 流式管道（单向）：
    - 通常一条管道只被一个客户端使用。
    - 若是多个客户端使用同一条管道，则无强制要求系统软件对被传输的数据进行同步，而是采用先入先出的顺序进行传输。
    - 支持除控制型之外的传输类型。
  - 消息管道（双向）：
    - 传输的内容有固定的模板：Request/Data/Status
    - 不支持并发处理，一次只能发一条消息，发完当前消息或发送出错，才能发下一条（但后一个传输的Setup提前出现能中止前一个传输，这是需要避免的）。
    - 允许多个客户端同时使用默认控制管道，遵循先入先出的原则。
    - 仅支持控制型传输。
- 帧（Frame）、微帧（Microframe）：
  - 均是时间片段（前者是1ms，用于低速/全速总线；后者是125us，用于高速总线），而不是数据格式。
  - 一个帧/微帧内可传输若干个事务。
  - 等时型和中断型每隔N个帧/微帧就会获得使用总线的机会，对于N值的指定及其他细节，详见后文。
控制型传输（双向，走消息管道）：
- 用于传输配置、命令、状态信息。
- 固定的通信模板：
```
  Host                    Device
    |         Setup         |
    |---------------------->|
    |     IN Data (>= 0)    |
    |<----------------------|
    |           .           |
    |           .           |
    |           .           |
    |           or          |
    |     OUT Data (>= 0)   |
    |- - - - - - - - - - - >|
    |           .           |
    |           .           |
    |           .           |
    |         Status        |
    |<----------------------|
```
- 数据格式：详见第8.5.3节和第9章。
- 数据载荷最大长度（后文用wMaxPacketSize表示）：
  - 低速：8字节
  - 全速：8、16、32或64字节
  - 高速：64字节
  - 当最后一个载荷长度小于wMaxPacketSize时，不必填充，但前面的载荷长度必须是wMaxPacketSize。
  - Setup报文固定8字节。
  - 0号端点（使用的是默认控制管道）的wMaxPacketSize可通过传送过来的设备描述符 （Device Descriptor）的前8个字节获知。
  - 其他控制端点的wMaxPacketSize值要在初始化完成后才确定。
  - 数据传输完成的条件：
    - 传输的数据量正好等于Setup阶段指定的字节数；
    - 或者报文的载荷长度小于wMaxPacketSize（包括0长度）。
  - 管道被关停（abort、halt或retire）的条件：
    - 数据传输完毕，但主控不进入Status阶段；
    - 或传输超量数据。
- 总线访问限制：
  - 所有控制型传输都是尽最大努力（best effort）去实施，速率变动很大。
  - 比等时型和中断型传输的优先级低，不允许侵占这两者的总线时间，只能趁它们空闲时使用总线。
  - 比批量型传输的优先级高，只有当控制型传输使用的帧时长小于10%或微帧时长小于20%，剩余的时长才可被批量型传输使用。
  - 不同端点的控制型传输，采取公平的访问策略。
  - OUT方向的高速控制端点必须支持PING协议，详见第8.5.1节。
  - 每一帧允许的最大传输次数举例（载荷长度不同，次数也不同，详见第5.5.4节的表格）：
    - 低速：< 8Bytes * 4
    - 全速：< 8Bytes * 29
    - 高速：< 64Bytes * 32
  - 待理解：10%的低速/全速帧预留和20%的高速微帧预留。可能原文表述有问题。
- 异常情况处理：
  - 在Data和Status报文期间，端点处于繁忙状态，主机应在稍后进行重试。
  - 后一个传输的Setup提前出现能中止前一个传输，这是需要避免的。
  - 有错误检测、恢复/重发的机制，但只有Data和Status报文能分辨是原报文或是重发报文， Setup报文则无法分辨。
等时型传输（定速、保带宽、限延迟；仅限全速和高速；单向）：
- 数据格式：无。
- 数据载荷最大长度：
  - 全速：1023字节
  - 高速：3072字节
  - 每个（不限于最后一个）事务（还是报文？）的数据载荷长度可以小于wMaxPacketSize，由发送端决定，且接收端也知晓。
  - 所有设备的默认接口设置都不准包含wMaxPacketSize为0的等时型端点，若需要更大的wMaxPacketSize，可另行指定配置或接口设置并将该字段设成非0值。
- 总线访问限制：
  - 全速端点不能占用超过90%的帧时长，高速端点不能超过80%。
  - 端点需明确指定所需的总线访问周期：F * 2^(bInterval - 1)，其中F为1ms（全速）或125us（高速），bInterval的范围为[1, 16]，有若干点需要说明：
    - 由公式可知，允许以较慢速度进行传输（即多个帧或微帧才传输一个事务）。
    - 除非是高速高带宽端点（此时F=1，且每个周期传输字节数大于1024，每微帧也不止一个事务，更详细的描述见第5.9.2小节），否则每帧或微帧的事务数量不能超过1。
    - 当主机轮询（即IN方向传输）时间间隔小于该周期，端点必须返回一个0长度报文。
  - 每一帧允许的最大传输次数举例（载荷长度不同，次数也不同，详见第5.6.3节的表格）：
    - 全速：< 256Bytes * 6
    - 高速：< 1024Bytes * 8
- 异常情况处理：
  - 无握手报文，也不支持重发。
  - 更注重实时性，而非可靠性，所以允许丢包，出现错误时也会继续后面数据的传输。
中断型传输（不频繁但要求迅速响应；单向）：
- 数据格式：无。
- 数据载荷最大长度：
  - 低速：8字节
  - 全速：64字节
  - 高速：1024字节
  - 当最后一个载荷长度小于wMaxPacketSize时，不必填充，但前面的载荷长度必须是wMaxPacketSize。
  - 所有高速设备的默认接口设置都不准包含wMaxPacketSize大于64的中断型端点，若需要更大的wMaxPacketSize，可另行指定配置或接口设置并将该字段设成更大值。
  - 数据传输完成的条件：
    - 传输的数据量正好等于指定的字节数；
    - 或者报文的载荷长度小于wMaxPacketSize（包括0长度）。
  - 传输完成后，主控会继续处理下一个IRP。
  - 管道被关停（abort、halt或retire）的条件：
    - 传输超量数据。
- 总线访问限制：
  - 低速/全速端点不能占用超过90%的帧时长，高速端点不能超过80%。
  - 每一帧允许的最大传输次数举例（载荷长度不同，次数也不同，详见第5.7.4节的表格）：
    - 低速：< 8Bytes * 7
    - 全速：< 64Bytes * 20
    - 高速：< 1024Bytes * 7
  - 端点需明确指定所需的总线访问周期：
    - 低速：10～255 ms
    - 全速：1～255 ms
    - 高速：125us * 2^(bInterval - 1)，其中bInterval的范围为[1, 16]。高速高带宽端点的情况也与等时型传输类似，详见第5.9.1小节。
    - 注意：系统提供的实际周期可能短于理论值，主控也会确保两个事务发起的时间点间隔不会大于一个理论周期，但有错误发生时除外。
  - 如果客户端没有待处理的IRP，就不会轮询端点，即使总线时间点到了或端点有数据。一旦有可用的 IRP，会安排在下一个周期传输数据。
  - 若端点无中断型数据，可回复NAK。
- 异常情况处理：
  - DATA0、DATA1报文标识的切换问题，详见第8章。
  - 若有偶发性的错误导致要重试，则重试要安排在下一个周期。
  - 若传输出错或端点返回STALL握手包导致管道停机（halt），需要通过一条独立的控制管道进行软件干预才能恢复。
批量型传输（较大数据量且灵活利用总线时间；仅限全速和高速；单向）：
- 数据格式：无。
- 数据载荷最大长度：
  - 全速：8、16、32或64字节
  - 高速：512字节
  - 当最后一个载荷长度小于wMaxPacketSize时，不必填充，但前面的载荷长度必须是wMaxPacketSize。
  - 数据传输完成的条件：
    - 传输的数据量正好等于指定的字节数；
    - 或者报文的载荷长度小于wMaxPacketSize（包括0长度）。
  - 传输完成后，主控会继续处理下一个IRP。
  - 管道被关停（abort、halt或retire）的条件：
    - 传输超量数据。
- 总线访问限制：
  - 所有批量型传输都是很努力（good effort）地去实施，优先级最低（比控制型传输还低，速率变动更大，但有时候也能比控制型传输先行，取决于实际的主控策略和当时的总线利用情况）。
  - 仅在带宽较宽裕时才轮候得到。
  - 不同端点的批量型传输，采取公平的访问策略。
  - OUT方向的高速控制端点必须支持PING协议，详见第8.5.1节。
  - 偶发性错误会尝试重发；保证可靠性但不保证带宽和延迟。
  - 每一帧允许的最大传输次数举例（载荷长度不同，次数也不同，详见第5.8.4节的表格）：
    - 全速：< 64Bytes * 20
    - 高速：< 512Bytes * 14
- 异常情况处理：
  - DATA0、DATA1报文标识的切换问题，详见第8章。
  - 若传输出错或端点返回STALL握手包导致管道停机（halt），需要通过一条独立的控制管道进行软件干预才能恢复。
高速高带宽端点：略。
分离事务（Split Transaction）：
- 用于HC和hub之间的通信，对于设备是不可见的。
- 作用是令到全速和低速设备能接到高速hub。
- 中断型和等时型的高速分离事务占用的是内容带宽，即最高80%的那部分。
总线访问（主机侧逻辑）：
- 传输管理（向设备分配带宽的过程）：
  - 注意第5.11.1小节的示意图，记住IRP、Transfer、Transaction、Packet的互转关系，还有Client Software、USBD、HCD、HC的层级关系，以及它们的主要职责如下：
    - Client Software：
      - 调用USBD提供的接口来发出IRP，或通过回调函数（或特定缓冲区）来接收IRP结果。
    - USBD：
      - 利用HCD接口来对IRP和Transfer进行互转。
      - 参与设备的挂载（涉及接收配置、创建管道、分配带宽等）和移除。
      - 参与常规传输过程。
    - HCD：
      - 将Transfer转成Transaction并放入Transaction List投递给HC，或从Transaction List取出Transaction并转成Transfer向上传给USBD。
      - 控制带宽和帧的使用额度。
      - 操作与客户端相关的缓冲区。
    - Transaction List：
      - 是待收/发事务的暂存区。
      - 概念是通用的，但具体实现则取决于各厂商。
    - HC（硬件）：
      - 逐个取出Transaction并将其报文化为Packet，再转成物理电信号发送到总线，或将电信号还原成Packet，再组装成Transaction向上传给HCD（先放入暂存列表）。
      - 还能获知Transaction的状态，例如完成（done）、未决（pending）、中止（halted）等。
- 事务追踪：
  - 解决IRP和Transaction的互转（合并/拆分、报文化）问题。
  - 决定收/发时机和报文间顺序：
    - 同一个IRP的Transaction不一定在同一帧，不同IRP的Transaction可能在同一帧。
    - 后到IRP的部分Transaction可能插队打散先到IRP，但同一IRP的各个Transaction的时间顺序一定不会乱。
  - 主要抽象关系：
    - IRP = Transfer * n
    - Transfer = Transaction * n
      - Control Transfer = Setup(OUT) + Data(IN/OUT) * n + Status(IN)
      - Other Transfer = Data(IN/OUT) * n
- 总线时间的计算：
  - 与wMaxPacketSize、传输类型、传播延时等因素有关，不在此展开。
  - 计算公式见第5.11.3节。
- 缓冲区大小：
  - 对于等时型管道，缓冲区长度通常是1ms或125us内能传输的数据量的2倍，更多细节详见第5.12.4小节。
  - 对于其他类型的管道，只要系统内存足够，应当容纳数量不限的事务。
- 带宽回收：
  - 不同类型的传输优先级不同，能获知未用帧时间的方法也与实现相关，故无统一策略。
有关等时传输的特殊考虑：暂略。

6、机械封装

略。

7、电气特性

待补充。

8、协议层

待补充。

9、`USB`设备框架

待补充。

10、`USB`主机的硬件和软件

待补充。

11、集线器规范

暂略。

USB 2.0协议摘要

1、简介

2、术语和缩略词

3、背景

4、架构概述

5、数据流程模型（必读）

6、机械封装

7、电气特性

8、协议层

9、USB设备框架

10、USB主机的硬件和软件

11、集线器规范

9、`USB`设备框架

10、`USB`主机的硬件和软件