您好！
我已经设法修改了 tivaware usblib、以便成功响应 Microsoft 的操作系统字符串描述符-这是一种非标准的描述符类型。 下面显示了这个 USB 交易交换的屏幕截图。 此描述符交换由 Data0设置数据包中的 EE 表示。
此描述符交换看起来与所有标准描述符交换完全匹配。 请参阅下面的标准设计。
现在、我遇到的问题是、在 windows 发送一个 OS 字符串描述符后、它会发送一个兼容的 ID 描述符。 我以相同的方式对该描述符请求进行响应、响应会失败。 我一直在测试修改 usblib 以进行响应的不同方式、它们似乎都以如下所示的相同方式失败。
我在协议分析器上遇到的错误说明"Invalid PID sequence"、并详细说明"已观察到无效的数据包序列"。
我已经尝试使用以下函数进行响应、但运气不好。 不过、我确实看到"in"数据包的 Data1具有正确的数据。 我正在尝试发送以下描述符响应。
使用此函数：
目前为了测试、我还尝试了以下方法进行回应。
这些代码片段可在 usbdenum.c 文件的以下函数中找到。
我还尝试过使用处理程序/回调方法、但由于这不起作用、我正在简化这种情况、将我需要用来直接响应此描述符的代码添加到非标准描述符的调度处理程序功能调用区域。 有人知道为什么这些数据包/PID 序列不符合处理描述符请求的这些(目前粗略的)代码模块的顺序吗？
对于以下代码、处理操作系统描述符(第一个)似乎很奇怪。 您可以看到、我在这里添加了一条 if 语句、来查找0xEE 值并在底部的字符串处理程序情况中响应该描述符。
所以我在此停留、试图调试这一非标准描述符处理不起作用的问题。 即使是 TI 的文档也说第一个函数应该能够处理这种"我认为"。
非常感谢任何帮助！
尊敬的 Robert：
1. 是否应通过 RX 端点中断提醒 Tiva 部件发生了输入请求、以便它可以提取要发回的数据？
通常、输入和输出是相对于主机指定的。 因此、IN 意味着从 USB 主机读取/接收数据。 我假设在事务中、它应该对应于来自从器件的 TX 事务。
2. 是否应在主机发出 IN 事务之前将数据加载到环形缓冲区中？
尽管缓冲区是可选的、但 usb_dev_example 确实使用该缓冲区来提高效率。
#define bulk_buffer_size 256
//*****
//
//传输缓冲区(从 USB 的角度)。
//
//*****
uint8_t g_pui8USBTxBuffer[bulk_buffer_size]；
tUSBBuffer g_sTxBuffer =
｛
true、//这是传输缓冲器。
TxHandler、// pfnCallback
(void *)&g_sBulkDevice、//回调数据是我们的器件指针。
USBDBulkPacketWrite、// pfnTransfer
USBDBulkTxPacketAvailable、// pfnAvailable
(void *)&g_sBulkDevice、// pvHandle
g_pui8USBTxBuffer、// pi8Buffer
BULK_BUFFER_SIZE、// ui32BufferSize
}；
尊敬的 Robert：
不确定这是否有用。 我运行库存 USB_DEV_BULK 示例并捕获输入事务和输出事务的调用栈。 USB0DeviceIntHandler ()用于输入和输出事务。 HandleEndpoints()函数应转向 ProcessDataToHost()或 ProcessDataFromHost()，具体取决于是输入事务还是输出事务。
对于输出事务：
进行输入事务。
尊敬的 Robert：
访问 TivaWare 下载站点时、您可以选择下载下面以黄色突出显示的实用程序。 我还要在此处附加二进制文件。 请首先在库存示例中运行代码以了解相关情况。
