USB 协议工作过程原理

Arrom
208 阅读7分钟

image.png

USB 协议工作过程原理图描述

这幅图主要展示主机（Host） 与设备（Device） 之间的一次典型 IN 事务（主机从设备读取数据）和一次 OUT 事务（主机向设备写入数据），并体现端点（Endpoint）、管道（Pipe） 和包（Packet） 的概念。同时会示意主机中心制和传输类型的影响。

图例：

  1. 主机 (Host): 位于图左侧。包含：
    • 主机控制器 (Host Controller): 硬件，管理物理总线信号和底层协议。
    • USB 系统软件 / 驱动栈 (USB System Software / Driver Stack): 包含 USB 核心驱动、可能的设备类驱动（如 HID）和客户端驱动/应用软件。
    • 内存缓冲区 (Memory Buffers): 存放待发送或接收的数据。
    • 调度器 (Scheduler): 在帧/微帧内安排事务（示意为一个时钟图标）。
  2. 设备 (Device): 位于图右侧。包含：
    • USB 设备控制器 (USB Device Controller): 硬件，处理物理信号和底层协议。
    • 设备固件 (Device Firmware): 实现设备功能逻辑，处理 USB 请求和数据。
    • 端点 (Endpoints): 用 EP X IN 和 EP Y OUT 表示。每个端点是一个数据缓冲区（矩形框）。IN 端点箭头指向主机，OUT 端点箭头指向设备内部。端点 0 (EP0) 单独标出（通常是控制端点）。
  3. USB 总线 (USB Bus): 连接主机和设备的一条双向线（物理上 D+/D- 或 USB-C 的多对差分线，这里简化）。
  4. 包 (Packets): 用不同形状/颜色的“信封”图标表示：
    • 令牌包 (Token): 红色信封，标有 IN 或 OUT，以及目标 ADDR (设备地址) 和 ENDP (端点号)。
    • 数据包 (Data): 蓝色信封，标有 DATA0 或 DATA1 PID。
    • 握手包 (Handshake): 绿色信封，标有 ACK, NAK, STALL。
  5. 管道 (Pipe): 用一条从主机软件（特定驱动/应用的内存缓冲区）连接到设备端点的虚线表示。标明其传输类型 (如 Interrupt IN, Bulk OUT)。
  6. 帧/微帧 (Frame/Microframe): 用一条贯穿主机和设备的时间轴表示，上面有等距的刻度线代表帧/微帧边界。调度器在时间轴上方。

工作过程图示 (动态描述)：

场景 1：主机发起一个 IN 事务 (读取设备数据 - 例如读取鼠标移动)

  1. 调度与令牌 (Host Initiation):

    • 调度器 (时钟图标闪烁): 在当前的帧/微帧内，根据配置好的轮询间隔（对于中断传输）或可用带宽（对于批量传输），调度一个 IN 事务到目标设备的特定 IN 端点 (例如 EP1 IN)。
    • 主机控制器发送令牌包 (红色 IN 信封): 令牌包通过 USB 总线发送到设备。包内包含：
      • PID = IN
      • ADDR = [目标设备地址] (例如 5)
      • ENDP = [目标端点号] (例如 1)

  2. 设备响应 (Device Response):

    • 设备控制器接收令牌包: 识别出是发给自己的 IN 请求，目标端点是 EP1 IN。
    • 设备固件检查端点缓冲区:
      • 情况 A (有数据): EP1 IN 缓冲区中有新的鼠标移动数据待发送。固件准备好数据。
      • 情况 B (无数据/未准备好): EP1 IN 缓冲区为空或数据未准备好。
    • 设备控制器发送响应包:
      • 情况 A: 发送一个数据包 (蓝色 DATA0/DATA1 信封) 包含 EP1 IN 缓冲区中的数据。数据包通过 USB 总线发回主机。
      • 情况 B: 发送一个握手包 (绿色 NAK 信封)，表示“暂时没有数据/未准备好”。

  3. 主机确认 (Host Acknowledgment):

    • 主机控制器接收响应包:
      • 收到数据包 (情况 A): 主机控制器检查数据包 CRC 正确。然后发送一个握手包 (绿色 ACK 信封) 给设备，确认成功接收。接收到的数据被放入主机内存中对应的管道缓冲区，最终送达应用软件（如鼠标驱动）。
      • 收到 NAK (情况 B): 主机知道设备暂无数据。本次 IN 事务结束（失败）。主机可能在下一个轮询周期再次尝试。
    • (错误情况): 如果主机接收数据包时检测到 CRC 错误或物理错误，则不发送 ACK。设备在超时后知道需要重发数据（下次主机再次 IN 时）。

场景 2：主机发起一个 OUT 事务 (向设备写入数据 - 例如向打印机发送数据)

  1. 调度与令牌+数据 (Host Initiation with Data):

    • 调度器 (时钟图标闪烁): 在当前的帧/微帧内，根据带宽分配（批量传输用剩余带宽，同步传输有预留带宽）调度一个 OUT 事务到目标设备的特定 OUT 端点 (例如 EP2 OUT)。
    • 主机控制器发送令牌包 (红色 OUT 信封): 令牌包通过 USB 总线发送到设备。包内包含：
      • PID = OUT
      • ADDR = [目标设备地址] (例如 5)
      • ENDP = [目标端点号] (例如 2)
    • 主机控制器紧接着发送数据包 (蓝色 DATA0/DATA1 信封): 包含要写入设备的数据。

  2. 设备响应 (Device Response):

    • 设备控制器接收令牌包: 识别出是发给自己的 OUT 请求，目标端点是 EP2 OUT。
    • 设备控制器接收数据包: 尝试接收数据包，检查 CRC。
    • 设备固件处理:
      • 情况 A (成功接收且有空间): CRC 正确，且 EP2 OUT 缓冲区有空间接收该数据包。固件将数据放入缓冲区处理（如放入打印队列）。设备控制器发送握手包 (绿色 ACK 信封) 给主机。
      • 情况 B (接收成功但无空间/忙): CRC 正确，但 EP2 OUT 缓冲区满或固件太忙无法处理。设备控制器发送握手包 (绿色 NAK 信封)，表示“请稍后重发”。
      • 情况 C (接收错误): CRC 错误或物理错误。设备控制器不发送握手包（或可能发送其他错误指示，取决于协议版本）。主机将超时。
      • 情况 D (端点错误): 端点被停用或存在永久错误。设备控制器发送握手包 (绿色 STALL 信封)，表示“有问题，别试了”。

  3. 主机确认/后续动作 (Host Follow-up):

    • 主机控制器等待握手包:
      • 收到 ACK (情况 A): 事务成功。数据已成功写入设备端点。主机可以发送下一个数据包（DATA1/DATA0 交替）。
      • 收到 NAK (情况 B): 主机知道设备暂时无法接收。本次 OUT 事务结束（失败）。主机稍后（在下一个调度机会）会重发整个事务（令牌+同一个数据包）。
      • 收到 STALL (情况 D): 主机知道端点有错误。通常会报告给上层软件（驱动），停止向该端点发送数据，可能需要重新配置设备。
      • 超时 (无响应或情况 C): 主机未收到任何握手包（或收到无效响应）。主机将重发整个事务（令牌+同一个数据包）。

关键概念在图中体现：

  • 主机中心制: 所有事务都由左侧主机发起（红色令牌包首先发出）。
  • 端点和管道: 虚线管道连接主机内存和设备端点缓冲区。IN 和 OUT 端点方向清晰。
  • 包交换: 事务由令牌、数据（可选）、握手包组成。包的类型和流向清晰标注。
  • 传输类型: 管道上的标签 (Interrupt IN, Bulk OUT) 表明事务调度的策略和特性不同（中断有固定间隔轮询，批量利用空闲带宽）。
  • 错误处理: NAK, STALL 握手包和超时重发机制被展示。
  • 帧/微帧: 时间轴表示通信发生在离散的时间单元内，调度器负责安排。
  • 分层: 主机侧的驱动栈和设备侧的固件代表上层逻辑，依赖底层的包传输机制。

绘制建议：

  1. 将主机画在左侧，设备画在右侧，USB 总线居中连接。
  2. 用不同颜色和形状清晰区分令牌包、数据包、握手包。
  3. 明确标注端点号 (EP0, EP1 IN, EP2 OUT) 和方向。
  4. 用带标签的虚线表示管道及其传输类型。
  5. 用带刻度的时间轴表示帧/微帧，调度器图标放在时间轴上方。
  6. 用箭头表示包的传输方向。
  7. 可以用序号标注一次典型 IN 事务和一次典型 OUT 事务的步骤流程（1. 主机发令牌, 2. 设备发数据/NAK, 3. 主机发 ACK/重试 等）。

这幅原理图的核心在于展示 “主机发起 -> 令牌指定 -> 数据传递 (可选) -> 握手确认/错误反馈” 这个基础事务流程，以及端点、管道、传输类型这些抽象概念如何映射到实际的包交换过程中。理解了这个流程图，就掌握了 USB 协议通信的骨架。

avatar
文章
阅读
粉丝