当前位置：首页 > news >正文

UART串口驱动框架：从一次深夜调试说起

news 2026/4/20 6:30:41

凌晨两点，示波器上的波形还在跳，串口就是不出数据。同事把逻辑分析仪往我桌上一放：“115200波特率，8N1，配置绝对没错，但tty设备就是没反应。” 我盯着内核日志里那句“ttyS0: tx fifo empty”，突然意识到问题不在硬件——驱动框架没吃透，调死都是白搭。

串口驱动的三层结构

Linux的UART驱动像个三明治。最上层是tty核心，提供/dev/ttyS*设备节点，处理行规程和用户空间IO。中间层是uart核心，实现统一的注册接口和tty操作集。最底层才是我们常写的平台相关驱动，负责操作具体的硬件寄存器。

// 典型的驱动初始化模板staticintmy_uart_probe(structplatform_device*pdev){structuart_port*port;// 1. 从设备树获取硬件信息port=devm_kzalloc(&pdev->dev,sizeof(*port),GFP_KERNEL);// 这里踩过坑：MEM资源要用devm_ioremap_resource，自己手写ioremap容易漏释放// 2. 填充port结构体port->ops=&my_uart_ops;// 关键操作集port->line=of_alias_get_id(pdev->dev.of_node,"serial");// line号别硬编码，设备树里用aliases节点分配更稳妥// 3. 注册到uart核心uart_add_one_port(&my_uart_driver,port);// 注册完不代表就能用了，还要看console是否配置正确}

那个让我熬通宵的fifo问题

回到开头的问题。硬件fifo大小为16字节，但驱动里写的fifosize = 1。为什么？因为早年抄的某个bsp模板就这么写的。结果就是tx中断疯狂触发，实际只发了1字节就报empty。

staticstructuart_opsmy_uart_ops={.tx_empty=my_tx_empty,// 这个函数要真实反映硬件状态.start_tx=my_start_tx,// 启动发送前一定要清空状态寄存器里的错误标志};

正确的做法是查芯片手册，找到fifo深度寄存器，或者直接写死真实的硬件值。更专业的做法是在probe里动态检测：先写满fifo再读可用空间。

中断处理里的门道

串口中断处理函数最容易写崩。有人图省事，在一个ISR里既处理接收又处理发送还处理错误，最后spin_lock没用好，系统偶尔卡死。

staticirqreturn_tmy_uart_interrupt(intirq,void*dev_id){structuart_port*port=dev_id;unsignedintstatus;spin_lock(&port->lock);status=readl(port->membase+REG_STATUS);// 顺序很重要：先错误再接收最后发送if(status&REG_STATUS_ERR){handle_errors(port,status);// 清错误标志要趁早}if(status&REG_STATUS_RX_READY){my_rx_chars(port);// 这里记得用tty_insert_flip_char}if(status&REG_STATUS_TX_READY){my_tx_chars(port);// 发完记得关tx中断，等下次start_tx再打开}spin_unlock(&port->lock);returnIRQ_HANDLED;}

控制台的那些坑

想让内核早期printk从你的串口输出？得实现console_write。这里有个细节：控制台写函数不能依赖中断，必须是纯轮询。因为早期中断系统还没初始化。

staticvoidmy_console_write(structconsole*co,constchar*s,unsignedintcount){structuart_port*port=&my_ports[co->index];// 关中断！这里用_local_irq_saveunsignedlongflags;local_irq_save(flags);// 直接操作硬件寄存器输出字符while(count--){while(!(readl(port->membase+REG_STATUS)&TX_READY))cpu_relax();// 忙等，别无选择writel(*s++,port->membase+REG_TX);}local_irq_restore(flags);}

设备树里要配好stdout-path，内核命令行要有console=ttyS0,115200。两个地方对不上，启动信息就可能跑到别的串口去。

流控不是摆设

产品到了现场，偶尔丢包。加打印发现是缓冲区溢出。硬件流控（RTS/CTS）没启用，软件流控（XON/XOFF）也没配。驱动里config_termios函数要认真实现：

staticvoidmy_config_port(structuart_port*port,intflags){// 检查硬件是否支持流控if(port->flags&UPF_HARD_FLOW){// 配置RTS/CTS引脚复用pinctrl_select_state(pinctrl,flow_ctrl_state);}// 软件流控更简单，但占用带宽if(termios->c_iflag&IXON){// 响应XON/XOFF字符}}