1. 项目背景与需求拆解1.1 为什么要在工控板子上折腾USB虚拟串口做过工控的朋友都清楚调试串口这东西平时用用UART转USB模块还行一旦设备封箱发到现场再想接个串口线就得拆机壳麻烦得很。尤其是那种安装在配电柜里的采集终端现场维护人员手里只有一根Type-C线你让他去找DB9串口线基本等于让他放弃。GD32H759这块片子是兆易创新出的高性能MCUCortex-M7内核主频能跑到600MHz带USB HS OTG控制器拿来做工控网关、数据采集终端非常合适。RT-Thread作为国产RTOS里生态比较完整的USB协议栈也相对成熟两者搭配算是当前工控圈子里比较主流的方案。这个项目的核心目标很明确在GD32H759上跑RT-Thread把USB设备控制器配置成CDC ACM类设备插到电脑上直接识别成一个虚拟串口COM口不需要额外装驱动拿来就能收发数据。这样一来现场调试、固件升级、日志输出都可以走这一根USB线省事不少。适合谁来参考这篇内容如果你已经能在GD32H759上跑通RT-Thread的基本任务调度对USB协议有一点点概念但没实际做过CDC ACM那这篇就是写给你的。如果你连RT-Thread的线程怎么创建都还不熟建议先把基础过一遍再来看USB部分不然容易卡在中间。1.2 CDC ACM到底是什么工控场景下能解决哪些实际问题CDC ACM全称是Communication Device Class - Abstract Control Model翻译过来就是通信设备类-抽象控制模型。说人话就是让USB设备模拟成一个传统的串口。电脑那边看到的是一个COM口你用什么串口助手、SecureCRT、Putty都能直接打开跟操作真实串口一模一样。工控场景下这个功能的价值主要体现在几个方面。第一是现场调试设备装到现场后维护人员拿笔记本插上USB线就能看日志、发命令不用拆机接串口线。第二是参数配置很多工控设备需要现场改参数用虚拟串口配合上位机软件比按键数码管的方式效率高太多。第三是固件升级通过虚拟串口传固件包比拆机接JTAG方便得多。第四是数据回传有些场景下设备不需要走485或者以太网直接USB连工控机就能传数据。还有一点容易被忽略USB CDC ACM的带宽比普通UART高得多。GD32H759的USB HS控制器理论速率480Mbps实际跑CDC ACM也能到几MB/s传大量日志或者采集数据的时候优势明显。当然工控场景一般用不到这么高带宽但留着余量总不是坏事。1.3 整体方案选型与框架设计方案上其实没太多纠结的地方。RT-Thread自带了USB Device协议栈里面已经实现了CDC ACM类我们只需要做三件事配置USB外设时钟和引脚、把RT-Thread的USB协议栈移植到GD32H759上、编写CDC ACM的接口代码。框架上分三层来看。最底层是GD32H759的USB HS/FS控制器硬件负责物理层和链路层。中间层是RT-Thread的USB Device Core处理USB标准请求、设备枚举、端点管理。最上层是CDC ACM Class Driver实现串口的数据收发接口对上层应用暴露成RT-Thread的设备节点比如/dev/ttyACM0。应用层就简单了直接像操作普通串口一样用rt_device_open、rt_device_read、rt_device_write这些标准接口就行。这种分层设计的好处是应用代码跟USB细节完全解耦以后换成别的USB类比如MSC或者HID应用层改动很小。注意GD32H759有两个USB控制器一个是USB FS全速12Mbps一个是USB HS高速480Mbps。做CDC ACM用FS就够了HS虽然快但PCB布线要求高差分线要走90欧姆阻抗一般工控板子没必要上HS。2. 硬件与软件环境准备2.1 硬件连接与引脚分配要点GD32H759的USB FS控制器引脚是固定的DMD-和DPD分别在PA11和PA12上。这两个引脚不能随便改硬件设计的时候就要确定好。如果用的是USB HS引脚在PB14和PB15上但HS还需要外接ULPI PHY芯片电路复杂不少。VBUS检测这块要注意。USB设备作为从设备的时候理论上需要检测VBUS是否有效但很多简化设计直接忽略这个靠软件延时来等枚举。我建议还是加上VBUS检测用一个分压电阻把5V降到3.3V以内接到某个GPIO上这样插拔USB的时候软件能及时响应。不加的话有时候会出现设备已经拔了但软件还在等数据的情况。还有一个容易踩的坑USB的DP上拉电阻。全速设备需要在DP上加1.5k上拉电阻告诉主机我是全速设备高速设备则在DM上加。GD32H759内部已经集成了这个上拉电阻可以通过寄存器控制不需要外部再加。但如果你画板子的时候手抖加了外部上拉可能会导致枚举异常这个要检查一下原理图。2.2 RT-Thread工程配置与USB协议栈裁剪RT-Thread的工程配置用menuconfig来做。进入RT-Thread Components - Device Drivers - USB把USB Device打开然后选上CDC ACM类。这里有个细节RT-Thread的USB协议栈分Device和Host两部分我们只需要DeviceHost那部分可以关掉省空间。# 在工程根目录下执行 scons --menuconfig # 配置路径 RT-Thread Components - Device Drivers - USB - [*] USB Device - [*] Enable USB Device CDC ACM配置完之后要检查几个宏定义。RT_USING_USB_DEVICE必须打开RT_USB_DEVICE_CDC必须打开RT_USB_DEVICE_CDC_ACM也要打开。另外RT_USING_HEAP建议打开因为USB协议栈内部会动态申请内存。如果堆空间不够枚举过程中可能会失败这个后面排查问题的时候会详细说。时钟配置方面USB FS需要48MHz时钟。GD32H759的USB时钟来源可以是PLL或者外部晶振一般用PLL分频得到。在RT-Thread的时钟初始化代码里要确保USB时钟使能否则USB控制器根本不工作。这个在board.c里改具体寄存器操作参考GD32H759的用户手册。2.3 驱动文件结构与关键宏定义RT-Thread的USB Device驱动在drivers/usb/目录下核心文件包括usb_device.c设备核心、usb_cdc.cCDC类驱动、usb_cdc_acm.cACM子类。GD32H759的USB底层驱动需要自己写或者找现成的主要实现USB控制器的初始化、端点配置、中断处理这几个函数。关键宏定义在rtconfig.h里我列一下必须确认的宏定义作用建议值RT_USING_USB_DEVICE启用USB设备协议栈必须打开RT_USB_DEVICE_CDC启用CDC类必须打开RT_USB_DEVICE_CDC_ACM启用ACM子类必须打开RT_USB_DEVICE_CDC_ACM_RX_BUFSIZE接收缓冲区大小512或1024RT_USB_DEVICE_CDC_ACM_TX_BUFSIZE发送缓冲区大小512或1024RT_USB_DEVICE_CDC_ACM_MAX_PACKET_SIZE端点最大包长FS下64HS下512缓冲区大小要根据实际数据量来定。如果只是传日志512字节够了。如果要传采集数据建议1024以上。但注意RT-Thread的USB协议栈用的是静态内存池缓冲区开太大占RAMGD32H759虽然有1MB RAM但也要省着用。3. USB CDC ACM核心实现细节3.1 USB描述符配置与枚举过程解析USB设备枚举是整个通信的基础枚举不成功后面什么都白搭。枚举过程简单说就是主机复位设备 - 主机读设备描述符 - 主机分配地址 - 主机读配置描述符 - 主机读字符串描述符 - 主机选择配置 - 枚举完成。CDC ACM的描述符比普通HID复杂一些因为它是一个复合设备包含两个接口一个是通信接口Communication Interface一个是数据接口Data Interface。通信接口用来传控制命令数据接口用来传实际数据。每个接口下面还有端点通信接口用中断端点数据接口用批量端点。描述符的结构在usb_cdc_acm.c里定义关键字段包括bDeviceClassCDC设备的设备类一般填0x02Communication Device ClassbInterfaceClass接口类通信接口填0x02数据接口填0x0AbInterfaceSubClass子类ACM填0x02bInterfaceProtocol协议ACM填0x01AT命令或者0x00厂商自定义字符串描述符里有个iSerialNumber字段这个可以填也可以不填。填了的话每台设备的序列号不一样电脑会记住这个设备。不填的话每次插拔可能分配不同的COM口。工控场景建议填上方便上位机固定端口号。实操心得描述符里的wMaxPacketSize字段全速设备批量端点最大64字节高速设备最大512字节。如果你填错了枚举可能会失败或者通信不稳定。我遇到过填了512但实际是FS的情况电脑能识别但一发大数据就丢包。3.2 端点配置与数据收发机制CDC ACM用了三个端点一个中断输入端点EP1 IN、一个批量输入端点EP2 IN、一个批量输出端点EP2 OUT。中断端点用来传串口控制信号比如波特率设置、DTR/RTS状态批量端点用来传实际数据。端点的配置在USB控制器初始化的时候完成。GD32H759的USB FS控制器有4个双向端点每个端点可以配置成控制、中断、批量、同步四种类型。CDC ACM需要配置EP1为中断类型EP2为批量类型。数据收发的机制是这样的主机发数据下来USB控制器收到后触发OUT端点中断中断服务程序把数据搬到接收缓冲区然后通知上层应用有数据可读。应用调用rt_device_read的时候从接收缓冲区里取数据。发送方向反过来应用调用rt_device_write把数据写到发送缓冲区USB协议栈在合适的时机把数据通过IN端点发出去。这里有个关键点USB批量传输不是实时性的主机什么时候来取数据取决于主机的调度。所以发送缓冲区要足够大不然应用写太快会丢数据。RT-Thread的CDC ACM驱动里有个发送完成回调可以在回调里通知应用可以继续发了。/* 接收回调示例 */ static rt_err_t cdc_acm_rx_callback(rt_device_t dev, rt_size_t size) { /* 通知应用线程有数据到达 */ rt_sem_release(rx_sem); return RT_EOK; } /* 应用层读取数据 */ rt_size_t read_len rt_device_read(dev, 0, buf, sizeof(buf)); if (read_len 0) { /* 处理数据 */ }3.3 串口参数动态配置的实现CDC ACM的一个优势是可以通过USB控制端点动态设置串口参数比如波特率、数据位、停止位、校验位。虽然虚拟串口的波特率实际上不影响USB传输速率但很多上位机软件会先发一个设置波特率的命令如果不响应可能会报错。RT-Thread的CDC ACM驱动里已经实现了SET_LINE_CODING请求的处理收到这个请求后会解析出波特率等参数保存在一个结构体里。应用层可以通过一个自定义的接口来读取这些参数或者注册一个回调函数参数变化的时候被通知。/* 线路编码结构体 */ struct cdc_line_coding { uint32_t dwDTERate; /* 波特率 */ uint8_t bCharFormat; /* 停止位0-1位1-1.5位2-2位 */ uint8_t bParityType; /* 校验0-无1-奇2-偶 */ uint8_t bDataBits; /* 数据位5-8 */ }; /* 获取当前线路编码 */ rt_err_t cdc_acm_get_line_coding(rt_device_t dev, struct cdc_line_coding *coding);实际用的时候我一般会在应用层注册一个回调当上位机修改波特率的时候把新的波特率打印出来方便调试。虽然虚拟串口不关心波特率但知道上位机设了多少对排查问题有帮助。3.4 与RT-Thread设备框架的对接RT-Thread的设备框架用rt_device结构体来抽象所有设备CDC ACM也不例外。驱动初始化的时候会调用rt_device_register把设备注册到系统里设备名一般是ttyACM0或者vcom。注册之后应用层就可以用标准接口来操作了/* 查找设备 */ rt_device_t dev rt_device_find(ttyACM0); if (dev RT_NULL) { rt_kprintf(find ttyACM0 failed\n); return; } /* 打开设备以读写方式 */ rt_device_open(dev, RT_DEVICE_OFLAG_RDWR | RT_DEVICE_FLAG_INT_RX); /* 设置接收回调 */ rt_device_set_rx_indicate(dev, cdc_acm_rx_callback); /* 发送数据 */ rt_device_write(dev, 0, send_buf, send_len); /* 接收数据 */ rt_device_read(dev, 0, recv_buf, sizeof(recv_buf));这里有个细节打开设备的时候要指定RT_DEVICE_FLAG_INT_RX这样接收数据的时候才会触发回调。如果不指定就只能用轮询方式读效率低很多。另外RT_DEVICE_OFLAG_RDWR表示以读写方式打开如果只需要发送可以只写RT_DEVICE_OFLAG_WRONLY。注意rt_device_read的第二个参数是偏移量对串口设备来说这个参数没用填0就行。第三个参数是缓冲区指针第四个是期望读取的长度。返回值是实际读到的字节数如果返回0表示没有数据。4. 实操过程与关键环节实现4.1 从零搭建工程的完整步骤第一步准备基础工程。如果你已经有GD32H759跑RT-Thread的工程直接在上面改就行。如果没有建议先用RT-Thread Studio或者MDK创建一个基础工程确保LED能闪、串口能打印再往上加USB功能。第二步配置RT-Thread。用menuconfig打开USB Device和CDC ACM保存配置后重新生成工程。这一步会往rtconfig.h里加宏定义往工程里加USB相关的源文件。第三步添加GD32H759的USB底层驱动。RT-Thread的USB协议栈需要底层驱动提供几个接口函数usb_dcd_init、usb_dcd_deinit、usb_dcd_ep_set_stall、usb_dcd_ep_clear_stall、usb_dcd_ep_write、usb_dcd_ep_read等。这些函数需要根据GD32H759的USB控制器寄存器来实现。/* USB底层驱动接口示例 */ static const struct usb_dcd_ops gd32_usb_ops { .init gd32_usb_init, .deinit gd32_usb_deinit, .ep_set_stall gd32_usb_ep_set_stall, .ep_clear_stall gd32_usb_ep_clear_stall, .ep_write gd32_usb_ep_write, .ep_read gd32_usb_ep_read, };第四步初始化USB设备。在应用初始化代码里调用rt_usb_device_init传入CDC ACM的配置参数。这个函数会初始化USB控制器、注册CDC ACM设备、启动USB协议栈。/* USB设备初始化 */ rt_usb_device_init(cdc_acm_config);第五步编写应用代码。查找设备、打开设备、注册回调、收发数据。这部分跟操作普通串口几乎一样没什么特别的。4.2 关键配置参数的计算与选择USB时钟配置是第一个要算的。GD32H759的USB FS需要48MHz时钟这个时钟可以从PLL分频得到。假设系统时钟是600MHzPLL分频系数要设置成600/4812.5不是整数所以不能直接用系统时钟分频。一般做法是用PLL的某个输出专门给USB比如PLLQ输出48MHz。端点缓冲区大小也要算。CDC ACM用了三个端点每个端点的缓冲区大小要跟wMaxPacketSize匹配。全速设备批量端点最大64字节所以EP2的缓冲区至少64字节。中断端点最大64字节EP1的缓冲区也至少64字节。实际分配的时候一般会留余量比如EP1给64字节EP2给128字节。接收和发送缓冲区的大小要根据应用场景来定。如果只是传调试日志512字节足够。如果要传文件或者大量采集数据建议2048以上。但要注意RT-Thread的USB协议栈用的是静态内存池缓冲区开太大占RAM。GD32H759有1MB RAM开个几KB的缓冲区问题不大。参数计算依据推荐值USB时钟必须48MHzPLLQ输出48MHzEP1缓冲区中断端点最大包长64字节EP2缓冲区批量端点最大包长128字节接收缓冲区应用数据量1024字节发送缓冲区应用数据量1024字节4.3 枚举失败的排查过程实录枚举失败是最常见的问题表现是插上USB线电脑没反应或者提示未知USB设备。排查的时候按以下顺序来先看硬件。用万用表量DM和DP的电压正常情况下一根是3.3V左右上拉一根是0V。如果两根都是0V说明USB控制器没工作检查时钟和电源。如果两根都是3.3V说明上拉电阻有问题。再看时钟。用示波器量USB时钟引脚应该是48MHz。如果没有时钟检查PLL配置和USB时钟使能位。GD32H759的USB时钟使能在RCU_USBFS寄存器里这个别忘了。然后看描述符。用USB分析仪抓包看主机发了什么请求设备回了什么。如果没有分析仪可以在USB中断里打印调试信息看枚举走到哪一步失败了。常见的问题是描述符长度不对、端点地址冲突、配置描述符里的接口数量跟实际不符。最后看内存。RT-Thread的USB协议栈在枚举过程中会动态申请内存如果堆空间不够枚举会失败。可以在rtconfig.h里把RT_USING_HEAP打开把堆大小调大一些。我遇到过堆只剩几百字节的情况枚举到一半就挂了调大堆之后就好了。实操心得枚举失败的时候先别急着改代码用USB分析仪抓个包看看主机和设备之间的交互。很多时候问题很明显比如设备返回的描述符长度是0或者STALL了不该STALL的请求。没有分析仪的话在USB中断里加打印也能看出大概。4.4 数据收发稳定性测试与优化枚举成功之后下一步是测试数据收发的稳定性。我的测试方法是上位机用串口助手每隔10ms发一包256字节的数据连续发10万包看MCU这边收到多少、有没有丢包。同时MCU这边也定期往上位机发数据看上位机能不能完整收到。测试过程中发现几个问题。第一个是发送太快会丢数据原因是发送缓冲区满了之后rt_device_write直接返回0应用层没处理这个返回值。解决办法是在应用层加个信号量发送完成回调里释放信号量应用层等信号量再发下一包。第二个问题是接收数据太多的时候接收回调触发太频繁影响其他线程运行。解决办法是加大接收缓冲区让USB中断一次多搬点数据减少回调次数。RT-Thread的CDC ACM驱动里有个RT_USB_DEVICE_CDC_ACM_RX_BUFSIZE宏调大这个值就行。第三个问题是长时间运行后偶尔会断连。排查发现是USB中断优先级配置不对被其他高优先级中断打断了。解决办法是把USB中断优先级设成中等既不能太高影响系统调度也不能太低被其他中断阻塞。/* 发送完成回调 */ static rt_err_t cdc_acm_tx_callback(rt_device_t dev, void *buffer) { rt_sem_release(tx_sem); return RT_EOK; } /* 应用层发送线程 */ void tx_thread_entry(void *param) { while (1) { rt_sem_take(tx_sem, RT_WAITING_FOREVER); rt_device_write(dev, 0, buf, len); } }5. 常见问题与排查技巧实录5.1 电脑识别不到COM口的几种原因电脑识别不到COM口原因可能出在硬件、固件、驱动三个层面。硬件层面先检查USB线是不是只能充电不能传数据的那种这种线插上电脑完全没反应。再检查DM/DP有没有接反虽然USB协议里DM是D-、DP是D但有些板子丝印标反了实际接的时候要对着原理图确认。固件层面最常见的是描述符配置错误。比如bDeviceClass填了0xFF厂商自定义但实际实现的是CDC类电脑就不知道加载什么驱动。或者配置描述符里的接口数量跟实际不符电脑枚举到一半就失败了。还有一种情况是设备描述符里的bMaxPacketSize0填错了全速设备控制端点最大包长是8、16、32、64填错了枚举会失败。驱动层面Windows 10及以上版本自带CDC ACM驱动插上就能识别。但有些精简版系统或者老版本Windows可能没有需要手动装。Linux和macOS一般自带cdc_acm驱动插上就能用。如果电脑能识别到设备但没分配COM口可以在设备管理器里看看有没有黄色感叹号有的话就是驱动问题。现象可能原因排查方法完全没反应USB线问题、供电问题换线、量电压提示未知设备描述符错误USB分析仪抓包有设备无COM口驱动问题设备管理器查看COM口时有时无接触不良、VBUS检测检查连接器、加VBUS检测5.2 数据丢包的定位与解决思路数据丢包分两种情况接收丢包和发送丢包。接收丢包一般是接收缓冲区太小USB中断搬数据的时候缓冲区满了新数据覆盖旧数据。解决办法是加大接收缓冲区或者在接收回调里尽快把数据读走。发送丢包一般是应用层写太快发送缓冲区满了之后rt_device_write返回0应用层没处理这个返回值继续写就丢了。解决办法是在应用层加流控发送完成回调里释放信号量应用层等信号量再发下一包。还有一种丢包是USB主机调度导致的。USB批量传输不是实时性的主机可能隔一段时间才来取一次数据。如果设备发送缓冲区满了主机还没来取新数据就发不出去。这种情况只能加大发送缓冲区或者降低应用层发送速率。/* 带流控的发送函数 */ rt_size_t cdc_acm_send(rt_device_t dev, void *buf, rt_size_t len) { rt_size_t sent 0; while (sent len) { rt_size_t ret rt_device_write(dev, 0, (char *)buf sent, len - sent); if (ret 0) { /* 发送缓冲区满等待发送完成 */ rt_sem_take(tx_sem, RT_WAITING_FOREVER); } else { sent ret; } } return sent; }5.3 长时间运行断连的排查记录长时间运行断连是个比较头疼的问题表现是设备跑几个小时或者几天后USB突然断开电脑提示设备已拔出。重新插拔USB线又能恢复但过一段时间又断。排查这种问题先看电源。USB供电不稳会导致设备复位尤其是工控现场电源波动大的时候。可以在VBUS上加个大电容或者用外部供电。再看USB中断优先级如果USB中断被其他高优先级中断长时间阻塞主机可能会认为设备无响应而断开。把USB中断优先级调到中等既不影响系统调度也不被其他中断阻塞。还有一种情况是RT-Thread的USB协议栈内部状态机卡死。这个比较难排查可以在USB中断里加个计数器看断连的时候中断还在不在触发。如果不触发了说明控制器挂了需要复位USB控制器。如果还在触发但状态不对可能是协议栈的问题需要看RT-Thread的USB协议栈源码。我遇到过一次断连是因为堆内存碎片化。USB协议栈在运行过程中会动态申请和释放内存长时间运行后堆碎片化申请不到连续内存就挂了。解决办法是用静态内存池代替动态申请或者定期重启USB设备。5.4 与上位机通信协议对接的注意事项CDC ACM只是提供了物理层的串口通信实际的数据格式和协议要靠应用层来定义。跟上位机对接的时候有几个地方要注意。第一是数据帧格式。工控场景一般用二进制协议帧头、长度、命令字、数据、校验和。帧头要选不容易跟数据混淆的值比如0xAA55或者0xEB90。长度字段要明确是包含帧头还是不包含校验和用CRC16还是累加和这些都要跟上位机约定好。第二是超时处理。上位机发命令下来设备要在规定时间内回复超时上位机会重发。设备这边要处理好重发的情况避免重复执行命令。可以在命令里加个序列号设备记录最近处理的序列号重复的序列号直接忽略。第三是流控。如果数据量大要考虑流控机制。CDC ACM支持硬件流控RTS/CTS但虚拟串口一般不用。可以用软件流控比如XON/XOFF或者自定义的流控命令。我一般是在协议里加个准备好命令上位机收到之后才发下一包。/* 简单的帧格式定义 */ typedef struct { uint16_t header; /* 帧头 0xAA55 */ uint16_t length; /* 数据长度 */ uint8_t cmd; /* 命令字 */ uint8_t data[256]; /* 数据 */ uint16_t crc; /* CRC16校验 */ } frame_t; /* 解析帧 */ int parse_frame(uint8_t *buf, int len, frame_t *frame) { if (len 7) return -1; /* 最小帧长 */ if (buf[0] ! 0xAA || buf[1] ! 0x55) return -1; /* 帧头不对 */ frame-length buf[2] | (buf[3] 8); if (len frame-length 7) return -1; /* 数据不够 */ /* 校验CRC */ uint16_t crc buf[frame-length 5] | (buf[frame-length 6] 8); if (crc ! calc_crc16(buf, frame-length 5)) return -1; /* 解析成功 */ frame-cmd buf[4]; memcpy(frame-data, buf[5], frame-length); return frame-length 7; }6. 性能优化与进阶玩法6.1 提高USB传输速率的几个手段CDC ACM的传输速率受限于几个因素USB速度等级、端点缓冲区大小、主机调度间隔、应用层处理速度。全速USB理论12Mbps实际批量传输能到1MB/s左右。高速USB理论480Mbps实际能到30MB/s以上。提高速率的手段第一是改用高速USB。GD32H759支持USB HS但需要外接ULPI PHY硬件成本高一些。如果应用确实需要高带宽比如传图像或者大量采集数据上HS是值得的。第二是加大端点缓冲区。全速设备批量端点最大64字节这个改不了。但高速设备可以到512字节一次传输的数据量更大效率更高。第三是优化应用层处理。接收回调里不要做耗时操作尽快把数据读走。发送的时候尽量一次发大包不要频繁发小包。USB协议栈有开销包越小效率越低。第四是调整主机调度。这个在设备端控制不了但可以在上位机软件里设置。比如Windows的串口驱动有个延迟定时器默认16ms可以改小到1ms提高响应速度。优化手段预期效果实施难度改用USB HS速率提升10倍以上高需要改硬件加大端点缓冲区速率提升20%左右低改配置即可优化应用层速率提升取决于瓶颈中需要调代码调整主机调度延迟降低低改上位机设置6.2 多路虚拟串口的实现思路有些工控场景需要多个虚拟串口比如一个用来调试一个用来传数据一个用来升级固件。CDC ACM支持在一个USB设备里实现多个通信接口也就是多路虚拟串口。实现思路是在配置描述符里定义多个接口每个接口对应一个CDC ACM功能。RT-Thread的USB协议栈支持复合设备但需要自己组织描述符。每个接口有自己的端点互不干扰。应用层会看到多个设备节点比如/dev/ttyACM0、/dev/ttyACM1。/* 多路CDC ACM配置 */ #define CDC_ACM_NUM 2 static struct cdc_acm_config acm_config[CDC_ACM_NUM] { { .device_name ttyACM0, .rx_bufsize 1024, .tx_bufsize 1024, }, { .device_name ttyACM1, .rx_bufsize 1024, .tx_bufsize 1024, }, };多路虚拟串口的难点在描述符的组织。USB描述符是嵌套结构配置描述符下面有接口描述符接口描述符下面有端点描述符。多个CDC ACM功能的话描述符会很长要仔细计算每个描述符的长度和偏移。建议用工具生成描述符或者参考RT-Thread的复合设备例程。6.3 与固件升级功能的结合虚拟串口用来做固件升级是个很实用的场景。设备出厂后现场维护人员拿USB线插上用上位机软件把新固件通过虚拟串口传进去设备收到后写到Flash里重启生效。实现思路是定义一个简单的升级协议。上位机先发一个进入升级模式的命令设备收到后跳转到Bootloader或者进入升级状态。然后上位机分块发送固件数据每块带个序号和CRC设备收到后校验并写入Flash。全部发完后上位机发升级完成命令设备校验整个固件然后重启。/* 固件升级状态机 */ typedef enum { OTA_IDLE, /* 空闲 */ OTA_START, /* 收到开始命令 */ OTA_RECEIVING, /* 接收数据中 */ OTA_VERIFY, /* 校验固件 */ OTA_DONE, /* 升级完成 */ } ota_state_t; /* 处理升级命令 */ void ota_process(uint8_t *data, uint16_t len) { switch (ota_state) { case OTA_IDLE: if (data[0] OTA_CMD_START) { ota_state OTA_START; ota_offset 0; /* 擦除Flash */ flash_erase(OTA_FLASH_ADDR, OTA_FLASH_SIZE); } break; case OTA_START: if (data[0] OTA_CMD_DATA) { /* 写入数据 */ flash_write(OTA_FLASH_ADDR ota_offset, data[1], len - 1); ota_offset len - 1; ota_state OTA_RECEIVING; } break; case OTA_RECEIVING: if (data[0] OTA_CMD_DATA) { flash_write(OTA_FLASH_ADDR ota_offset, data[1], len - 1); ota_offset len - 1; } else if (data[0] OTA_CMD_END) { ota_state OTA_VERIFY; /* 校验固件 */ if (verify_firmware(OTA_FLASH_ADDR, ota_offset)) { ota_state OTA_DONE; /* 设置升级标志重启后跳转到新固件 */ set_ota_flag(); rt_hw_cpu_reset(); } else { ota_state OTA_IDLE; } } break; default: break; } }升级功能有几个要注意的地方。第一是Flash分区Bootloader和Application要分开升级的时候写Application区不影响Bootloader。第二是断电保护升级过程中断电的话下次上电要能恢复到升级前的状态。第三是固件校验CRC或者SHA256确保固件完整。6.4 低功耗场景下的USB唤醒处理工控设备有些是电池供电的需要低功耗。USB设备在挂起状态下电流要小于2.5mA这个对低功耗设计很重要。GD32H759的USB控制器支持挂起和唤醒主机不发数据的时候设备进入挂起状态有数据的时候唤醒。挂起检测是通过USB中断里的挂起标志位来判断的。检测到挂起后把USB时钟关掉CPU进入低功耗模式。唤醒的时候USB控制器会产生一个唤醒中断CPU退出低功耗模式重新初始化USB时钟。/* USB挂起处理 */ void usb_suspend_handler(void) { /* 关闭USB时钟 */ rcu_periph_clock_disable(RCU_USBFS); /* 进入低功耗模式 */ pmu_to_deepsleepmode(PMU_LDO_LOWPOWER, WFI_CMD); } /* USB唤醒处理 */ void usb_wakeup_handler(void) { /* 重新使能USB时钟 */ rcu_periph_clock_enable(RCU_USBFS); /* 重新初始化USB */ usb_device_reinit(); }低功耗场景下还有个细节VBUS检测。如果设备是自供电的USB拔掉之后VBUS没了设备要能检测到并进入低功耗。如果设备是USB供电的拔掉USB就断电了不用考虑这个。注意进入低功耗之前要确保USB数据传输完成不然会丢数据。可以在挂起中断里等发送缓冲区空了再进低功耗。另外唤醒之后要重新枚举主机可能会重新分配地址这个要有心理准备。7. 实际项目中的经验总结7.1 硬件设计阶段的避坑指南硬件设计阶段有几个坑我踩过这里分享一下。第一个是USB差分线的阻抗控制。全速USB虽然速率不高但差分线还是要按90欧姆阻抗走不然信号质量差枚举可能失败。走线尽量短不要有过孔远离高频信号线。第二个是VBUS检测电路。如果要做VBUS检测分压电阻要选好确保3.3V以内。我见过用10k和20k分压的5V进来变成3.3V刚好在GPIO的耐压范围内。但要注意GPIO要配置成浮空输入不要开内部上拉不然分压比例会变。第三个是ESD保护。USB接口经常插拔ESD保护器件不能省。一般用TVS二极管放在连接器附近走线要短。没有ESD保护的话冬天静电一打USB控制器可能就挂了。第四个是电源滤波。USB的5V电源要加滤波电容一般100nF和10uF并联。如果设备对电源噪声敏感还可以加个磁珠或者电感。我遇到过USB供电噪声导致ADC采样不准的情况加了滤波之后就好了。7.2 软件架构的分层与解耦软件架构上我建议把USB CDC ACM驱动和应用逻辑分开。驱动层只负责数据收发不关心数据内容。应用层负责协议解析和业务逻辑。两层之间用消息队列或者信号量来通信不要直接在中断里处理业务。/* 驱动层接收回调只负责把数据放到消息队列 */ static rt_err_t cdc_acm_rx_callback(rt_device_t dev, rt_size_t size) { uint8_t buf[256]; rt_size_t len rt_device_read(dev, 0, buf, sizeof(buf)); if (len 0) { rt_mq_send(usb_mq, buf, len); } return RT_EOK; } /* 应用层从消息队列取数据处理业务 */ void app_thread_entry(void *param) { uint8_t buf[256]; while (1) { rt_size_t len rt_mq_recv(usb_mq, buf, sizeof(buf), RT_WAITING_FOREVER); if (len 0) { process_data(buf, len); } } }这种分层的好处是驱动层改动不影响应用层应用层改动也不影响驱动层。以后如果换成USB HS或者别的通信方式应用层几乎不用改。7.3 调试手段与工具链推荐调试USB问题有几个工具很有用。第一个是USB分析仪能抓USB总线上的所有数据包枚举过程、数据传输都能看到。价格从几百到几万不等预算够的话建议买一个排查问题效率高很多。第二个是串口打印。在USB中断和协议栈的关键位置加打印能看到枚举走到哪一步、数据收发是否正常。但要注意打印不能太频繁不然会影响USB时序。可以用一个环形缓冲区把打印信息存起来事后分析。第三个是逻辑分析仪。量DM/DP的信号质量看眼图是否张开有没有过冲或者振铃。全速USB虽然速率不高但信号质量差的话也会导致枚举失败。第四个是RT-Thread的msh命令行。可以在msh里加一些调试命令比如查看USB状态、复位USB设备、打印描述符等。调试的时候很方便不用重新烧固件。工具用途价格区间USB分析仪抓USB数据包几百到几万逻辑分析仪量信号质量几百到几千串口打印看软件流程免费msh命令行在线调试免费7.4 从单机调试到批量生产的经验单机调试通过之后批量生产的时候还会遇到新问题。第一个是器件一致性不同批次的USB连接器、晶振、TVS管参数可能有差异导致部分板子枚举失败。解决办法是留足够的余量比如晶振精度选±20ppm以内的TVS管选低容值的。第二个是生产测试。每台设备出厂前要测USB功能可以写个自动化测试脚本插上USB后自动枚举、收发数据、校验结果。测试不通过的板子要标记出来分析原因。第三个是固件版本管理。批量生产的时候固件版本要统一不能有的板子跑旧版本有的跑新版本。建议在固件里加个版本号通过虚拟串口可以查询方便追溯。第四个是现场问题处理。设备发到现场后如果USB功能出问题维护人员不一定有调试工具。可以在固件里加个自检功能通过虚拟串口发个命令设备自己检查USB状态并返回结果。这样维护人员不用拆机就能初步判断问题。实操心得批量生产的时候我一般会做一个小工具插上USB后自动读取设备信息、测试收发、记录结果。测试数据存到数据库里方便追溯。这个工具用Python写就行pyserial库操作串口很简单。7.5 后续功能扩展的方向CDC ACM做完之后还可以往上加功能。第一个是复合设备把CDC ACM和MSC大容量存储做在一起设备既能当串口用又能当U盘用。现场维护的时候插上USB既能调试又能拷日志很方便。第二个是WebUSB通过浏览器直接跟设备通信不用装上位机软件。这个需要设备支持USB DFU或者自定义类实现起来复杂一些但用户体验好。第三个是USB转以太网用CDC ECM或者RNDIS类设备通过USB虚拟成一个网卡。工控场景下有些设备没有以太网口通过USB转以太网可以接入网络。第四个是USB音频用UAC类设备虚拟成声卡。这个在工控场景下用得少但在消费电子里很常见。这些扩展方向都需要对USB协议有更深入的理解建议先把CDC ACM做稳定再考虑往上加功能。USB协议栈的代码量不小改的时候要小心别把原来的功能改坏了。