VxWorks下的USB驱动程序原理与分析

VxWorks 下的 USB 驱动程序原理与分析 1 问题的提出 通用串行总线 USB 作为一种中高速的数据方式 已经很普遍地应用于外设与主机的通信 中 VxWorks 是当今十分流行的实时操作系统 在通信 国防 工业控制 医疗设备等嵌 入式实时应用领域 很多 VxWorks 系统中都有 USB 设备 可是关于 USB 的驱动实现并没 有相关的资料可以参考 给实际工作带来了难题 本文通过详细地分析 VxWorks 下的 USB 驱动栈 具体提出了其实际应用的方法 为 USB 在应用 VxWorks 的嵌入式系统的开发扫 清了技术障碍 2 VxWorks 简介 VxWorks 是 WindRiver 公司开发的具有工业领导地位的高性能实时操作系统 Real Tim Operation System RTOS 内核 具有先进的网络功能 VxWorks 的开放式结构和对工业 标准的支持 使得开发人员易于设计高效的嵌入式系统 并可以很小的工作量移植到其它 不同的处理器上 作为一种先进的实时操作系统 它具有以下特点 可裁剪微内核结构 高效的任务管理 多任务 具有 256 个优先级 具有优先级排队和循环调度 快速的 确定性的上下文切换 灵活的任务间通讯 三种信号灯 二进制 计数 有优先级继承特性的互斥信号灯 消息队列 套接字 Socket 共享内存 信号 Signals 微秒级的中断处理 支持 POSIX 1003 1b 实时扩展标准 支持多种物理介质及标准的 完整的 TCPIP 网络协议 灵活的引导方式 支持从 ROM flash 本地盘 软盘或硬盘 或网络引导 支持多处理器并行处理 快速灵活的 l O 系统 支持 MS DOS 和 RT 11 文件系统 支持本地盘 flash CD ROM 的使用 完全符合 ANSI C 标准 多个系统调用 3 USB 驱动程序的结构概述 图 1 提供了一个 USB 主驱动栈结构的简单概括 图 2 显示了 USB 主驱动栈的各模块之间 的功能联系 在栈的最底部是 USB 主控制器 USB HC 即 USB Host Controller 这是主系统中控制每 一个 USB 设备的硬件部分 目前 市场上主要有两大类 USB 主控制器 一种是支持由 ime1 公司最先提出的通用主控 制器接口 Universal Host Controller Interface 简称 UHCI 另一种是支持由微软 康柏和 国家半导体公司联合设计提出的开放主控制器接口 Open Host Controller Interface 简称 OHCI 硬件厂商一般根据这两个规范设计他们的 USB 主控制器 对于每一类型的主控制器都有一个与硬件独立的 USB 主控制器驱动主控制器驱动 HCD Host Controller Driver 简称 HCD WindRiver 提供了两个驱动 usbHcdUhciLib UHCI 主控制器库 和 usbHedOheiLib OHCI 主控制器库 USB 主驱动主驱动 USBD USB host driver 简称 USBD 和 HCD 之间的接口允许一个或超过一个的底层主控制器 而且 WindRiver 的 USBD 能够同 时连接多个 USB HCD 这样的设计特点可以使开发者建立复杂的 USB 系统 USBD 是在 HCD 之上的与硬件独立的模块 USBD 管理每一个与主机相连的 USB 设备 向更高层次提供了可与 USB 设备通信的路径 它还负责自动处理 USB 电力管理以及 USB 带宽管理 而且 USBD 还管理 USB hub Hub 功能是一个驱动能否对 USB 正确操作的评 价之一 因此 WindRiver 的 USBD 设计者要使 USBD 透明地处理 hub 的功能 这意味着 USBD 还能处理 USB hub 和设备的动态插拔 USB Client 模块在 USB 主驱动栈的顶端 USB 类驱动 USB Class Driver 是 Client 模块的典 型例子 USB 类驱动负责管理连接到 USB 上的不同类型的设备 它们依靠 USBD 来提供 与每个设备的通信路径 USB client 模块的其他例子就是那些利用 USBD 与 USB 设备通信 的应用程序 4 USBD 驱动详解 这一部分将要描述 USBD USB Host Driver 的典型应用 例如初始化 client 注册 动态连 接注册 设备配置 数据传输 同时还探讨了 USBD 内部设计的关键特性 这部分是 VxWorks 下 USB 驱动的核心 4 1 初始化 USBD 分为两步 1 必须至少调用一次函数 usbdInitialize 在一个给定的系统中 usbdlnifialize 初始化内 部 USBD 数据结构 并依次调用其它 USB 驱动栈模块的入口 usbdinitialize 可以在启动 时调用一次 也可以对每一个设备各调用一次 USBD 自己记录了调用 usbdInitialize 和 usbdShutDown 的次数 只有大于等于 1 时才是真正初始化了 而等于 0 是 关闭了 2 用 USBD 的 lisbdHedAttaeh 函数来把至少一个 HCD 连接到 USBD 上 这一过程既可 以在 VxWorks 启动时 也可以在运行时把 HCD 连接到 USBD 上去 后一种机制可以支持 热插拔 而不用象前一种那样需要重新启动 4 2 HCD 的连接 attaching 与断开 detaching 当 HCD 连接到 USBD 时 调用者为 usbdHedattaeh 函数传递 HCD 执行入口 表 HCD EXEC FUNC 和 HCD 连接参数 HCD attach parameter USBD 用 HCD FNC ATYACH 服务请求依次激活 HCD 的执行入口 传递同样的 HCD attach 参数 需要强调虽然可以改变用 HCD 定义的参数 但是最好不应该有所改变 对于 WindRiver 提 供的 UHCI 和 OHCI 的 HCD HCI attach 参数是一个指向结构 PCI CFG HEADER 定义在 pciConstants h 的指针 该结构用 UHCI 和 OHCI 主控制器的 PCI 配置头来初始化 而 HCD 用这个结构中的信息来 定位 管理特定的主控制器 典型的 调用者用 usbPeiClassFind 和 usbPciConfigHeaderGet 来得到想要的主控制器的 PCI 配置头 这两个函数定义在 usbPciLib 中 stubUsbarchPciLib h 中 如果有 UHCI 或 OHCI 要连接到 USBD 就要调用 这些函数来获得每一个主控制器的 PCI CFG HEADER 然后利用 usbdHedAttaeh 来激活 已鉴别出的每一个主控制器 注意 底层 BSP 可能不支持 USB 的 HCD 断开 因为当中断向量表重新使能时 如果还应 用的是过期的向量表 会导致错误 4 3 启动顺序 必须在所有 USBD 函数前执行函数 usbdInitialize 存在以下两种调用方式 1 传统的 启动 初始化 执行顺序与其意义如下 a usbdInitialize b usbdPciClassFind 定位一个 USB 主控制器 c usbdPeiConfigHeaderGet 读 USB 主控制器配置头 d usbdHedAttaeh 连接 HCD 将其作为特定的主控制器 e 调用 USB class driver 初始化入口点 f USB class driver 调用 usbdlnitialize 2 热插拔 调用 执行顺序与其意义如下 Boot Code 里调用 a USB class driver 初始化入口点 b USB class driver 调用 usbdlnitialize Hot Swap code 调用 c Hot Swap 鉴别 USB 主控制器的连接或断开 d Usbdlnitialize e UsbdPciConfigHeaderGet 读 USB 主控制器配置头 f UsbdHedAttaeh 连接 HCD 将其作为特定的主控制器 因为热插拔可以在任何时刻发生 所以 USBD 和其 Client 都必须被写成可以动态识别 USB 设备被插入还是被拔出 当主控制器连接到系统时 USBD 自动地鉴别与其相连的设备 并通知相关的 client 同样 拔出设备时 也要通知相关设备 重要的是 USBD 的 client 比如 USB class driver 在 client 初始化时 从不设想特定的设备已经出现 而在其 他时候 这些驱动随时检查设备是否已经连接到系统上 4 4 总线任务 对每一个连接到 USBD 的主控制器 例如插入或拔出设备 USBD 都会产生一个总线任务 来监控总线事件 一般情况下 这些任务是休眠的 不消耗 CPU 只有当 USB hub 报告它 的一个端口有变化时 它们才被唤醒 每一个 USBD 总线任务有 VxWorks 任务名 UsbdBus 虽然 HCD 委托 USBD 来管理 但有可能 HCD 亲自监视主控制器事件 例如 WindRiver 提 供了 UHCI 和 OHCI 的 HCD 来创造这样的任务 对于 WindRiver 的 UHCI 模块 usbHcdUheiLib 后台任务只是被周期地唤醒 目的是为了检查超时 IRP 用一个中断来通 知 OHCI 根 hub 发生改变 用以在 USBD 和 USB 之问进行通信的 client 模块 除了调用 usbdlnitialize 外 必须调用 usbClientRegister 使其在 USBD 注册 当一个 client 注册到 USBD 时 USBD 把每一个以 后将要用到的 client 的数据结构定位 并跟踪那个 client 的请求 对于每一个 client 在 client 注册过程中 USBD 还创建了一个 callback 任务 在成功注册 client 后 USBD 返回一个句柄 USBD CLIENT HANDLE 以下对 USBD 的调用 将会用到 这个句柄 当所有句柄都不需要时 可以调用 usbdClientUnregister 来释放每一个 client 的数据结构和 callback 任务 注意 此时所有 client 要求的任务都会被取消 例如 注册一个叫 USBD TEST 的 client 再注销 注册 usbdClientRegister USBD TEST usbdClientHandle 注销 usbdClientUnregister usbdClientHandle 4 5 client 回调 callback 任务 USB 操作是严格遵守时序的 例如为使中断传输和同步传输正确工作 需要依靠时钟中断 在一个有几个不同 client 出现的主系统中 总是有可能出现一个 client 打断其它 client 传输 事件的发生 WindRiver USBD 建议用 client callback 任务来解决这个问题 许多 USB 事件 可以导致一个 USB client 的 callback 任务 例如 每当 USBD 完成 USB IRP 后 client 的 IRP callback 函数被激活 同样 当 USBD 识别出一个动态连接事件后 会激活一个或 更多的动态 attach callback 操作 但不是马上激活这些回调操作 而是安排合适的相应的 USBD client 的回调任务来执行 callback 一般的情况下 每一个 client 的 callback 任务处于 休眠 态 阻塞态 每一个 client 的 callback 继承了 usbdClientRegister 产生的 VxWorks 任务优先级 这确保了每一个 callback 按其 client 的任务优先级来执行 而且可以利用优先级来写 client 保证对时间要 求严格的 USB 传输 由于每一个 client 有它自己的 callback 任务 因此在 callback 期间 它们有很大的灵活性决定可以做什么 例如 允许在不破坏 USBD 或其它 USBD client 性 能的条件下 使 callback 执行代码运行至阻塞态 Client callback task 有 VxWorks 任务名 tUsbdCln 4 6 USBD 内部 Client 当第一次初始化 USBD 时 由 USBD 产生并注册一个内部 client 以跟踪 USB 请求 USBD 可以产生什么类型的 USB 请求呢 所有 USBD 与 USB 设备的传输 均利用调用 USBD client 的形式来完成 例如 当一个设备第一次连接到系统时 USBD 用一个控制 管道 control pipe 自动地创建设备需要的所有的 control pipe 即 USBD client 要用 usbdPipeCreate 来创建一个与 USB endpoint0 通话的通道 然后所有 USBD 内部 外部 client 通过这个管道来发送诸如 usbdDescriptorGet 或 usbdFeatureGet 等的函数 进行 操作 所以 USBD 的一个机制就是 USBD 循环利用它自己的 entry point 而内部 chent 跟踪这 些请求 4 7 动态连接的注册 每当一个特定类型的设备插入或拔出时 USBD client 都通知上一层 利用调用 usbdDynamicAttachRegister 操作 client 可以指定一个 callback 操作 以便可以获取这 样的通知 USB 设备类型用 class subclass protocol 来区别 标准的 USB 类在 usb h 中定义为 USB CLASS XXXX Subclass 和 protocol 根据 class 来定义 因此这些常数根据特定的 class 在头文件中定义 有时 一个 client 当利用 usbdDynamicAttachRegister 进行注册时 只对特定的 class subclass protocol 感兴趣 例如 USB 键盘类驱动 usbkeyboardLib 注册了 Human Device Interface HID 类 subclass 是 USB SUBCLASS HID BOOT protocol 是 USB PROTOCOL HID BOOT KEYBOARD 通过 callback 机制的响应 每当一个设备 完全符合这样的标准 从设备上插入或拔出时 SBD 便通知给 keyboard class driver 而 在其它情况下 client 关注的范围更广泛了 常量 USBD NOTIFY 定义在 usbdLib h 可以 替代任意的 class subclass protocol 例如 USB 打印机 USB 驱动 usbPrinterLib 其 class 等于 USB CLASS PRINTER subclass 等于 USB SUBCLASS PRINTER usbPrinter h protocol 等于 USBD NOTIFY ALL 典型的 当一个 client 只调用一次 usbdDynamicAttachRegister 时 对一个 client 能拥有的并发通知请求数目没有限制 4 8 Node ID USB 设备一般用 USBD NODE ID 来区别 从其作用来看 USBD NODE ID 是 USBD 用 来跟踪一个设备的句柄 它与 USB 设备真正的 USB 地址无关 这表明 client 并不真正关心 想要了解设备是物理上与哪一个 USB 主控制器相连 应用为每个设备抽象定义的 Node ID 使 client 可以不用考虑物理设备的连接细节以及 USB 地址分配 并允许 USBD 在其 内部对这些进行详细的管理 当一个 client 通知有一个设备连接或断开时 USBD 经常通过 USBD NODE ID 来定位设备 同样 当一个 client 想通过 USBD 与一个特定的设备通信时 它必须向 USBD 传递那个设 备的 USBD NODE ID 4 9 总线编号 bus enumeration 操作 usbdLib 模块提供了 usbdBusCountGet usbdRootNodeldGet usbdHubPortCountGet usbdNodldGet 操作 它们被一起称作总线编号操作 它们使 USBD Client 对连接到每一 个主控制器上的设备进行编号 这些操作对于诊断程序和测试工具很有用 例如 usbTool WindRiver 提供的一个测试工具 但是 利用它们编号之后 调用者无法知道 USB 的拓扑结构是否变化 因此 建议 USB class driver 的开发者不要用这些操作 4 10 数据传输 一旦 client 配置完成一个设备 就开始利用 USBD 提供的管道和传输功能与设备进行数据 交换 传输种类 分为控制 块 中断和同步传输 用一个 USB IRP 数据结构来描述 USB IRP 的具体描述请参见 HCD FUNC IRP SUBM1T USB 数据传输被定位于每一个设 备的特定 endpoint 在 USBD client 和特定的设备 endpoint 之间的通道被称作管道 pipe 每一个管道有以下若干特性 USBD NODE ID 设备的 endpoim 数目 数据传输方向 带宽需求 延时需求 为了和设备交换数据 client 必须先创建管道 作为结果 USBD 得到了一个 USBD PIPE HANDLE 它被用于随后对这个管道的所有 client 操作 当 client 企