windows USB设备驱动开发-开发USB 设备端驱动

USB 设备是通过单个端口连接到计算机的外设，例如鼠标设备和键盘。 USB 客户端驱动程序是计算机上安装的软件，该软件与硬件通信以使设备正常运行。如果设备属于 Microsoft 支持的设备类，Windows 会为该设备加载 Microsoft 提供的 USB 驱动程序（随机类驱动程序）之一。否则，自定义客户端驱动程序必须由硬件制造商或第三方供应商提供。当 Windows 第一次检测到该设备时，用户会为该设备安装客户端驱动程序。成功安装后，Windows 将在每次连接该设备时加载此客户端驱动程序，并在该设备与主计算机断开连接时卸载此驱动程序。

可以通过使用 Windows 驱动程序框架 (WDF) 或 Windows 驱动程序模型 (WDM) 来开发 USB 设备的自定义客户端驱动程序。大多数客户端驱动程序将其请求发送到 Microsoft 提供的 USB 驱动程序堆栈，该堆栈进行硬件抽象层 (HAL) 函数调用，以便将客户端驱动程序的请求发送到硬件，而不是直接与硬件通信。下面介绍客户端驱动程序可以发送的典型请求，以及客户端驱动程序为创建这些请求而必须调用的设备驱动程序接口 (DDI)。

选择用于开发 USB 客户端驱动程序的驱动程序模型

USB 设备制造商通常必须为应用程序提供访问设备功能的方法。若要选择访问 USB 设备的最佳机制，请从最简单的方法开始，仅在必要时才使用更复杂的解决方案。以下汇总可能的选项：

如果你的设备属于 Windows 包含收件箱驱动程序的 USB 设备类，则无需编写驱动程序；
如果你的设备没有 Microsoft 提供的类驱动程序，并且该设备由单个应用程序访问，则加载 WinUSB 作为功能驱动程序；
如果设备需要由并发应用程序访问，并且设备没有常量终结点，请编写基于 UMDF 的客户端驱动程序；
如果类驱动程序、WinUSB 或 UMDF 解决方案不是适合你的选项，请编写基于 KMDF 的客户端驱动程序；
如果 KMDF 不支持特定功能，请编写调用 WDM 例程的混合驱动程序；

最常见的方法是实现设备驱动程序，我们称为 USB 客户端驱动程序，并提供一个安装包，用于在 Microsoft 提供的 USB 驱动程序堆栈上方的设备堆栈中安装驱动程序作为功能驱动程序。客户端驱动程序公开应用程序可用于获取设备的文件句柄的设备接口。然后，应用程序可以通过调用 Windows API 使用此文件句柄与驱动程序通信。

编写根据设备要求自定义的驱动程序是提供 USB 设备访问权限的最灵活方法。但是，实现驱动程序需要大量的工作。驱动程序必须执行复杂的任务，例如检测到新设备时的驱动程序初始化、电源管理、I/O 操作、意外删除、状态管理和删除设备时的清理。

是否可以使用 Microsoft 提供的驱动程序？

在以下的情况下，你可能不需要编写驱动程序：

你的设备属于 Microsoft 支持的 USB 设备：在这种情况下，相应的类驱动程序将作为设备驱动程序加载。
你的设备不属于设备类：对于此类设备，请评估设备功能，以确定是否可以将 Microsoft 提供的 WinUSB (Winusb.sys) 加载为设备的功能驱动程序。

在以下的情况下，使用 WinUSB 是最佳解决方案：

设备由单个应用程序访问；
设备支持批量、中断或常时等量终结点；
你的设备适用于运行 Windows XP 和 Service Pack 2 (SP2) 及更高版本的 Windows 的目标计算机。将 WinUSB 加载为函数驱动程序提供了实现自定义 USB 驱动程序的更简单的替代方法。例如，WinUSB 是电子气象站的首选方法，只能由与设备一起打包的应用程序访问。它还可用于与设备的诊断通信和刷写固件。为了使应用程序能够轻松地向 Winusb.sys 发送请求，我们提供了一个公开 WinUSB 函数的用户模式 DLL Winusb.dll。应用程序可以调用这些函数来访问设备、对其进行配置，并将数据传输到设备的终结点；

在以下的情况下，WinUSB 不是一个选项：

设备由多个应用程序访问；
你的设备具有在 Windows 操作系统中已具有内核模式支持的函数。例如，对于调制解调器功能 (TAPI 支持) 或 LAN 功能 (NDIS 支持) ，必须使用 Usbser.sys 驱动程序支持的接口来管理具有用户模式软件的调制解调器设备；

在 Windows 8 中，我们已向 INF for WinUSB 安装添加了新的兼容 ID。如果设备固件包含该兼容 ID，则默认情况下将 WinUSB 作为设备的函数驱动程序加载。这意味着硬件制造商不需要为其 WinUSB 设备分发 INF 文件。

如果编写 USB 客户端驱动程序，哪种驱动程序模型最佳？

答案取决于设备的设计。首先，确定特定驱动程序模型是否满足你的要求。一些设计注意事项基于你是否希望多个并发应用程序访问 USB 设备，以及是否支持通过常时等量终结点进行数据流式处理。

如果选择编写驱动程序，可以选择以下选项：

1. 用户模式驱动程序框架 (UMDF)

UMDF 提供设备驱动程序接口 (DDI) 客户端驱动程序可用于与 Windows 组件（如即插即用 Manager 和 Power Manager）集成。 UMDF 还为 USB 设备提供专用目标对象，这些对象在用户模式下抽象硬件并简化驱动程序的 I/O 操作。除了 UMDF 接口外，WDF 还为用户模式驱动程序提供了增强的调试器扩展和跟踪工具。 UMDF 基于组件对象模型 (COM) ，对于 C++ 开发人员来说，开发用户模式驱动程序更容易。

在以下情况下，为 USB 设备实现基于 UMDF 的客户端驱动程序：

设备由多个应用程序并发访问；
设备支持批量传输或中断传输；

在用户模式下运行的驱动程序只能访问 (虚拟) 用户地址空间，并且对系统的风险要低得多。内核模式驱动程序可以访问系统地址空间和内部系统结构。编码错误的内核模式驱动程序可能会导致影响其他驱动程序或系统的问题，并最终导致计算机崩溃。因此，在安全性和稳定性方面，用户模式驱动程序可能比内核模式驱动程序更安全。

用户模式驱动程序的另一个优点是利用所有 Win32 API。例如，驱动程序可以调用 Winsock、压缩、加密 API 等 API。这些 API 不适用于内核模式驱动程序。

对于支持常量终结点的 USB 设备，不支持基于 UMDF 的客户端驱动程序。

注意 Windows 8.1引入了 UMDF 2.0 版。使用 UMDF 版本 2.0，可以使用 C 编程语言编写 UMDF 驱动程序，该语言调用许多可用于 KMDF 驱动程序的方法。不能使用 UMDF 版本 2.0 为 USB 编写较低的筛选器驱动程序。

2. 内核模式驱动程序框架 (KMDF)

KMDF 旨在使驱动程序模型易于扩展以支持新型硬件。 KMDF 提供 DDI 和数据结构，使内核模式 USB 驱动程序比早期 Windows 驱动程序模型 (WDM) 驱动程序更容易实现。此外，KMDF 提供专用的输入/输出 (I/O) 目标，可用于编写使用 Microsoft USB 驱动程序堆栈的全功能客户端驱动程序。

在某些情况下，如果特定功能未通过 KMDF 公开，驱动程序必须调用 WDM 例程。驱动程序不需要实现整个 WDM 基础结构，而是使用 KMDF 方法访问一组所选的 WDM 例程。例如，若要执行常时等量传输，基于 KMDF 的客户端驱动程序可以将描述请求的 WDM 样式的 URL 发送到 USB 驱动程序堆栈。在此文档集中，此类驱动程序称为混合驱动程序。

KMDF 还支持端口微型端口驱动程序模型。例如，在上边缘使用内核流式处理的内核流式处理微型端口驱动程序 (（例如 USB 网络摄像头) ）可以使用 KMDF USB I/O 目标对象将请求发送到 USB 驱动程序堆栈。还可以将 KMDF 用于基于协议的总线（如 USB）来编写 NDIS 驱动程序。

纯 WDM 驱动程序难以编写、复杂且不可靠。随着 KMDF 的发展，不再需要编写此类驱动程序。

Microsoft Visual Studio 2012 包括 USB User-Mode 驱动程序和 USB Kernel-Mode 驱动程序模板，它们分别为 UMDF 和 KMDF USB 客户端驱动程序生成入门代码。模板代码初始化 USB 目标设备对象，以启用与硬件的通信。