第 13 章 USB设备

通用串行总线(USB)是将设备连接到个人计算机的一种新方法。总线 结构突出了双向通信的特色，并且其开发充分考虑到了设备正逐渐智能化 和需要与host进行更多交互的现实。对USB的支持包含在当前所有芯片中, 因此在新近制造的PC中都可用。苹果(Apple)引入仅带USB的iMac对硬件 制造商生产他们USB版本的设备是一个很大的激励。未来的PC规范指定 PC上的所有老连接器应当由一个或多个USB连接器取代，提供通用的 即插即用能力。对USB硬件的支持在NetBSD的相当早期就有了，它是由 Lennart Augustsson为NetBSD项目开发的。代码已经被移植到FreeBSD上， 我们目前维护着一个底层共享代码。对USB子系统的实现来说，许多USB的 特性很重要。

Lennart Augustsson已经完成了NetBSD项目中USB支持的 大部分实现。十分感谢这项工作量惊人的工作。也十分感谢Ardy和Dirk 对本文稿的评论和校对。

为USB子系统以及连接到它的设备开发驱动程序受已开发或将要开发的 规范的支持。这些规范可以从USB主页公开获得。苹果(Apple)通过使得 通用类驱动程序可从其操作系统MacOS中获得，而且不鼓励为每种新设备 使用单独的驱动程序来强烈推行基于标准的驱动程序。本章试图整理基本 信息以便对FreeBSD/NetBSD中USB栈的当前实现有个基本的了解。然而， 建议将下面参考中提及的相关规范与本章同时阅读。

主控器（HC）控制总线上包的传输。使用1毫秒的帧。在每帧开始 时，主控器产生一个帧开始（SOF, Start of Frame）包。

SOF包用于同步帧的开始和跟踪帧的数目。包在帧中被传输，或由host 到设备（out），或由设备到host（in）。传输总是由host发起（轮询传输）。 因此每条USB总线只能有一个host。每个包的传输都有一个状态阶段， 数据接收者可以在其中返回ACK（应答接收），NAK（重试），STALL（错误 条件）或什么也没有（混乱数据阶段，设备不可用或已断开）。USB规范 USB specification的第8.5节更详细地解释了包的细节。USB总线 上可以出现四中不同类型的传输：控制(control)， 大块(bulk)， 中断 (interrupt)和同步(isochronous)。传输的类型和他们的特性在下面 描述（管道’子节中）。

USB总线上的设备和设备驱动程序间的大型传输被主控器或HC 驱动程序分割为多个包。

到默认端点的设备请求（控制传输）有些特殊。它们由两或三个阶段 组成：启动（SETUP），数据（DATA，可选）和状态（STATUS）。设置（set-up） 包被发送到设备。如果存在数据阶段，数据包的方向在设置包中给出。 状态阶段中的方向与数据阶段期间的方向相反，或者当没有数据阶段时 为IN。主控器硬件也提供寄存器，用于保存根端口的当前状态和自从 状态改变寄存器最后一次复位以来所发生的改变。USB规范[2]建议使用一个 虚拟hub来提供对这些寄存器的访问。虚拟hub必须符合规范第11章中给出的 hub设备类。它必须提供一个默认管道使得设备请求可以发送给它。它返回 标准和hub类特定的一组描述符。它也应当提供一个中断管道用来报告其 端口发生的变化。当前可用的主控器规范有两个： 通用主控器接口（UHCI；英特尔）和开放主控器接口（OHCI；康柏，微软，国家半导体）。 UHCI规范的设计通过要求主控器驱动程序为每帧的传输提供完整的调度， 从而减少了硬件复杂性。OHCI类型的控制器自身提供一个更抽象的接口来 完成很多工作，从而更加独立。

集中器(hub)通知新设备已连接后，服务层给端口加电(switch on)， 为设备提供100mA的电流。 此时设备处于其默认状态，并监听设备地址0。服务层会通过默认 管道继续检取各种描述符。此后它将向设备发送Set Address请求，将设备 从默认设备地址(地址0)移开。可能有多个设备驱动程序支持此设备。例如， 一个调制解调器可能通过AT兼容接口支持ISDN TA。然而，特定型号的ISDN 适配器的驱动程序可能提供对此设备的更好支持。为了支持这样的灵活性， 探测会返回优先级，指示他们的支持级别。支持产品的特定版本会具有最高 优先级，通用驱动程序具有最低优先级。如果一个配置内有多个接口，也可能 多个驱动程序会连接到一个设备。每个驱动程序只需支持所有接口的一个子集。

为新连接的设备探测驱动程序时，首先探测设备特定的驱动程序。 如果没有发现，则探测代码在所有支持的配置上重复探测过程，直到 在一个配置中连接到一个驱动程序。为了支持不同接口上使用多个驱动 程序的设备，探测会在一个配置中的所有尚未被驱动程序声明(claim)的 接口上重复进行。超出集中器功率预算的配置会被忽略。连接期间，驱动 程序应当把设备初始化到适当状态，但不能复位，因为那样会使得设备将 它自己从总线上断开，并重新启动探测过程。为了避免消耗不必要的带宽， 不应当在连接时声明中断管道，而应当延迟分配管道，直到打开文件并真的 使用数据。当关闭文件时，管道也应当被再次关闭，尽管设备可能仍然 连接着。

USB规范没有定义除默认管道外其他管道上使用的协议。这方面的信息 可以从各种来源获得。最准确的来源是USB主页[1]上的开发者部分。从这些 页面上可以得到数目不断增长的设备类的规范。这些规范指定从驱动程序 角度看起来兼容设备应当怎样，它需要提供的基本功能和通信通道上使用的 协议。USB规范[2]包括了集中器类的描述。人机界面设备(HID)的类规范已经 创建出来，以迎合对键盘、数字输入板、条形码阅读器、按钮、旋钮(手柄knob)、 开关等的要求。另一个例子是用于大容量存储设备的类规范。设备类的完整列表 参看USB主页[1]的开发者部分。

然而, 许多设备的协议信息还没有被公布。关于所用协议的信息 可能可以从制造设备的公司获得。一些公司会在给你规范之前要求你签署 保密协议(Non-Disclosure Agreement, NDA)。大多数情况下，这会阻止 将驱动程序开放源代码。

另一个信息的很好来源是Linux驱动程序源代码，因为很多公司已经 开始为他们的设备提供Linux下的驱动程序。联系那些驱动程序作者询问 他们的信息来源总是一个好主意。

例子：人机界面设备。人机界面设备，如键盘、鼠标、数字输入板、 按钮、拨号盘等的规范被其他设备类规范引用，并在很多设备中使用。

例如，音频扬声器提供到数模转换器的端点，可能还提供额外管道 用于麦克风。它们也为设备前面的按钮和拨号盘在单独的接口中提供HID 端点。监视器控制类也是如此。通过可用的内核和用户空间的库，与HID 类驱动程序或通用驱动程序一起可以简单直接地创建对这些接口的支持。 另一个设备可以作为在一个配置中的多个接口由不同的设备驱动程序驱动 的例子，这个设备是一种便宜的键盘，带有老的鼠标接口。为了避免在 设备中为USB集中器包括一个硬件而导致的成本上升，制造商将从键盘背面的 PS/2端口接收到的鼠标数据与来自键盘的按键组合成在同一个配置中的 两个单独的接口。鼠标和键盘驱动程序各自连接到适当的接口，并分配到 两个独立端点的管道.

例子：固件下载。已经开发出来的许多设备是基于通用目的处理器， 并将额外的USB核心加入其中。由于驱动程序的开发和USB设备的固件仍然 非常新，许多设备需要在连接(connect)之后下载固件。

下面的步骤非常简明直接。设备通过供应商和产品ID标识自身。第一 个驱动程序探测并连接到它，并将固件下载到其中。此后设备自己软复位， 驱动程序分离。短暂的暂停之后设备宣布它在总线上的存在。设备将改变 其供应商/产品/版本的ID以反映其提供有固件的事实，因此另一个驱动程序 将探测它并连接(attach)到它。

这些类型的设备的一个例子是基于EZ-USB的ActiveWire I/O板。这个 芯片有一个通用固件下载器。下载到ActiveWire板子上的固件改变版本ID。 然后它将执行EZ-USB芯片的USB部分的软复位，从USB总线上断开，并再次 重新连接。

例子：大容量存储设备。对大容量存储设备的支持主要围绕现有的 协议构建。Iomega USB Zip驱动器是基于SCSI版本的驱动器。SCSI命令和 状态信息被包装到块中，在大块(bulk)管道上传输到/来自设备，在USB线 上模拟SCSI控制器。ATAPI和UFI命令以相似的方式被支持。

大容量存储规范支持两种不同类型的对命令块的包装。最初的尝试 基于通过默认管道发送命令和状态信息，使用大块传输在host和设备之间 移动数据。在经验基础上设计出另一种方法，这种方法基于包装命令和 状态块，并在大块out和in端点上发送它们。规范精确地指定了何时必须 发生什么，以及在碰到错误条件的情况下应该做什么。为这些设备编写 驱动程序的最大挑战是协调基于USB的协议，让它适合已有的对大容量存储设备 的支持。CAM提供了钩子，以相当直接了当的方式来完成这个。ATAPI就 没有这么简单了，因为历史上IDE接口从未有过多种不同的表现方式。

来自Y-E Data的对USB软盘的支持也不是那么直观，因为设计了一套 新的命令集。