USB3.2 摘录(五)(下)

简介: USB3.2 摘录(五)

USB3.2 摘录(五)(上):https://developer.aliyun.com/article/1598623

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 后的最短时间以及可以启动 U1U2 条目的时间。此外,它还列出了设备在突发时必须遵守的 DP 之间的最长时间。

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


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

简单归纳

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

DP(Data Packet)

    第七章已经稍有描述其结构,DPDPH 后面紧跟着一个 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 域置 1Data 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,其 transactionBULK 类似。

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 开始。

目录
相关文章
|
4月前
|
存储 缓存 算法
USB3.2 摘录(一)(下)
USB3.2 摘录(一)
57 12
|
4月前
|
机器学习/深度学习 流计算
USB3.2 摘录(五)(上)
USB3.2 摘录(五)
72 1
|
4月前
|
缓存
USB3.2 摘录(一)(上)
USB3.2 摘录(一)
63 0
USB3.2 摘录(一)(上)
|
4月前
USB3.2 摘录(八)
USB3.2 摘录(八)
53 2
|
4月前
|
安全 索引
USB3.2 摘录(11)
USB3.2 摘录(11)
54 1
|
4月前
|
存储 运维
USB3.2 摘录(七)
USB3.2 摘录(七)
49 1
|
4月前
|
存储 算法
USB3.2 摘录(10)
USB3.2 摘录(10)
61 1
|
4月前
|
存储 算法
USB3.2 摘录(九)
USB3.2 摘录(九)
47 1
|
4月前
USB3.2 摘录(六)
USB3.2 摘录(六)
43 1
|
4月前
|
存储 XML 前端开发
GIGE 协议摘录 —— 引导寄存器(四)(上)
GIGE 协议摘录 —— 引导寄存器(四)
59 1