1. UART驱动开发的起点：先把硬件手册吃透
1.1 串口协议的本质
做嵌入式驱动开发这几年，UART串口是我打交道最多的外设之一。第二期专门聊聊它，因为串口驱动看着简单，真正调起来坑一点不比SPI、I2C少：波特率不准、数据错位、中断风暴、DMA和FIFO互相打架，每个都能让人挠头。这篇我不打算罗列寄存器手册，而是把我在实际项目里调试UART驱动时沉淀下来的一套思路——从硬件协议、Linux驱动框架、裸机寄存器配置到调试排错，按真实开发顺序捋一遍，给正在搞嵌入式软件或驱动开发的朋友做个参考。
先讲基础。UART的全称是Universal Asynchronous Receiver/Transmitter，中文叫通用异步收发器。它最核心的特点是“异步”，收发两端没有单独的时钟线，全靠双方约定一个波特率来采样数据。一个完整的帧一般由起始位、数据位（常见8位）、可选的校验位、停止位组成，传输方向从最低有效位开始。这些概念很多人能背下来，但真正写驱动时容易踩的第一个坑，是把UART和USART混为一谈。USART多了同步时钟功能，引脚定义和时序都不一样；还有的人把UART的电平和RS232电平搞反，板子上电后直接烧输入引脚。
驱动开发中，必须先确认硬件手册里给出的串口类型，以及信号线电平是TTL、CMOS还是RS232/RS485。TTL和CMOS一般都在0到3.3V或5V之间，而RS232是负逻辑，空闲时是负电压，数据位用正电压表示。如果直接把TTL调试线接到RS232设备上，出来的数据必然是乱码甚至完全没反应。这些属于硬件层的规矩，驱动人员若只看寄存器不看引脚定义，后面排查起来会非常头大。我见过太多人拿着逻辑分析仪去量TTL信号，结果解码出来的波形和实际完全对不上，最后发现是协议类型选错。
1.2 管脚复用和电平转换
绝大多数SoC不会把UART引脚固定死，而是通过引脚复用（Alternate Function）来配置。以STM32为例，USART1的TX/RX通常复用PA9和PA10，但前提是GPIO的AFR寄存器里写对了复用编号。不少人配置完RCC_USART1时钟，直接去操作USART寄存器，结果串口完全没输出，最后发现是GPIO复用没有配置，或者没把TX配置成合适的输出模式。配置GPIO时还要注意，如果只是做调试输出，TX脚是否可以复用为open-drain、是否需要上拉，这些都会直接影响波形质量。
电平转换是另一个容易忽略的环节。板内调试可以全是TTL电平，但一旦要跟PC的串口工具连接，通常需要RS232电平或USB转TTL模块。工业场景常常用RS485，这就要外接收发器芯片，并控制DE/RE方向引脚。有人问TTL UART通过光耦能传多远，其实光耦不是用来加距离的，而是做隔离。光耦本身有传输延迟，PC817这种低速器件在115200波特率下的上升沿已经明显变差，如果还要跑1M以上的波特率，就得选高速光耦（比如6N137），并且注意输入侧限流电阻。距离和速率永远是相互制约的，别指望一根长线缆跑满带宽。
1.3 时钟树和波特率发生器
波特率不是随便写的数字，而是由外设时钟经过分频得到的。以STM32F1为例，USART1挂在APB2总线上，典型时钟是72MHz，波特率计算公式可以简写为：
BRR = fck / (波特率 × 过采样倍数) - 1
8倍过采样时，求出的DIV小数部分用DIV_Fraction表达。举个例子：72MHz时钟下要产生115200，72e6 / (115200 × 8) = 78.125，整数部分是78，小数部分0.125用4位二进制表示就是2/16，这样配置出来的实际波特率仍有约0.16%的误差。这个误差在串口通信里能接受，通常小于3%就能工作。但如果你的系统主频比较低，比如16MHz要跑230400波特率，分频值太小，误差百分比就会很大，这时候就需要使用更高的过采样倍数或者换时钟源。
驱动开发里最常见的坑，是改了主频没有同步更新BRR。有人低功耗模式下调了系统时钟，串口立刻乱码，查了很久才发现波特率配置寄存器是按旧时钟算的。我的建议是：把波特率计算封装成一个函数，输入参数同时带上时钟频率、波特率、过采样倍数，不要在驱动里写死数值。时钟树里的分频系数也要一并考虑。有的芯片UART模块时钟不是来自系统总线直接分频，而是独立PLL，这类配置的波特率精度反而更高，但前提是你看懂时钟框图并选对了时钟源。
2. Linux下的UART驱动：从设备树到tty的完整链路
2.1 设备树节点配置
在嵌入式Linux项目中，串口驱动的第一站通常是设备树。很多人以为设备树只是个“开关”，实际上它决定了驱动能看到什么资源。一个常见的最小UART节点长这样：
&uart1 { pinctrl-0 = <&uart1_pins>; pinctrl-names = "default"; status = "okay"; };pinctrl节点一般是全局定义好的：
&pinctrl { uart1_pins: uart1_pins { function = "uart1"; pins = "PA9", "PA10"; bias-pull-up; }; };如果要用DMA收发，还需要在节点里增加dmas和dma-names属性。我见过非常多的配置错误，集中在status没从disabled改成okay，导致/dev/ttyS*根本没生成；还有pinctrl的function名称写错，驱动probe成功了，但引脚功能不对，数据就是收发不了。排查这类问题，先用ls /dev/tty*确认节点是否存在，再用cat /proc/device-tree或devmem去读复用寄存器，别一上来就怀疑驱动代码。
设备树中还可以配置硬件流控，例如uart-has-rtscts属性或linux,rs485-enabled-at-boot-time。这些属性会直接影响底层termios配置。如果设备树声明了RS485功能，驱动会在打开串口时自动完成方向切换，用户态程序里就不要再自己拉GPIO控制收发方向了，否则会和驱动内部逻辑打架。还有一种容易被忽略的情况：多个串口共用同一个pinctrl节点，导致第二个串口申请引脚时失败，/dev/ttyS1始终打不开。这种资源冲突必须在设备树阶段就排查清楚。
2.2 从platform driver到uart_ops
Linux串口驱动框架分三层：最上层是tty核心，中间是通用串口层（serial core），底层才是具体硬件驱动。我们做驱动开发主要关心底层如何注册struct uart_driver和struct uart_port。一个典型的platform驱动会注册一组uart_ops回调：
static struct uart_ops my_uart_ops = { .startup = my_uart_startup, .shutdown = my_uart_shutdown, .start_tx = my_uart_start_tx, .stop_tx = my_uart_stop_tx, .stop_rx = my_uart_stop_rx, .set_termios = my_uart_set_termios, .tx_empty = my_uart_tx_empty, .set_mctrl = my_uart_set_mctrl, }; static struct platform_driver my_uart_driver = { .probe = my_uart_probe, .remove = my_uart_remove, .driver = { .name = "my-uart", .of_match_table = my_uart_match, }, }; module_platform_driver(my_uart_driver);probe函数要做的事情包括：获取寄存器基地址、申请中断、初始化时钟、设置uart_port的type和ops、调用uart_add_one_port把端口挂到serial core上。startup和shutdown会在每个串口打开/关闭时被调用，不要把一次性初始化放在这里。时钟使能放在probe更好，而FIFO和中断使能放在startup更合理，因为这样不会出现“串口还没打开但不是所有状态都准备好”的尴尬情况。
set_termios是波特率和数据格式的源头。用户态执行tcsetattr、stty或打开设备时都会走到这里。很多驱动只更新了寄存器，却没有把termios->c_cflag里的配置记录下来，导致后面的流控判断拿不到正确状态。C_BAUD、CSIZE、PARENB这些位都要在set_termios里逐一解析并同步到硬件。还要注意termios的c_iflag和c_cflag之间的映射关系，比如软件流控IXON/IXOFF如果没处理好，二进制数据里的0x11、0x13会被系统吞掉，这是很多协议解析乱象的根源。
2.3 数据收发路径
接收路径通常靠中断：硬件收到数据触发RX中断，驱动在中断里把数据从寄存器或FIFO中读出，然后通过uart_insert_char或tty_insert_flip_char插入到tty flip buffer，再调用tty_flip_buffer_push让tty层处理。这里有个细节：如果数据量很大，频繁中断会拖垮系统，所以很多平台会用FIFO阈值中断或者DMA批量传输。Linux内核的kfifo机制也是做类似的事，但驱动里更多是直接操作tty缓冲区。
发送路径则跟接收不对称。start_tx不一定马上就能发送，它往往在数据量不满时被调用，真正的发送由start_tx里使能TXE中断或触发DMA完成。驱动要维护一个发送队列，每次TXE中断发送下一个字符。常见的bug是stop_tx把TX中断屏蔽得太早，导致还有数据在FIFO里没发完；或者tx_empty永远返回1，上层误以为数据发完了。硬件流控中，set_mctrl用来调整RTS信号，而CTS状态变化一般会触发modem status中断，这个中断里要处理ring indicator和carrier detect等信号，否则对端断开连接，驱动毫无感知。
3. 裸机下UART编程的实操要点：寄存器配置、中断和DMA
3.1 初始化流程和寄存器配置顺序
裸机编程没有Linux那套抽象，所有配置都要自己来，但顺序很重要。以STM32为例，我的标准做法是：先使能外设时钟，再配GPIO复用，然后复位UART外设，按波特率、数据格式、FIFO/中断使能、最后使能UART的顺序走下去。代码片段大概是：
RCC->APB2ENR |= RCC_APB2ENR_USART1EN; GPIOA->MODER &= ~(GPIO_MODER_MODER9_MASK); GPIOA->MODER |= GPIO_MODER_MODER9_1; // PA9 AF GPIOA->AFR[1] &= ~(0xF << 4); GPIOA->AFR[1] |= 0x7 << 4; // AF7 -> USART1_TX GPIOA->AFR[1] |= 0x7 << 8; // AF7 -> USART1_RX GPIOA->PUPDR |= GPIO_PUPDR_PUPD10_0; // RX上拉 USART1->CR1 &= ~USART_CR1_UE; // 先禁止 USART1->BRR = compute_brr(72000000, 115200); // 设置波特率 USART1->CR1 |= USART_CR1_TE | USART_CR1_RE; // 收发使能 USART1->CR3 |= USART_CR3_EIE; // 错误中断使能 USART1->CR1 |= USART_CR1_RXNEIE; // 接收缓冲非空中断 NVIC_EnableIRQ(USART1_IRQn); USART1->CR1 |= USART_CR1_UE; // 最后打开UART注意最后才写UE位，因为一旦使能，外设就会开始按配置工作，如果FIFO和中断还没准备好，一进数据就会出错。还有很多人会在初始化期间一直轮询发送，如果这时候对端没连接，TX引脚会一直输出空闲电平；如果连接了流控线，就要保证CTS电平有效再发。GPIO复用寄存器写错或者没写，是初始化完没输出最常见的原因。
3.2 中断处理：接收FIFO、超时和错误标志
中断处理里最容易犯的错是标志清除顺序。很多UART外设规定：必须先读SR（状态寄存器），再读DR（数据寄存器），RXNE标志才会被自动清除。如果只读DR不清SR，或者反过来，会导致硬件认为数据没读完，进入死循环或者持续触发中断。我的建议是状态寄存器和数据寄存器都以volatile方式读，并且用调试器观察标志位变化。自己封装驱动时，最好把“清标志”和“读数据”绑定在一个函数里，防止顺序搞错。
接收中断大致有三种：RXNE表示FIFO里有一个或多个有效数据；IDLE表示总线空闲，常用于判断一帧接收完成；ORE表示过载，也就是数据太多来不及读。驱动里应当把ORE当作一次接收重置信号，而不是简单地忽略。我在实际项目中遇到一次奇怪的卡顿现象：接收中断偶尔停止，后来发现问题是ISR里先执行了清标志操作，但数据寄存器因为某些原因没有成功读取，导致ORE置位后又没有处理。正确做法是进入ISR后先读取SR，如果ORE置位，不管数据是否有效，先把DR读掉，保证FIFO清空。
发送中断同样有讲究。TXE表示数据寄存器空，可以写下一个字节；TC表示发送移位寄存器完全移完，一帧真正结束。轮询发送可以一直查TC，但在中断里不要等TC，因为等待时间可能很长，会阻塞其他中断。正确做法是发送队列非空时，使能TXE中断，每次在TXE中断里从队列取一个字节写入DR，当队列空了就关闭TXE中断。这样可以确保不浪费一个字节的数据窗口。
3.3 DMA传输：什么时候该用DMA
DMA不是万能的，它适合传输量较大且吞吐要求较高的场景。比如GPS模块持续输出高频NMEA数据，或者蓝牙接收大量的音频日志，用中断模式的话每个字节都进一次ISR，CPU占用率可能到20%以上。反过来，如果只是几个调试命令交互，DMA的配置和同步逻辑反而增加了复杂度，中断模式足够。
使用DMA时要注意两点。第一，DMA通道的请求源要匹配。有的芯片UART接收DMA列表和发送DMA列表不同，配置错了会收不到数据。第二，结合UART的IDLE中断实现不定长接收。通常做法是：DMA工作在循环模式，把接收数据写入内存缓冲区；UART的IDLE中断在总线空闲时触发，此时读取DMA当前数据计数，减去上次位置，即可得到这一帧的有效长度。这个模式在Modbus或AT指令场景下特别好用。
3.4 波特率校准的实测经验
驱动写完后不要急着接业务，先用示波器量一下TX引脚波形。空闲时是高电平，起始位是一个低电平脉冲，其宽度就是1/波特率。比如配置115200，起始位低电平持续时间应该是8.68us左右。如果测出来是8.2us，说明波特率偏快；如果9.1us，说明偏慢。只要有示波器，这一步能直接发现问题，不用靠人眼猜乱码。
另一个经验：如果板卡上使用的是无源晶振而不是有源晶振，实际频率可能偏离标称值1000ppm以上，在115200下问题不大，但上到921600或者1M之后，误差会迅速放大。对付这种场景，应该通过测量多个字节的时间间隔来推算实际时钟频率，再重新计算分频系数，而不是拿着数据手册的频率值硬算。还可以把波特率配置成略低于标称值，给容错留出空间。实际工程中，很多“接上设备就乱码”的根源就在这里。
4. 调试UART驱动时容易踩的坑和排查方法
4.1 丢数据？先从波特率和FIFO查起
丢数据是我被问得最多的问题。如果上位机接收到的字节流里，每隔固定长度就缺一个字节，首先怀疑接收中断来不及响应。这里要区分两个层次：如果CPU被高优先级中断长时间占用，UART的接收FIFO会溢出，新数据直接丢弃；如果中断优先级设置不当，两个字节间隔很短，ISR还没进，硬件FIFO已经满了。解决办法是提高UART中断优先级，或者在硬件支持的情况下开启FIFO接收阈值，让多个字节攒够一次中断后再整体读取。
还有一个很隐蔽的坑：发送端在写入下一个字节之前，没确认TXE标志。如果直接连续写DR两次，第二个字节会覆盖前一个，上位机看到的就是乱码或者丢字节。这个过程在仿真器全速运行时不容易发现，因为CPU执行速度很快，但如果开了指令断点或者被其他中断打断，就会出现。我在调试时习惯在发送函数里加一个计数，配合逻辑分析仪看实际发送的字节数，非常直观。
4.2 回环测试为什么能过，接上设备就乱码
裸机调试时我都习惯先做回环测试：把TX和RX短接，跑一个自收发程序，验证驱动基本逻辑。但回环测试通过后接上设备就乱码的事情太常见了。第一类是共地问题，两个设备之间没有共同参考地，信号线上的压差漂移，导致采样错误。第二类是引脚接反，TX接TX、RX接RX，这种错误回环测试完全发现不了，因为本来就是短接的。第三类是电平不匹配，具体表现往往是没有数据或者烧毁引脚。
我建议在回环测试之后、接真实设备之前，加一步“半回环”验证：用逻辑分析仪或示波器看TX脚发出的波形，用解码功能确认波形里的帧正好和预期数据相同。这一步不需要对端设备，但能验证电平、波特率、极性都对。然后再接设备，如果还是乱码，就用逻辑分析仪夹在UART线和对方引脚之间，看信号到了对方接口后是否仍然正确。如果波形已经畸变，大概率是电平匹配或者线材问题，而不是软件问题。
4.3 用逻辑分析仪做时序分析
逻辑分析仪是我调试UART的必备工具。哪怕是几十块的USB逻辑分析仪，只要能解码UART协议，就能把波特率、帧格式、数据内容完全摊开。我的习惯是：在串口线上并联接入逻辑分析仪，不需要断开线缆，然后设置好和驱动配置一致的波特率，比如115200 8N1。如果解码出来的内容断续或乱码，可以看每个字节起始位的边沿间隔是否一致。如果间隔抖动很大，说明干扰严重或者是发送端CPU调度抖动导致。
逻辑分析仪还能直接验证流控信号。硬件流控下，RTS信号应该在数据进入时拉低还是拉高，不同芯片的极性定义可能不同。实际观察一下CTS输入和TX输出的对应关系，就能确定CTS是否被正确响应。这个排查手段比起看寄存器日志直观得多。我还习惯用逻辑分析仪抓“发送空档”，确认两个数据帧之间是否有足够间隙，防止对方按帧间隔来判断消息边界时出错。
4.4 流控信号没有正确配置导致的死锁
启用硬件流控后，最典型的故障是发送死等。比如对方把CTS拉低了，表示“我不能接收数据”，但你的驱动没有正确处理这个状态，只是一直在start_tx里检查CTS，然后永远清不了TXE，整个发送队列卡住。这通常出现在把硬件流控管脚接到了别的功能上，或者设备树里声明了uart-has-rtscts但底层没有把引脚复用成CTS功能。
排查时，先确认硬件上CTS引脚的电平是否正常。如果对端设备没有驱动CTS，引脚悬空，驱动会随机读到高或低。如果一定要用硬件流控，对端还必须共地并正确连接RTS/CTS。否则建议先禁用流控把链路跑通，确认数据收发稳定后再加上。还有一个经验：软件流控（XON/XOFF）在普通数据传输中尽量别用，因为0x11和0x13可能在二进制数据中偶然出现，导致协议解析错乱，工业通信里这是个大坑。
5. 从驱动到业务：环形缓冲区与数据分帧
5.1 为什么驱动程序里一定要有环形缓冲区
中断处理函数属于原子上下文，里面不能做耗时操作，比如解析协议、申请内存、打印日志，更不能调用可能睡眠的函数。但业务层需要串口数据完整连贯，所以最常见的做法是中断里只负责把字节放入环形缓冲区，由执行上下文（线程或main循环）取出来做后续处理。环形缓冲区本质是固定数组加两个指针，读指针和写指针，通过取模或位掩码来循环使用。
以位掩码方式为例，缓冲区大小必须是2的幂次。一个最简单但能工作的实现：
#define RBUF_SIZE 256 static uint8_t rbuf[RBUF_SIZE]; static volatile uint16_t head = 0; static volatile uint16_t tail = 0; static inline void rbuf_push(uint8_t c) { rbuf[head & (RBUF_SIZE - 1)] = c; head++; } static inline uint8_t rbuf_pop(void) { uint8_t c = rbuf[tail & (RBUF_SIZE - 1)]; tail++; return c; }实际项目里还要加满/空判断和互斥保护。在单核MCU上，如果在中断里push、在主循环里pop，那么push操作天然不会被普通代码打断，pop操作可能出现读到一半被中断更新的情况，所以对共享缓冲区的访问要关中断或者使用原子操作。在Linux内核驱动里则是spinlock配合关中断。很多丢数据问题不是波特率而是缓冲区溢出，写满后新数据被丢，却又没有溢出计数，排查时无从下手。我习惯在缓冲区结构体里加一个lost_count字段，溢出时累加，这个字段对分析突发流量非常有用。
5.2 数据粘包和拆包
UART本质是字节流，没有提供“帧”的概念。两个不同时刻发送的串（比如A帧和B帧）在接收端连在一起，就是常说的粘包。拆包思路有几种：固定帧长、特殊分隔符、帧头+长度字段+校验。GPS NMEA协议就是典型的分隔符法，以$开头，\r\n结尾，解析时逐字节判断状态机。Modbus RTU则是帧间隔加CRC，帧间静默时间少于3.5个字符周期就会被认为连续数据。
在驱动层面，我觉得最稳妥的是只提供字节流接口，不要强行在中断里做协议解析。因为协议可能变化，放驱动里会导致模块耦合太深。但底层可以做一个“以空闲中断作为帧边界”的辅助功能，比如STM32的IDLE中断，能把一批数据分成一段；Linux下可以用tty line discipline或者读取时配合超时处理。帧的合法性校验放在协议层，驱动层只负责数据完整性。这样驱动可复用性最高，业务层改动也不会影响底层。
5.3 用户态编程与驱动层配合
在嵌入式Linux里，很多情况下我们并不需要改内核驱动，直接在用户态操作/dev/ttyS0或/dev/ttyUSB0就行。配置串口的标准方式是termios结构体，比如设置原始模式、波特率、8N1：
struct termios opt; tcgetattr(fd, &opt); cfsetispeed(&opt, B115200); cfsetospeed(&opt, B115200); opt.c_cflag &= ~CSIZE; opt.c_cflag |= CS8; opt.c_cflag |= CLOCAL | CREAD; opt.c_cflag &= ~PARENB; opt.c_cflag &= ~CSTOPB; opt.c_cflag &= ~CRTSCTS; // 需要硬件流控时改为 |= CRTSCTS opt.c_lflag &= ~(ICANON | ECHO | ECHOE | ISIG); tcsetattr(fd, TCSANOW, &opt);读数据时不要用阻塞式read加sleep轮询，更不要用忙等。正确做法是用select/poll/epoll，设定一个超时时间，比如等待200ms，超时后就当作一帧接收完成。这样做既不会漏数据，也不会浪费CPU。用户态和驱动层的配合还有一个点：如果应用在中断密集型场景需要更低延迟，可以在驱动层把tty->low_latency置1，让收到的数据直接进入tty缓冲，减少调度延迟。这个参数在Documentation里有说明，但默认不开启，驱动人员要清楚它的代价和适用范围。
最后提一个我自己的习惯：无论裸机还是Linux，串口驱动写好后，先跑一遍压力测试——固定往缓冲区里灌数据，记录最大丢帧数和延迟抖动。这个测试过不了，后面做业务协议一定会出问题。UART驱动看着简单，真正做稳定需要把硬件时序、中断优先级、缓冲区策略全部串起来。第二期就先分享到这儿。
