windows USB 设备驱动开发-USB带宽

本文讨论如何仔细管理 USB 带宽的指导。 每个 USB 客户端驱动程序都有责任最大程度地减少其使用的 USB 带宽,并尽快将未使用的带宽返回到可用带宽池。

在这里,我们认为USB 2.0 的速度是480Mbps、12Mbps、1.5Mbps,这分别对应高速、全速、低速三种,但实际上USB 2.0 的带宽非常紧张,这也是本文的前提之一,USB 3.0看起来缓解了带宽的问题,但是带宽的问题并不是上限不够而是调度芙蓉问题。

为什么我的 USB 驱动程序出现带宽不足错误?

USB 总线上带宽的竞争来自多个来源,包括硬件和软件。 很难准确预测 USB 客户端驱动程序的可用带宽量。 USB 主控制器需要一定数量的带宽来运行。 所需的量取决于控制器是否高速。 它因系统而异。 高速运行的 USB 集线器有时必须转换高速上游端口与下游低速设备之间的事务,并且此转换过程会消耗带宽。 但是,事务转换是否需要带宽取决于连接的设备类型和设备树的拓扑。

带宽资源最严重的压力通常来自垄断带宽的 USB 客户端驱动程序。 系统按先到先得的原则分配带宽。 如果加载的第一个 USB 驱动程序请求所有可用带宽,则以后加载的 USB 驱动程序不允许其设备的任何带宽。 系统无法配置设备,也无法枚举该设备。 由于枚举失败的原因不明显,因此用户体验不佳。

有时,客户端驱动程序会通过高速中断传输耗尽可用带宽。 但到目前为止,最常见的情况是客户端驱动程序为常量传输分配过多带宽,但无法及时释放带宽。 系统保留分配的带宽,直到请求它的驱动程序通过打开另一个端点关闭其端点,或者删除为其分配带宽的设备。 系统不为批量传输分配有保证的带宽,因此批量传输绝不是枚举失败的原因。 但是,大容量传输设备的性能取决于为定期 (常时等时等和中断) 传输的设备分配的带宽量。

USB 2.0 规范要求常量设备在其默认接口设置上具有零带宽端点。 这可确保在函数驱动程序打开非默认接口之前不会为设备保留任何带宽,这有助于防止在设备配置期间因带宽请求过多而导致的枚举失败。 它不会阻止客户端驱动程序在配置其设备后分配过多的带宽,从而阻止其他设备正常运行。

正确带宽管理的关键是,系统中执行常量传输的每个 USB 设备都必须为包含常量端点的每个接口提供多个备用 (Alt) 设置,并且客户端驱动程序必须明智地使用这些 Alt 设置。 客户端驱动程序应首先请求具有最高带宽的接口设置。 如果请求失败,客户端驱动程序应以越来越小的带宽请求接口设置,直到请求成功。

例如,假设网络摄像头设备具有以下接口:

接口 0 (默认接口设置:默认设置中没有具有非零常时等量带宽的端点)

常量端点 1:最大数据包大小 = 0 字节

常量端点 2:最大数据包大小 = 0 字节

接口 0 Alt 设置 1

常量端点 1:最大数据包大小 = 256 字节

常量端点2:最大数据包大小 = 256 字节

接口 0 Alt 设置 2

常量端点 1:最大数据包大小 = 512 字节

常量端点 2:最大数据包大小 = 512 字节

网络摄像头的驱动程序将网络摄像头配置为在初始化时使用默认接口设置。 默认设置没有常时常量带宽,因此在初始化期间使用默认设置可以避免网络摄像头由于常量带宽请求失败而无法枚举的危险。

当客户端驱动程序准备好执行常时等量传输时,它应尝试使用 Alt 设置 2,因为 Alt 设置 2 具有最大的数据包大小。 如果请求失败,驱动程序可以使用 Alt 设置 1 进行第二次尝试。 由于 Alt 设置 1 需要的带宽较少,因此即使第一个请求失败,此请求也可能成功。 多个 Alt 设置允许驱动程序在放弃之前进行多次尝试。

网络摄像头变为空闲后,可以通过再次选择默认设置,将分配的带宽返回到可用带宽池。

用户可以通过在 Windows 设备管理器 中检查控制器的属性来查看 USB 控制器分配了多少带宽。 选择控制器的属性,然后在"高级"选项卡下查看。此读数并不指示 USB 集线器为事务转换分配了多少带宽。

报告 USB 控制器带宽使用情况的设备管理器功能在 Windows XP 中无法正常工作。

USB 传输和数据包大小
最大传输大小

最大传输大小指定 USB 驱动程序堆栈中的硬编码限制。 低于这些限制的传输大小可能会因为系统资源限制而失败。 若要避免这些类型的故障并确保所有 Windows 版本的兼容性,请避免使用大型传输大小进行 USB 传输。

USBD_PIPE_INFORMATION 结构的 MaximumTransferSize 成员已过时。 USB 驱动程序堆栈忽略复合和非复合设备的 MaximumTransferSize 中的值。

在 Windows 2000 中,USB 驱动程序堆栈将 MaximumTransferSize 初始化为 USBD_DEFAULT_MAXIMUM_TRANSFER_SIZE。 客户端驱动程序可以在配置设备时设置较小的值。 对于复合设备,每个函数的客户端驱动程序只能更改非默认接口设置中管道的 MaximumTransferSize 。

USB 传输大小受以下限制:

使用 MaximumTransferSize 限制传输大小不会直接影响设备消耗的带宽。 客户端驱动程序必须更改接口设置或限制USBD_PIPE_INFORMATION的 MaximumPacketSize 成员中设置的最大数据包大小。

最大数据包大小

最大数据包大小由端点描述符的 wMaxPacketSize 字段定义。 客户端驱动程序可以在对设备的选择接口请求中调节 USB 数据包大小。 更改此值不会更改设备上的 wMaxPacketSize 。

在请求的 URB 中是管道 的USBD_PIPE_INFORMATION 结构。 在该结构中,

  • 修改 USBD_PIPE_INFORMATION 结构的 MaximumPacketSize 成员。 将其设置为小于或等于设备固件中为当前接口设置定义的 wMaxPacketSize 的值。
  • 在 PipeFlags 成员USBD_PIPE_INFORMATION结构中设置 USBD_PF_CHANGE_MAX_PACKET 标志。
读取传输缓冲区的最大数据包大小限制

当客户端驱动程序发出读取请求时,传输缓冲区必须是最大数据包大小的倍数。 即使驱动程序所需的数据小于最大数据包大小,它仍必须请求整个数据包。 当设备发送的数据包小于最大大小 (短数据包) 时,表示传输已完成。

在较旧的控制器上,客户端驱动程序可以重写该行为。 在数据传输 URB 的 TransferFlags 成员中,客户端驱动程序必须设置 USBD_SHORT_TRANSFER_OK 标志。 该标志允许设备发送小于 wMaxPacketSize 的数据包。

在 xHCI 主控制器上,USBD_SHORT_TRANSFER_OK忽略批量端点和中断端点。 在 EHCI 控制器上传输短数据包不会导致错误情况。

在 EHCI 主控制器上,对于批量端点和中断端点,将忽略USBD_SHORT_TRANSFER_OK。

在 UHCI 和 OHCI 主机控制器上,如果未为批量传输或中断传输设置USBD_SHORT_TRANSFER_OK,则短数据包传输将停止端点,并返回传输的错误代码。

使用短数据包分隔写入传输

USB 驱动程序堆栈驱动程序在写入设备时对数据包大小施加的限制与从设备读取时施加的限制不同。 某些客户端驱动程序必须频繁传输少量的控制数据,以管理其设备。 在这种情况下,将数据传输限制为统一大小的数据包是不切实际的。 因此,在数据写入期间,驱动程序堆栈不会为大小小于端点最大大小的数据包分配任何特殊意义。 这允许客户端驱动程序将设备的大型传输分解为多个大小小于或等于最大值的多个 URB。

驱动程序必须使用小于最大大小的数据包结束传输,或使用零长度的数据包分隔传输结束。 在驱动程序发送小于 wMaxPacketSize 的数据包之前,传输才完成。 如果传输大小正好是最大值的倍数,驱动程序必须发送零长度分隔数据包才能显式终止传输。

根据 USB 规范的要求,客户端驱动程序负责使用零长度数据包分隔数据传输。 USB 驱动程序堆栈不会自动生成这些数据包。

使用小于 wMaxPacketSize 的数据包分隔 USB 数据传输

合规的 USB 2.0 和 USB 1.1 驱动程序必须传输最大大小的数据包 (wMaxPacketSize) ,然后以小于最大大小的数据包结束传输,或使用零长度数据包分隔传输结束。 在驱动程序发送小于 wMaxPacketSize 的数据包之前,传输才完成。 如果传输大小正好是最大值的倍数,驱动程序必须发送零长度分隔数据包才能显式终止传输

设备驱动程序负责根据 USB 规范的要求使用零长度数据包分隔数据传输。 系统 USB 堆栈不会自动生成这些数据包。

相关推荐
TeYiToKu10 小时前
笔记整理—linux驱动开发部分(9)framebuffer驱动框架
linux·c语言·arm开发·驱动开发·笔记·嵌入式硬件·arm
学习嵌入式的小羊~1 天前
linux驱动-i2c子系统框架学习(1)
linux·驱动开发
挨踢小明2 天前
DPDK eth 网卡驱动开发
驱动开发
TeYiToKu3 天前
笔记整理—linux驱动开发部分(6)platform平台总线
linux·c语言·arm开发·驱动开发·笔记·嵌入式硬件
学习嵌入式的小羊~3 天前
linux驱动-认识输入子系统源码以及裁剪
linux·驱动开发
学习嵌入式的小羊~5 天前
linux驱动—input输入子系统
驱动开发
深度学习渣5 天前
SCSI驱动与 UFS 驱动交互概况
驱动开发·交互
郁大锤6 天前
linux alsa-lib snd_pcm_open函数源码分析(一)
linux·驱动开发·嵌入式硬件·音频·pcm·视频编解码
郁大锤6 天前
linux alsa-lib snd_pcm_open函数源码分析(二)
linux·驱动开发·嵌入式硬件·音视频
weixin_750335527 天前
OpenHarmony驱动开发--UART(串口)驱动
驱动开发