This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
您好!
我必须为123GX LaunchPad 运行 USB 项目、并且试着将这两个 USB 项目组合成一个复合器件。 阅读了几天的文档和 usblib 源代码后、我遇到了看起来存在冲突的信息-或者我很困惑。
我在这里看到 usblib 用户指南说您需要支持3个有道理的字符串(如下所示):
但当我查看源代码时、它需要的不止这些。 请参见下方的。
// //! A pointer to the string descriptor array for this device. This array //! must contain the following string descriptor pointers in this order. //! Language descriptor, Manufacturer name string (language 1), Product //! name string (language 1), Serial number string (language 1), Composite //! device interface description string (language 1), Configuration //! description string (language 1). //! //! If supporting more than 1 language, the descriptor block (except for //! string descriptor 0) must be repeated for each language defined in the //! language descriptor. //! // const uint8_t * const *ppui8StringDescriptors; // //! The number of descriptors provided in the ppStringDescriptors //! array. This must be 1 + ((5 + (number of strings)) * //! (number of languages)). // const uint32_t ui32NumStringDescriptors;
上述用户指南屏幕截图和源代码片段涉及如下所示的复合器件结构(可在 usbdcomp.h 中找到)的一部分:
在 usbdcomp.h 中找到的完整结构源
//***************************************************************************** // //! The structure used by the application to define operating parameters for //! the composite device class. // //***************************************************************************** typedef struct { // //! The vendor ID that this device is to present in the device descriptor. // const uint16_t ui16VID; // //! The product ID that this device is to present in the device descriptor. // const uint16_t ui16PID; // //! The maximum power consumption of the device, expressed in mA. // const uint16_t ui16MaxPowermA; // //! Indicates whether the device is self or bus-powered and whether or not //! it supports remote wake up. Valid values are \b USB_CONF_ATTR_SELF_PWR //! or \b USB_CONF_ATTR_BUS_PWR, optionally ORed with //! \b USB_CONF_ATTR_RWAKE. // const uint8_t ui8PwrAttributes; // //! A pointer to the callback function which will be called to notify //! the application of events relating to the operation of the composite //! device. // const tUSBCallback pfnCallback; // //! A pointer to the string descriptor array for this device. This array //! must contain the following string descriptor pointers in this order. //! Language descriptor, Manufacturer name string (language 1), Product //! name string (language 1), Serial number string (language 1), Composite //! device interface description string (language 1), Configuration //! description string (language 1). //! //! If supporting more than 1 language, the descriptor block (except for //! string descriptor 0) must be repeated for each language defined in the //! language descriptor. //! // const uint8_t * const *ppui8StringDescriptors; // //! The number of descriptors provided in the ppStringDescriptors //! array. This must be 1 + ((5 + (number of strings)) * //! (number of languages)). // const uint32_t ui32NumStringDescriptors; // //! The number of devices in the psDevices array. // const uint32_t ui32NumDevices; // //! This application supplied array holds the the top level device class //! information as well as the Instance data for that class. // tCompositeEntry * const psDevices; // //! The private data for this device instance. This memory must remain //! accessible for as long as the composite device is in use and must //! not be modified by any code outside the composite class driver. // tCompositeInstance sPrivateData; } tUSBDCompositeDevice;
Question:
1.我应该只遵循结构源代码中的注释,字符串 desc 指针,说明以下是必需的{language desc, manf name string, product name str, serial num string, composition dev interface desc string, configuration desc string}? 我提出这个问题、因为这超出了用户指南所说的数量。
2.字符串应该是什么格式? 下面显示了一个 hid 字符串描述符示例。 我是否应该复制粘贴这些内容并只更改复合字符串的内容?
//***************************************************************************** // // The languages supported by this device. // //***************************************************************************** const uint8_t g_pui8LangDescriptor[] = { 4, USB_DTYPE_STRING, USBShort(USB_LANG_EN_US) }; //***************************************************************************** // // The manufacturer string. // //***************************************************************************** const uint8_t g_pui8ManufacturerString[] = { (17 + 1) * 2, USB_DTYPE_STRING, 'T', 0, 'e', 0, 'x', 0, 'a', 0, 's', 0, ' ', 0, 'I', 0, 'n', 0, 's', 0, 't', 0, 'r', 0, 'u', 0, 'm', 0, 'e', 0, 'n', 0, 't', 0, 's', 0, }; //***************************************************************************** // // The product string. // //***************************************************************************** const uint8_t g_pui8ProductString[] = { (19 + 1) * 2, USB_DTYPE_STRING, 'G', 0, 'e', 0, 'n', 0, 'e', 0, 'r', 0, 'i', 0, 'c', 0, ' ', 0, 'B', 0, 'u', 0, 'l', 0, 'k', 0, ' ', 0, 'D', 0, 'e', 0, 'v', 0, 'i', 0, 'c', 0, 'e', 0 }; //***************************************************************************** // // The data interface description string. // //***************************************************************************** const uint8_t g_pui8DataInterfaceString[] = { (19 + 1) * 2, USB_DTYPE_STRING, 'B', 0, 'u', 0, 'l', 0, 'k', 0, ' ', 0, 'D', 0, 'a', 0, 't', 0, 'a', 0, ' ', 0, 'I', 0, 'n', 0, 't', 0, 'e', 0, 'r', 0, 'f', 0, 'a', 0, 'c', 0, 'e', 0 }; //***************************************************************************** // // The configuration description string. // //***************************************************************************** const uint8_t g_pui8ConfigString[] = { (23 + 1) * 2, USB_DTYPE_STRING, 'B', 0, 'u', 0, 'l', 0, 'k', 0, ' ', 0, 'D', 0, 'a', 0, 't', 0, 'a', 0, ' ', 0, 'C', 0, 'o', 0, 'n', 0, 'f', 0, 'i', 0, 'g', 0, 'u', 0, 'r', 0, 'a', 0, 't', 0, 'i', 0, 'o', 0, 'n', 0 };
结构中的注释听起来几乎像以下指向这些字符串的指针。
//***************************************************************************** // // The descriptor string table. // //***************************************************************************** const uint8_t * const g_ppui8StringDescriptors[] = { g_pui8LangDescriptor, g_pui8ManufacturerString, g_pui8ProductString, g_pui8SerialNumberString, g_pui8DataInterfaceString, g_pui8ConfigString };
3. 对于"字符串数"字段(ppui8StringDescriptors 指针) ,结构源说明如下:
// //! The number of descriptors provided in the ppStringDescriptors //! array. This must be 1 + ((5 + (number of strings)) * //! (number of languages)). // const uint32_t ui32NumStringDescriptors;
那么、哪些字符串会计入该等式的"字符串数"部分? 前面的幻灯片中提到的所有
const uint8_t * const *ppui8StringDescriptors;
4、 通过 HID-Bulk 设备结构时,是否通过标准结构? 我注意到该示例使用了我不使用的缓冲器吗? 我的两个器件接口仅使用 USBLIB 的标准结构。 例如、我的批量项目中正在工作的批量器件接口仅使用以下结构-我删除了示例项目附带的缓冲支持。
//***************************************************************************** // //! The structure used by the application to define operating parameters for //! the bulk device. // //***************************************************************************** typedef struct { // //! The vendor ID that this device is to present in the device descriptor. // const uint16_t ui16VID; // //! The product ID that this device is to present in the device descriptor. // const uint16_t ui16PID; // //! The maximum power consumption of the device, expressed in milliamps. // const uint16_t ui16MaxPowermA; // //! Indicates whether the device is self- or bus-powered and whether or not //! it supports remote wakeup. Valid values are USB_CONF_ATTR_SELF_PWR or //! USB_CONF_ATTR_BUS_PWR, optionally ORed with USB_CONF_ATTR_RWAKE. // const uint8_t ui8PwrAttributes; // //! A pointer to the callback function which will be called to notify //! the application of events related to the device's data receive channel. // const tUSBCallback pfnRxCallback; // //! A client-supplied pointer which will be sent as the first //! parameter in all calls made to the receive channel callback, //! pfnRxCallback. // void *pvRxCBData; // //! A pointer to the callback function which will be called to notify //! the application of events related to the device's data transmit //! channel. // const tUSBCallback pfnTxCallback; // //! A client-supplied pointer which will be sent as the first //! parameter in all calls made to the transmit channel callback, //! pfnTxCallback. // void *pvTxCBData; // //! A pointer to the string descriptor array for this device. This array //! must contain pointers to the following string descriptors in this //! order. Language descriptor, Manufacturer name string (language 1), //! Product name string (language 1), Serial number string (language 1), //! Interface description string (language 1) and Configuration description //! string (language 1). //! //! If supporting more than 1 language, the strings for indices 1 through 5 //! must be repeated for each of the other languages defined in the //! language descriptor. // const uint8_t * const *ppui8StringDescriptors; // //! The number of descriptors provided in the ppStringDescriptors array. //! This must be 1 + (5 * number of supported languages). // const uint32_t ui32NumStringDescriptors; // //! The private instance data for this device. This memory must //! not be modified by any code outside the bulk class driver. // tBulkInstance sPrivateData; } tUSBDBulkDevice;
可以吗、因为看起来用户指南示例向 CDC 器件传递了我在批量示例中不再使用的缓冲器和东西。
尊敬的 Robert:
1. 我是否应该遵循结构源代码中关于字符串 desc 指针的注释,说明以下是必需的{language desc、manf name string、product name str、serial num string、composition interface desc string、configuration desc string}? 我提出这个问题、因为这超出了用户指南所说的数量。 [/报价]比较用户指南中针对复合器件字符串的措辞与 tUSBDCompositeDevice 中定义的结构、区别在于 tUSBDCompositeDevice 还包括针对语言、复合器件 I/f 字符串和配置字符串的描述符。
在用户指南中、我想知道是否 所有其他字符串都 是指 语言、复合器件 i/f 字符串和配置字符串。
此字符串列表应按以下顺序包括以下三个字符串:制造商、产品和产品序列
组成部分。 这些类使用的所有其他字符串都是指定的,并且来自包含的
器件类。我想我会遵循已经定义的复合器件结构。
2. 字符串应该采用什么格式? 下面显示了一个 hid 字符串描述符示例。 我是否应该复制和粘贴这些字符串,只需更改组合字符串的内容?我建议您查看 C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_usb example。 这是一个 TM4C129的示例。 但是、TM4C129和 TM4C123共享相同的 USB 库、因此想法是相同的。 在此示例中、同时为 HID 类和 DFU 类设置了复合器件。
3. 对于字符串数字段(ppui8StringDescriptors 指针)、 结构源将显示以下内容:我希望您可以使用 C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_usb\usb_hiddfu_structs.c 和 C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_usb\boot_demo_starts.c 作为复合设备的起点、以构建 usb_hiddfu_structs.h。
还有另一个包含两个 CDC 类器件的复合器件、作为起点、您可能会有所帮助。 C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\usb_dev_cserial
[/quote]
尊敬的 Charles:
感谢示例项目-我一直在研究这些项目、它们非常有帮助。 我确实发现 USB 复合驱动程序代码中有一些非常有趣的内容,我*认为* TI 已将其硬编码。 我注意到在 usbdcomp.c 中的以下结构中
//**************************************************************************** // // Device Descriptor. This is stored in RAM to allow several fields to be // changed at runtime based on the client's requirements. // //**************************************************************************** static uint8_t g_pui8CompDeviceDescriptor[] = { 18, // Size of this structure. USB_DTYPE_DEVICE, // Type of this structure. USBShort(0x110), // USB version 1.1 (if we say 2.0, hosts assume // high-speed - see USB 2.0 spec 9.2.6.6) USB_CLASS_MISC, // USB Device Class (spec 5.1.1) USB_MISC_SUBCLASS_COMMON, // USB Device Sub-class (spec 5.1.1) USB_MISC_PROTOCOL_IAD, // USB Device protocol (spec 5.1.1) 64, // Maximum packet size for default pipe. USBShort(0), // Vendor ID (filled in during USBDCompositeInit). USBShort(0), // Product ID (filled in during USBDCompositeInit). USBShort(0x100), // Device Version BCD. 1, // Manufacturer string identifier. 2, // Product string identifier. 3, // Product serial number. 1 // Number of configurations. };
"接口关联描述符"似乎有硬编码值。 相关的字节是以下三个字节-{USB_CLASS_MISC、USB_MISC_SUBCLASS_COMMAND、USB_MISC_PROTOCOL_IAD}、它们分别设置为{0xEF、0x02、0x01}。
链接到描述 IAD 的 Microsoft 文档:
由于我的应用需要两个独立的 TX/Rx 接口(一个中断/hid 和一个大容量)、我认为我不需要 IAD 功能。 您知道为什么这似乎是硬编码的,如果客户需要两个单独的接口,我们应该修改它并设置为零,这是正确的吗? 似乎这基本上会将我的两个接口绑定到同一个驱动程序-这是 usblib 驱动程序堆栈的目的吗?
谢谢!
尊敬的 Robert:
我确实发现 USB 复合驱动程序代码中有一些非常有趣的内容,我*认为* TI 已将其硬编码。 我注意到在 usbdcomp.c 中的以下结构中
全屏123456789101112131415161718192021//*****////设备描述符。 这存储在 RAM 中、以允许使用多个字段//根据客户要求在运行时进行更改。////*****静态 uint8_t g_pui8CompDeviceDescriptor[]={18、 此结构的大小。USB_DTYPE_DEVICE、 //此结构的类型。USBShort (0x110)、 // USB 版本1.1 (假设是2.0,主机假定//高速-请参阅 USB 2.0规范9.2.6.6)USB_CLASS_MISC、 // USB 设备类(规范5.1.1)USB_MISC_SUBCLASS_COMMAND、// USB 器件子类(规格5.1.1)USB_MISC_PROTOCOL_IAD、// USB 器件协议(规格5.1)64、 //默认管道的最大数据包大小。USBShort (0)、 //供应商 ID (在 USBDCompositeInit 期间填写)。USBShort (0)、 //产品 ID (在 USBDCompositeInit 期间填充)。USBShort (0x100)、 //设备版本 BCD。1、 //制造商字符串标识符。2、 //产品字符串标识符。XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXFullscreen123456789101112131415161718192021//****************************************************************************//// Device Descriptor. This is stored in RAM to allow several fields to be// changed at runtime based on the client's requirements.////****************************************************************************static uint8_t g_pui8CompDeviceDescriptor[] ={18, // Size of this structure.USB_DTYPE_DEVICE, // Type of this structure.USBShort(0x110), // USB version 1.1 (if we say 2.0, hosts assume// high-speed - see USB 2.0 spec 9.2.6.6)USB_CLASS_MISC, // USB Device Class (spec 5.1.1)USB_MISC_SUBCLASS_COMMON, // USB Device Sub-class (spec 5.1.1)USB_MISC_PROTOCOL_IAD, // USB Device protocol (spec 5.1.1)64, // Maximum packet size for default pipe.USBShort(0), // Vendor ID (filled in during USBDCompositeInit).USBShort(0), // Product ID (filled in during USBDCompositeInit).USBShort(0x100), // Device Version BCD.1, // Manufacturer string identifier.2, // Product string identifier.XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX//**************************************************************************** // // Device Descriptor. This is stored in RAM to allow several fields to be // changed at runtime based on the client's requirements. // //**************************************************************************** static uint8_t g_pui8CompDeviceDescriptor[] = { 18, // Size of this structure. USB_DTYPE_DEVICE, // Type of this structure. USBShort(0x110), // USB version 1.1 (if we say 2.0, hosts assume // high-speed - see USB 2.0 spec 9.2.6.6) USB_CLASS_MISC, // USB Device Class (spec 5.1.1) USB_MISC_SUBCLASS_COMMON, // USB Device Sub-class (spec 5.1.1) USB_MISC_PROTOCOL_IAD, // USB Device protocol (spec 5.1.1) 64, // Maximum packet size for default pipe. USBShort(0), // Vendor ID (filled in during USBDCompositeInit). USBShort(0), // Product ID (filled in during USBDCompositeInit). USBShort(0x100), // Device Version BCD. 1, // Manufacturer string identifier. 2, // Product string identifier. 3, // Product serial number. 1 // Number of configurations. };"接口关联描述符"似乎有硬编码值。 相关的字节是以下三个字节-{USB_CLASS_MISC、USB_MISC_SUBCLASS_COMMAND、USB_MISC_PROTOCOL_IAD}、它们分别设置为{0xEF、0x02、0x01}。
[/报价]我认为0xEF、0x02和0x01具有在接口级别中定义类用法的含义。 我认为它与将类代码设置为0x0具有相同的含义、这意味着类用法是在接口描述符中定义的。
由于我的应用需要两个独立的 TX/Rx 接口(一个中断/hid 和一个大容量),因此我认为我不需要 IAD 功能。 您知道为什么这似乎是硬编码的,如果客户需要两个单独的接口,我们应该修改它并设置为零,这是正确的吗? 似乎这基本上会将我的两个接口绑定到同一个驱动程序-是否是 usblib 驱动程序堆栈的目的?是的、我认为您可以在器件描述符中将 器件类设置为0x0、以便在 两个接口描述符中描述器件的用法。 尽管在库中用 {0xEF、0x02、0x01}硬编码、它并不会阻止接口描述符描述器件的用法。 对于包含 HID 和 DFU 的复合器件示例、界面描述符描述了 HID 类和 DFU 类。 因此、我认为 {0xEF、0x02、0x01}具有与 {0x0、0x0、0x0}相同的效果。
老实说、我在回答您的问题时学习 USB。 :-)
[/quote]
嗨、Charles、
我想我必须使1294xl 开发板启动并运行、然后对枚举流量进行协议分析器捕获。 我最初的想法是、一旦我将两个接口启动并在单独的项目中运行(不确定您是否还记得、 但我修改了 usblib 以处理批量设备的 Microsoft OS 描述符)我可以将它们组合在复合文件中,它们将枚举并显示在窗口中,就像它们分开显示一样。 似乎有更多的故事。
我遇到的问题可能不是由于上述有关 {0xEF、0x02、0x01}的帖子 、因为我将它们归零、但仍然得到完全相同的流量。 看起来复合器件从 HID/BULK 器件信息中获取描述符信息并将其合并到配置描述中。 我捕获了这个、所有的流量看起来都是正确的(我认为) 除外 一个从0x09、0x21开始的描述符部分是毫无道理的、其中第二个字节应该是描述符类型 ID、但0x21并不代表我在 USB 规范中能找到任何内容。 我将在下面粘贴原始流量-您可以看到我无法确定的描述符部分。 我必须在这方面做更长的工作并报告。
/*
*调试说明的其他有用信息。
*问题。
*
*/
描述符类型(来自 USB 规范表9-5):
-------------------------------------------------------
器件1
配置2
字符串3
接口4
端点5
器件限定符6
其他_Speed_Config 7
接口_电源8
/*
*初始复合设备描述符捕获
*来自协议分析器
*
*/
复合器件的器件去纹波器-出现的第一个描述符
-------------------------------------------------------
12 //长度
01 // b 描述符类型
10 01 // bcdUSB
EF // bDeviceClass
02 // bDevice子 类
01 // bDevice协议
40 // bMaxPacketSize
bf 1C // id 供应商
07 00 // idProduct
00 01 // bcdDevice (发布编号)
01 // iManufacturer (字符串描述的索引)
02 // iProduct (产品字符串描述的索引)
03 // iSerialNumber (字符串索引)
01 // bNumConfigurations
//-->以下都在单个描述符事务中
复合器件的配置描述符- 2个接口
-------------------------------------------------------
09 //长度
02 // bDesc 类型
40 00 // wTotalLen
02 // bNumInterfaces
01 // bConfigurationValue
00 // iConfiguration
80 // bmAttributes
7d // bMaxPower
配置描述符中接口0的接口描述符
-------------------------------------------------------
09 //长度
04 //描述符类型
00 // bInterfaceNumber
00 // bAlternateSetting
02 // bNumEndpoints
03 // bInterfaceClass
00 // bInterfaceSubclass
00 // bInterfaceProtocol (接口协议)
00 //接口
!!! 不确定这是什么
-------------------------------------------------------
09
21
00
02
00
01
22
20
00
端点描述
----------------
07
05
81
03
40
00
01
端点描述
----------------
07
05
01
03
40
00
01
配置描述符中接口1的接口描述符
-------------------------------------------------------
09
04
01
00
02
FF
00
00
00
端点描述
----------------
07
05
82
02
40
00
00
端点描述
----------------
07
05
02
02
40
00
00
!!! 不确定这是什么
-------------------------------------------------------
09
21
00
02
00
01
22
20
00[/报价]尊敬的 Robert:
我不知道这是什么。 唯一有意义的是第一个字节、该字节指示了描述符的9个字节。 这可能是一个损坏的接口描述符、但我不确定。 通常、每个器件只有一个器件描述符、大小为18 (0x12)个字节。 对于大多数用例、通常有一个配置描述符。 采集的端点描述符也是7个字节。 这会 在无人的土地上留下该9个字节的额外描述符。
复合设备配置描述符- 2个接口
-------------------------------------------------------
09 //长度
02 // bDesc 类型
40 00 // wTotalLen
02 // bNumInterfaces
01 // bConfigurationValue
00 // iConfiguration
80 // bmAttributes
7d // bMaxPower我认为您的配置描述符可能值得调查。 看看 wTotalLen。 它显示为40 00。 我不确定是否应该将其解释为0x4000 (16384)或0x0040 (64)。 很可能意味着64字节。 如果它是64字节、则应包含 为此配置返回的所有描述符(配置、接口、端点以及类或供应商特定)的组合长度。 在将所有描述符添加在一起时、它真的是64字节吗? 如果我不计算奇怪的描述符 、那么只有55个字节。 如果我对奇怪的描述符进行计数、则表示有64个字节。
配置描述(9)+接口0描述(9)+端点描述(7 )+端点描述(7 )+接口1描述(9)+端点描述(7 )+端点描述(7)= 55。
配置说明(9)+ 接口0说明(9)+ 奇怪的描述(9) +端点描述(7)+ 端点描述(7 )+接口1描述(9)+端点描述(7)+ 端点描述(7)= 64。
我建议您弄清如何计算得出总长度为64字节。 希望这将引导您找到奇怪的描述符的来源。
[/quote]
尊敬的 Charles:
所以我弄清楚发生了什么。 我需要在 Microsoft OS 兼容 ID 字符串描述符中定义该接口以指向第二个接口(接口1)、而该接口指向接口0。 我还必须将 USB 版本设置为2.0。 在 usblib 中、它默认设置为1.1。
现在、我已经在复合器件中安装了两个接口、并且至少从器件管理器的角度运行了这两个接口。 但是、我的确注意到我的第二个接口(bulk)中没有 bulk 字符串描述符。 批量接口显示为设备(正如使用 usbccgp.sys 驱动程序时所预期的那样)、但显示为复合设备描述符。 usblib 的复合设备驱动程序是否打算丢弃大容量字符串描述符? 这是一个问题,因为复合设备字符串所描述的这些附加接口具有误导性。
我还注意到、对于复合描述符、设置事务中的流量与我认为第二个接口的批量描述符会往何处去不同。
复合描述符设置令牌请求:
基数:十六进制
80 06 02 03
09 04 1C 00
我认为发生了大容量(接口#2)字符串描述符请求的地方:
基数:十六进制
80 06 02 03
09 04 02 08
这么长的故事短我的问题是2倍- usbVersion 在正常描述符中的设备和 MS OS 兼容的功能描述符接口指针字段。
感谢您的帮助!
噢! 还有一件事我想跟你说。 当为复合设备设置接口时,您为"设备"设置典型结构,如 HID 或 BULK 等。 然后将这些驱动器传递给复合器件驱动器、再合并这些驱动器、再将它们置于总线上。
在成为复合器件接口的独立器件的单独数据结构中、有 RX/TX 等的回调。 例如 HID 具有针对流量、连接、断开等的处理程序。 传递到复合器件的其他结构也是如此。 在 driverlib 复合器件示例中、它们对 CDC 器件使用相同的回调。 这很好、但是如果复合器件上有两个完全不同的接口怎么办? 是否分别调用各个回调(例如对于 HID 和 BULK)? 因此、对于 HID 流量、HID 回调处理程序/ISR 处理程序会被调用、而对于批量传输则是一样的? 几乎就像通信的回调/ISR 处理程序一样、它们仍然像单独的器件一样运行?
换句话说、如果两个 CDC 结构需要具有不同的回调处理程序而不是使用相同的回调处理程序、driverlib 文档中的示例会发生什么情况?
尊敬的 Robert:
我认为是这样。 在 C:\ti\TivaWare_C_Series-2.2.0.295\examples\boards\ek-tm4c1294xl\boot_demo_usb\boot_demo_usb.c 示例中、会对每个单独器件进行回调。 在此示例中、有 HID 类和 DFU 类器件。