问题标签 [winusb]

我正在使用需要以下 USB 功能的 LPC1788 开发产品：

• 固件下载（从主机 PC 到设备，而不是通过 USB 密钥）。
• 文件上传（从设备到主机）。
• 理想情况下，我们还可以从设备中获取一些信息，例如序列号等。

该设备应仅与自定义 Windows 应用程序一起使用，因此仅按原样使用大容量存储设备是行不通的。有相当多的数据要上传（200MB +），所以使用 USB 批量传输对我来说似乎是必要的。

解决这个问题的最佳方法是什么？我想我需要创建某种 USB 复合设备（？）。但是，我希望使用 nxpUSBlib 或 winUSB，这样我就不必通过 Windows 驱动程序验证过程......我有什么选择？也许有什么方法可以让大容量存储设备对 Windows 不可见？

谢谢！

短剑

我正在尝试编写一个 c++ 代码来关闭 USB 设备上的电源管理选项，我发现有 winusb api 可以做同样的事情。我下载了 wdk 并获得了相同的必要文件。我去看了system32文件夹，我可以看到文件winusb.sys已经存在（在Windows 7中），所以我应该按照链接中的步骤通过使用inf文件并创建包来重新安装驱动程序吗？.

我通过 api 和 API 需要 winusb.sys 的 GUID 来初始化 winusb 函数并获取设备的句柄，给定一个 winusb.sys 如何找到它的 guid？

我正在开发 WinUSB 应用程序，它使用通用 USB 设备通过中断端点进行基本读取。设备驱动程序安装正常。但是当设备连接时，应用程序 t_main 函数根本没有被触发。它仅在 Visual Studio 调试器中触发并且工作正常。

我在这里想念什么？Winusbtrace 检测设备并记录 WinUSB_InitControlPipe 和 WinUSB_DOEntry 的进入和退出。Windows/inf/*.log 中的日志没有帮助，因为它们只记录安装。我可以参考任何其他日志吗？

我真的很感激任何投入。提前致谢。下面是我的 INF 文件，我在 Win 7 x64 上使用 Visual Studio 2013

我有一个在 DoWork() 中等待 WinUSB ReadPipe() 调用的 BackGroundWorker。当 ReadPipe() 返回数据时，该数据被打包到 DoWorkEventArgs 参数中，并且 DoWork() 结束。

通常 RunWorkerCompleted() 在 DoWork() 结束后很快执行。然而，有时两者之间会有 5 秒的延迟。我在 DoWork() 和 RunWorkerCompleted() 的开始和结束处使用了 DateTime.Now 时间戳，以确定延迟发生的确切位置。

什么可能导致 DoWork() 和 RunWorkerCompleted() 之间的延迟？有什么我可以做的吗？

有没有办法确定我是否可以在任何给定设备上使用 WinUSB？

我正在尝试查看是否可以将 libusb 与 USB3 Vision 设备一起使用。这是我第一次尝试与 USB 设备通信，所以我遇到了一些困难。

从 libusb 的网站我知道它需要使用 WinUSB 作为设备的驱动程序。对于许多设备来说，WinUSB 似乎也是一个安全的选择，但我很难确定 WinUSB 是否可以与 USB3 Vision 设备一起使用。

由于我无法在网上直接找到是或否，我尝试使用Zadig安装 WinUSB，但没有成功。我还尝试制作自定义 inf 文件并尝试通过设备管理器安装 WinUSB 驱动程序。显然我没有太多的运气。

我知道 USB3 Vision 相对较新，所以我知道可能没有多少人尝试过做类似的事情。所以我想知道是否值得继续尝试安装 WinUSB 作为设备的驱动程序。有什么方法可以确定它是否可以与我的设备一起使用？

更新：

该设备的详细信息部分似乎没有任何兼容的 ID（设备管理器 -> 右键单击​​设备->属性->详细信息）。缺少 WinUSB 兼容 ID 是否意味着它肯定不兼容？

以前我使用 Windows 窗体应用程序建立一些 RS232 连接。我使用了已经提供的串口组件（SerialPort），能够相对容易地建立RS232通信。

现在，我想知道在 Winodows Form 应用程序中是否会有类似的东西来建立 USB 通信？

似乎有这个 WinUSB API 提供了与设备的非常低级的接口。但是，我不确定这有多容易？此外，不确定集成到 Windows 窗体应用程序有多容易？！

这种USB接口API会有更简单的版本吗？

我不必坚持使用 Visual Studio。除了 WinUSB 之外，还有其他更标准的 c++ USB API 吗？我想开发一个通过 USB 进行一些通信的 GUI API。如果需要，我可以使用 Python 或其他一些工具（如果它有助于该过程）？

提前致谢。

我有一台 Win7/64 开发机器（由我无法联系的其他人）配置为使用 ST-LINK/V2 加密狗开发/调试嵌入式项目。PC 检测并安装加密狗 正常，但没有应用程序可以访问加密狗，出现'No ST-Link device detected'类型错误。

让这如此令人沮丧的是我有另一台 Win7/64 机器，它使用相同的驱动程序、软件和加密狗完美地工作，我无法在机器之间转移开发环境。

我发现（使用 USBlyzer）WinUSB 将 IRP 状态返回STATUS_ACCESS_DENIED给每个加密狗访问请求。我希望有人以前见过这样的事情。

PS“STMicroelectronics STLink 加密狗驱动程序”日期为 28/07/2010。

我正在尝试编写代码以使微控制器可以通过 USB 与 PC 进行通信。我认为大部分代码都已到位，只要速度较慢（每条消息> ~ 5ms），通信通常可以正常工作。但是，我想让它以更高的速度以 0% 的丢弃率工作（最好在每条消息之间以几十到几百微秒的速度）。通信配置为使用全速 USB 2.0 协议，因此我的传输速率约为 12 MHz。

由于协议的工作方式，我发现相对于（比如）CAN 的 USB 问题更难调试，但我相信问题出在我编写的与设备接口的 PC 端驱动程序上。

设备和驱动程序使用两个标准控制端点（物理端点 0 和 1）并另外使用两个批量端点：

• BULK 2 Out（物理端点 4）
• BULK 2 In（物理端点 5）

这两者的最大数据包大小为 64 字节。

我创建的驱动程序或多或少基于Microsoft 网站上的示例代码。我导出了一个receiveMessage函数，最初，每次调用它时，它都会分配一个 64 字节的缓冲区，并使用WinUsb_ReadPipe. 如果没有要读取的数据，则会有 1 毫秒的超时以防止应用程序挂起。

这实质上意味着从管道读取数据的速率受限于应用程序可以轮询它的速率。如果设备向管道写入数据的速度快于应用程序从中读取数据的速度，我相信这会导致问题。我试图通过在驱动程序中创建一个队列和一个线程来解决这个问题，该线程除了不断地轮询管道并将任何接收到的消息存储在队列中之外什么都不做，然后应用程序可以使用“receiveMessage”随意读取这些消息。但是，这并没有很好地工作。

我想要的是一个代码示例，它演示了一种确保以下内容的方法：

• 可以尽可能快地从 BULK In 管道中读取数据。
• 有一种“缓冲”消息的方法，以便设备可以比应用程序在短时间内更快地写入管道，但不会丢弃任何消息。

我认为一种可能的方法可能是在设备和驱动程序之间建立另一个批量管道。然后，设备应将所有传出消息存储到缓冲区中，并保留一个单独的数组，该数组包含该缓冲区中相应索引处的每个消息的字节数。然后每当应用程序想要读取一组消息时，驱动程序使用这些管道之一从设备请求消息字节数组。对于此数组中的每个值，驱动程序使用 发出对该字节数的请求，WinUsb_ReadPipe设备通过以相同顺序通过 USB 总线发送每个消息来服务该请求。不过，我不确定这是否可行，或者是否过于复杂。

我当前的初始化代码：

我使用以下代码在内部轮询驱动程序中的消息：

receiveMessage此处给出了使用驱动程序的应用程序可以用来接收消息的导出代码：

编辑

根据 Hasturkun 的建议，我对代码进行了以下更改。

在初始化中：

读取管螺纹：

我还注释掉了与 相关的所有内容messagePoller，因为readPipe现在处理所有这些。

但是，我仍然遇到性能问题。

编辑 2

更新readPipe了上面的代码。

我开始认真地怀疑问题出在我的驱动程序还是微控制器上。使用像 CAN 这样的协议，可以更容易地判断问题出在哪里......

我让我的驱动程序生成它收到的所有消息的日志，包括其他详细信息，例如接收两条消息的线程之间的时间增量，以及哪个线程正在处理消息（我有两个）。我得到这样的输出：

本质上，当应用程序首次启动时，会在应用程序和设备之间发送许多“启动”消息。大约 4 秒后，我使用应用程序从设备请求稳定的消息流，其中包含一组 4 条消息，这些消息以 50 毫秒的间隔发送：

1. 0000000D...
2. 0000010D...
3. 0000020D...
4. 0000030D...

看起来驱动程序实际上表现得非常好，因为我们可以看到它在几百微秒内始终如一地在我们预期的点上报告值。然而：

• 30D... 消息似乎始终在 20D... 消息之前到达
• 10D... 消息不断被丢弃

这可能是微控制器代码的问题。我正在使用双缓冲端点，因此可以理解为什么消息无序到达。

一件事是，在发送后续消息之前，我没有明确等待微控制器代码中批量 IN 管道上的 ACK。这可能是问题所在，尽管我之前尝试过这样做，但似乎没有太大影响。

下面是 USBLyzer 输出的屏幕截图，如果它们有帮助的话（在不同的运行期间拍摄，因此数据不会完全相同但仍然非常相似）。它们是屏幕截图，只是因为日志文件格式不正确。

直接链接

直接链接

编辑 3

似乎我的微控制器正在向驱动程序发送消息，每条消息之间只有大约 30 微秒（以最大速率），而根据日志，驱动程序处理一条消息似乎需要 200-500 微秒。这是一个很大的差异。真正的问题是，即使我的驱动程序跟不上，比我的驱动程序软件更低级别的东西正在以与发送消息相同的速率向微控制器发送 ACK，因此我不能基于此限制它。似乎每次驱动程序收到消息时，我可能需要从驱动程序显式向 BULK Out 管道上的微控制器发送一条消息，说“我已准备好接收另一条消息”，但这似乎真的很慢事情下来了。有没有更好的选择？

我已经编写了一个用于从光谱仪获取数据的 WinUSB 项目，该代码似乎在几周前工作。在后期我尝试将此项目与 CUDA 链接，经过几次尝试，我解决了 CUDA 链接器错误。不幸的是，我在主程序（Winusb 项目）中出现了“错误 LNK2019：未解析的外部符号”。起初我以为是因为 .cu 文件，我决定从项目中删除所有 .CU(CUDA) 文件，但我仍然不断收到相同的错误（LNK2019）。以下是我的 Winusb 项目代码（几周前运行良好，但现在我完全迷路了，需要一些帮助）

主文件

我的 Pch.h

我的设备.h #include

我的构建日志

我有两个应用程序 Winusb 并使用 CUDA 将数据从 cpu 处理到 GPU。两者都可以作为两个单独的项目正常工作，但是当我尝试将它们组合为一个项目时，出现以下链接错误。

构建日志：

主文件

包装器.cu

函数.cu

我还有一个device.cpp，它具有opendevice、closedevice等功能（Winusb的一部分，自动生成的代码行太多）。它看起来像是 Cuda 和 Winusb 应用程序之间的某种链接器错误。当我简单地为 Cuda 和另一个为 winusb 创建两个视觉工作室项目时，两者都可以完美运行。