USB3.2 摘录（五）

本文主要是介绍USB3.2 摘录（五），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

系列文章目录

USB3.2 摘录（一）
USB3.2 摘录（二）
USB3.2 摘录（三）
USB3.2 摘录（四）
USB3.2 摘录（五）

---

---

8 协议层（Protocol Layer）

    协议层管理 Host 和 Device 间 end-to-end 数据流，是建立在链路层正确传输基础上的。本章详细描述：

• 包类型；（LMP，DP，TP，ITP）
• 包格式；
• 包期待的响应；
• 四种 transaction 类型

8.12 TP 流程（TP Sequences）

    由事务处理组成的包依赖端点类型变化。有四种端点类型：块，控制，中断和同步。

8.12.1 块事务处理（Bulk Transactions）

    块事务处理类型具有通过错误检测与重试保证无错误的在主机与设备之间传输数据的属性。块事务处理使用由 TPs 和 DPs 组成的双相事务处理。

8.12.1.1 状态机注释信息（State Machine Notation Information）

    这个区域展示详细的需要在 IN 和 OUT 管道上提出协议的主机和设备状态机制。

    Figure 8-35 展示了状态机的图解。

8.12.1.2 块输入事务处理（Bulk IN Transactions）

    当主机准备好接收块数据时，它就发送一个 ACK TP 给设备指示它想要的从设备得到的包顺序号与包数量。

    主机应该为每个从设备收到的有效 DP 发送一个 ACK TP 。如果前一个 ACK TP 指示主机期待设备发送不止 1 个 DP（Data Packet）（依赖于 TP（Transaction Packet） 中 NumP 域值），则设备不必等待 ACK TP 就可以发送下一个 DP 给主机。 ACK TP 暗中用前一个被主机成功接受到的顺序号来应答最后的 DP 也对设备指示下一个顺序号的 DP 和主机想要从设备获得的包数量。如果主机在收到 DP 时检测到一个错误，它应该发送一个顺序号值被设置为发生错误的第一个包顺序号的 ACK TP ，其 retry 位也要置位，即使是这个包以后的包都没有错误发生。设备需要重新发送从发生错误的那个顺序号包开始的所有 DPs 。

    当端点初始化后（通过命令 Set Confguration，Set Interface，ClearFeature（STALL）参考 Chapter 9 命令），主机开始第一次从端点接收数据的传输，主机期待第一个 DP 的顺序号被设为 0 。第二个被设备端点发送的 DP 顺序号应该被设置为 1 ；第三个被设备发送的 DP 顺序号应该设为 2 ，…… 直到顺序号为 31，顺序号 31 的下一个 DP 的顺序号又为 0 。一个设备端点保持它发送的包顺序号递增，除非它收到一个带有 retry 位置位的 ACK TP ，这指示主机不得不重新发送前一个 DP 。

    如果主机要求从设备获得多个 DP，设备在那时刻没有那么多有效的 DPs 可以发送，则设备发送最后的 DP 应该在 DPH（Data Packet Header） 中的 EOB（End Of Burst） 标志置位（因为有部分数据可以发送，所以不发送 NRDY TP）。当再有数据发送时，设备要发送 ERDY TP 给主机。注意：如果被发送给主机的 DP 的数据量比端点中定义的最大包尺寸少（短包），则没有必要设备 EOB 标志。当设备发送了所有被主机期待的数据时或发送了一个比最大数据包尺寸小的 DP（短包）时，传输就完成了。当主机想要开始一次新的传输，它应该发送另外的期待从设备获得的下一个顺序号和 DPs 数量的 ACK TP 。例如，如果数据量比最大包尺寸小的 DP 为 2 ， 则主机应该通过发送一个带有期待顺序号被设为 3 的 ACK TP 来开始新传输。

8.12.1.3 块输出事务处理（Bulk OUT Transactions）

    当主机准备发送块数据时，它会发送一个或多个 DPs 给设备。如果设备收到有效的 DPH（有效的 device address，endpoint number，direction 和期待的顺序号），它应该以 Section 8.11.3 定义的 应答。

    在端点初始化之后，主机总是在第一次对端点输出数据的传输中，以第一个 DP 顺序号为 0 开始。第二个被设备端点发送的 DP 顺序号应该被设置为 1；第三个被设备发送的 DP 顺序号应该设为 2，…… 直到顺序号为 31，31 的下一个顺序号为 0 。主机保持它发送的包顺序号递增，除非它收到一个带有 retry 位置位的 ACK TP ，这指示主机不得不重新发送前一个 DP 。

    传输是在主机发送完所有它要发给设备的数据时完成。然而，传输的最后 DP 可能有或没有一个等于端点最大包尺寸大小的数据。当主机想要开始一次新传输，它应该发送另外的 DP ，这个 DP 带有下一个目标端点想要的顺序号。

8.12.1.4 块流协议（Bulk Streaming Protocol）

    流（Stream ）协议遵循标准超速块（Enhanced SuperSpeed Bulk ）协议，因此在支持流的超速块管道上进行的数据包交换与不支持流的超速块管道上的数据包交换没有什么区别。流协议通过包头中的流 ID 域的操作被严格管理。

    注意：如这个区域描述一样，流协议适用于管道状态，它被描述成单个实体。实际上，流协议在管道的一端独立的被主机追踪，在另外一端被设备追踪。所以由于在主机与设备间的包传播延迟，任何时刻两端可能随时不相同。

    Figure 8-38 展示了流协议状态机制（SPSM，General Stream Protocol State Machine）的基本状态转变。这里描述了当它们都适用于 IN 和 OUT 端点时的一般 SPSM 转变。IN 和 OUT 端点的 SPSM 的详细操作在随后的区域中被描述。

• Disabled —— 这是在被配置后管道的初始化状态。如果在任何其他状态中检测到错误，则转变到这个状态。一个端点 buffer 第一次被分配到一个管道时，主机应该把 SPSM 转变成 Prime Pipe 状态。如果由于错误进入 Disabled 状态，那么错误条件必须在状态退出之前由软件的介入来消除。注意错误（stall，超时等）应该要把任何 SPSM 状态转变成 Disabled 状态。

• Prime Pipe —— 这个状态总是被主机初始化，通知设备端点 buffer 设置已经被软件添加或修改。

• ldle —— 这个状态指示当前流没有被选择。在这种状态，SPSM 正 等待 Prime Pipe 或主机初始化转变成 Move Data 状态，或者设备初始化转变成 Start Stream 状态。主机和设备初始化转变的对象是开始一次流（被主机或设备各自设置为当前流），开始移动数据。

• Start Stream —— 当想要选择一个流或开始一次数据传输时，这个状态总是被设备初始化得来的。如果设备选择的流被主机接收，则当前流被设置，管道进入 Move Data 状态。如果设备选择的流被主机拒绝，管道返回 Idle 状态。

• Move Data —— 在这个状态中，流数据被传输。如果这个状态是由于主机初始化流选择而进入的，则当前流应该被主机设置。如果这个状态是从 Start Stream 状态进入的，则当前流选择被设备设置。当流传输完成时或者如果主机或设备决定终止流传输时 SPSM 转变回 Idle 状态。转变成 Idle 状态使管道的当前流无效。

    注意：一般规则是，Stream 状态机仅在接收到良好的 DP 或 TP 时才会前进。例如，如果接收到的 DP 带有错误的 DPP，则 Stream 状态机应在当前状态下执行任何重试，并且仅在传输了良好的数据包时才前进。

8.12.1.4.1 流 ID（Stream IDs）

    一个 16 位域的流 ID 域在 DP 头中被保留，也保留在主机和设备间传输流 ID 的 ACK，NRDY，ERDY TP 中。流协议和其他 SID 表示法保留的特定 SID 值包括：

• Nostream —— 这个流 ID 指示没有流 ID 被分配给各个相关的总线包，流 ID 域应该不被解释成有效流。NoStream 流 ID 值是 FFFFh 。

• Prime —— 这个流 ID 被用来定义转变到 Prime Pipe 状态或从 Prime Pipe 状态中转变出来。Prime 流 ID 是 FFFEh。

• Stream n —— n 是在 1 到 65533（FFFDh） 之间的值。这个标记是用来指示一个有效流 ID 。如果使用这种标记，则在包头中的流 ID 域是有效的。有效的 Stream n 流 ID 值当中的 n 值，是在 1 到 65533（FFFDh） 之间。

• Stream 0 —— 这个值保留，不被管道用来支持流。Stream 0 流 ID 值是 0000h 。它需要被标准块管道使用。

• CStream —— 代表被分配给管道的当前流 ID 的值，一个 CStream 值都被主机和设备操控。流协议确保 CStream 值在主机与设备中是一致的。有效值是 NoStream 或 Stream n 。

• LCStream —— 代表在最后一个状态转变之前被分配给管道的 CStream 流 ID 的值。一个 LCStream 值被主机操控，有效值为 Prime，NoStream，或 Stream n 。例如，当在 Move Data 状态下 CStream=Stream n 的管道从 Move Data 到 ldle 状态转变时，LCStream 被设置为 Stream n，CStream 被设置为 NoStream，因此 LCStream 记录了 “最后的（上一个）当前流” 值。

    Stream n 流 ID 值被主机分配，被传递到一个设备。Stream n 流 ID 值应该被设备当成一个逻辑值对待，即设备不应该从值中推断出任何意思或修改它。

    注意：下面描述的块 IN 和 OUT 流协议是简化了的状态机制，没有明确仔细说明超速端点的突发特性（允许 DP 没有收到 ACK 就被发送）。一个实施应该扩展这些状态机制管理突发。

8.12.1.4.2 块 IN 流协议（Device IN Stream Protocol）

    本部分定义了增强型 SuperSpeed 数据包交换，该数据包交换将 IN 批量端点上的流协议的设备端从一种状态转换为另一种状态。

    对于 IN 管道，主机中端点 buffers 从设备收到功能数据：

    Disabled，端点被配置以后，管道在 Disabled 状态。主机应该通过发送流 ID 域设置为 Prime 的 ACK TP 将管道转变成 Prime Pipe 状态。这个转变在端点 buffers 被系统软件分配到管道上后发生。

    设备会通过发流 ID 域设置为 Prime 的 NRDY TP 引起管道退出 Prime Pipe 状态，转变到 ldle 状态。

    注意：如果中间的集线器（deferred）延迟了 ACK TP，则主机和设备会犹如设备发送一个 NRDY TP 一样。即，当收到延迟应答时，主机会转变到 Idle 状态。当收到延迟 ACK TP 时，设备会转变到 Prime Pipe 状态，然后立刻转变到 Idle 状态犹如它已经发送了流 ID 域设置为 Prime 的 NRDY TP。

    在 ldle 状态下，管道正在等待流选择（例如一次到 Start Stream 或 Move Data 的转变）或等待端点 buffers 已经为管道被添加或修改的主机通知（转变到 Prime Pipe）。在 Idle 状态，被主机初始化的流选择通过流 ID 被设置为 Stream n 和 NumP 值大于 0 的 ACK TP 确认。这个包会将 ISPSM 从 ldle 状态转变成 Move Data 状态。如果最后一次的 ISPSM 是从 Start Stream 或 Move Data 转变的，则主机会由于两个可能的条件而开始一次从 ldle 到 Move Data 状态的转变：

1. 如果为 LCStream 而给管道布置端点 buffer ，并且最后的 ISPSM 转变不是由于一个 NRDY（Stream n）Move Data 状态退出；

2. 如果是为新的流布置端点 buffer（例如新发送的不等于 LCStream 的流 ID ）。在 ldle 中，被设备开始的流选择是通过一个流 ID 被设置为 Stream n，NumP 值大于 0 的 ERDY TP 来确认的。这个包会将 ISPSM 从 ldle 状态到 Start Stream 状态转变。当设备想要开始流传输时，不管它是否在一个流控制条件中，都应该开始这个转变。

    在 Start stream 状态下，管道正等待主机接收或拒绝设备发起的流选择。主机会通过发送一个 StreamID=Stream n 和 NumP>0 的 ACK TP 来指示接收到设备初始化的流选择这个包会历经从 Start Stream 状态到 Move Data 状态的 ISPSM 转变。主机会通过发送 StreamID=NoStream ，NumP=0，Packet Pending（PP）= 0 的 ACK TP 来指示拒绝由设备初始化的流选择。这个包会历经从 Start Stream state 到 Idle state 的 ISPSM 转变。如果没有有效端点 buffer 为设备选择流 ID ，主机会拒绝流选择。

    ISPSM 独立的在主机和设备上执行。一种条件发生：如果设备发送一个 ERDY 给主机，并且进入 Start Stream 状态，与此同时，主机发送 ACK（Prime，PP=0） 给设备，并且进入 Prime Pipe 状态。为了从此条件中恢复，如果设备在 Start Stream 状态下接收到一个 ACK（Prime，PP=0），它会转变到 Prime Pipe Ack 状态，并且发送一个 NRDY（Prime） 给主机为主机完成从 Prime Pipe 到 ldle 状态的转变，和为设备完成从 Prime PipeAck 到 ldle 状态的转变。

    在 Move Data 状态，当前流在管道的两端被设置，并且管道被激活移动数据到主机。总线事务处理在 Move Data 状态的执行和它的退出条件在下面的 IN Move Data State Machine 详细定义

    如上面描述，IN Move Data 状态机制（IMDSM）是从 Start Stream 或 ldle 状态进入的。当转变到 INMvData Device 状态，就立刻进入 IMDSM。所有被 IMDSM 产生的包的流 ID 域会是 Stream n 。

    每次进入 INMvDataDevice 状态时，设备都会进行下面的操作进入 IMDSM：

if (Device Function Data bytes > Max Packet Size) {设备会产生一个 EOB 域值为 0 的 DP ，这会引起管道转变成 INMvDataHost 状态
} else if (Device Function Data bytes = Max Packet Size) {设备会产生一个 EOB 域值为 1 的 DP ，这会引起管道转变成 INMvDataDeviceTerminate 状态
} else (Device Function Data bytes < Max Packet Size ) {设备会产生一个短包 DP ，这会引起管道转变成 INMvDataDeviceTerminate 状态
}

    可选择的，设备可以产生一个流 ID 设置为 Stream n 的 NRDY TP 终止流，会引起管道退出 IMDSM，转变成 Idle 状态。设备可以使用这个转变来拒绝由主机初始化的 Move Data 。

    注意：如果中间的集线器（deferred）延迟了 ACK TP，主机和设备会视如设备发送了一个 NRDY TP 。即当主机收到延迟的应答，它会转变到 Idle 状态。当设备收到（deferred 延迟的 ACK TP 时犹如它收到了一个流 ID 域设置为 Stream n 的 NRDY TP ，它会退出 IMDSM，转变到 Idle 状态。如果设备接收主机初始化的流 ID，它会发送一个流 ID 域设置为 Stream n 的 ERDY。如果设备拒绝由主机初始化的流 ID，它会停留在 ldle 状态，并且等待下一个主机或设备初始化的流选择。

    INMvData Host 状态的进入是因为设备有更多的功能数据要发送，所以主机要执行下面的操作进入 IMDSM：

if ( 在此次突发中能安排另外的 DP ) {if (主机有更多的有效端点 buffers) {产生 NumP>0 的 ACKTP，这会引起管道转变到 INMvDataDevice 状态} else (主机没有有效空间) {产生一个NumP=0 and PP=0 的 ACK TP 结束，这会引起管道退出 IMDSM 转变到 Idle 状态。}
} else (已经收到突发的最后一个 DP) {终止突发;if (主机有更多的有效端点buffers) {通知设备突发完成（NumP=0）主机应该为 CStream 安排另外一次突发（PP=1）产生 NumP=0，PP=1 的ACK TP，这会引起管道转变成 INMvData Burst End 状态。} else {// (主机没有有效空间)产生 NumP=0 and PP=0 的 ACK TP 终止，这会引起管道退出 IMDSM ，转变成 Idle 状态。}
}

    在 INMvData Burst End 状态中，主机会产生 NumP>0 and PP=1 的 ACK 开始下一次突发，引起管道转变成 INMvData Device 状态。

    Pseudo 码描述 IMDSM 假设收到的 DP 是有效的。如果它无效，则 ACK TP 被产生，这会把管道转变成 INMvDataDevice 状态。ACK TP 中的顺序号不会上涨，然后，重试位可以减少发送的 NumP 值。如果 NumP=0，并且主机中还有有效的端点 buffer，PP 会被设置为 1 ；否则，PP 被设置为 0 。

    INMvData Device Terminate 状态的进入是因为设备没有更多的功能数据要发送，所以主机会产生一个 NumP=0 and PP=0 的 ACK TP 终止，这会引起管道退出 IMDSM，并且转变成 ldle 状态。如果主机在最后一个被设备发送的 DP 中检测到一个错误，它会以带有重试位的 ACK TP（Stream n，NumP>0，Rty） 应答，IMDSM 会转变成 INMvDataDevice 状态。

    注意：如果 DP 错误在 INMvDataHost 中被检测到，主机会产生一个 NumP>0 and Rty=1 的 ACK TP，这会引起管道转变成 INMvDataDevice 状态，并且重新发送包。

8.12.1.4.3 块 OUT 流协议（Device OUT Stream Protocol）

    这个区域定于了超速包交换进行从一个状态转变到另外一个状态的输出块端点上的流协议。

    对于输出管道，主机的端点数据被发送到功能设备的 buffers 中，除非另外的规定，DP 将包含端点数据。

    在端点配置后，管道在 Disabled 状态。主机通过发送带有流 ID 域设为 Prime 的 DP 要将管道转变成 Prime Pipe 状态。这个转变发生在端点 buffers 被主机软件分配给管道之后。

8.12.1.4.4 主机 IN 流协议（Host IN Stream Protocol）

    对于 IN 管道，主机中的端点缓冲区从设备接收函数数据。

8.12.1.4.5 主机 OUT 流协议（Host OUT Stream Protocol）

    对于 OUT 管道，设备中的函数缓冲区从主机接收端点数据。

8.12.2 控制传输（Control Transfers）

    控制传输最小有两个事务处理阶段；建立阶段（Setup）和状态阶段（Status）。一次控制传输可以可选的在建立阶段和状态阶段中间包含一个数据阶段（Data stage）。数据阶段的方向由在 setup 包数据负载的第一个字节中的 bmRequestType 域指示。在 setup 阶段期间，一次 setup 事务处理是用来发送信息给设备的控制端点。Setup 事务处理和一次块 OUT 事务处理格式相似，但是在 DPH 中有个 setup 区域被设置为 1 ，并且数据长度域被设置为 8 。 除此之外，setup 包总是使用数据顺序号 0 。设备收到 setup 包会以在 Section8.11.4 中定义的应答。在主机和设备上任何控制端点之间交换的 TP 或 DP 的方向域应该被设置为 0（控制端点为双向的，所以不区分端点方向）。

    注意：如果端点想要对控制传输进行流控制，则它可以返回 NumP 域被设为 0 的 ACK TP 作为一个 SETUP 包的应答。设备必须发送 ERDY 开始数据或状态阶段。

    控制传输如果存在数据阶段的话，它由一个或多个 IN/OUT 事务处理组成，并且和带有突发设置为 1 的块传输的协议规则相同。数据阶段总是从顺序号设置为 0 开始。所有数据阶段的事务处理应该是在同一个方向（比如全部为 IN 或 OUT）。在数据阶段期间要被发送的最大数据量和它的方向在 setup 阶段被指定了。如果数据量超过了最大包大小，数据以多个最大数据包大小发送。剩下的任何数据在最后数据包中被发送。

    注意：所有的控制端点值支持突发次数为 1，因此，主机一次只能对控制端点发送或接收一个包。

    控制传输的状态阶段是整个控制传输流程的最后的事务处理。状态阶段事务处理通过子类型被设为 STATUS 的 TP 来确认。作为对 Deferred 位为 0 的 STATUS TP 的应答，设备应该发送 NRDY，STALL 或 ACK TP 。如果设备发送一个 NRDY TP（收到 STATUS TP 后没完成状态阶段），主机再发送另外一个 STATUS TP 给设备之前会等待设备为控制端点发送一个 ERDY TP 。如果 STATUS TP 中的 Deferred 位置位，那么设备会发送一个 ERDY TP 向主机指示，准备完成控制传输的状态阶段了。

    Figure 8-47 and Figure 8-48 展示了控制读和写流程的事务处理顺序，数据顺序号值和数据包类型：

    当一个 STALL TP 在数据阶段或状态阶段被控制端点发送时，STALL TP 应该在所有随后对端点访问中被退回，直到收到 SETUP DP 。当端点随后收到一个 SETUP DP ，它应该返回一个 ACK TP 。对于控制端点，如果 ACK TP 为 SETUP 事务处理被返回，那么主机期待端点已经自动从引起 STALL 的条件中恢复，并且端点会正常操作。

8.12.2.1 报告状态结果（Reporting Status Results）

    在“状态”（Status）阶段，设备向主机报告传输的先前设置和数据阶段的结果。可能会返回三个可能的结果：

• 命令序列成功完成。
• 命令序列无法完成。
• 设备仍在忙于完成命令。

    状态报告始终处于设备到主机的方向。表 8-31 总结了每种响应所需的响应类型。所有控制传输都会在 TP 中返回 STATUS，该 TP 在响应 STATUS TP 事务时返回给主机。

8.12.3 总线间隔和服务间隔

    对所有周期性端点，端点必须要被服务的间隔称为一个 “服务间隔” 。在这个规范中， “总线间隔” 用来指一个 125us 的周期。

8.12.4 中断事务处理（Interrupt Transactions）

    中断传输类型是用来在有界限的服务周期内进行稀少的数据传输。它支持在保证的界限延迟下可靠的数据传输。只要数据是有效的，则它提供可靠的恒定数据率。如果错误在数据传输中被检测到，则主机不要求在同一个服务间隔中重试事务处理。然而，如果设备不能立刻发送或接收数据（例如应 NRDY TP），则主机只会在它收到一个来于设备的 ERDY TP 之后重新开始对端点的事务处理。

    中断事务处理域块事务处理非常相似。但是限制在每个服务间隔中一次突发 3 个 DPs 。只要设备能接收数据（OUT）或者能发送数据（IN），则主机会在协定的服务间隔中继续对中断端点进行事务处理。主机被要求在服务间隔中为每个成功接收到的 DPs 发送一个 ACK TP ，即使它是在那个服务间隔中的最后的包。最后的 ACK TP 包会应答收到的最后的 DPs ，会使 Number of Packets 域设置为 0 。如果在当前服务间隔中对中断端点进行事务处理时发生了错误，那么主机不要求在当前服务间隔重试事务处理，但是主机最迟会在下一个服务间隔中进行重试。

8.12.4.1 中断输入事务处理（Interrupt IN Transactions）

    当主机想要开始一次对端点的中断 IN 事务处理，则它发送一个带有期待顺序号和它期待要从端点接收的包数量的 ACK TP 给端点。如果中断端点能发送数据作为来自于主机的 ACK TP 的应答，则它可以在相同的服务间隔中发送主机所要求的包数量。主机对每个 DPs 应答 ACK TP，指示成功的接收了数据或请求要被重试的 DP，以防 DPP 损坏。

    请注意，在初始化端点后，主机期望在从特定端点开始第一次传输时，第一个 DP 的序列号设置为零。初始化端点是指通过 SetConfguration 或 SetInterface 或 ClearFeature（STALL） 命令。

    中断端点应响应从主机接收的 TPs ，如第 8.11.1 节所述。只要设备返回数据以响应发送 ACK TP 的主机，并且传输未完成，主机应在该端点的每个服务间隔内继续向设备发送 ACK TP。

    当下面任何一个发生时，主机会停止对端点进行事务处理：

• 端点以 NRDY 或 STALL TP 应答时
• 所有要传输的数据都成功接受到了
• 端点在发送给主机的最后的 DP 中设置 EOB 标志，

    当端点收到来自于主机的一个 ACK TP，并且不能通过发送数据来应答，它会发送一个 NRDY（或当内部端点或设备错误时发送 STALL）TP 给主机。主机在随后的服务间隔中不会对端点进行更多任何的事务处理。

    只在收到一个来自于端点的 ERDY TP 后，主机才会重新对端点进行中断事务处理，用上一次服务间隔中的流控制应答来进行应答。这个通知主机关于端点是否再次发送数据。一旦主机接收到 ERDY TP ，则它会在不超过两个服务间隔内发送一个 IN 请求（通过 ACK TP ）给端点，这个值由中断端点描述符中的 blnterval 域决定。一个中断端点通过返回 DP（包顺序号比最后成功发送的数据包顺序号大 1）或，如果不能返回数据，则返回 NRDY 或 STALL TP 来应答。

    如果设备接收一个 DL（deferred） 置位的中断 IN TP ，并且设备需要发送中断 IN 数据，则设备会以 ERDY TP 应答，并且保持它的链路在 U0 状态直到它收到随后的来自于主机的中断事务处理，或直到 tPingTimeout（参考 Table 8-36）超时。

    正如块事务处理情况下，每个被中断端点发送的包顺序号连续递增，当顺序号到了 31 ，下一个它会变为 0 。

    注意：在图 8-53 中，主机在相同的服务间隔内重试收到的报文，但出现错误。它不是必需的，并且可以在下一个服务间隔内重试事务。

8.12.4.2 中断输出事务处理（Interrupt OUT Transaction）

    当端点想要对端点开始一次中断输出事务处理时，它发送期待第一个的顺序号的数据包。如果端点支持大于 1 的突发大小，则主机在同一个服务间隔可以发送更多的包给端点。如果端点能接收主机的数据，则它发送一个 ACK TP 应答数据的成功接收。

    注意：在端点初始化后，主机在一次传输中总是以第一个 DP 的顺序号为 0 开始。在端点的每个服务周期中，只要设备返回 ACK TPs 作为主机发送数据包的应答，并且传输没有完成，则主机要继续发送数据给设备。设备要应答对 DP 的成功接收，或者如果数据包损坏了，则要求主机重试事务。

    对于主机 OUT 数据的应答，中断端点要以 Section 8.11.3 中描述来进行应答。

    当端点接收来自主机的数据，但是不能立刻接收时，则要发送 NRDY TP （或在发生内部端点错误或设备错误时发送 STALL）给主机；主机在随后的总线周期中不能对端点进行任何事务处理（除非发送了 ERDY 异步通知）。

    在收到一个来自于端点的 ERDY TP 后，主机要重新开始端点的中断事务处理，以流控制应答来进行应答。这告知主机关于端点是否又能准备接收数据了。一旦主机收到 ERDY TP ，主机就要在两个服务间隔内发送数据包给端点。服务间隔在中断端点的描述符中的 blnterval 域被描述。

    如果设备收到一个deferred（延迟的）的中断输出 DPH，并且设备此时需要接收中断 OUT 数据，设备要以 ERDY TP 应答，保持它的链路在 U0（逻辑空闲）状态下，直到它收到随后的来自于主机的中断事务处理，或者直到 tPingTimeout 超时了。

    正如在块事务处理情况下，顺序号随着主机发送的包增加，当顺序号达到 31，它下个顺序号会变成 0 。

    注意：在 Figure 8-57 中，主机在同一个服务间隔中重试收到带有错误的数据包。其实没必要这样做，可以在下一个服务间隔中重新进行事务处理。

8.12.5 主机时序信息（Host Timing Information）

    USB 3.0 主机控制器不会向增强型超高速 USB 链路上的所有设备广播常规帧起始 (SOF) 数据包。当根端口链路在总线间隔边界附近处于 U0 时，主机通过等时时间戳数据包 (ITP) 发送主机时序信息。集线器将等时时间戳数据包（根据第 10.9.4.4 节中所述的任何必要修改）转发到任何具有 U0 链路且已完成端口配置的下游端口。主机应根据非扩展时钟提供等时时间戳。当设备操作需要等时时间戳时，设备负责将链路保持在总线间隔边界附近的 U0 中。除非设备操作需要时间戳，否则设备绝不应将链路保持在 U0 中以仅用于接收时间戳。

8.12.6 同步事务处理（Isochronous Transactions）

    IN 同步事务只在第一次发 ACK TP 请求同步数据。

    输入同步事务在 Figure 8-60 中展示，输出同步事务处理在 Figure 8-61 中展示。对于输入同步事务处理的，主机为其发送一个紧跟着返回数据的 ACK TP 。对于输出同步事务处理，当有数据要在当前服务间隔中被发送时，主机会简单的发送数据。同步事务处理不支持重试。

    每个服务间隔包含单个数据包的超速同步事务处理总是使用顺序号 0（每个服务间隔发送一个数据包，顺序号总是为 0 ）对于每个服务间隔包含多数据包的同步事务处理后面的数据包顺序号以 1 递增。在任何服务间隔中第一个数据包总是使用顺序号 0 。主机在每个服务间隔中最多应该能接收和发送 48 个 DPs 。顺序号是从 0 到 31 循环的。带有同步端点的超速设备要能够发送或接收在其端点和 endpoint companion descriptors 中指定的包数量。

    如果数据比端点最大包尺寸少，那么它发送时，在服务间隔的最后包中 lpf 域会置位。如果在一个服务间隔期间没有数据发送给输出同步端点，那么主机在整个间隔周期不会发送任何数据。如果带有同步输入端点的设备在接收到来自主机的同步输入 ACK TP 时 没有数据要发送，则它会发送一个 0 长度的数据包 。

    Figure 8-62 和 Figure 8-63 展示了同步输入和输出事务处理例子，其端点已经提供有一个不超过服务间隔请求 2000 字节的带宽（每个服务间隔不超过 2 个数据包被发送或接收）。

    如果主机由于一个错误条件而在指定的间隔中不能发送同步输出数据，则主机放弃数据，通知主机软件发生了错误。如果主机由于错误条件而在指定的服务间隔中不能发送一个同步 ACK TP ，主机同样会通知主机软件错误的发生。

    不同服务间隔中顺序号总是从 0 开始。

    注意：上图表示在同一个服务间隔中，进行了三次事务请求，所以，顺序号一直递增。

    上图表示在同一个服务间隔中，如果没有数据发送了，但是传输还没有完成，等到有数据发送时，则顺序号仍然在原来的基础上递增。

8.12.6.1 在同步事务处理中的主机柔性

    Host Flexibility in Performing SuperSpeed Isochronous Transactions 。

    主机被允许在进行同步服务间隔中的一些柔性。主机与端点传输所有的 DPs 可以作为一次单个同步突发事务处理或者它可以将传输分为更小的突发，像 2，4，或 8 个 DPs 服务间隔中最后的同步突发带有剩下的数据包 DP 。主机在任何其他情况下不会进行同步事务。对于有一个比 1 大的 Mult 的同步端点，这些规则分别适用于跟每个 Mult 值相关的突发事务处理。设备要支持所有可能的这些规则允许的主机突发事务处理。例如，如果同步输出端点在一次 11 的突发中请求一次最大数量的包，主机在服务间隔中有 11 个包要发送给端点，那么有四种主机进行事务处理的可能方式：

• 单次突发 11 个包
• 一次 8 个包的突发，然后跟着一次 3 个包的突发
• 两次 4 个包的突发，然后跟着一次 3 个包的突发
• 5 次 2 个包的突发，然后一次 1 个包的突发

    每个服务间隔进行多次突发时，主机不会复位服务间隔中的顺序号，主机仅仅会在服务间隔中设置最后一次突发中最后包的 LPF 标志。

8.12.6.2 设备对同步输入事务处理的应答

    Device Response to Isochronous IN Transactions 。

    表 8-33 列出了设备在响应 ACK TP 时可能做出的响应。如果存在以下任何一种情况，则认为 ACK TP 无效：

• 其设备地址不正确
• 其端点编号和方向不是指属于当前配置一部分的端点
• 它没有预期的序列号
• 它设置了延迟位
• 其 TT 与端点类型不匹配（适用于在 SuperSpeedPlus 模式下运行的设备）。

8.12.6.3 主机对同步输入事务的处理

    Host Processing of Isochronous IN Transactions 。

    表 8-34 列出了主机对 IN 事务中的数据的处理。主机从不返回对收到的同步 IN 数据的响应。在表 8-34 中，DP 错误可能是由于以下一种或多种原因造成的：

• CRC-32 不正确
• DPP 中止
• DPP 缺失
• DPH TT 未设置为同步（来自在 SuperSpeedPlus 模式下运行的设备）
• DPH 中的数据长度与实际数据有效载荷长度不匹配。

    如果主机接收到一个损坏的数据包，则它丢弃在当前服务间隔中剩下的数据，并且通知主机软件错误的发生。

    No-Data Packet 应该是指 DPH 。

8.12.6.4 设备对同步输出数据包的应答

    Device Response to an Isochronous OUT Data Packet 。

    设备对 OUT 数据包数据的处理方式如表 8-35 所示。设备永远不会返回 TP 作为应答。在表 8-35 中，DP 错误可能是由于以下一种或多种原因造成的：

• CRC-32 不正确
• DPP 中止
• DPP 缺失
• DPH TT 未设置为同步（对于在超高速模式下运行的设备）
• DPH 中的数据长度与实际数据有效载荷长度不匹配
• DPH 中设置的延迟位

8.13 时间参数（Timing Parameters）

    表 8-36 列出了设备在响应其接收的各种类型的数据包时应遵守的最短和/或最大时间。它还列出了设备可以在延迟容忍消息中设置的默认值和最短时间，以及收到某些 TP 后的最短时间以及可以启动 U1 或 U2 条目的时间。此外，它还列出了设备在突发时必须遵守的 DP 之间的最长时间。

    注意：当设备没有其他要在它的上游连接上发送的时候，所有的 txxxResponse（例如 tNRDY 应答）时间都是设备要满足的时序。

    注意：如果主机在 10us 内没有看见一个对数据事务处理的应答（IN/OUT），它要假定事务处理已经失败了，端点已经停止了。不进行重试。

简单归纳

    下面是些简单解说，详细解说见各章节。

DP（Data Packet）

    第七章已经稍有描述其结构，DP 是 DPH 后面紧跟着一个 DPP 构成，格式如下图所示：USB2.0中的 SETUP 包，在 USB3.0 中是一个 DP 格式出现的。

ITP（Isochronous Timestamp Packet ）

    ITP 构造同头包，格式如下图所示：

    从四种包类型的构造、格式上来看，与 USB2.0 的包结构、格式完全不同。尽管 USB3.0 中也有 ACK、STALL、SETUP、PING 等各种 SubType，似乎和 USB2.0 的 ACK、STALL、SETUP、PING 等有对应关系，但是实际上除了包结构、格式不同外，用法和意义有了一些变化，并增加了许多新的 Type 和 SubType，包的管理已经完全不同，所以决不能简单地认为 USB3.0 和 USB2.0 的 packet 有对应关系或者是简单的扩展关系。

BULK transactions

BULK IN Transactions

    当 Host 希望从 Device 读数据的时候，Host 发送包含数据包顺序号和包数量信息的 ACK TP 给 Device，然后 Device 发送 DP 给 Host，Device 不需要等待收到下一个 ACK TP 而可以继续发送后续的 DP。每个 DP 的包序号是递增的，从 0~31，然后回转到 0，重新递增。如果 Host 发送了一个 retry 位为 1 的 ACK TP，则从该 ACK TP 中表示的包序号开始的数据包需要重传。当 Device 完成了 Host 请求的数据包之后，或者 Device 发送了一个短包，这次 transfer 就完成了。

BULK OUT Transactions

    Host 发送 DP 给 Device，每个 DP 使用递增的包序号（0~31），Device 向每个 DP 回 ACK TP 。同样的，Host 不必等待收到 ACK TP 就可以继续发送下一个 DP，如果 Device 回复了一个 retry 位被置位的 ACK TP，Host 需要从该 ACK TP 指示的包序号开始重传 DP。Host 发送完所有数据后，该 transfer 就完成了。

Control Transfers（控制传输）

    控制传输仍然分为 SETUP stage，可选的 Data stage 和 STATUS stage 。

    SETUP 是一个 DP，其 DPH 中的 Setup 域置 1，Data length 域为 8 。

    Data stage 不采用包序号，所有 DP 顺序号都是 0 。不使用 burst 方式。

    STATUS stage，Host 发送一个 TP，其 SubType 是 STATUS，Device 返回一个 NRDY，STALL，或者 ACK TP 完成 SETUP transfer 。

    每一个设备需要启动默认控制管道作为一个消息管道。这个管道是用来设备初始化和管理，用来访问设备描述符和请求操作一个设备。控制传输必须遵守 USB2.0 定义的相同的要求。

Interrupt Transactions

    Interrupt transaction 周期性吞吐数据，每个服务间隔限制为最多三个 DP，其 transaction 和 BULK 类似。

Isochronous Transaction

    ISO transaction 在每个服务间隔最多可以传送 48 个 DP 。ISO IN 时，Host 只需要发送一个 ACK TP，然后 Device 返回一个或多个 DP，Host 不需要回 ACK TP。ISO OUT 时 Device 发送一个或多个 DP，Host 不返回 ACK TP。这类似于 USB2.0 时 ISO 传输没有握手过程。每个服务间隔的第一个 DP 其顺序号总是 0 开始。

9 设备框架（Device Framework）

10 集线器、主机下游端口和设备上游端口规范（Hub, Host Downstream Port, and Device Upstream port Specification）

11 互操作性和功率传输（Interoperability and Power Delivery）

A Gen1 符号编码（Gen 1 Symbol Encoding）

B 符号扰乱（Symbol Scrambling）

C 电源管理（Power Management）

D 示例数据包（Example Packets）

E 中继器（Example Packets）

   
 

☆

这篇关于USB3.2 摘录（五）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---