STM32F407 USB Host直连4G模块：从硬件设计到AT指令状态机实战

很多时候我接到物联网项目的需求，看到板子上明明是一颗STM32F407，主控连4G模块却还在用老一套：MCU的UART接一颗CH340或者CP2102之类的USB转串口芯片，再把这颗芯片的USB口插到4G模块上，或者干脆是模块的USB口被当成一个“串口”来用。这颗USB转串口芯片好像成了约定俗成的标配，很少有人质疑它到底该不该出现。实际上STM32F407自带完整的USB OTG外设，完全可以以USB Host的身份直接和广和通MC665这种LTE Cat4模块建立USB链路，AT指令走USB CDC虚拟串口，既省掉中间那颗芯片，又能拿到比UART高得多的带宽余量。这篇文章就把我从硬件设计、枚举调试到AT状态机落地的全过程记录下来，给正在做4G透传、DTU、远程维护设备这类项目的工程师一个可以直接参考的路线。

1. 为什么放弃USB转串口芯片，直连4G模块的一切理由

1.1 一条看似合理但实际鸡肋的传统链路

很多开发板原理图上画的是：MCU UART的TX/RX接到一颗USB转串口芯片，这颗芯片再通过USB口连到4G模块。这个方案的初衷是让PC机能通过USB口直接配置模块，或者让MCU“借用”USB物理层传输数据。但放在真正的产品里，这条链路的问题很明显。

首先是BOM成本。USB转串口芯片本身不贵，但配套的晶振、去耦电容、ESD防护、PCB面积摆在那里，加起来就不止几块钱了。对于量产设备，这几块钱和几十平方毫米的板面积都是实打实的成本。

其次是速率天花板。UART链路再快也就是921600bps，而USB Full Speed的12Mbps理论值摆在那里，实际上CDC Bulk端点的吞吐能做到1MB/s左右。4G模块Cat4的下行速率可以到150Mbps，如果用UART承载网络数据，模块能力再强也吐不出来。

第三是可靠性。UART没有校验重传机制，波特率存在晶振误差时，长时间大数据传输偶发错字节是家常便饭。USB协议自带CRC校验和重传，底层的可靠性根本不需要应用层操心。

第四是电源和信号匹配的麻烦。UART电平可能3.3V、1.8V不匹配，USB则是标准电平，不用管模块的串口电平域。

1.2 直连方案带来的是量变还是质变

把STM32F407的USB Host直接对接MC665模块的USB口，本质上是用USB协议替代UART承载AT指令和数据。在AT指令这种低频小数据量的场景下，两者体感差别不大，但在网络数据业务上差别就非常明显。

USB枚举完成后，模块呈现给主控的是一个符合CDC ACM规范的虚拟串口设备。主控不需要配置波特率，不需要管RTS/CTS，不需要关心奇偶校验，只需要向Bulk端点读写数据。这些原本USB转串口芯片要做的“脏活累活”，模块自己已经在内部处理了。

我自己体会最深的点是，省掉USB转串口芯片之后，整条通信链路的“中间人”少了一个，出问题时排查链路也短了一截。以前数据乱了，要判断是MCU侧波特率配错、还是USB转串口芯片驱动问题、还是模块串口缓冲溢出，现在直接面对USB协议层的错误返回，问题定位清晰得多。

1.3 谁适合用谁不适合用

这个方案并不是所有场景都值得上。如果只是开发原型、临时调个AT指令，随便找一个USB转串口小板捅到PC上反而更省事。但如果目标是大批量产品、对BOM成本敏感、需要稳定高速的模块通信链路，或者想在模块串口上外接其他低速传感器，那么USB Host直连就是更优解。

特别提醒一点：如果打算用USB跑RNDIS/ECM网卡数据，也就是把模块抽象成一个以太网接口，那么STM32F407内置的Full Speed PHY会变成瓶颈。那场景就需要外接USB3300这类ULPI高速PHY，这就是另一套硬件设计了。本篇文章默认的痛点是AT指令通信和透传业务，Full Speed足够。

2. STM32F407 USB Host硬件链路：从PHY选型到USB座接线

2.1 先想清楚走全速还是高速

STM32F407有两个USB外设：OTG_FS自带Full Speed PHY，引脚固定在PA11/PA12；OTG_HS默认需要外部ULPI PHY才能跑480Mbps高速，但它也可以配置成使用内部Full Speed PHY，引脚切到PB14/PB15。

决定用哪个外设、要不要外接PHY，是整个项目最开始就要定的。我的选择是走Full Speed，也就是12Mbps，原因有三个：

1. 广和通MC665是USB 2.0 High Speed设备，但USB规范要求HS设备必须兼容Full Speed，主机全速枚举时设备会以Full Speed模式工作。实测这个模块在Full Speed下能把CDC ACM的AT通道正常枚举出来。

2. AT指令的数据量非常小，一条指令几十字节，12Mbps的带宽对AT通道来说完全是富余的。即便是通过AT口做PPP拨号和透传，12Mbps实际可用吞吐也远高于传统UART方案。

3. 外接USB3300这类ULPI PHY看着不难，实际上布线和参考时钟处理不好就是各种随机枚举失败，项目周期很容易被拖死。

如果你确信后续要跑RNDIS/ECM或者需要超过1MB/s的USB吞吐，才需要认真考虑外接高速PHY。否则用内部FS PHY就能把这个项目做得很稳。

2.2 引脚分配与信号连接表

用OTG_FS外设做Host时，引脚分配最简洁。CubeMX里把USB_OTG_FS的模式选为Host_Only，会自动生成以下连接。

如果选择用OTG_HS外设加上内部FS PHY，引脚则是PB14(DM)、PB15(DP)、PB13(VBUS检测)、PB12(ID)。两个方案的功能没区别，看板子上哪个引脚的复用资源更宽裕。

2.3 VBUS供电与模块VBAT的关系

这里有个特别容易想当然的坑：很多人以为USB口的VBUS就是给模块供电的，5V一接就能跑。实际上广和通MC665是M.2封装，模块的主供电从VBAT引脚进，工作电压3.4V到4.2V，峰值电流在LTE发射时能到2A甚至更高。而USB座的VBUS在模块这里通常只负责USB信号检测，最多提供一小部分辅助电流。

所以硬件设计上要分开两路：

• VBUS：从5V主电源过来，经过负载开关（比如TPS2051）或者直接经ESD保护器件接到USB座，给模块的USB检测逻辑用。
• VBAT：单独从DC-DC或LDO出，电压和电流余量按照模块手册的峰值需求设计，走线尽量短粗。

我见过有人把两个混在一起，结果模块发射时VBUS跌到4V以下，USB枚举频繁失败，查了半天才发现是供电设计的问题。

2.4 PCB布线的几个细节

USB Full Speed虽然只有12Mbps，但也不是随便拉两根线就完事的。我的经验是：

• DP/DM做等长差分对，长度差控制在10mil以内，这个要求不算苛刻，画板时稍微注意就行。
• 每根线串联22欧姆电阻，放在靠近MCU引脚的位置，用来抑制振铃。
• 在USB座旁边加USBLC6-2SC6之类的ESD保护芯片，数据线和VBUS都要过。
• USB座的金属外壳接地，通过一个1M电阻并联0.1uF电容接到地平面，避免外壳电荷积累干扰信号。

把这些做到位之后，枚举成功率明显比乱拉线时高很多。尤其是批量打样时，同一个固件在不同板卡上的稳定性，往往就取决于这些细节。

3. MC665模块USB枚举画像：它到底是几个设备

3.1 上电时序与枚举结果

MC665模块从VBAT上电到USB口真正能被枚举出来，通常需要1到3秒。这个时间被模块内部的固件初始化、网络搜网流程占用。很多人的第一版代码是MCU和模块同时上电，MCU侧疯狂尝试枚举，模块还没准备好，结果就是连失败。

我在调试早期踩过的坑：MCU复位后USBH_Process跑了不到1秒就开始报错，模块根本没响应。后来在模块供电稳定后加了一个“等待500ms以上再启动Host枚举”的逻辑，问题才消失。

模块成功枚举后，在PC端用USB分析工具抓包，能看到它不是一个单一功能的USB设备，而是一个复合设备，通常包含：

• 一个CDC ACM接口，这就是AT指令通道，表现为虚拟串口。
• 一个或多个网卡接口（RNDIS或ECM/NCM），用于上网拨号。
• 一个DIAG口，用于日志和诊断。
• 不同固件版本可能还有额外的Modem口、PCUI口等。

如果嵌入式设备只需要AT指令通道，那么在枚举阶段只关注CDC ACM接口就够了。STM32的USB Host库在枚举时会扫描配置描述符，找到第一个接口类匹配CDC ACM的接口，然后绑定对应的类驱动。

3.2 CDC ACM端点结构与AT通道

CDC ACM接口的内部结构是固定的：一个中断IN端点用来传输线路状态通知，一个Bulk OUT端点用来收主机发的数据，一个Bulk IN端点用来向主机回数据。在我们这个场景里，Bulk OUT对应“向模块发AT指令”，Bulk IN对应“模块回复的AT响应”。

因为AT指令数据量小，发一个“AT+CSQ\r\n”也就是9个字节，一个Bulk事务就完成了。接收也一样，模块回复可能是几行文本几十字节，同样一个包就能装下。

关于端点地址，不同模块固件可能略有差异。USB规范不强制端点地址固定，所以代码里不能写死0x02/0x82，要读取描述符后动态获取。STM32的USBH_CDC类驱动已经做了这件事，它把端点信息存在CDC句柄里，应用层直接用句柄里的收发接口就行。

3.3 Full Speed下哪些功能会受影响

主机以Full Speed枚举MC665时，Socket本质上是USB设备以Full Speed模式重新协商配置。Bulk端点的最大包长从High Speed的512字节降为64字节，传输速率上限降到理论12Mbps。

对AT指令来说，这个速率没有影响，指令交互本来就是毫秒级的事务。但要注意，如果模块的某种USB固件配置里，RNDIS/ECM网卡接口只在High Speed描述符中启用，Full Speed下可能不会枚举出网卡接口，或者枚举出来但驱动交互异常。这一点需要实测，不能只看手册里的接口列表。

我的实测结果是：MC665默认固件在Full Speed主机下，CDC ACM的AT口可以正常枚举和使用，网卡口相关的接口在你的主机没有对应类驱动时本来就不会绑定，不影响AT通道。如果你后面需要做USB网卡拨号，那我再强调一次，老老实实上外部高速PHY。

4. CubeMX配置与Host栈启动：我自己踩过的初始化顺序问题

4.1 时钟和堆栈是第一步也是最多人翻车的一步

STM32F407的USB外设需要精确的48MHz时钟，时钟源一般从PLLQ输出取。CubeMX的时钟树里，如果你配置HSE为8MHz、主频168MHz，那么PLLQ输出默认就是48MHz，直接供给USB_OTG_FS。用内部HSI或CSI做USB时钟会引入频偏，有可能导致枚举随机失败，强烈不建议。

另一个容易被忽略的是堆大小。STM32 USB Host库在运行时要动态分配内存，默认的链接脚本里Heap Size可能只有0x200甚至更小，枚举到一半就出现内存分配失败。我一般直接把Heap Size调到0x2000，稳妥。

如果遇到枚举过程中HardFault，第一步查对齐，第二步查堆大小，第三步查中断优先级，这三个顺序走了无数遍。

4.2 中间件配置与代码生成

在CubeMX的Middleware里选择USB_HOST，Class选Communication Host Class (CDC)，也就是usbh_cdc。注意不要选成USB_Device，这是完全不同的分支。

生成代码后，工程里会有几个关键文件：

• usbh_cdc.c：CDC类驱动实现。
• usbh_conf.c：Host栈底层配置，里面可以调整控制端点最大包长、线程周期等。
• usbh_platform.c：HCD相关的平台初始化。
• app_usbh_host.c：中间层状态机和用户回调。

中断配置方面，OTG_FS_IRQn或者OTG_HS_IRQn要手动在NVIC里打开。优先级别设成最高，也别低于你能容忍的最大延迟。如果跑FreeRTOS，一般建议把USB中断优先级设在可管理中断组内的一个合适值，确保RTOS的心跳不会被USB中断无限抢占。

4.3 Host状态机初始化与延迟枚举

主循环里核心就是反复调用USBH_Process。不要把它放到一个被延时的循环里，USB枚举是个对时间敏感的过程，主机和设备之间有一堆超时机制，你慢了它就认为链路异常。

我常用的框架是这样：

int main(void) { HAL_Init(); SystemClock_Config(); MX_GPIO_Init(); MX_USB_HOST_Init(); // 让4G模块先完成启动 HAL_Delay(1500); USBH_Start(&hUsbHostFS); while (1) { USBH_Process(&hUsbHostFS); if (usb_host_ready) { at_task_handler(); } } }

usb_host_ready这个标志位在用户回调里置位：

static void USBH_UserProcess(USBH_HandleTypeDef *phost, uint8_t id) { switch (id) { case HOST_USER_CLASS_ACTIVE: usb_host_ready = 1; break; case HOST_USER_DISCONNECTION: usb_host_ready = 0; at_ring_reset(); break; case HOST_USER_UNRECOVERED_ERROR: // 延迟后重新启动Host break; } }

4.4 关键代码骨架

CDC通道打开之后，收发函数的用法如下：

uint8_t tx_buf[128]; uint8_t rx_buf[512]; uint16_t rx_len = 0; // 发送AT指令 USBH_CDC_Transmit(&hUsbHostFS, tx_buf, strlen((char *)tx_buf)); // 异步接收：提交一次接收请求，数据到了会回调 USBH_CDC_Receive(&hUsbHostFS, rx_buf, sizeof(rx_buf));

注意USBH_CDC_Receive是异步操作，rx_buf的内存必须一直有效，直到回调函数被触发。不能传一个栈上的局部数组，这是非常容易踩的坑。我在工程里直接用全局或者静态数组。

5. AT通信状态机：从收到第一个字符到稳定收发

5.1 发送侧设计：队列与超时重发

AT指令的核心是一个“发——收——判”的循环，但发不能无脑发。如果上一条指令还没收到完成标志就发下一条，模块的响应会交织在一起，解析器完全没法工作。所以发送侧必须串行化。

我用一个简单的busy_flag来实现串行：

static volatile uint8_t at_tx_busy = 0; void at_send_command(const char *cmd) { uint16_t len = strlen(cmd); memcpy(tx_buffer, cmd, len); at_tx_busy = 1; USBH_CDC_Transmit(&hUsbHostFS, tx_buffer, len); }

在USBH_CDC_TransmitCplt回调里清除busy_flag。发送完成只代表数据进了USB，不代表模块已经处理完了。模块响应是否完成要由接收状态机来判断。

AT指令的结束符是\r，不是\n，也不是\r\n。很多从PC串口助手转过来的代码习惯写\r\n，模块也能接受，但标准AT指令集只要求\r。

5.2 接收侧设计：环形缓冲与行解析

接收侧是整个AT状态机里最关键的部分。我在回调里做的事非常少，就是把数据搬进环形缓冲，然后立刻重新提交一次接收请求：

void USBH_CDC_ReceiveCplt(USBH_HandleTypeDef *phost, uint8_t *pbuf, uint32_t *len) { ring_buffer_write(rx_ring, pbuf, *len); USBH_CDC_Receive(phost, rx_buf, sizeof(rx_buf)); }

真正的解析放到了主循环的at_task_handler里。这样做的原因是，USB接收回调的上下文不适合做耗时的字符串匹配和业务分发。如果回调里处理时间过长，会拖累USB Host栈，导致丢事件。

解析逻辑采用一个经典的“按行切分”状态机：从环形缓冲区里逐字节取出，拼成一行，遇到\r\n或\n就算一行完整。每一行再跟期望的关键词匹配。

AT指令的响应格式大概是这样的：

AT+CSQ\r\n +CSQ: 21,99\r\n \r\n OK\r\n

注意第一行是模块回显的命令，不是真正的响应内容。虽然可以发ATE0关掉回显，但保留回显对调试更友好，所以解析器要能跳过命令回显行。

5.3 一次AT+CSQ的完整流程代码

下面的代码展示一个最小可用的AT指令收发流程：

static uint8_t at_rx_ring_buf[2048]; static ring_buffer_t at_rx_ring = {0}; static uint8_t at_line_buf[256]; static uint16_t at_line_len = 0; static uint8_t at_csq_done = 0; static int at_csq_rssi = -1; static int at_csq_ber = -1; static const char *at_cmd_csq = "AT+CSQ\r"; void at_task_handler(void) { uint8_t ch; // 从环形缓冲取字节并按行切分 while (ring_buffer_read(&at_rx_ring, &ch) == 0) { if (ch == '\n' || ch == '\r') { if (at_line_len > 0) { at_line_buf[at_line_len] = '\0'; at_process_line((char *)at_line_buf); at_line_len = 0; } } else { if (at_line_len < sizeof(at_line_buf) - 1) { at_line_buf[at_line_len++] = ch; } } } } void at_process_line(char *line) { // 跳过命令回显行 if (strncmp(line, "AT", 2) == 0) { return; } if (strcmp(line, "OK") == 0) { at_csq_done = 1; } else if (strncmp(line, "+CSQ:", 5) == 0) { sscanf(line + 5, "%d,%d", &at_csq_rssi, &at_csq_ber); } }

调用端则是：

void at_query_csq(void) { at_csq_done = 0; at_csq_rssi = -1; at_send_command(at_cmd_csq); uint32_t start = HAL_GetTick(); while (at_csq_done == 0) { at_task_handler(); if ((HAL_GetTick() - start) > 3000) { break; } } if (at_csq_done) { printf("RSSI=%d BER=%d\r\n", at_csq_rssi, at_csq_ber); } }

超时用HAL_GetTick()计算，而不是HAL_Delay阻塞等待，这样整个等待期间USBH_Process依然能在主循环里运行，不会把USB栈卡死。

5.4 URC消息怎么处理

除了对当前指令的同步响应，模块还会主动上报一类消息，术语叫URC（Unsolicited Result Code），例如网络注册状态变化、信号强度主动上报、SIM卡热插拔提醒等。这些消息可能在任意时刻插进来，跟当前指令的响应混在一起。

我的处理方式是：在at_process_line里，先把所有不以AT开头、也不匹配当前指令关键字的行当成URC，放到一个独立的urc_queue里。应用层可以轮询这个队列，也可以注册回调函数处理网络状态变化。

typedef struct { char data[128]; } urc_entry_t; #define URC_QUEUE_SIZE 8 static urc_entry_t urc_queue[URC_QUEUE_SIZE]; static uint8_t urc_head = 0; static uint8_t urc_tail = 0; void urc_push(const char *line) { // 队列满就丢弃最旧的 strncpy(urc_queue[urc_tail].data, line, sizeof(urc_queue[0].data) - 1); urc_tail = (urc_tail + 1) % URC_QUEUE_SIZE; }

这样即使模块在你执行AT+CSQ的过程里突然冒出一行“+CEREG: 1”，也不会把CSQ的解析搞乱。

6. 实测踩坑记录：枚举失败、对齐HardFault与粘包

6.1 模块上电慢导致的不稳定枚举

现象是：冷启动后USB Host偶尔识别不到MC665，串口日志停在HOST_PORT_ENABLE或者HOST_ENUMERATION这一步，反复复位MCU也不一定能恢复，必须把模块也断电重来。

排查链路走了一遍，最后定位到两个因素叠加。第一个是模块启动时间比MCU长，MCU在模块D+还没稳定时就开始枚举，导致设备状态机和模块实际状态对不上。第二个是模块固件对重复的USB复位比较敏感，MCU复位的瞬间会把整个USB总线的D+拉低，模块误认为是主机的复位信号，就重新进入内部初始化流程。

解决办法分两步走：软件上，Host启动前加一个1到2秒的延时；链路失败时不要无限重试，而是先USBH_Stop，等200ms再USBH_Start。硬件上，尽量让MCU和模块的复位电路独立，不要让看门狗复位MCU的时候顺带把模块弄挂。

6.2 缓冲区对齐问题引发的HardFault

F407的USB Host控制器走AHB总线访问内存，DMA传输要求缓冲区地址按4字节对齐。如果你在代码里写了一个裸的uint8_t数组作为USBH_CDC_Receive的接收缓冲，编译器默认把它放在一个不知道对齐地址的位置，那么当DMA搬运数据时，可能触发总线错误，表现为HardFault。

这不是CPU访问越界，而是DMA对非对齐地址的行为未定义。解决方式是在数组定义时加上对齐属性：

__ALIGN_BEGIN static uint8_t usb_rx_buf[512] __ALIGN_END;

CubeMX生成的HAL库里__ALIGN_BEGIN和__ALIGN_END就是用来干这个的。我建议所有USB收发的缓冲区都加，不要偷懒。这个坑的特征很典型：第一次枚举正常，一旦开始传输数据就跑飞，且错误发生的位置随机。

6.3 大批量响应粘包和丢行

AT+CSQ这种短指令不会有问题，但像AT+CGDCONT?这种可能返回二三十行配置的指令，如果一次没接收完，就可能出现“粘包”和“丢行”。

根因在于USBH_CDC_Receive一次最多只能接收你提交的缓冲长度，比如64字节。如果模块一次返回了400字节，Host驱动会分成好几次回调通知应用。如果你的解析器在收到“OK”之后就把状态清了，而后面还有几行数据堵在环形缓冲里，这些数据就会被当成下一条指令的响应，逻辑就全乱了。

我的处理原则是：一条指令的完成标志不是“收到OK/ERROR”，而是“收到OK/ERROR且环形缓冲被消费到了OK这一行之后”。更稳的做法是在状态机里增加一个“等待行空闲”的判定，也就是确保OK/ERROR之后没有残余未处理的行，再回到IDLE状态。

接收环形缓冲的大小也值得关注。我一般给AT通道设置2KB以上的环形缓冲，够容纳大多数查询指令的完整响应。如果你要跑FTP、HTTP这类大流量AT指令，缓冲还要再大一些，或者改成按需动态申请。

6.4 热插拔处理的完整链路

4G模块如果允许在线插拔，Host端必须要能优雅处理断开和重连。STM32的USB Host库会通过HOST_USER_DISCONNECTION回调通知应用，但应用侧不能只是把ready标志清零就完事。

我建议在断开回调里做这些事：

1. 停止当前AT任务，把发送队列和接收环形缓冲全部清空。
2. 关闭CDC的数据通道，等待Host栈自动重新枚举。
3. 超过一定时间没有重新枚举成功，就主动调用USBH_Stop/Start做一次冷重启。

另外，很多4G模块在USB断开后不会立即关断内部电源，重新插入时可能会以“新设备”身份枚举，端点和配置描述符可能有微调。所以每次重新枚举成功之后，理论上应该重新读取一遍模块的工作模式参数，比如回显是否关闭、SIM卡状态等。

7. 实测表现与工程选型参考：什么时候值回票价

7.1 不同方案性能对比

我把传统USB转串口芯片方案和F407 USB Host直连方案放在一起对比，供选型参考。

7.2 实测数据与资源占用

我在168MHz主频、Full Speed模式下实测AT指令的往返延迟大约是10到20毫秒，其中大头是模块的响应时间，USB传输本身几乎不增加延迟。连续收发数百条指令没有出现丢字节。

做TCP透传时，通过AT口传输数据的实际吞吐大概在400KB/s到600KB/s之间，这个数值受模块AT指令处理能力和流控机制限制，但已经远高于UART 921600bps的实际吞吐了。

CPU占用方面，USBH_Process每秒调用数量取决于主循环频率，我按1kHz调用，整机CPU占用不到10%，对MCU业务来说影响很小。中断回调里只做数据搬运，不会出现长时间关中断导致RTOS tick丢失的情况。

内存方面，USB Host栈本身需要大约10KB左右的RAM，再加上我开的2KB接收环形缓冲和1KB发送缓冲，在F407的192KB RAM里完全不算什么。

7.3 其他4G模块的复用建议

这套方案理论上适用于所有提供USB CDC ACM接口的4G模块，包括移远、广和通、有方等主流厂商的主流型号。差别主要在于枚举时的接口排列顺序和设备描述符细节。

换模块时的适配步骤我固定为：

1. 先用PC + BusHound抓取目标模块的枚举信息，确认CDC接口是第几个，端点地址是多少。
2. 对照STM32 USBH_CDC类驱动的匹配逻辑，看它绑定的接口号是否和模块一致。如果不一致，可能需要改驱动里的接口匹配条件。
3. 发一轮基础AT指令验证收发链路，再跑大数据量压力测试。
4. 实际确认Full Speed枚举下模块的可用接口，尤其是要注意目标模块会不会在全速模式下发疯。

这套流程走完，基本就不会再被模块差异卡脖子了。

从项目立项到量产，我用这套方案在STM32F407上把USB转串口芯片从BOM表里彻底删掉了。第一版调通花了差不多两天，后面再复制到其他项目，半天就能跑起AT通信。如果你也在做类似的4G模块接入方案，我的建议是别怕USB Host这套复杂的东西，它其实就是“枚举一个虚拟串口再读写Bulk端点”这么简单。FS模式下的AT通道稳得很，真正要谨慎的是USB网络数据业务，那才是需要高速PHY的地方。