1. 同步传输为实时而生但绝非“实时”保证在USB的世界里数据传输有四种基本类型控制、中断、批量以及我们今天要深入探讨的同步传输。很多人一听到“同步”脑海里立刻会浮现出“实时”、“无延迟”、“绝对准时”这些概念尤其是在看到“分布式事务”、“事务一致性”这些热词时更容易产生联想。但我要告诉你USB的同步传输和你理解的“事务”可能完全是两码事。它解决的是一种特定场景下的需求并且有其明确的代价和限制。简单来说USB同步传输的核心设计目标是为那些对数据传输的周期性和带宽保证有严格要求的设备服务的。最典型的例子就是音频和视频设备一个USB麦克风需要每隔固定的时间比如每125微秒向主机发送一段音频采样数据一个USB摄像头需要稳定地输送视频帧。如果数据时快时慢音频就会卡顿、视频就会掉帧。同步传输就是为了在USB这个共享总线上为这类设备预留出固定的时间片确保它们能“按时”拿到传输机会。但请注意它只保证“有机会按时传”并不保证“数据一定正确传到”。这是同步传输与中断、批量传输最根本的区别之一——同步传输没有硬件级的错误重传机制。数据包如果因为噪声干扰在总线上传错了这个包就直接丢弃了USB硬件不会要求对方重发。对于音频视频流偶尔丢一两个采样点或几个像素人耳人眼可能察觉不到或者可以通过插值算法弥补这比因为重传而引入不确定的延迟要更能接受。这就是设计上的权衡用一定的数据可靠性换取确定的传输延迟和带宽。所以当你看到“同步传输”时应该想到的是“等时传输”或“流传输”它更像是一条有固定班次周期的公交专线到点就发车但不在乎车上的人是否坐对了位置数据是否正确。而“事务”在这里指的是完成一次这种固定周期数据传输所需的一系列底层总线操作的最小单元。接下来我们就拆开这个“事务”看看里面到底是怎么运转的。2. 同步传输事务的组成一次“准时班车”的完整行程一个完整的USB同步传输事务发生在主机通常是你的电脑和设备如摄像头之间由主机完全调度。它由三个连续的、不可分割的包序列组成依次是令牌包、数据包、握手包。但同步传输的握手包比较特殊我们稍后细说。为了让你有直观印象我们先看一个主机从设备读取IN同步数据的时序概念图。主机侧时间线 |--- 帧/微帧 (125μs/125μs) ---| 设备侧时间线 | | 主机发送: [令牌包IN] ---- [数据包DATA] ---- [握手包ACK/NAK/...]? | | 设备响应: 接收令牌 准备数据并发送 接收握手(或无)(注这是一个逻辑时序示意非精确时间比例)2.1 令牌包发车指令令牌包由主机发出它宣告一次事务的开始并指明了这次事务的方向和目的地。它主要包含以下关键信息包标识符对于同步传输如果是主机从设备读数据就是IN令牌如果是主机向设备写数据就是OUT令牌。同步传输不支持SETUP令牌那是控制传输用的。设备地址7位地址指定总线上的哪个设备需要响应。端点号4位端点号指定设备上的哪个端点参与此次传输。设备端点在配置时会声明自己是同步端点并分配一个唯一的端点号。主机控制器根据事先设置好的调度表在精确的时刻发出这个令牌包。这个“精确时刻”就是同步传输“周期性”的体现。对于全速和高速USB这个周期通常是1毫秒帧或125微秒微帧。2.2 数据包乘客上车令牌包之后紧接着就是数据包阶段。对于IN事务设备在收到指向自己的IN令牌包后必须在极短的时间内USB协议有严格的时间窗口规定将数据放入指定的端点缓冲区并驱动总线将数据包发送给主机。这个数据包的最大长度在端点描述符中定义对于同步端点全速下最大为1023字节高速下最大为1024字节。但实际每次传输的数据量可以小于这个最大值。对于OUT事务主机在发出OUT令牌包后紧接着就会发出数据包设备负责接收并存入指定的端点缓冲区。这里有一个关键点同步传输的数据包内容没有像其他传输类型那样的数据切换同步机制。控制、中断、批量传输使用DATA0/DATA1包PID来同步发送和接收方防止丢包或重复包。而同步传输的数据包PID始终是DATA0对于高速高带宽同步端点有DATA1/DATA2但仅用于多事务调度不用于错误检测。这再次印证了其“不重传”的特性。2.3 握手包到站确认特殊的“已阅不回”这是同步传输最与众不同的一环。在其他传输类型中握手包用于报告事务状态ACK确认数据包被正确接收。NAK设备暂时无法响应如缓冲区满/空。STALL端点被挂起需要主机干预。但在同步传输中设备在IN事务里不允许返回NAK或STALL。这意味着什么意味着设备端点必须被设计成“时刻准备着”。当主机发来IN令牌时设备端点必须有数据可发如果没数据也要发一个长度为0的数据包或者重复上一次的数据具体看设备实现。它不能对主机说“稍等”。这是保证周期性的关键牺牲。那么握手包谁发呢在IN事务中握手包由主机发出。如果主机正确收到了设备发来的数据包它会回复一个ACK。注意这个ACK只是告诉设备“我收到了”即便数据有误只要CRC校验通过主机也会发ACK。如果主机没收到数据包如CRC错误它就不会发任何握手包这个事务就静默失败了。在OUT事务中设备不允许返回任何握手包。主机发出数据和令牌后事务即结束。设备即使没收到或收到错误数据也不能通过总线通知主机。设备只能通过后续的通道如通过中断端点报告状态来间接告知主机其接收情况但这已经超出了本次事务的范围。这种握手机制的设计彻底避免了因重试而导致的周期抖动确保了带宽的确定性。代价就是数据可靠性需要由上层应用或驱动来负责例如在音频流中加入错误掩盖算法。3. 带宽分配与事务调度如何保证“准时发车”USB主机控制器就像一个交通总指挥它需要管理总线上所有设备的传输请求。对于同步和中断传输主机采用了一种“预留带宽”的调度机制。当设备插入并被枚举时主机需要读取其配置描述符和接口描述符。对于一个同步端点描述符中会包含几个关键字段wMaxPacketSize该端点一次事务能传输的最大数据字节数。bInterval轮询间隔。这个值表示该端点希望被主机服务的周期单位对于全速/低速是1ms对于高速是125μs的微帧。bInterval必须是2的幂次方1,2,4,8...。值越小要求的服务频率越高。主机控制器会根据所有活动同步和中断端点的wMaxPacketSize和bInterval计算出一个微帧125μs内需要为它们预留多少时间。这个计算必须确保所有预留带宽之和不超过微帧时间的某个比例通常是80%-90%为控制传输和其他开销留出空间。如果超过主机将拒绝配置该设备这就是为什么有时插上多个高带宽USB音频设备时可能会有一个无法正常工作。一旦配置成功主机就会在内部建立一个周期性的调度列表。在每个微帧开始时控制器按照列表依次发起各个同步事务。由于总线传输时间、包间间隔等都是纳秒级精确的所以主机可以确保每个同步事务都在其预定的时间窗口内开始。这种基于描述符声明的静态带宽分配是USB同步传输实现“周期性”和“带宽保证”的基石。4. 同步传输的实战考量与常见陷阱理解了原理在实际开发和调试中我们才会明白哪些地方容易出问题。4.1 端点配置与带宽计算这是最容易踩坑的地方。假设你在设计一个高速USB摄像头需要传输1280x72030fps的YUV数据。计算带宽需求一帧图像大小 ≈ 1280 * 720 * 1.5 (YUV420) ≈ 1.38 MB。30帧每秒所需带宽 ≈ 41.5 MB/s。转换为USB事务高速USB同步事务每次最多1024字节。每帧需要的事务数 ≈ 1.38 MB / 1 KB ≈ 1382 次。每秒需要的事务数 ≈ 1382 * 30 ≈ 41460 次。设置bInterval高速USB每秒钟有8000个微帧125μs一个。如果我们想让数据均匀分布理想情况下每个微帧都传输一点。那么bInterval应该设为1即每个微帧都服务一次。每个微帧需要处理的事务数 ≈ 41460 / 8000 ≈ 5.18。这意味着每个微帧你需要安排至少6次IN事务因为事务次数是整数。检查带宽可行性每次事务除了数据还有令牌包、握手包、包间间隔等开销。高速USB上一个1024字节的数据包传输时间大约在10μs量级加上其他开销一次事务可能在15μs左右。6次事务就占用了90μs。而一个微帧只有125μs这已经占用了72%的带宽。主机很可能会因为带宽不足而拒绝配置。这时你可能需要降低图像分辨率或帧率。使用更高的图像压缩比。使用高带宽同步端点这是高速USB的增强特性允许一个微帧内为同一个端点调度多次事务2或3次从而减少令牌包等开销的比例更高效地利用带宽。这需要在端点描述符中配置bmAttributes的Mult字段。配置不当设备在枚举阶段就会失败错误可能表现为“设备描述符请求失败”或“配置不成功”。4.2 数据缓冲区管理与“哑铃”模型设备端的固件设计对于同步传输至关重要。由于设备不能对IN事务说“不”它必须有一个精心设计的数据缓冲区管理策略。一个经典的模型是“双缓冲区”或“乒乓缓冲区”。当主机正在从缓冲区A读取数据时设备的上层应用如图像传感器采集正在向缓冲区B写入下一帧数据。下一次事务到来时切换缓冲区。这需要精确的同步确保在主机读取指针到达之前新数据已经就绪。更复杂的情况下可能需要一个环形缓冲区。核心原则是生产采集数据的速度必须平均大于或等于消费USB传输的速度。否则就会发生“欠载”——主机来要数据时缓冲区是空的。根据协议此时设备要么发送一个零长度包要么重复旧数据这都会导致上层应用如播放器收到错误或卡顿的数据。4.3 错误处理与健壮性设计既然链路层不负责重传应用层就必须承担起健壮性保障。对于音频可以使用前向纠错编码或者在驱动层实现简单的插值算法用前后正确的采样点计算当前丢失点的近似值。对于视频可以使用带内信令在数据流中插入时间戳和帧号。接收端如果发现帧不连续可以决定是丢弃不完整的帧还是尝试用上一帧来填补。状态报告许多高质量的USB音频/视频设备会额外提供一个中断端点定期向主机报告自身的状态如温度、信号强度、内部错误计数器等。主机驱动可以根据这些信息调整行为或向用户提示设备可能工作不佳。在驱动开发中你需要处理可能发生的“Babble”或“CRC”错误。这些错误通常意味着物理连接问题线缆不良、接口氧化、信号干扰。一个健壮的驱动不应该在遇到几次同步传输错误后就崩溃或挂起设备而应该记录错误率当错误率超过阈值时再提示用户检查硬件连接。5. 同步传输与其他传输类型的对比与选择为了让你更清楚何时该用同步传输我们把它和中断、批量传输放在一起对比。特性同步传输中断传输批量传输设计目标周期性保证带宽容忍少量错误周期性保证最大延迟数据可靠非周期性充分利用剩余带宽数据可靠数据可靠性无保证无链路层重传有保证有ACK/NAK重传有保证有ACK/NAK重传周期性严格保证固定间隔大致保证有最大延迟上限无保证有空闲时才传带宽可预留有保证可预留有保证但通常量小无保证尽力而为典型应用音频流、视频流、实时采集键盘、鼠标、游戏手柄大文件传输、打印机、扫描仪事务握手IN由主机ACKOUT无设备握手双向ACK/NAK双向ACK/NAK数据PID切换固定DATA0或DATA0/1/2用于调度DATA0/DATA1切换DATA0/DATA1切换选择的关键在于你的首要需求是什么要稳定的数据流不怕偶尔丢一点- 选同步传输。要数据绝对正确且对响应时间有要求但不需要严格周期- 选中断传输。要传大量数据但不着急不能出错- 选批量传输。很多设备是组合使用的。例如一个USB摄像头通常包含一个同步IN端点用于传输主要的视频数据流。一个中断IN端点用于传输摄像头控制状态如自动对焦状态或元数据。一个控制端点0用于标准的设备枚举和控制命令。6. 调试同步传输问题从协议分析仪视角看问题当你的同步传输设备工作不正常时如视频卡顿、音频爆音仅靠打印日志往往不够。一个USB协议分析仪如Ellisys Beagle等是必不可少的工具。通过分析仪你可以确认调度是否准时观察连续的IN或OUT令牌包测量它们之间的时间间隔。它们应该严格符合bInterval所设定的周期考虑微帧边界。如果间隔抖动很大可能是主机控制器负载过重或者有其他高优先级中断打断了USB调度这在一些实时性不佳的操作系统或BIOS上可能出现。观察数据包内容虽然分析仪通常不解码音视频内容但你可以检查数据包的长度是否符合预期。如果出现大量零长度数据包说明设备端数据供应不上缓冲区欠载。检查错误分析仪会标记出CRC错误、Babble错误等。如果发现某个端点的事务持续出现错误重点检查该端点的物理链路和信号质量。查看握手包对于IN事务确认主机是否对每个数据包都回复了ACK。如果主机没有回复ACK可能是主机侧驱动或硬件问题。对于OUT事务本来就没有设备握手所以这里看不到异常是正常的。验证带宽分配在分析仪软件中通常可以查看一个微帧内各种传输类型的时间分布。确认同步传输所占用的时间是否与你计算的理论值吻合是否接近总线带宽上限。我个人的经验是同步传输的问题十之八九出在端点描述符配置和设备端缓冲区管理上。首先反复核对wMaxPacketSize和bInterval的计算确保主机能够且愿意分配你所请求的带宽。其次在设备固件中加入丰富的调试信息比如记录缓冲区的水位线、数据生产与消费的速度差这些信息可以通过调试接口或一个辅助的批量端点传回对于定位“哑铃”模型是否运转顺畅至关重要。最后别忘了物理层。劣质的USB线缆、过长的延长线、不稳定的电源都可能导致信号完整性下降从而引发CRC错误。对于高速同步传输对信号质量的要求非常高有时换一条质量好的、带屏蔽的短线问题就可能迎刃而解。
