TinyUSB项目中NCM模式在RTOS环境下工作异常问题分析

问题背景

在嵌入式开发中，TinyUSB作为一个轻量级的USB协议栈，为开发者提供了便捷的USB设备实现方案。近期有开发者在使用TinyUSB的NCM（Network Control Model）模式时遇到了工作异常的问题，具体表现为在Windows 11系统下无法正常识别设备并建立网络连接。

环境配置

问题出现在以下环境中：

• 操作系统：Windows 11
• 开发板：MIMXRT11XX系列
• 固件版本：基于TinyUSB仓库a068b81674e8b47d6fb78ab6a06abb7decc2e644提交
• 参考示例：device/net_lwip_webserver

问题现象

开发者在使用NCM模式时遇到了以下具体问题：

1. Windows 11系统能够检测到名为"TinyUSB Network Interface"的驱动
2. 设备显示为"未启动"状态，错误代码0xC00000E5
3. 无法ping通开发板，也无法访问网页服务
4. 切换到ECM_RNDIS模式后，所有功能正常

技术分析

1. RTOS集成问题

开发者在项目中同时使用了lwIP和TinyUSB，并且都运行在RTOS环境下。这带来了几个关键的技术挑战：

• 在linkoutput_fn函数中，开发者用vTaskDelay(1)替代了tud_task()
• 在service_traffic处理中，使用tcpip_input替代了ethernet_input
• 当返回值不是ERR_OK时，没有执行pbuf_free操作

这些修改虽然使ECM模式正常工作，但在NCM模式下却出现了问题。

2. NCM缓冲区配置

经过多次测试，开发者发现NCM模式的正常工作与以下配置参数密切相关：

• CFG_TUD_NCM_IN_MAX_DATAGRAMS_PER_NTB
• CFG_TUD_NCM_OUT_MAX_DATAGRAMS_PER_NTB

当将这些值设置为1时，NCM模式可以正常工作。这表明在RTOS环境下，NCM模式对数据报的处理可能存在并发问题。

3. 数据接收流程

深入分析发现，在tud_network_xmit_cb回调中，每次只处理一个数据报，然后通过tud_network_recv_cb为这个数据报分配内存。这种设计在RTOS环境下可能导致性能问题和处理延迟。

解决方案

1. 参数优化配置

针对NCM模式在RTOS下的工作，建议采用以下配置：

#define CFG_TUD_NCM_IN_MAX_DATAGRAMS_PER_NTB  1
#define CFG_TUD_NCM_OUT_MAX_DATAGRAMS_PER_NTB 1
#define CFG_TUD_NCM_OUT_NTB_N                 2
#define CFG_TUD_NCM_IN_NTB_N                  2

这种配置减少了并发处理的数据报数量，降低了RTOS环境下的处理复杂度。

2. RTOS适配方案

对于需要在RTOS环境下使用NCM模式的开发者，可以考虑以下几种方案：

1. 非RTOS模式：如果不必须使用RTOS，可以考虑关闭TinyUSB的RTOS支持
2. 直接输入模式：修改service_traffic()实现，直接在tud_network_recv_cb()中将数据输入到lwIP
3. 批量处理模式：重写tud_network_recv_renew()，实现批量处理数据报

3. 使用网络粘合层代码

参考项目中提供的网络粘合层代码(net_glue.c)，这种实现方式专门为RTOS环境设计，能够更好地处理NCM模式下的数据流。

性能优化建议

对于已经能够工作但存在延迟的情况，可以考虑：

1. 适当增加缓冲区数量，但不宜过多
2. 优化RTOS任务优先级，确保网络任务有足够的执行时间
3. 检查内存分配策略，避免频繁的内存分配/释放操作

结论

TinyUSB的NCM模式在RTOS环境下确实存在一些特殊挑战，特别是与数据报处理和缓冲区管理相关的方面。通过合理的参数配置和适当的代码调整，可以解决大部分兼容性问题。对于性能要求较高的应用，建议参考专门为RTOS优化的网络粘合层实现方案。

开发者应当根据具体应用场景选择最适合的解决方案，并在实现过程中注意RTOS环境下资源竞争和任务调度带来的影响。