写这篇文章的起因有点俗群里又有人在问“UART和USART到底有啥区别”底下答案五花八门有说“名字不一样而已”的有说“USART快一点”的还有说“USART就是UART升级版”的——不能说全错但基本都跑偏了。我在嵌入式这行摸爬滚打了十几年光串口就调过几百个见过太多人把这两个东西混着用结果要么多焊了一根没用的线要么SPI和USART互相抢引脚要么在特定场景下白浪费了USART的一身本事。UART和USART的区别不是“型号升级”那种关系而是“子集和超集”的关系USART能干的UART不一定能干但UART能干的USART全能干。这篇文章我就把自己在项目里踩出来的理解、翻芯片参考手册的经验、以及实际调板子时总结的配置细节全写出来希望你看完之后不用再被这两个名字绕晕。1. 从名字看透本质UART与USART的定义差异1.1 拆开英文缩写看功能边界UART的全称是Universal Asynchronous Receiver/Transmitter翻译过来叫“通用异步收发器”注意关键词是“异步”。USART则是Universal Synchronous/Asynchronous Receiver/Transmitter“通用同步/异步收发器”关键词是“同步”和“异步”两者都支持。异步是什么意思就是收发双方各自用自己的时钟去采样数据不需要一根额外的时钟线。所以UART最少只需要两根信号线TX发送、RX接收。收发双方约定好波特率发送方按这个速率把数据位一个个发出去接收方按同样的速率去采。这里有一个天然的问题如果两边时钟精度不够累加久了就会错位所以UART每帧通常都有起始位和停止位用来重新对齐采样点。USART则在这种异步模式下额外增加了一个同步模式。同步模式下主设备要额外产生一根时钟信号线在标准叫法里通常叫SCLK这个时钟信号就是在告诉对方“你按我的节奏来采样不用自己猜”。有了时钟线速度上限就可以大幅提升同时也省去了在异步模式下追求极低波特率误差的烦恼。很多初学者最大的误区是把“USART支持同步”理解为“USART比UART快很多”。实际上在异步模式下一旦配置好两者的数据速率由波特率和时钟源共同决定没有谁天生碾压谁。真正的差异在于USART能切换工作模式UART则只有一条路可走。1.2 UART其实是USART的一个子集搞嵌入式的一定要建立“子集/超集”的观念。USART在寄存器设计、信号引脚和配置状态上向下兼容了UART的全部异步功能。也就是说你把USART配置成只用TX、RX不用SCLK它就是一颗“纯粹”的UART。在驱动代码的层面很多底层库函数也确实是把USART当作UART用反正异步模式下SCLK根本不会参与。但反过来的事情做不成你拿着一颗只有UART的芯片想让它输出同步时钟硬件上就没有SCLK引脚软件上寄存器也没有这方面的控制位想“刷”出一个同步模式是没戏的。所以选型的时候如果已经明确要接并转串芯片、要刷外部移位寄存器、要带模拟前端采集芯片等需要同步时钟的设备那优先看USART齐全的型号。反过来如果只是跟蓝牙模块、GPS模块、Wi-Fi透传模块打交道UART绰绰有余不必为了用不上同步功能多花预算。注意有些厂商的文档里会把USART叫做UART或者反过来把UART里面加了个同步功能这种命名混乱在低端8位单片机上尤其常见。看数据手册时不要只看标题要看引脚定义和寄存器有没有SCLK、有没有同步模式的描述这才是判定依据。2. 硬件架构层面的核心区别拆解2.1 同步时钟线的存在与控制逻辑USART多出来的SCLK引脚在硬件架构上属于“时钟域”的控制范畴。发送端在主模式下产生SCLK接收端作为从设备去跟随这个时钟。SCLK在空闲时是高还是低、数据是在上升沿采样还是下降沿采样这些参数都是可配置的。我在用某款国产MCU做外部ADC采集时就深刻体会过SCLK相位配置的重要性。当时硬件上用了USART的同步模式去读取一颗24位ADCSPI接口同样能实现但PCB上已经把USART的SCLK、TX、RX三根线引过去了改硬件太麻烦就在软件里把USART调成同步主模式。结果采样数据一直出错十六进制数看起来毫无规律后来检查发现是SCLK的相位和ADC芯片要求的采样沿不一致——人家要求数据在时钟下降沿被锁存我这边默认配的是上升沿。各个厂商的USART对同步模式下“时钟极性CPOL”和“时钟相位CPHA”的寄存器定义不一定一样有的只有一位控制翻转极性有的分开两个位段控制下手之前先对着参考手册确认别拿一套代码往两款芯片上套。UART的物理层则要简单得多没有SCLK也没有相位、极性的概念。接收方用自己的波特率生成器对RX线上的电平进行采样。所以UART抗干扰能力在高速率下是比较吃亏的没有时钟做基准全靠过采样和边沿检测一旦信号质量变差误码率就上来了。2.2 数据缓冲与错误检测机制的差异芯片手册上常出现“发送数据寄存器TDR”“接收数据寄存器RDR”“移位寄存器”这些名词。USART在这类缓冲结构上通常做得比老式UART更完善比如部分支持FIFO多数支持硬件级别的奇偶校验、帧错误检测、噪声检测、溢出检测甚至带LIN总线断开符号检测、红外IrDA编解码等这些都是USART在不同场景下的拓展能力。UART的老式实现往往是一字节一中断软件上稍有延迟就会导致数据覆盖所以早年单片机搞串口总在强调“中断服务程序要短、要快”。现在的UART控制器则大多带了几级FIFO但相比而言USART的同步模式在数据流控上有一个天然优势有主时钟控节奏发送方和接收方天然同步软件操作起来比异步模式更加从容。对于普通调试串口应用这种缓冲差异体验不太出来。真正能感受到的是在大量数据传输时USART如果支持自动流控和DMA协同工作CPU负载能明显降下来。UART则常需要软件干预实现“缓冲空闲检测”“半满中断”等机制。我个人的观点是选型时不要只盯着是否带FIFO还要看FIFO深度和触发阈值能否配置这决定了你在高负载下能做多少优化。2.3 速率上限与信号质量的实际差距这里必须澄清一个概念USART的同步模式速率上限通常高于异步模式但“USART速率高于UART”的说法并不准确。USART在同步模式下时钟由主设备自己产生只要芯片内部逻辑跟得上速度可以做到很高常见的中低端MCU上甚至能跑几Mbps。异步模式下USART受制于波特率误差、采样次数通常16倍过采样和信号上升沿质量速率一般也就用在小几百Kbps到一两Mbps的范围。UART本身也是同样原理所以所谓“快”是工作模式不同导致的不是协议名字带来的优势。信号质量上我做过一个对比同样的PCB走线长度、同样的TTL电平、9600波特率UART和USART异步模式表现几乎一致但是把波特率提到921600后UART这边的波形过冲明显沿也不够陡而USART同步模式下用SCLK采样则稳得多。这也解释了为什么很多高速ADC、并转串器件喜欢挂在USART或SPI这类同步总线上而不是用异步串口硬跑。重要在异步模式下采样通常采用16倍或8倍过采样。也就是说波特率时钟频率不是等于波特率×1而是波特率×16或×8。这个倍数直接参与波特率寄存器的除法计算后面配置章节我会给具体公式。3. 同步模式在实际应用中的价值3.1 同步模式能做什么快速扩展外部设备USART的同步模式可以和多种外设通信。最常见的有带SPI接口的Flash芯片、串行ADC/DAC、移位寄存器级联LED灯板、数字电位器等。只要协议里没有强制要求CS片选线USART就能按“主设备输出时钟数据”的方式去驱动。区别在于SPI通常有四根线SCLK、MOSI、MISO、CS。USART同步模式则相当于把MOSI和MISO复用成了TX和RXSCLK存在但没有专门的CS线。如果外部设备是以“帧”为单位的比如一次命令8位、一次数据16位那CS功能可以用GPIO去模拟发送前拉低、结束后拉高。靠GPIO去“造”片选不是什么高科技但一定要在时序上留足余量避免电平转换还没稳定就开始发数据。我自己做过一个LED驱动板项目主控的SPI接口留给了一个Flash芯片而LED的级联要额外驱动一串移位寄存器眼见着引脚不够用了最后就是用USART的同步模式去刷那排寄存器。一个字节一个字节地往TX写SCLK由硬件自动生成直接省了一个SPI控制器。这种用法最大的好处是省硬件资源代价是你得接受USART固定的帧格式比如8位数据、可选的奇偶校验灵活性不如SPI那么开放。3.2 与SPI的对比为什么不去直接用SPI遇到这种情况很多人会问那直接用SPI不就行了说句实在话如果芯片上SPI资源富余我确实更推荐直接用SPI。但现实是做产品设计时常常遇到下面这几种情况芯片选型已经锁死引脚不够SPI控制器数量有限。PCB已经画完投板SCLK和TX已经连到目标外设但之前没用上同步模式现在只能靠软件把它激活。目标外设本身对时序要求不高只要“有时钟有数据”就能工作用USART同步模式省资源。USART同步模式还有个“不情不愿”的亮点它天生支持发送和接收同时进行。在全双工同步模式下你可以在发指令的同时收到对方回的数据这和SPI的主出从入很相似。但要注意USART同步模式下从设备的数据线如果没东西回会呈现高阻或高电平不定状态必须做好上拉或者按手册处理不然RX路径上可能出现悬空电平进而误触发出错标志。3.3 特殊模式LIN、智能卡与红外除了同步/异步USART往往还集成了若干种“附加工作模式”。举几个我实际接触过的LIN总线模式汽车电子里很常见本质上是把UART的帧格式做了扩展增加同步断开场检测和Checksum校验。部分芯片里需要配置成LIN模式串口才能在LIN总线上做主机/从机通信。智能卡模式一些USART支持ISO 7816协议可以直接驱动接触式IC卡。需要额外的时钟输出和SCLK相关以及特定字节重发机制。如果做读卡器类产品仔细看看选型芯片的USART是否支持这个模式能帮你省去一片独立的智能卡接口芯片。红外IrDA模式老式红外通信会用38kHz载波调制USART的IrDA模式可以在硬件层面做编解码省了软件翻转IO的苦差事。这些内容在UART的数据手册上基本看不到或者即便提到了也只作为“兼容串口应用”的边角料。这也是我判断一颗芯片串口功能是否强大的重要参考。4. 寄存器级配置与代码实现剖析4.1 一个典型USART初始化流程这部分我拿常见MCU上的通用寄存器来说不同芯片寄存器名可能略有出入但思路是通用的。配置异步模式串口的基本流程大致如下开启USART外设时钟同时开启对应GPIO口的时钟。将TX、RX引脚复用为USART功能。设置波特率写入波特率寄存器。设置字长8位或9位、停止位1位或2位、奇偶校验模式。设置是否开启接收中断、发送完成中断或空闲中断。如果有DMA需求配置DMA通道并使能相应请求。使能USART模块然后分别使能发送和接收。代码层面上伪代码大概是这样的USART_ClockEnable(); GPIO_SetAlternate(TX_PIN, AF_USART); GPIO_SetAlternate(RX_PIN, AF_USART); USART_BRR 0x00000000; USART_BRR CalculateBRR(PeriphClock, 115200); // 8位数据无校验1位停止位 USART_CR1 0x0000; USART_CR1 | (0x00 12); // M08位 USART_CR1 | (0 10); // 无校验 // 使能收发 USART_CR1 | (1 3); // TE USART_CR1 | (1 2); // RE // 使能外设 USART_CR1 | (1 13); // UE拿到真实芯片上细节只会更多。比如有的芯片要求先使能USART再配置波特率顺序反了就会偶发乱码有的芯片DMA请求要分别在发送和接收两个方向单独使能漏一步数据就会卡死还有的芯片复位默认TX引脚是IO模式要写复用寄存器才能转成串口。我是强烈建议把“初始化流程”固化成自己的一套模板之后换芯片就只改寄存器名碰到问题时先复查初始化顺序。4.2 波特率计算公式和取整陷阱波特率计算是串口调不通的头号原因尤其是用内部振荡器跑非标称频率的时候。异步模式下的计算公式在绝大多数MCU上可以写成[ BRR \frac{Fck}{16 \times 波特率} ]其中Fck是USART的外设时钟频率。如果开启8倍过采样则分母的16变成8。硬件自动采样时用的是16倍过采样所以BRR计算的结果是分频值很多时候不能整除需要取整。举个例子某款MCU的外设时钟是8MHz想跑到115200那么[ 8000000 / (16 \times 115200) 8000000 / 1843200 \approx 4.34 ]寄存器只能存整数所以4.34要取整为4。取整后实际波特率[ 8000000 / (16 \times 4) 125000 ]实际波特率是125000跟目标的115200差了约8.5%。这个误差会直接导致接收端采样错位偶尔能通但数据一多就乱码。怎么解决要么换一个能整除的外部晶振频率比如7.3728MHz要么在应用层允许的情况下改用整数波特率比如9600、19200、38400这些跟常见晶振能整除的值。同步模式下波特率计算可以换成外设时钟直接除以分频系数因为SCLK本身就是时钟输出公式略有不同[ SCLK频率 \frac{Fck}{2 \times BRR} ]不过得看具体芯片手册有的芯片SCLK是直接等于波特率有的则是波特率的一半。我的习惯是配置完同步模式后直接拿示波器打在SCLK引脚上看频率确认是否和预期一致比反复翻译手册里的废话快得多。4.3 中断、DMA和海量数据收发策略UART/USART的数据收发最基础的方式是轮询。但轮询会阻塞CPU真正做产品时很少用。进阶方案是中断收发每收到一个字节就触发一次接收中断软件把数据丢进环形缓冲区发送时则先往数据寄存器写一个字节等到发送完成中断再填下一个。再往上是DMA搬运。DMA适合大批量、定长数据的场景比如每秒从外部ADC读取几千个采样点。DMA模式下CPU只要在初始化时把源地址、目的地址和数据长度配好外设收到固定数量数据后触发完成中断CPU再来搬运一次结果即可。这个方案的CPU占用率极低是我做大流量数据采集时的首选。DMA也有坑如果数据长度不固定比如面对AT指令这种不定长回包DMA不能自动判断“这帧数据结束了没”需要配合空闲中断或定时器来判断。所谓空闲中断就是总线在接收完最后一个字节后空闲了若干个位时间硬件触发一次标志此时软件就把DMA缓冲里的数据当作完整一帧处理。这个思路在UART、USART上通用只是有的芯片叫“IDLE中断”有的叫“RXNE TO”之类名字不同但意思差不多。4.4 同步模式下的帧格式细节同步模式下发送的数据格式不再是简单的“起始位数据停止位”那种异步结构SCLK会跟随每位数据生成时钟脉冲。发送方必须在使能同步模式前把CTRL寄存器里的CLKEN位置1否则SCLK引脚不会输出时钟。具体到某些MCU上还需要选择时钟极性和相位对应到寄存器位就是CPOL和CPHA。有一次我在配置完同步模式后发现SCLK只有在发送数据时才产生脉冲空闲时完全不输出查手册才知道这跟CPOL的设置有关。CPOL0时SCLK空闲为低CPOL1时空闲为高。如果目标外设期望空闲时高电平而我配成低它就会把空闲期识别成时钟开始信号进而吞掉第一帧数据。很多时候不是协议本身难而是寄存器位含义在芯片间有细微差异看手册不能只看图要看文字描述里的时序图怎么画。我后来习惯在纸上画一个简单的时序波形标好时钟极性和采样沿再去对照寄存器说明基本不会出大错。5. 工程选型与实战避坑指南5.1 什么时候选UART什么时候选USART选型阶段考虑的不只是“这个芯片有没有USART”还包括“这个USART能不能满足当前和未来好几个项目的通信需求”。我的习惯是分几个层次来评估第一层确认用途如果只是打印日志、与蓝牙模块或4G模组透传UART足够。若后续想扩展同步外设比如要挂外部Flash或ADC、要通过并转串芯片扩IO那么尽早选带USART的型号。第二层确认引脚USART的SCLK引脚是否和SPI或其他外设复用冲突。很多芯片把SCLK复用在了PWM通道旁边两者共用会导致方向配置互相干扰PCB布线阶段就要提前规划。第三层确认时基精度内部RC振荡器在常温下误差能到±2%左右对于9600波特率通常可接受但在115200以上、且接收端是另一个独立振荡器的时候就可能频繁乱码。追求可靠性的场景建议加外部晶振或选择内部振荡器校准能力强的芯片。我在一个环境监测项目里就吃过亏最初图省事用了内部RC跑115200设备单机测试没问题一挂在正式环境上隔几分钟就丢几帧。后来把所有串口速率降回9600连续跑了一周传输率稳定多了。这个教训开始让我真正重视“波特率余量”这个概念。5.2 硬件排查示波器和逻辑分析仪才是主角串口调不通的时候我极少先怀疑软件因为软件只要按流程配基本不容易错。我的排查顺序是示波器看TX脚有没有波形 → 看波形幅度是否正常 → 看波形波特率是否达标 → 再看对端RX引脚有没有接收到。如果示波器显示TTL电平只有1.8V而对端是3.3V供电直接加电平转换如果TX和RX飞线接反了波形看起来完全正常但对端就是没反应这时候打RX脚常被当成TX脚用判断不出来就得用逻辑分析仪直接按协议解码。逻辑分析仪调试串口是我极力推荐的方式。它可以按波特率自动解码把每一帧的十六进制数据和时间戳显示出来比示波器直观太多。很多硬件问题在逻辑分析仪下一目了然比如波形毛刺导致起始位被误解析数据位多了一个或少了一个误码率视图直接把问题暴露出来。实际项目中我还遇到过把USART的DE方向使能接反的情况。在RS-485电路里DE脚控制收发器方向软件配置成发送完成后拉低、接收时拉高结果方向反了导致一发数据对方立刻把它当成自己的驱动信号给短路掉了。这类问题要用示波器同时抓DE和TX两条线看出有没有逻辑组合错误单查一条线很难定位。5.3 流控处理RTS/CTS你真的用对了吗硬件流控在很多UART/USART上都有但实际用的项目很少。RTS/CTS的原理不复杂接收方在自己缓冲区快满时拉低RTS提醒发送方暂停发送方看到CTS为高时停止发送。这种机制对于“极大数据量对端处理不过来”的场景非常有用尤其是模块对接的时候比如主控和蓝牙模组通信模组固件偶尔忙不过来就会丢包有了流控能显著缓解。但流控也有坑如果硬件设计上没接RTS/CTS软件却使能了硬件流控发送方会一直等CTS有效导致串口“假死”。我见过很多人因此怀疑芯片坏了跑过来一问发现是拿TTL的USB转串口模块去连一个使能了流控的USART引脚。解决方式是检查软件配置确认使能流控的同时硬件上确实把对应引脚连到了对端。还有种“软流控”是用XON/XOFF字符去控制这种方式其实对二进制数据不友好因为数据里可能恰巧出现0x13或0x11容易误触发。5.4 善用环形缓冲区嵌入式串口的地基串口驱动好不好的一个分水岭就是有没有一个可靠、高效的环形缓冲区。轮询收一个字节处理一个逻辑那是教材写法实战中我会拆成“ISR只管往环形缓冲区放数据主循环或任务再从缓冲区取数据解析”。缓冲区大小要预估最大突发数据量避免溢出。我自己的模板里缓冲区大小通常取2的幂比如256或512这样取模可以用位运算替代速度更快。判断满和空时经典做法是用读索引和写索引分别维护满的条件是(write 1) % size read。另外串口中断里尽量避免调用复杂函数只做数据搬运加锁的粒度要小否则可能造成中断嵌套或任务切换不及时。DMA模式下环形缓冲区和DMA配合需要留意循环DMA模式和普通DMA模式的差异有的芯片要用“半转移中断转移完成中断”来模拟环形效果这个细节调试起来最烧时间。6. 个人实操中的一些心得6.1 代码分层把串口驱动做成模板串口驱动工程上我习惯做三层接口层、注册层、硬件层。接口层向上提供open/read/write/ioctl之类的函数注册层维护一个全局结构体把每路串口的中断回调、DMA句柄、缓冲区指针统一起来硬件层才做寄存器操作。这样换MCU平台时只需要重写硬件层接口层和业务层基本不用动。具体到代码组织我常用类似这样的结构typedef struct { uint8_t *rx_buf; uint16_t rx_size; volatile uint16_t rx_head; volatile uint16_t rx_tail; void (*rx_callback)(uint8_t byte); void (*rx_idle_callback)(void); } uart_port_t;然后每个串口在初始化时把回调函数注册进去。中断服务函数统一读取数据寄存器放入缓冲区再判断是否触发空闲中断。业务层只管调用uart_read或等待rx_idle_callback来解析一帧完整数据。这套体系我用了很多年不管是裸机还是RTOS稍微改上锁机制就能适配。6.2 调试串口时的三板斧调试UART/USART的时候我总结了三个立刻能产生效果的招数新手可以直接套用:降低波特率。把115200降到9600先确认通信链路通畅。如果9600能通而115200乱码基本可以判断是波特率误差、信号质量或接线长度的问题而不是逻辑代码错误。用回环测试。短接本端的TX和RX向自己发数据看能否收到。这个测试能隔离“本端软件/硬件”和“对端问题”。回环如果都不通问题出在本端初始化或电平转换回环通了而对端不通那才需要检查对端。检查引脚复用和时钟。很多“串口完全没反应”的问题查到最后是GPIO复用没配置或者外设时钟没开。对着手册的复用表“按图索骥”比瞎子摸象可靠得多。这三板斧没有技术含量但真实解决的棘手问题比任何高级技巧都多。我曾经被一个“时通时不通”的串口折磨了两天最后发现是飞线过长信号反射导致间歇性误码降波特率后问题消失。调串口别老想着奇技淫巧先确认物理层没问题再谈别的。6.3 复用轮询、中断、DMA三种模式的取舍做项目时我常常面对一个选择这个串口到底用哪种收发方式我的原则是数据量不超过几十字节、且对CPU占用不敏感时用中断收发逻辑简单调试容易。数据量中等、以“帧”为单位交互、且帧长不固定时用“空闲中断DMA接收普通发送”的组合。DMA负责接收不定长数据发送如果量小就轮询或中断发送。数据量极大、且帧长固定比如音频流、高速传感器流直接用“双缓冲DMA乒乓切换”一个缓冲区在接收另一个缓冲区在计算无缝衔接不浪费一个时钟周期。这里提一句“乒乓切换”说白了就是两块缓冲区轮流用DMA满了切到另一块CPU处理已经填满的那块。这个思路在处理连续数据流时比环形缓冲区更好使但代码复杂度和内存占用也会相应提高。项目资源紧张时别硬上环形缓冲配合空闲中断其实已经可以覆盖绝大多数场景。6.4 别忽略电源和地线的干扰串口问题排查到最后硬件层面还有一个常被忽略的坑电源和地线干扰。TTL串口是单端信号地线压差直接影响逻辑电平判断。如果两个设备之间地线整条太细、过长或接触电阻偏大高速传输时信号跳变引起的电流波动会在地线上产生噪声导致接收端误判。我调一块工业主板时往上位机一接串口数据就每隔一段时间出现一个错字节。一开始以为波特率不对后来发现是USB转串口模块的地线通过桌面上的一个金属支架形成了环路支架耦合了干扰。处理方式很简单把地线缩短必要时加磁环或隔离问题立刻消失。所以如果你经常遇到“时好时坏”的串口不妨拿万用表测一测两端地线之间的电压差超过几十毫伏就该考虑隔离方案了。6.5 从错误标志位里找线索UART/USART控制器除了数据寄存器还有一堆状态位比如帧错误FE、噪声错误NE、溢出错误ORE、校验错误PE。这些标志平时不参与业务逻辑但调不通时可都是线索来源。芯片里对错误标志的处理往往是“读状态寄存器再读数据寄存器”来清掉的顺序反了可能清除不掉。我推荐的排查方法是在接收中断里进服务函数后先读SR寄存器检查这几个错误位是否被置1再把错误计数累加到调试变量里。通过周期性地打印这些计数值能发现通信质量的长期趋势。比如ORE溢出计数持续增长说明接收缓冲太小或中断响应太慢FE帧错误增多说明波特率有问题或信号受干扰PE校验错误则直接指向校验位配置不匹配。很多工程师习惯性地“读数据、清标志、关中断”三步走遇到偶尔丢字节的问题就一脸懵。其实只要把这些隐藏状态位在初始化时打印出来一次往往能省下一整天的盲排查时间。7. 写在最后一次升级带来的工程思考我记得有一次和同事一起调试一块老款控制板想把原来用的UART接收升级成更稳的USART同步接收项目主管当时随口说了一句“串口嘛能发能收就行了别折腾”。结果后来现场反馈的数据丢包率确实高分析下来是模块端和主控端时钟各自为政异步采样在高频干扰下频繁采错边沿。换到USART的同步模式后主控主动输出时钟接收模块跟着时钟走丢包率直接归零改动的代码不足十行。这个经历让我明白一件事UART和USART的差异从来不只是规格书上的字母多少而是在异常环境下谁扛得住、谁省资源、谁好调试。作为嵌入式软件工程师把这两者的关系理清楚学会在不同项目中做出选择比死记硬背某个芯片的某个寄存器要靠谱得多。而这篇文章里提到的所有配置思路、排查顺序、代码分层说白了都是我从无数次烙铁烫到手指、示波器看到眼花、串口助手刷出一屏乱码之后总结出来的。希望它对你也有用哪怕只帮你省下一次抓耳挠腮的排查我也算没白写。