USB 2.0 详解（二）—— 数据流模型（下）

由 发布于

数据流模型

5.4 传输类型

USB在主机的客户端软件（USB设备的驱动程序）与USB设备的端点之间通过管道传输数据。由消息管道传输的数据以USB定义的结构进行传输，但USB也允许设备特定的结构化数据在USB定义的消息数据载荷中进行传输。USB还定义了所有管道（无论是流式传输管道还是消息传输管道）传输的数据都必须以数据包的形式传输，但最终数据载荷的格式和解释由使用该管道的客户端软件和功能来负责。

然而，USB提供了不同的传输类型，这些类型优化了与客户端软件和功能的服务需求匹配的特性。一个IRP（I/O请求包）使用一个或多个总线事务在客户端软件和其功能之间传输信息。

每种传输类型决定了通信流的不同特性，包括以下几点：

  • USB强加的数据格式
  • 通信流的方向
  • 数据包大小的限制
  • 总线访问的限制
  • 延迟的限制
  • 所需的数据顺序
  • 错误处理

USB设备的设计者为设备的端点选择功能。当为端点建立管道时，大部分管道的传输特性会被确定，并且在管道的生命周期中保持固定。可以修改的传输特性将在每个传输类型的描述中详细说明。

USB定义了四种传输类型：

  • 控制传输（Control Transfers）：突发、非周期性、主机软件发起的请求/响应通信，通常用于命令/状态操作。
  • 等时传输（Isochronous Transfers）：周期性、连续的主机与设备之间的通信，通常用于与时间相关的信息。该传输类型也保持了数据中封装的时间概念。但这并不意味着此类数据的传输需求始终是时间关键的。
  • 中断传输（Interrupt Transfers）：低频、有限延迟的通信。
  • 批量传输（Bulk Transfers）：非周期性、大数据包的突发通信，通常用于可以使用任何可用带宽并且可以延迟直到带宽可用的数据。

每种传输类型将在后续四个主要部分中详细描述。任何IRP的数据都通过数据包的载荷字段进行传输，如8.3.4节所述。第8章还描述了每种特定传输类型对协议的影响。

在USB 2.0中，数据的传输通过“管道”（pipe）进行，管道是主机（Host）与USB设备（Device）之间的数据传输通道。每个管道都有一组特定的传输特性，包括数据格式、方向、数据包大小限制、延迟、错误处理等。不同的传输类型在这些特性上有不同的要求和优化，以适应不同类型的应用需求。具体来说，USB定义了四种主要的传输类型，每种类型都有其独特的适用场景和功能。

  1. 控制传输（Control Transfers）：

    • 特点：这种传输是突发式的、非周期性的，通常由主机软件发起，适用于命令或状态请求/响应操作。
    • 使用场景：控制传输通常用于设备配置、命令执行、状态查询等控制类的操作。例如，当USB设备刚连接到主机时，主机会通过控制传输来查询设备的能力，或者给设备发送配置命令。

  2. 等时传输（Isochronous Transfers）：

    • 特点：周期性、连续的通信，具有一定的时间敏感性，通常用于音频、视频等需要按时传输的实时数据。这种传输类型不仅考虑数据内容的传输，还保持了时间的顺序性，即数据必须按照特定的时间间隔传输。
    • 使用场景：适用于视频会议、音频流等应用，这些应用中的数据有严格的时间要求，如音频和视频的帧同步。如果数据传输延迟过长，会导致音视频不同步。

  3. 中断传输（Interrupt Transfers）：

    • 特点：这种传输类型用于低频、有限延迟的通信，通常用于处理按需发送的小数据量，且要求响应时间低。
    • 使用场景：例如，键盘、鼠标等设备常用中断传输来传输数据。主机对这些设备的事件（如按键、鼠标点击）通常有较高的响应要求，延迟必须小。

  4. 批量传输（Bulk Transfers）：

    • 特点：非周期性、大数据包的传输，适用于需要大量数据传输且不要求实时性的数据，传输过程中的带宽可用性比较灵活。数据传输可以延迟，直到总线空闲并可以提供足够的带宽。
    • 使用场景：批量传输适用于文件传输、打印机数据传输等场景，其中数据量大但对延迟没有严格要求。它通过利用USB总线的剩余带宽来传输数据，因此可以在带宽空闲时进行较大的数据批量传输。

USB设备的设计者根据其设备的需求选择每个端点的传输特性，并确定管道的类型和传输模式。这些特性一旦设定，通常在管道的生命周期内保持不变，确保设备通信的稳定性和一致性。

通过选择合适的传输类型，USB能够支持从低延迟、高实时性的应用（如音视频流）到高带宽、大数据量的应用（如文件传输）的各种不同需求。

5.4.1 表格计算示例

以下部分描述了USB传输类型的每种情况。在这些部分中，表格展示了在一个（微）帧中可能包含的最大事务数量。这些表格可以用来确定特定传输类型下，可能达到的最大性能。实际性能可能会因具体系统实现的细节而有所不同。

每个表格展示了以下内容：

  • 特定传输类型（及速度）所需的协议开销
  • 对于某些样本数据负载大小：
    • 可能达到的最大持续带宽
    • 每个事务占用（微）帧的百分比
    • 对于特定情况，单个（微）帧中可容纳的最大事务数量
    • 对于特定情况，剩余的（微）帧字节数，这些字节不需要用于该事务
    • 对于特定情况，单个（微）帧中传输的总数据字节数

每个传输类型的事务通常需要多个数据包。每个事务的协议开销包括：

  • 每个数据包的 SYNC 字段：低速/全速为 8 位，高速为 32 位
  • 每个数据包的 PID 字节：包括 PID 和 PID 校验位
  • 每个数据包的 EOP 字段：低速/全速为 3 位，高速为 8 位
  • 在令牌数据包中，包含端点号、设备地址和 CRC5 字段（共 16 位）
  • 在数据包中，包含 CRC16 字段（共 16 位）
  • 在数据包中，包含数据字段（每个字节 8 位）
  • 对于多个数据包的事务，数据包之间需要的间隔（包括总线切换时间）。

这些计算假设不会发生比特填充（bit-stuffing）问题。

举例说明：低速中断 OUT 传输的事务由 5 个数据包组成：

  1. 一个 PRE 特殊数据包
  2. 一个令牌数据包
  3. 一个 PRE 特殊数据包
  4. 一个数据包
  5. 一个握手数据包

在数据包和握手数据包之间会有一次总线切换。此时，协议开销为：

  • 5 个 SYNC 字段
  • 5 个 PID 字段
  • 端点号 + CRC5 字段
  • CRC16 字段
  • 5 个 EOP 字段
  • 数据包间的延迟（包括一次总线切换、两个数据包之间的延迟、以及 2 次集线器设置时间）

USB 事务和协议开销，在USB传输中，每个事务通常包括多个数据包。每个数据包都需要一些额外的协议开销。这些开销是为了确保数据能够正确传输并且可以被接收方正确理解。

  1. SYNC 字段：用于同步信号，以确保接收方能够正确识别数据流的开始和结束。在低速和全速中，SYNC 字段是 8 位；在高速传输中，SYNC 字段是 32 位。
  2. PID 字段：每个数据包都包含一个 PID（Packet Identifier）字段，用于标识数据包的类型，如令牌包、数据包或握手包。PID 字段也包括校验位，用于确认数据的正确性。
  3. EOP 字段：EOP（End of Packet）是每个数据包的结束标志。低速和全速中，EOP 字段是 3 位；在高速传输中，EOP 字段是 8 位。
  4. CRC 字段：
    • 在令牌包中，有 CRC5（用于令牌包的错误检查），占用 16 位。
    • 在数据包中，有 CRC16（用于数据包的错误检查），也占用 16 位。
  5. 数据字段：数据包中除了协议开销外，还包含有效载荷数据，每个字节的数据字段占 8 位。
  6. 总线切换与数据包间延迟：每次数据包之间会有一个间隔时间（通常包括总线切换和集线器的时间设置）。这些延迟时间也要考虑到协议的开销。

以低速中断 OUT 传输为例，整个事务由 5 个数据包 组成，具体如下：

  1. PRE 特殊数据包（PRE Special Packet）
    这是一个预先的特殊数据包，通常用于标识传输的开始，或者为后续数据包的传输做准备。
  2. 令牌数据包（Token Packet）
    令牌包用于启动数据传输，包含目标设备的地址、端点号以及其他控制信息。它指示哪个设备应该响应，并为数据传输做准备。
  3. PRE 特殊数据包（PRE Special Packet）
    这是另一个 PRE 特殊数据包，通常用于维持帧的同步或者继续准备数据的传输。
  4. 数据包（Data Packet）
    数据包包含实际传输的数据，它是 USB 传输中最重要的部分。这个数据包的内容是需要从主机到设备（或者反向传输）的数据负载。
  5. 握手数据包（Handshake Packet）
    握手包用于确认数据是否成功传输，并告知接收方是否存在错误。它通常在数据包之后发送，确保数据的完整性和可靠性。

在数据包和握手包之间，通常还会有一个 总线切换（Bus Turnaround）时间，即主机和设备之间的通信方向切换时间。在这个示例中，数据包和握手包之间的总线切换时间是一个关键因素，它会影响整个传输的延迟。

每个数据包都包含一定的协议开销，比如 SYNC 字段、PID 字段、EOP 字段等。由于存在数据包之间的延迟和总线切换时间，因此在计算每个事务的实际带宽时，协议开销和间隔时间会影响实际传输的效率。

5.5 控制传输

控制传输允许访问设备的不同部分。控制传输旨在支持客户端软件与设备功能之间的配置/命令/状态类型通信流。一个控制传输由一个 Setup 总线事务组成，该事务将请求信息从主机传输到设备功能，零个或多个数据事务根据 Setup 事务指示的方向传输数据，最后是一个状态事务从设备功能返回状态信息给主机。当端点成功完成请求的操作时，状态事务返回“成功”。第 8.5.3 节描述了完成控制传输所使用的数据包、总线事务和事务序列的详细信息。第 9 章描述了已定义的 USB 命令代码的详细信息。

每个 USB 设备都必须实现默认控制管道作为消息管道。此管道由 USB 系统软件使用。默认控制管道提供对 USB 设备的配置、状态和控制信息的访问。功能可以（但不是必需的）为其自己的实现需求提供额外的控制管道端点。

USB 设备框架（参考第 9 章）定义了可以用来操控设备状态的标准、设备类或厂商特定的请求。还定义了描述符，这些描述符可以包含设备上的不同信息。控制传输提供了传输机制，用于访问设备描述符并向设备发出请求以操控其行为。

控制传输仅通过消息管道进行。因此，使用控制传输的数据流必须遵循第 5.5.1 节中描述的 USB 数据结构定义。

USB 系统将尽力支持主机和设备之间控制传输的传输。功能和其客户端软件不能请求特定的总线访问频率或带宽用于控制传输。USB 系统软件可能会限制设备对控制传输所需的总线访问和带宽。这些限制在第 5.5.3 节和第 5.5.4 节中进行了定义。

控制传输的目的：

  • 控制传输用于在主机和 USB 设备之间进行配置、命令和状态的交换。
  • 它允许通过 Setup 事务传输请求，之后通过数据事务传输数据，最后通过状态事务返回执行状态。

控制传输的构成：

  1. Setup 事务：传递请求信息，从主机到设备。
  2. 数据事务：根据 Setup 事务的指示方向，主机和设备之间传递数据（可能有多个数据事务）。
  3. 状态事务：设备返回执行结果（例如“成功”）的状态信息。

默认控制管道：

  • 每个 USB 设备都必须实现一个默认的控制管道，用于传输控制信息，如配置、状态、控制命令等。
  • 控制传输通过这一管道进行，但设备可以选择为特定需求提供其他控制管道。

请求和描述符：

  • 控制传输可以通过发送标准、设备类或厂商特定的请求来操控设备状态。
  • 设备描述符包含了设备的基本信息，控制传输用于访问这些描述符。

数据传输的结构要求：

  • 控制传输的数据流必须遵循 USB 数据结构定义，以确保数据正确传输。

带宽和频率：

  • 控制传输的带宽和频率由 USB 系统控制，设备无法指定需要的总线访问频率或带宽。

5.5.1 控制传输数据格式

"Setup" 事务（包含多个数据包）具有 USB 定义的结构，支持最小的命令集，以便主机和设备之间进行通信。该结构定义允许设备特定的命令扩展（即厂商特定扩展）。在 Setup 之后的 Data 事务遵循 USB 定义的结构，除非携带厂商特定的信息。Status 事务也具有 USB 定义的结构。具体的控制传输 Setup/Data 定义在第 8.5.3 节和第 9 章中进行了描述。

控制传输通常分为三个阶段：

  1. Setup 阶段：

    • 这是传输的起始阶段，主要用于指定控制传输的命令和参数。
    • Setup 阶段的数据包（Setup Packet）有一个预定义的结构，这个结构包含了最小的命令集，确保主机和设备能够理解彼此的指令。
    • 该结构也允许厂商扩展，以支持设备特定的命令。

    Setup 包的结构通常包括：

    • bmRequestType：定义请求的类型（例如设备请求、接口请求、端点请求等）。
    • bRequest：请求代码，指定设备应该执行的操作。
    • wValue：用于指定请求的具体参数，通常用于指定特定的功能或配置。
    • wIndex：指定特定设备或接口的索引。
    • wLength：传输数据的长度，通常表示设备或主机需要发送或接收的数据长度。

  2. Data 阶段：

    • 如果请求需要传输数据（如设置配置、获取设备描述符等），Setup 阶段之后会进入 Data 传输阶段。
    • 该阶段的结构也遵循 USB 定义的格式，确保数据正确传输。
    • 如果传输的数据是厂商特定的内容，那么 Data 事务的格式可能会有所不同，通常会包含厂商自定义的数据结构。

  3. Status 阶段：

    • 在传输结束时，会进入 Status 阶段。这个阶段是为了确保数据传输成功或者指示失败。
    • 通过 Status 阶段，主机或设备会互相确认数据传输是否完成，并且提供最终的传输状态。

5.5.2 控制传输方向

控制传输是通过消息管道（message pipes）支持的双向通信流。因此，当配置一个控制管道时，它将使用指定端点号的输入和输出端点。

在 USB 2.0 规范中，控制传输是双向的，也就是说数据可以从主机到设备，或者从设备到主机。为了支持这种双向通信，每个控制管道会涉及两个端点：一个输入端点和一个输出端点。这两个端点在用于接收和发送数据时分别作为输入端点和输出端点共享同一个端点号。

控制传输通常用于设备配置、状态查询、设置参数等操作。控制传输是 USB 协议栈中的核心部分，因为它负责设备的初始化、配置、命令传输等。

控制传输的数据流是 双向的，也就是说它可以支持从主机到设备的请求/数据传输，也可以支持从设备到主机的响应/数据传输。这个双向性通过所谓的 "管道"（pipes）来实现。

管道是 USB 设备和主机之间进行数据传输的逻辑通道。每个管道都有一对端点（endpoint）：输入端点和输出端点。输入端点用于从设备到主机的传输，输出端点用于从主机到设备的传输。

每个端点都有一个编号，端点号用于标识特定的输入或输出端点。当设备配置控制传输管道时，它会使用相同的端点号来分别配置输入（该端点作为输入）和输出（该端点作为输出）端点。

控制传输的双向特性使得 USB 设备能够灵活地进行请求和响应的数据交换。在实际应用中，这种方式常用于：

  • 主机向设备发送请求（例如，获取设备描述符，设置设备参数）。
  • 设备向主机发送响应（例如，返回设备状态，提供数据）。

5.5.3 控制传输的数据包大小限制

控制传输的端点指定了该端点能够从总线接收或传输的最大数据有效载荷大小。对于全速设备，允许的最大控制传输数据有效载荷大小为 8、16、32 或 64 字节；对于高速设备，最大有效载荷大小为 64 字节；对于低速设备，最大有效载荷大小为 8 字节。这个最大值适用于 Setup 包之后的数据包中的数据有效载荷；也就是说，指定的大小仅适用于数据字段部分，不包括协议所需的其他信息。Setup 包始终为 8 字节。控制管道（包括默认控制管道）始终使用其 wMaxPacketSize 值作为数据有效载荷大小。

端点在其配置中报告其最大数据有效载荷大小的值。USB 不要求传输的数据有效载荷必须恰好是最大值；即，如果数据有效载荷小于最大值，则无需填充到最大大小。

所有主机控制器都必须支持以下数据有效载荷大小：

  • 对于全速控制端点：8 字节、16 字节、32 字节和 64 字节。
  • 对于低速控制端点：仅支持 8 字节。
  • 对于高速控制端点：仅支持 64 字节。

没有主机控制器要求支持更大或更小的最大数据有效载荷大小。

为了确定默认控制管道的最大数据包大小，USB 系统软件读取设备描述符。主机会读取设备描述符的前 8 字节，设备始终会在单个数据包中响应至少这 8 个字节。主机读取完设备描述符的前部分后，保证会读取到该默认管道的 wMaxPacketSize 字段（设备描述符的第 7 字节）。之后，它将允许对所有后续的事务使用正确的大小。对于所有其他控制端点，最大数据有效载荷大小在配置后已知，USB 系统软件可以确保不会发送超过该端点支持大小的数据有效载荷。

端点必须始终传输数据有效载荷，其数据字段大小应小于或等于该端点的 wMaxPacketSize（请参见第 9 章）。当控制传输涉及的数据量超过当前已建立的最大数据有效载荷大小时，所有数据包必须是最大数据包大小，除了最后一个数据包，它将包含剩余的数据。

控制传输的数据阶段从端点到主机的传输完成的条件是：

  • 精确传输了在 Setup 阶段指定的数据量。
  • 传输了一个有效载荷小于 wMaxPacketSize 的数据包，或者传输了一个零长度数据包。

当数据阶段完成时，主机控制器会进入状态阶段，而不是继续另一个数据事务。如果主机控制器没有在数据阶段完成时进入状态阶段，端点会按照第 5.3.2 节的说明暂停管道。如果从端点接收到的有效载荷超出了预期的大小，控制传输的 IRP 将被中止或结束。

控制传输的数据阶段从主机到端点的传输完成的条件是：

  • 所有数据都已传输完毕。
  • 如果端点从主机接收到的有效载荷超出了预期的大小，它会暂停管道。

  1. 最大数据有效载荷大小：

    • 控制传输的最大数据有效载荷大小由设备的速度（全速、低速、高速）决定。全速设备可以是 8、16、32 或 64 字节，高速设备固定为 64 字节，低速设备固定为 8 字节。

  2. wMaxPacketSize：

    • 每个控制端点有一个 wMaxPacketSize，指定了该端点能够接收或传输的最大数据有效载荷的大小。这个值由设备在描述符中报告，主机通过读取设备描述符来获知该值。

  3. 数据有效载荷的传输：

    • 控制传输的 Data 阶段可以有多个数据包，通常每个数据包的有效载荷大小为最大值（即 wMaxPacketSize），除非最后一个数据包。
    • 如果传输的数据量小于最大值，数据包不需要填充。

  4. 数据传输完成的条件：

    • 从端点到主机：数据阶段完成的标志是传输了精确的 Setup 阶段指定的数据量，或传输了小于最大大小的数据包或零长度数据包。
    • 从主机到端点：数据阶段完成的标志是所有数据都已传输完毕。

  5. 错误处理：

    • 如果从端点接收到的数据超出预期的大小，控制传输会中止或结束。
    • 如果接收到的数据超出端点支持的最大大小，端点会暂停管道。

  • 控制传输的作用：
    控制传输（Control Transfer）是 USB 中一种常用的数据传输方式，主要用于设备配置、命令控制和状态查询。控制传输包含 Setup、Data 和 Status 三个阶段。在这些阶段中，数据阶段通常是数据传输的核心。

  • 最大数据包大小（wMaxPacketSize）：
    这个值是在设备的描述符中定义的，告诉主机该端点能够接受或发送的最大数据包大小。控制端点的最大数据包大小是根据 USB 设备的速度（低速、全速或高速）而定的，并且该值需要在设备的描述符中提供。

  • 数据阶段的传输：
    当传输的数据量超过一个数据包的最大容量时，USB 会继续进行多个数据包的传输，每个数据包都传输最大数据量，直到所有数据都传输完毕。数据包的大小由设备的 wMaxPacketSize 决定，最后一个数据包可能比其他数据包小。

  • 状态阶段：
    在控制传输的 Data 阶段完成后，主机控制器将进入状态阶段。如果传输过程中有错误或数据超过了预期的大小，USB 协议要求端点暂停管道，主机会终止控制传输过程。

  • 如何保证传输准确性：
    在数据传输过程中，主机会根据设备描述符中的信息来确保不会发送超过端点支持的最大数据量。如果传输的数据包大小超出端点的能力，USB 协议会中止传输，防止错误数据的产生。

5.5.4 控制传输总线访问约束

控制传输可以由高速、全速和低速USB设备使用。
一个端点无法指示控制管道所需的总线访问频率。USB通过平衡所有控制管道和特定IRP（信息请求包）在总线上的访问需求，以提供“最佳努力”方式在客户端软件和功能之间传输数据。
USB要求保留每个（微）帧的部分时间供控制传输使用，具体规定如下：

  • 如果尝试的控制传输（根据实现方式）消耗的时间少于全速/低速端点的10%，或少于高速端点微帧的20%，则剩余时间可以用于支持批量传输（参见第5.8节）。
  • 一次控制传输尝试后，如果需要重试，可以在当前或未来的（微）帧中重试；即它不要求必须在同一个（微）帧内重试。
  • 如果控制传输的数量超出了保留时间，但有额外的（微）帧时间没有用于同步或中断传输，主机控制器可以根据需要移动额外的控制传输。
  • 如果待处理的控制传输数量超出了可用的（微）帧时间，控制传输将被按需要选择并移动到总线上。
  • 如果多个端点有待处理的控制传输，针对不同端点的控制传输会根据公正访问策略进行选择，这取决于主机控制器的实现。
  • 一个频繁重试的控制传输不应被期望消耗不公平的总线时间份额。

高速控制端点必须支持PING流控制协议以进行OUT事务。此协议的详细信息在第8.5.1节中描述。

这些要求确保控制传输能够定期以“最佳努力”的方式在主机和设备之间通过总线进行传输。
USB系统软件可以根据需要改变对特定端点的控制传输速率。端点和其客户端软件不能假定控制传输有特定的服务速率。一个控制端点在单个（微）帧中可能会看到零次或多次传输。分配给软件客户端及其端点的总线时间可以根据其他设备的插入和移除，或者其他端点请求控制传输的情况而变化。
总线频率和（微）帧的时序限制了每个USB系统在一个（微）帧中能够成功完成的最大控制传输数量。对于全速/低速总线，每个帧内成功的控制传输数量限制为少于29个全速8字节数据负载或少于4个低速8字节数据负载。对于高速总线，控制传输的数量限制为每个微帧少于32个高速64字节数据负载。
表5-1列出了不同大小的低速数据包及每帧可能的最大数据包数量。此表不包括比特填充相关的开销。

  1. 控制传输的调度与访问频率
    控制传输主要用于主机与设备之间的通信。不同于其他传输类型（如批量传输、同步传输等），控制传输的时间分配是通过"最佳努力"（best effort）方式进行调度的。这意味着USB总线会尽力在合适的时机为控制传输分配时间，但不保证每个控制传输都会立即获得处理。

    • 端点无法指定访问频率：控制传输的具体时间安排是由USB总线来管理的，设备无法控制自己传输的频率。
    • 可变的控制传输速率：USB系统软件可以根据实际情况动态调整控制传输的速率。例如，某个端点可能在某一时刻没有传输任务，而其他端点则需要更多的总线时间。

  2. 时间分配规则
    控制传输的时间分配与USB的传输方式和端点类型相关。

    • 全速和低速设备：如果控制传输的时间消耗低于帧时间的10%，则剩余时间可用于其他类型的传输（如批量传输）。
    • 高速设备：如果控制传输消耗的时间少于微帧的20%，则剩余时间也可以用于其他传输类型。
    • 重试机制：如果某个控制传输需要重试（可能因为传输失败或其他原因），它不必在同一个帧中进行重试，可以在之后的帧中完成。

  3. 控制传输的优先级和公平性

    • 控制传输的公平性：如果有多个控制传输待处理，主机控制器会根据公平访问策略来决定传输的顺序和分配优先级。具体的策略由主机控制器实现决定。
    • 避免占用过多总线时间：对于频繁需要重试的控制传输，USB规定它不应该占用过多的总线时间，这样可以确保其他控制传输也有机会进行。

  4. 高速控制端点的PING流控制
    高速USB设备的控制端点要求支持PING流控制协议，这用于控制OUT事务的传输过程，确保数据可靠地从主机传输到设备。PING协议的详细内容在USB规范的其他章节中有所描述。

  5. 最大传输数量的限制
    USB的总线频率和帧时序限制了在每个帧内能够成功完成的控制传输数量：

    • 全速/低速总线：每个帧内的成功控制传输数量限制较低。例如，对于全速传输，最多可以在一个帧内传输29个8字节的数据负载；对于低速，最多为4个8字节数据负载。
    • 高速总线：每个微帧可以完成更多的控制传输，最多可以完成32个64字节的数据负载。

  6. 低速数据包的传输限制
    表5-1展示了不同大小的数据包在低速下每帧内的传输限制。这个表格不考虑比特填充的开销，而是关注有效负载的传输能力。

    参见《usb2.0 specification》

好的，下面是你提供的USB 2.0官方手册中的第5.5.5节“控制传输数据序列”的翻译：

5.5.5 控制传输数据序列

控制传输要求主机向设备发送一个Setup总线事务，以描述设备应执行的控制访问类型。Setup事务后面可能会跟随一个或多个控制数据事务，这些数据事务携带请求访问的具体信息。最后，状态事务完成控制传输，并允许端点将控制传输的状态返回给客户端软件。控制传输的状态事务完成后，主机可以继续进行下一个控制传输。

如第5.5.4节所述，每个控制事务及下一个控制传输将在主机控制器实现定义的时间内通过总线传输。设备端点可能会在控制传输的数据和状态事务期间处于忙碌状态。在这些端点指示其忙碌的时段（有关详细信息请参见第8章和第9章），主机将在稍后的时间重试该事务。

如果在先前的控制传输未完成之前收到Setup事务，设备必须中止当前的传输/操作，并处理新的控制Setup事务。通常不应在前一个控制传输完成之前发送Setup事务。然而，如果由于总线上发生了错误导致传输被中止，主机可以从设备端点的角度提前发送下一个Setup事务。

在遇到暂停条件或主机检测到错误后，控制端点可以通过接受下一个Setup PID来恢复；即，控制端点不需要通过其他管道进行恢复操作。对于默认控制管道（Default Control Pipe），如果下一个Setup PID未被接受，则最终需要设备复位来清除暂停或错误条件。

USB提供了强大的错误检测和恢复/重传机制，用于处理控制传输过程中发生的错误。发送端和接收端能够在控制传输中保持同步，并以最小的努力进行恢复。数据和状态包的重传可以通过包中的数据重试指示符被接收端检测到。发送端可以通过包的握手信息可靠地确定对应的接收端是否已成功接受传输的包。该协议允许区分重传的包与原始包，唯一例外的是控制Setup包。由于传输错误，Setup包可能会被重传；然而，Setup包无法指示它是原始包还是重传的包。

控制传输（Control Transfer）的数据序列以及相关的机制，包括Setup事务、数据事务、状态事务以及错误恢复和重传机制。

  • Setup事务：

    • 主机发送一个Setup事务到设备，定义请求的类型和控制访问的参数。这个事务通常用于初始化设备或者请求设备的状态或数据。

  • 数据事务：

    • 如果控制传输需要携带数据（例如设备的配置信息或传输命令），那么在Setup事务后会发送一个或多个数据事务。这些数据事务用于传输具体的数据内容。

  • 状态事务：

    • 在数据事务之后，主机会发送一个状态事务以完成整个控制传输。这个事务的作用是接收设备对传输状态的确认或响应，表明控制传输是否成功完成。

控制传输的目的是通过这三个步骤来实现设备与主机之间的控制信息交换。

USB设备的端点（Endpoint）在进行控制传输时，可能会处于忙碌状态，特别是在数据事务和状态事务的过程中。如果端点在这些时刻忙碌，主机会在稍后的时间再次重试该事务。这种机制确保了设备能够在准备好之后继续处理传输。

通常情况下，Setup事务在前一个控制传输完成之前不应发送。然而，在以下两种情况下，主机可能会提前发送Setup事务：

  • 传输错误导致的中断：如果当前控制传输被总线错误等问题中断，主机可以从设备的角度提前发送新的Setup事务。
  • 异常情况：例如总线的错误或其他异常情况，可能导致设备需要中断当前操作并准备处理新的请求。

USB协议有强大的错误检测和恢复机制。具体体现在：

  • 重传机制：如果控制传输中的数据包（数据包和状态包）由于传输错误未成功接收，USB协议会支持通过重试进行恢复。接收方可以通过数据重试指示符检测重传的包。
  • 控制端点的恢复：如果出现暂停（Halt）条件或错误，控制端点可以通过接受下一个Setup PID（包标识符）来恢复，而无需通过其他管道进行复杂的恢复操作。如果是默认控制管道，则在未接受下一个Setup PID的情况下，需要设备复位来清除错误或暂停状态。

在控制传输中，Setup包具有特殊的处理方式。由于网络或传输问题，Setup包可能会被重传。然而，Setup包无法通过任何标记来区分它是原始的还是重传的。这意味着，Setup包是唯一无法通过额外信息来确定其是否为重传的数据包。

5.6 等时传输

在非USB环境中，等时传输通常意味着具有恒定速率、容错能力的传输。在USB环境中，选择等时传输类型将为请求者提供以下功能：

  • 保证访问USB带宽且有界延迟：请求者可以保证在一定的带宽范围内进行传输，且延迟是可预见的。
  • 保证恒定数据传输速率：只要数据被提供到管道中，数据速率将保持恒定。
  • 传输失败时不重试：如果因错误导致数据传输失败，不会重新尝试传输该数据。

虽然USB的等时传输类型是为支持等时源和目的地（如音频或视频流等）设计的，但并不要求使用此传输类型的软件必须具有等时性才能使用该传输类型。

5.12节会提供更多关于如何处理USB中等时数据的特殊考虑的详细信息。

5.6.1 等时传输数据格式

USB对等时管道中的通信流数据内容没有强制的结构要求。

5.6.2 等时传输方向

等时管道是流式管道，因此总是单向的。每个端点描述符会指示某个等时管道的通信流是流入主机还是流出主机。如果设备需要双向的等时通信流，则必须使用两个等时管道，每个方向一个。

5.6.3同步传输分组大小限制

参考手册

5.6.4同步传输总线接入限制

参考手册

5.6.5 同步传输数据序列

同步传输不支持因总线错误而重新传输数据。在接收端可以检测到传输错误。USB协议的低层并不允许对同步传输的端点进行返回握手，通常，握手操作是为了通知发送端一个数据包是否被成功接收。然而，对于同步传输，时间性比数据的正确性或重新传输更为重要，并且由于总线上预期的错误率较低，协议做出了优化，假定传输通常会成功。同步传输的接收端可以检测到在某一（微）帧期间是否丢失了数据。此外，接收端还可以确定丢失了多少数据。第5.12节会更详细地描述这些USB机制。

同步传输的端点永远不会停止，因为没有握手来报告停止条件。错误会作为与同步传输的IRP（I/O请求包）相关的状态报告，但同步传输的管道不会在出现错误时停止。如果检测到错误，主机会继续处理与下一个（微）帧相关的数据。由于同步事务的协议不允许每个事务进行握手，因此只能进行有限的错误检测。

USB的同步传输（Isochronous Transfer）设计用于传输对时间要求高、连续性强的数据，如音频和视频流。与其他传输类型（如控制传输或批量传输）不同，同步传输不允许因发生错误而重新传输数据。这是因为对于这些数据流来说，时间的准确性比数据的完美传输更为重要。

  • 错误检测与处理： 虽然同步传输中可以检测到错误，但并不会对错误进行数据重传。接收端能够检测到数据是否丢失或错过了某些数据包，以及丢失了多少数据。

  • 没有停止机制： 同步传输中的端点不会因为错误而停止工作。即使发生错误，主机依然会继续处理下一个（微）帧的数据。

  • 低错误率假设： 由于USB总线的错误率预期较低，协议假定传输大部分时间会顺利进行，因此没有为每个事务设计详细的握手机制来处理错误。

  1. 同步传输的特性
    同步传输最重要的特性之一是时间性要求。音频和视频数据流常常需要以固定的时间间隔传输，如果数据传输迟缓，可能会导致音视频的卡顿或不连贯。因此，USB 2.0对同步传输的设计进行了优化，使其能够在特定的时间点传输数据，保证数据流的连续性和实时性。

  2. 错误处理与数据丢失
    在同步传输中，协议不允许对传输错误进行自动的重传。也就是说，当某个数据包丢失或损坏时，它不会被重新发送。接收端可以检测到数据丢失或丢包的情况，但它不会发出请求要求重新传输丢失的数据。对于实时性强的应用来说，丢失一部分数据可能是可以接受的，只要数据流的时间性没有受到影响。

    例如，在视频播放过程中，如果某一帧的图像丢失了，视频可能会出现短暂的卡顿或失真，但这并不会停止视频的播放过程，用户也可能不会明显感知到。

  3. 无握手机制的原因
    对于控制传输和批量传输，USB协议会通过握手（ACK、NAK等）来确认每个数据包是否成功接收。这样可以确保数据的完整性。但对于同步传输，时效性更为重要。由于这些数据流要求在固定时间内传输，若每个数据包都要等待握手确认，则会浪费时间，导致数据传输的延迟。因此，USB协议在同步传输中省略了握手机制，假定大部分传输不会出错。

    如果发生错误（如数据丢失或传输错误），USB主机会继续向下一个时间点的数据传输推进，而不会因为一个小错误就中断整个传输过程。

  4. 端点的行为
    对于同步传输的端点，如果发生错误，它不会“停止”或“暂停”。传统的传输可能会通过“停止”机制来报告错误，意味着端点会被挂起并需要等待后续处理。然而，在同步传输中，端点会持续工作，并处理下一帧数据，即使当前帧发生了错误。这是为了保证实时性和持续性，避免因小的错误导致数据流中断。

  5. 有限的错误检测
    尽管同步传输协议不进行重传，接收端仍然能够检测到错误。例如，接收端可以通过检查帧的完整性或超时来识别是否有数据丢失。但由于没有握手机制来每次确认数据包的传输结果，因此错误检测在这种传输类型中是有限的。

  6. 5.12节的详细描述
    章节5.12可能会进一步描述同步传输中如何检测和报告错误，以及一些具体的错误处理机制。详细了解这一部分会帮助更深入理解同步传输中如何管理错误和数据流。

5.7 中断传输

中断传输类型旨在支持那些需要偶尔发送或接收数据，但需要在固定的服务周期内完成的设备。请求使用中断传输类型的管道时，提供给请求者以下内容：

  • 保证的最大服务周期：保证管道在一个固定的时间周期内得到服务。
  • 在传输尝试失败时进行重试：如果由于总线错误导致传输失败，会在下一个周期重新尝试传输。

5.7.1 中断传输数据格式

USB对中断管道的通信流没有强制的数据内容结构要求。

5.7.2 中断传输方向

中断管道是流式管道，因此它始终是单向的。一个端点描述会标明一个中断管道的通信流是从设备到主机（输入），还是从主机到设备（输出）。

中断传输是一种适用于那些需要周期性传输数据，但数据传输的频率不高的设备（例如：键盘、鼠标等外设）。通过中断传输，USB设备可以定期发送或接收数据，且每次传输的服务时间是固定的，保证了最大服务周期。

  1. 中断传输的应用场景：
    中断传输主要用于那些数据交换不频繁，但有实时性要求的设备。这类设备不需要持续的高速数据流，比如鼠标、键盘、游戏控制器等，这些设备只需要在特定时间间隔内向主机报告状态或者接收指令。

  2. 保证的最大服务周期：
    每个中断传输类型的管道都有一个固定的服务周期，USB系统会保证在每个服务周期内，设备的请求能够得到处理。举例来说，某个设备请求每100毫秒接收一次数据，那么USB主机会保证在每个100毫秒的周期内为该设备提供服务，即使没有数据需要传输。

  3. 传输失败后的重试：
    如果由于一些传输错误（例如总线上的干扰或设备的临时问题）导致传输失败，USB协议会在下一个周期重新进行尝试，而不会直接丢弃此次请求。这样就能保证中断传输的可靠性，尤其在数据丢失可能影响设备功能的场景中。

  4. 数据格式：
    USB协议对于中断管道的数据内容结构没有强制要求。这意味着设备可以根据自己的需要选择不同的数据格式，只要符合USB的传输规范即可。

  5. 管道方向：
    中断管道是单向的，意味着数据只会从设备流向主机，或者从主机流向设备，不会同时双向传输。USB端点描述符会明确标明该中断管道是输入还是输出，输入意味着从设备到主机的数据流，输出则是从主机到设备的数据流。

5.7.5 中断传输数据序列

中断传输可以使用交替的数据切换位（数据位仅在成功传输完成时切换），或者是持续不断地切换数据切换位。在任何情况下，主机必须假设设备遵守第8章中定义的完整握手/重试规则。设备可以选择始终切换DATA0/DATA1的PID，从而忽略主机的握手响应。然而，在这种情况下，当发生错误时，客户端软件可能会错过一些数据包，因为主机控制器会将下一个数据包解释为未收到的数据包的重试。

如果由于传输错误或从端点返回STALL握手而在中断管道上检测到停止条件（halt condition），则所有挂起的IRP（I/O请求包）都会被终止。停止条件的移除是通过软件干预实现的，通过一个单独的控制管道进行。该恢复操作将重置数据切换位为DATA0，以确保主机和设备上的端点一致。由于总线上检测到的错误会影响特定的传输，因此中断事务会因为这些错误被重试。

USB 2.0中断传输的数据切换位（toggle bit）用于控制数据包的顺序和完整性，确保数据的可靠传输。它们可以按照两种方式工作：

  1. 交替切换（Alternating Toggle）：在每次成功的传输后，数据切换位会切换，以便主机能够确定传输状态。
  2. 持续切换（Continuous Toggle）：数据切换位会持续变化，设备不再等待主机的确认，从而可能错过某些数据包，特别是在出现错误时。

在遇到传输错误或遇到STALL握手（中断的标志）时，中断传输会进入停止状态，所有挂起的I/O请求包（IRP）会被终止。为了解决这一问题，需要通过主机与设备之间的控制管道来恢复传输状态，恢复过程会重置数据切换位至DATA0，使得设备和主机上的状态一致。这样做是为了确保设备能够继续进行数据传输，并且防止由于错误的积累导致无法正常进行后续操作。

  1. 数据切换位（Data Toggle）：
    在USB中，数据切换位主要用于控制传输数据包的顺序。它分为DATA0和DATA1两个状态。在中断传输中，每个数据包都需要根据切换位的状态来判断是否是新的传输数据包。如果切换位没有变化，主机可以认为之前的数据包没有成功接收并会尝试重新传输。

    • 如果设备总是切换DATA0/DATA1，它可以避免等待主机的握手确认，但如果发生错误，主机会把下一个数据包视为对丢失数据包的重试，这可能会导致数据丢失，因为客户端软件可能会错过该数据包。

  2. 中断传输和错误重试：
    中断传输是一种低带宽的、周期性的数据传输方式，通常用于需要定期报告设备状态的场景，比如键盘或鼠标。中断传输的可靠性依赖于数据切换位和握手机制。若传输发生错误或接收到STALL握手响应（表示传输停止），则系统会进入暂停状态，并通过软件进行恢复。恢复过程会重置数据切换位，使得后续的数据传输可以正确进行。

  3. Halt Condition 和 Recovery：
    在USB中，如果传输错误导致传输无法继续，或者设备返回STALL信号表示它无法处理当前的请求，传输会进入“停止状态”（Halt Condition）。为了恢复传输，需要使用控制管道进行干预。通过控制管道发送一个复位信号来移除停止状态，并重置切换位为DATA0。这确保了设备和主机的状态一致，允许重新开始传输。

  • PID（Packet Identifier）：用于标识USB传输中的数据包类型。DATA0和DATA1是两种不同的PID，帮助主机区分数据包的状态和顺序。

  • STALL握手：这是USB协议中的一种错误或异常状态。当设备无法处理当前请求时，它会返回一个STALL信号，表示请求无法被执行，传输必须停止。

  • IRP（I/O请求包）：指主机向设备发出的请求或操作指令。当传输错误或条件停止发生时，IRP会被终止，等待恢复操作。

5.8 批量传输

批量传输类型旨在支持需要在高度可变的时间内传输大量数据的设备，这些设备可以使用任何可用的带宽。请求一个批量传输类型的管道（pipe）时，给请求者带来以下几项特性：

  • 带宽可用时，可以访问USB总线。
  • 数据传输重试：如果由于总线错误导致偶尔的传输失败，会进行重试。
  • 数据保证传输：虽然数据传输得到保证，但没有带宽或延迟的保证。

批量传输仅在有可用带宽的情况下进行。如果USB总线上有大量空闲带宽，批量传输可能会相对快速地进行；而如果带宽较为紧张，批量传输可能会非常缓慢，甚至是滴水般地进行。

5.8.1 批量传输数据格式

USB对于批量传输的数据内容没有强制的结构要求。也就是说，批量传输的数据可以是任何形式，数据的具体格式由设备或应用程序决定。

5.8.2 批量传输的方向

批量管道是流式管道（stream pipe），因此对于每个管道而言，数据流动的方向始终是单向的，即数据要么流向主机，要么从主机流出。如果设备需要双向的批量数据传输流，就必须使用两个批量管道，一个用于从设备到主机的传输，另一个用于从主机到设备的传输。

  • 数据量大，传输不定时：批量传输适用于需要传输大量数据，但传输时机不确定的设备。例如，打印机、大容量存储设备、扫描仪等都可能采用批量传输模式进行数据交换。这些设备可能不会持续不断地传输数据，而是间歇性地传输大数据块。

  • 带宽可用时进行传输：USB系统采用的是带宽共享机制。批量传输在总线上并不是优先进行的，它只能在USB总线空闲或者带宽可用时进行传输。如果USB总线上有其他数据传输正在进行，批量传输可能会被推迟。

  • 传输可靠性和重试机制：USB协议对批量传输有内建的错误重试机制。如果因为总线上的错误（例如信号干扰或设备错误）导致数据传输失败，系统会自动进行重试，以保证数据最终被正确传输。

  • 不保证带宽或延迟：批量传输并不像**流控制传输（Isochronous transfer）**那样保证实时性或带宽。批量传输的速度是依赖于当前可用带宽的，可能会有很大的波动，尤其是在总线上有多个设备同时传输时。

  • USB协议对于批量传输的数据格式没有特定要求。这意味着，发送和接收的数据可以是任何格式，如文件、图片、音频数据等，具体的内容和格式是由应用层或设备自身决定的。USB只关心数据的传输，而不涉及数据的具体含义或结构。

  • 在USB传输中，数据流向是有方向性的。对于一个批量管道来说，数据传输的方向是固定的，要么是主机向设备传输数据，要么是设备向主机传输数据。

  • 如果设备需要双向的数据传输（比如在两台设备间进行大文件交换），则需要分别为每个方向配置一个独立的批量管道。每个管道只能承载一个方向的数据流，因此需要两个管道来实现双向传输。

5.8.5 Bulk传输数据序列

Bulk传输使用数据切换位（data toggle bits），该位仅在事务成功完成时才会切换，以保持在事务因错误重试时发送方和接收方之间的同步。当端点通过适当的控制传输进行配置时，Bulk事务会初始化为DATA0。主机会在第一次Bulk事务时启动DATA0。如果由于传输错误或端点返回STALL握手而在Bulk管道上检测到停止条件（halt condition），所有待处理的IRP（I/O请求包）都会被终止。停止条件的去除通过软件干预实现，通常是通过一个单独的控制管道。这种恢复将重置端点上的数据切换位为DATA0，在主机和设备上都会进行重置。

  1. 数据切换位（Data Toggle Bit）：
    Bulk传输使用“数据切换位”来确保发送和接收双方的同步。数据切换位有两种状态：DATA0和DATA1。该位只有在成功完成事务时才会切换。这是为了在遇到错误时保持传输的同步。例如，当传输失败并需要重试时，接收方和发送方可以依赖这个切换位来确保他们在重试时的同步。

  2. 初始化：
    在端点被配置时（通过控制传输），Bulk传输的数据切换位会初始化为DATA0。当主机开始第一次Bulk传输时，数据切换位也是DATA0。

  3. 错误和重试：
    如果在Bulk传输过程中发生了错误（如传输错误或端点返回STALL响应），会导致在该管道上发生停止条件（halt condition）。此时，所有等待处理的I/O请求（IRP）会被终止。

  4. 恢复机制：
    如果检测到停止条件，必须通过软件干预来清除该条件。这通常通过一个单独的控制管道实现。清除停止条件后，数据切换位会被重置为DATA0，在主机和设备端都会执行这个重置操作。

  1. 数据切换位（Data Toggle Bit）：
    在USB通信中，数据切换位用于标识Bulk传输的数据序列的顺序。其目的是确保即使在发生重试时，发送方和接收方能够同步工作。具体而言，DATA0和DATA1分别代表两种状态，保证了数据传输的正确顺序。这个切换位只在事务成功时才会发生变化。如果事务失败，切换位不会改变，直到重试并成功完成。

  2. 传输错误和重试机制：
    USB设备和主机之间的Bulk传输往往是无连接的、无时序要求的（即“包容性传输”），这使得它们能够高效地传输大量数据。然而，数据的传输过程中可能会发生错误，例如信号干扰、设备响应延迟或其他通讯问题。在这种情况下，Bulk事务会被重试，而数据切换位确保了这些重试事务的顺序和同步。

  3. 停止条件和STALL握手：
    如果端点（无论是主机还是设备）检测到错误，它可能会返回一个“STALL”握手信号，表示它无法继续处理当前请求或事务。这时候，传输会进入停止状态。所有等待处理的IRP会被终止，直到错误被清除。

  4. 停止条件的清除和软件干预：
    一旦检测到停止条件，通常需要通过软件介入来清除。这通过控制传输实现，控制传输是一种由主机发起、用于管理USB设备状态的特殊传输类型。通过控制传输，主机可以重置端点的状态，恢复正常工作。数据切换位也会在恢复过程中被重置为DATA0，从而确保事务的顺序可以继续进行。

5.9 高速、高带宽端点

参考手册

5.9.1 高带宽中断端点

参考手册

5.9.2 高带宽等时端点

参考手册

5.10 分割事务

主机控制器和集线器支持一种额外的事务类型，称为分割事务。该事务类型允许全速（Full-Speed）和低速（Low-Speed）设备连接到高速度（High-Speed）运行的集线器。这些事务仅涉及主机控制器和集线器，对设备是不可见的。高速度的分割事务用于中断（Interrupt）和等时（Isochronous）传输时，必须由主机从微帧的80%周期部分分配。关于分割事务的更多信息可以在第8章和第11章中找到。

**分割事务（Split Transactions）**是一种由主机控制器和集线器（Hub）共同支持的事务类型，它的目的是使全速（Full-Speed）和低速（Low-Speed）设备能够通过高速度（High-Speed）集线器进行通信。简单来说，分割事务是为了确保较低速度设备（如USB 1.1设备）能够在USB 2.0的高速度环境下正常工作。

5.11 总线访问与传输

在主机与USB设备之间进行任何数据传输都需要使用USB带宽。为了支持各种同步和异步设备，需要满足每个设备的传输需求。分配总线带宽给设备的过程称为“传输管理”。主机上有多个实体协调USB上信息的流动：客户端软件、USB驱动程序（USBD）和主机控制器驱动程序（HCD）。这些实体的实现者需要理解与总线访问相关的关键概念：

  • 传输管理：支持USB通信流动的实体和对象。
  • 事务跟踪：用于跟踪事务在USB系统中流动的USB机制。
  • 总线时间：传输一个数据包所需的时间。
  • 设备/软件缓冲区大小：支持总线事务所需的空间。
  • 总线带宽回收：某些情况下，已分配给其他传输的带宽未被使用，因此可以被控制和批量传输重新使用。

前面的章节主要关注客户端软件如何与功能进行交互以及两者之间的管道流动。在这一节中，重点讲解主机的不同部分如何协同工作以支持数据在USB上传输。设备实现者也可能对这些信息感兴趣，以便他们了解当客户端请求传输时主机正在执行的操作，以及如何将该传输呈现给设备。

  1. 传输管理
    传输管理是确保USB设备与主机之间的高效数据交换的机制。它涉及到如何合理分配和调度带宽，以便满足不同设备的传输需求，特别是同步（如音视频流）和异步设备（如存储设备）的需求。不同类型的设备可能对带宽有不同的要求，传输管理需要确保所有设备的需求都能够被满足。

  2. 事务跟踪
    USB系统通过事务跟踪来确保数据传输按顺序、正确地完成。在USB中，数据传输是通过“事务”（Transaction）完成的，每个事务代表一个数据包的发送和接收过程。USB系统必须能够跟踪这些事务，确保数据在传输过程中没有丢失，并能够在出现错误时进行恢复。

    • USB事务通常包括三种类型：控制传输（Control Transfer）、批量传输（Bulk Transfer）和同步传输（Isochronous Transfer）。
    • 事务跟踪需要保证每个数据包按照正确的时间和顺序到达目标设备。

  3. 总线时间
    “总线时间”指的是将数据包从主机发送到设备，或从设备发送到主机所需的时间。这涉及到数据在USB总线上的传输延迟。USB系统设计时考虑到了不同传输速度（如低速、全速和高速），因此“总线时间”是衡量系统效率的重要因素之一。

    • 影响总线时间的因素包括数据包的大小、总线带宽的占用情况、设备的响应速度等。

  4. 设备/软件缓冲区大小
    USB事务的执行需要有适当的缓冲区空间。设备和主机在进行数据传输时，需要一定大小的缓冲区来暂存数据。设备端的缓冲区会存储接收到的数据，直到设备能够处理这些数据；主机端的缓冲区则用来缓存要发送的数据。

    • 如果缓冲区空间不足，可能会导致数据丢失或传输延迟。为了确保高效的传输，设备和主机都需要合适的缓冲区管理。

  5. 总线带宽回收
    在USB传输过程中，如果某些传输已经分配了带宽但没有实际使用（例如由于设备不响应或传输失败），这些空闲的带宽就可以被其他传输所回收并重新利用。特别是对于控制传输和批量传输，可以重新分配这些带宽，提高USB总线的利用率。

    • 例如，在同步传输（如视频或音频流）发生延迟或中断时，空闲的带宽可以用来进行批量传输，避免带宽浪费。

5.11.1 传输管理

传输管理涉及多个实体，它们在不同对象上操作，以便在总线上进行数据传输。主要包括以下几个实体：

  1. 客户端软件 (Client Software)：

    • 生成或消费特定功能的数据，通常是通过调用和回调请求 IRP（输入请求包）与 USBD（USB 驱动）接口交互。
    • 客户端软件通过其函数端点与 USB 设备进行通信。

  2. USB 驱动 (USBD)：

    • 负责将客户端的 IRP 中的数据转换为适合设备端点的格式，或者将设备端点的数据转换为客户端 IRP 所需的格式。
    • 它通过调用和回调与相应的主机控制器驱动程序（HCD）进行交互。一个客户端 IRP 可能涉及一个或多个传输操作。

  3. 主机控制器驱动 (HCD)：

    • 负责将 IRP 转换为主机控制器需要的事务（Transaction），并将这些事务组织起来，以便通过主机控制器进行处理。
    • 主机控制器驱动程序和硬件之间的交互是实现相关的，且超出了 USB 规范的范围。

  4. 主机控制器 (Host Controller)：

    • 负责根据事务生成总线活动，即通过数据包在总线上传输特定的功能数据。

  1. 客户端软件 (Client Software)：

    • 客户端软件是应用层的组成部分，通常是操作系统中的一部分或者用户编写的应用程序。它的主要职责是生成和消费数据。
    • 在 USB 的上下文中，客户端软件通常会使用 USB 驱动提供的接口来请求数据传输。数据的传输由 输入请求包（IRP） 描述，IRP 包含了如何处理数据的具体信息。
    • 客户端软件可以通过 回调函数（Callbacks）来处理传输过程中发生的事件，例如传输完成或发生错误。

  2. USB 驱动 (USBD)：

    • USB 驱动（USBD） 是 USB 系统中的核心组件，它的作用是将客户端软件的 IRP 转换成主机控制器能够理解的格式。它是操作系统的一部分，负责处理 USB 设备的通信。
    • 一个 IRP（输入请求包） 可能会涉及多个传输（Transaction），因此，USB 驱动需要将 IRP 中的请求分解并安排多个传输操作，以确保数据顺利传输到设备或者从设备传输到主机。

  3. 主机控制器驱动 (HCD)：

    • 主机控制器驱动（HCD） 是与硬件控制器交互的组件，负责将 IRP 转换为实际的硬件事务。它通过处理器与硬件之间的接口，确保数据能够按正确的时序传输。
    • HCD 还管理与硬件相关的所有细节，包括如何调度事务以及如何将数据正确地传输到 USB 总线。因为不同的硬件实现有所不同，HCD 可能会因硬件平台的不同而有所变化。

  4. 主机控制器 (Host Controller)：

    • 主机控制器 是 USB 系统中的硬件组件，它负责将从 USB 驱动和主机控制器驱动传来的事务转换为总线上的数据包，从而完成数据的传输。
    • 主机控制器会通过发送和接收数据包，进行具体的数据传输操作。数据包包括控制、数据和状态信息，用于实现数据传输。

这段文字描述了 USB 2.0 中 Client Software（客户端软件）的作用和行为，特别是如何通过 USBD 接口请求传输操作，并与 USB 驱动程序交互。以下是对该段文字的翻译、总结与详细解释：

5.11.1.1 客户端软件

客户端软件决定需要与功能设备进行哪些数据传输。它使用操作系统特定的接口来请求 IRP（I/O 请求包）。客户端软件仅仅知道它需要操作的管道（即接口）。客户端遵循之前描述的总线访问和带宽限制，并依据每种传输类型进行操作。客户端软件通过 USBD 接口发起请求。

某些客户端软件可能通过操作系统定义的其他设备类接口来操作 USB 功能，而不直接调用 USBD 接口。然而，总是有某个最低层次的客户端软件，通过调用 USBD 接口，将 IRP 传递给 USBD。所有传递的 IRP 都必须遵循在建立管道时商定的带宽约束。如果一个功能从非 USB 环境迁移到 USB 环境，那么原来直接通过内存或 I/O 访问硬件的驱动程序，便成为了 USB 环境中与 USBD 交互的最低层客户端软件。

在客户端软件请求了数据传输并且请求被处理后，客户端软件会收到 IRP 完成状态的通知。如果传输涉及主机到功能设备的数据传输，客户端软件可以访问与已完成 IRP 相关的数据缓冲区中的数据。USBD 接口在第10章中有详细定义。

客户端软件的主要任务是发起和管理与 USB 功能设备（比如 USB 外设）之间的传输请求。它通过操作系统提供的接口，向 USBD 发出 IRP 请求，并确保这些请求遵循事先设定的带宽和传输约束。客户端软件能够处理不同的传输类型，并且会根据操作的状态获取相应的反馈信息。更高层次的客户端软件可能不直接与 USBD 接口交互，而是通过其他设备类接口间接地与 USB 功能进行交互。

  1. 客户端软件（Client Software）：

    • 客户端软件指的是通过 USB 总线与 USB 功能进行交互的软件部分。它可能是操作系统的一部分，或是一个应用程序。
    • 该软件通过系统提供的接口来请求传输（数据读/写等），并需要遵循总线带宽和数据传输的协议。

  2. IRP（I/O 请求包）：

    • IRP 是一种请求结构，用于描述对设备的 I/O 操作（如数据传输）的具体要求。客户端软件通过 IRP 告诉 USB 驱动程序它希望进行什么样的操作。

  3. 管道和接口：

    • USB 中的管道（pipe）是指数据传输的通道，它们在 USB 设备和主机之间进行数据传输。接口（interface）则是客户端软件与设备通信的具体方式，不同的接口定义了不同的传输模式和协议。
    • 客户端软件通过操作这些管道和接口与 USB 设备进行交互。

  4. 带宽和总线访问约束：

    • USB 系统中的带宽和总线访问有严格的约束条件。例如，在数据传输时，需要保证每个传输类型（如控制传输、批量传输、同步传输等）不超过规定的带宽限制。这些限制由客户端软件和 USB 总线控制器共同遵守。

  5. USBD（USB 驱动程序堆栈）：

    • USBD 是 USB 驱动程序堆栈的一个接口，用于管理 USB 设备的所有数据传输。客户端软件通过 USBD 来提交 IRP 请求，并等待数据传输完成后的反馈。USBD 会负责处理这些请求，并确保它们符合带宽和总线访问的限制。

  6. 低层次客户端与高级客户端：

    • 高级客户端软件可能通过操作系统定义的设备类接口与 USB 功能交互。这些高级客户端可能没有直接调用 USBD 接口。
    • 然而，所有请求最终都会通过某个低层次的客户端（通常是直接与硬件进行交互的驱动程序）调用 USBD 接口。

  7. 数据传输完成后的反馈：

    • 客户端软件会收到关于 IRP 操作的完成状态通知，这意味着数据传输已完成。若传输是从功能设备到主机的数据传输，客户端软件将能够访问数据缓冲区，读取或处理数据。

5.11.1.2 USB驱动程序

通用串行总线驱动程序（USBD）在两个主要时间段内负责调解总线的访问：

  • 设备连接并配置时
  • 正常数据传输期间

当设备连接并配置时，USBD负责确保所需的设备配置可以在总线上实现。USBD接收来自配置软件的配置请求，这些请求描述了所需的设备配置，如端点（endpoint）、传输类型（transfer type）、传输周期（transfer period）、数据大小（data size）等。
USBD会根据带宽可用性和是否能够在总线上实现该请求类型来接受或拒绝配置请求。如果接受请求，USBD会为请求者创建一个管道（pipe），并根据传输类型的定义和相应的约束条件来配置。
对于周期性端点的带宽分配，在设备配置时并不需要进行，而且一旦分配完成，可以在不改变设备配置的情况下释放带宽。

USBD的配置方面通常是操作系统特定的，并且通常会利用操作系统的配置功能，避免定义额外的（冗余的）接口。

一旦设备配置完成，软件客户端就可以请求IRP（I/O请求包）来在客户端和设备的功能端点之间移动数据。

USB驱动程序（USBD）负责管理设备在USB总线上的连接和数据传输过程。其工作可以分为两大类时间段：

  1. 设备连接和配置阶段：

    • 在这个阶段，USBD的任务是根据配置请求来配置设备。这些请求会描述设备需要的端点、传输类型、周期性要求、数据大小等信息。
    • USBD会根据总线的带宽和资源是否足够来决定是否接受配置请求。
    • 如果请求被接受，USBD会创建一个管道（pipe）来处理数据传输。
    • 对于周期性传输的端点，带宽分配可以在设备配置后进行，并且可以根据需要释放，而不必重新配置设备。

  2. 正常数据传输阶段：

    • 设备配置完成后，软件客户端可以通过IRP来请求数据传输操作。IRP是操作系统提供的一个机制，允许客户端程序和设备之间进行数据交互。

USBD的配置功能通常与操作系统密切相关，它会充分利用操作系统提供的配置接口，从而避免冗余的功能实现。

  1. USBD的功能：

    • 配置设备：在设备插入并与计算机连接时，USBD会处理配置请求，确保设备的功能在USB总线上正确配置。例如，USB设备可能需要多个端点（Endpoint）来进行不同类型的数据传输，USBD会处理这些配置请求并在总线上分配资源。

    • 带宽管理：USB总线有一定的带宽限制，特别是在处理周期性传输时，带宽的分配尤为重要。USBD在设备配置阶段会根据设备请求的带宽要求来判断是否可以接受这个请求。如果带宽足够，USBD会为该请求分配资源（例如，周期性传输的带宽）。如果带宽紧张，USBD可能会拒绝某些请求。

    • 创建管道（Pipe）：USB的管道（pipe）是数据传输的逻辑通道，用于管理不同类型的数据传输。USB有不同的传输类型（如控制传输、批量传输、等时传输和中断传输），每种传输类型可能有不同的带宽要求、周期性要求和数据大小等。USBD根据传输请求的类型创建适当的管道。

    • 设备配置后的数据传输：设备配置完成后，软件客户端可以通过发出IRP来请求数据传输。IRP是操作系统中的一个抽象概念，它描述了一个I/O操作的请求，USB驱动程序会根据这些请求在设备端点之间传输数据。

  2. 操作系统和USBD的关系：

    • USBD的具体实现和功能通常与操作系统紧密结合。不同操作系统可能会有不同的设备配置和数据传输管理方法，但它们通常会提供一些接口来支持USB设备的管理。这些接口可以帮助避免开发者在每个USB驱动中重新实现相同的功能。

    • 例如，Windows操作系统中的USB驱动程序（如usbport.sys）和Linux中的usbcore模块都提供了USBD的实现，它们在底层负责设备的管理和数据传输，提供统一的接口给上层应用程序使用。

  3. 周期性传输的带宽管理：

    • USB有周期性传输的要求，比如音频设备或视频设备需要定时传输数据。这些设备通常要求一定带宽保证数据的及时传输，USBD会根据设备的需求来分配相应的带宽。
    • 对于周期性端点，USBD的配置阶段不一定会立刻分配带宽，而是在需要时进行。带宽一旦分配完成，如果不再需要使用时，可以释放该带宽而不影响设备的其他配置。

5.11.1.3 主控制器驱动程序

主控制器驱动程序（HCD）负责跟踪进行中的 IRP（I/O 请求包），并确保不会超过 USB 带宽和（微）帧时间的最大值。当针对一个管道发出 IRP 时，HCD 会将其添加到事务列表中。当某个 IRP 完成时，HCD 会通知请求的软客户端该 IRP 的完成状态。如果该 IRP 涉及从设备向软客户端传输数据，那么数据会被放置到客户端指定的数据缓冲区中。
IRP 的定义方式与操作系统相关。

主控制器驱动程序（HCD）在 USB 系统中起着关键作用，主要负责以下几个方面：

  1. 跟踪 IRP：HCD 负责追踪当前正在进行的所有 I/O 请求包（IRP）。每一个 USB 操作，如数据传输、设备状态查询等，都会对应一个 IRP。

  2. 带宽和时间控制：HCD 确保所有操作不会超过 USB 带宽的限制，也不会违反每个微帧的时间限制。这是为了确保在高数据传输量或多个设备同时运行时，USB 系统的稳定性和高效性。

  3. 事务管理：当为某个管道发出 IRP 时，HCD 会将该 IRP 添加到事务列表中。管道是 USB 中进行数据传输的逻辑通道。每个管道可以用于不同类型的传输（如控制传输、批量传输等）。

  4. IRP 完成后的通知：当 IRP 操作完成时，HCD 会通知发起请求的应用程序或驱动程序，告诉它操作的结果（成功或失败）。如果 IRP 涉及数据传输，数据会被放入客户端指定的缓冲区。

  5. 操作系统依赖性：IRP 的定义方式是和操作系统密切相关的。不同操作系统在实现 IRP 时可能会有所不同，因此 HCD 必须根据所在操作系统的具体要求来管理和处理这些请求。

  1. IRP（I/O 请求包）

    在 USB 和其他操作系统的 I/O 系统中，IRP 是一种标准化的数据结构，用于表示一个请求。每个 IRP 都包含了请求的类型、相关的输入/输出数据、请求的参数等。IRP 是操作系统与硬件之间进行交互的基本单元。在 USB 中，IRP 主要用于表示设备请求的操作（如读写数据），这些请求会由主控制器驱动程序（HCD）负责管理。

  2. 带宽和帧时间限制

    USB 系统有明确的带宽和时间限制，特别是在 USB 2.0 中，数据传输是以每微帧（1ms）为单位进行的。每个设备和每个传输管道都占用一定的带宽，HCD 必须管理这些带宽资源，确保不会发生超负荷情况，导致传输失败或数据丢失。

    • USB 2.0 的带宽为 480 Mbps，而 USB 1.1 的带宽为 12 Mbps。
    • 每个微帧的时间是 1 毫秒，这意味着每秒钟有 1000 个微帧，数据传输需要在每个微帧的时间限制内完成。

  3. 管道（Pipe）

    USB 设备通过管道与主机进行通信。管道是一种用于数据传输的逻辑通道。每个管道有其独特的传输类型（如控制传输、批量传输、等时传输等）和带宽需求。HCD 管理这些管道中的 IRP，并确保每个管道的数据传输不会超过其带宽限制。

    • 控制传输：用于设备初始化和命令传输。
    • 批量传输：用于大量数据传输，通常用于打印机、存储设备等。
    • 等时传输：用于连续数据流的传输，如音频和视频设备。

  4. 通知和数据缓冲区

    当 IRP 完成时，HCD 会通知发起请求的客户端。客户端可以是操作系统或应用程序。当 IRP 涉及数据传输时，数据会被存放在客户端指定的数据缓冲区中。这个过程确保了 USB 数据传输的正确性和完整性。

    • 数据缓冲区：这是一个内存区域，用于存储通过 USB 传输的数据。缓冲区的大小和管理是 HCD 需要关注的重点，确保数据能够准确地从设备传输到客户端。

  5. 操作系统依赖性

    不同操作系统对 IRP 的定义可能有所不同。例如，Windows 系统中有自己的 I/O 请求包结构和处理方式，而 Linux 和其他操作系统可能会有不同的实现。因此，HCD 需要根据所在操作系统的不同，适应其 IRP 结构和处理流程。

5.11.1.4 事务列表

事务列表是一个与主机控制器（Host Controller，简称HCD）相关的实现细节，描述了当前仍需在总线上执行的所有事务。只有HCD和它所控制的主机控制器能访问这种特定的表示形式。每个事务描述包含了事务的相关信息，其中包括数据大小（以字节为单位）、设备地址和端点号，以及数据将要发送或接收的内存区域等参数。
事务列表及其与主机控制器之间的接口通常是依赖于实现的方式，USB规格并没有明确规定它的具体定义。

事务列表中的每个条目包含了完成一个数据传输所需的所有关键信息，比如数据大小、设备地址、端点号以及数据存放的内存位置。这个列表以及它与主机控制器之间的接口形式是由具体的主机控制器的实现来决定的，USB规范并没有明确统一的定义。

1. 事务列表的作用：
在USB通信中，主机（Host）和设备（Device）之间的数据传输是通过“事务”进行的。这些事务通常包括数据的发送和接收。为了管理这些事务，主机控制器（HCD）需要维护一个事务列表，该列表包含了所有当前仍需完成的事务（即所有待处理的数据传输任务）。每个事务包含了完成数据传输所需的关键信息。

2. 事务列表的内容：

  • 数据大小（Data size）：每个事务涉及的数据的大小，单位是字节。比如，如果你从USB设备读取数据，事务中会包含要读取的数据量。
  • 设备地址（Device address）：USB设备的地址，这是主机用来识别不同设备的唯一标识符。每个USB设备在连接到主机后会被分配一个地址。
  • 端点号（Endpoint number）：USB通信是基于端点（Endpoint）进行的，每个端点都有一个唯一的编号。端点用于指定数据传输的方向和用途（比如控制传输、数据传输等）。
  • 内存区域（Memory area）：这指定了数据发送或接收的内存位置。比如，接收数据时，数据需要存放在主机的某一内存区域，发送数据时则需要从相应的内存区域读取。

3. 事务列表的实现依赖性：
这段文本还特别提到，事务列表的具体实现方式是与主机控制器（Host Controller）密切相关的，并且是实现依赖的。也就是说，不同的主机控制器可能会以不同的方式维护这个事务列表，USB规范并没有对事务列表的实现做出严格的定义。每个主机控制器的设计可能会有所不同，因此它们的事务列表结构和管理方式也可能不同。

4. 与USB规范的关系：

事务列表作为主机控制器的内部数据结构，并没有在USB规格中被明确规范化。USB规范主要关注的是USB总线的通信协议和设备的标准化，而具体的硬件实现（如主机控制器）则留给硬件制造商自行决定。因此，事务列表的实现方式、存储结构以及与主机控制器的接口形式都可能因硬件平台的不同而有所变化。

5. 事务列表与数据传输的关系：

事务列表是用来跟踪所有待执行的数据传输任务。当主机控制器需要执行一个数据传输时，它会从事务列表中获取相关的事务信息，执行相应的操作，直到事务完成。如果事务成功完成，相关的事务记录会从列表中移除。

在USB 2.0中，主机控制器（HCD）通过维护一个事务列表来跟踪当前需要执行的数据传输任务。这个事务列表包含了有关每个数据传输的详细信息，如数据大小、设备地址、端点号和内存位置等。尽管事务列表的管理方式在USB规范中并未详细规定，但它是主机控制器实现的一部分，具体的实现形式依赖于硬件设计。

5.11.1.5 主机控制器

主机控制器能够访问事务列表，并将其转换为总线活动。此外，主机控制器提供了一种报告机制，允许获取事务的状态（完成、待处理、停止等）。主机控制器将事务转换为与实现相关的活动，从而使 USB 数据包在根集线器根部的总线拓扑上移动。

主机控制器确保遵循协议中定义的总线访问规则，例如包之间的时间间隔、超时、冲突（babble）等。HCD（主机控制器驱动程序）接口为主机控制器提供了一种机制，参与决定是否允许新的管道（pipe）访问总线。这是因为主机控制器的实现可能对它们所支持的总线事务的最小间隔时间有所限制或约束。

事务列表和主机控制器之间的接口隐藏在 HCD 和主机控制器的实现中。

主机控制器（Host Controller）负责将 USB 事务（如数据传输请求）转化为实际的总线活动，并确保在总线上数据传输过程中遵循各种协议规则。它提供了事务状态的反馈机制（例如事务是否完成或挂起），并且通过一个接口（HCD接口）参与决定是否允许某些管道（pipe）访问总线。主机控制器的工作涉及对总线事务的时间间隔、超时以及防止总线冲突等方面的管理。HCD 和主机控制器的实现细节通常是隐藏的，不对外暴露。

  1. 主机控制器的功能：

    • 主机控制器是 USB 总线通信的核心部分，它负责管理和调度 USB 总线上的数据传输。它通过事务列表来追踪每个数据传输的状态，包括是否已完成、是否等待中、是否发生错误等。

  2. 事务列表（Transaction List）：

    • 事务列表是主机控制器用来管理所有待执行或正在执行的传输请求的队列。每个请求代表一次 USB 数据包传输操作，主机控制器通过对这些请求的调度，确保数据能够按时、按序地传输。

  3. 协议规则的遵循：

    • USB 协议定义了一些总线访问的规则，这些规则保证了总线上的数据传输有序且高效。例如：
      • 包之间的时间间隔：不同的数据包之间必须有适当的时间间隔，以避免数据冲突。
      • 超时：如果传输没有按预期完成，主机控制器需要处理超时情况。
      • 冲突（Babble）：冲突是指总线上发生的数据传输错误，主机控制器需要检测并避免这类情况的发生。

  4. HCD 接口：

    • 主机控制器驱动（HCD）是主机控制器与操作系统之间的接口。HCD 通过提供接口，使得主机控制器能够参与判断是否可以为新的管道（数据流）提供总线访问权限。比如，HCD 接口可以检查当前的事务负载和时间间隔是否允许新事务的加入。

  5. 总线访问的限制：

    • 由于硬件实现的限制，主机控制器可能对数据传输之间的最小时间间隔有所要求。例如，某些控制器可能不能够在非常短的时间内发起多个数据传输请求，因为这会导致总线负载过重或者不稳定。

  6. 隐藏的实现细节：

    • 事务列表和主机控制器之间的具体实现通常是抽象和封装的，用户和开发者通常不需要关注这些细节。它们通过 HCD 层与主机操作系统交互，而主机控制器的具体操作与实现则由硬件和驱动程序负责。