做嵌入式或者物联网开发的朋友几乎没有不跟串口打交道的。我第一块开发板就是靠串口调试接口跑通的当时连波特率是什么都说不清只知道用 minicom 连上去满屏乱码折腾了一个晚上也没弄明白。后来一个老工程师走过来看了一眼屏幕甩给我一句话“波特率不对去把 Linux 的 stty 指令搞明白再来调。”那是我第一次意识到Linux 下串口调试的大部分问题不是“硬件坏没坏”而是“参数对不对”。而参数对不对这件事绝大多数时候都靠 stty 这一条命令来检查、设置和应用。它不需要你写几十行 C 代码也不需要装什么重型工具一条命令就能把波特率、数据位、停止位、校验位、流控这些底层参数一次性配到串口设备上。这篇文章我就把自己这些年用 stty 调串口的经验完整梳理一遍从参数原理到实战命令再到排错思路尽量让新手也能少走弯路。1. 串口联调被“乱码”支配的经历stty 为什么值得专门学那次被老工程师点醒之后我才正儿八经去翻了手册。stty 是 Unix 系操作系统里非常古老的终端设置命令全称是 setting the options for a terminal device interface放到现代 Linux 环境里最常见的用途就是配置串口设备。无论是 /dev/ttyUSB0 这种 USB 转串口还是 /dev/ttyS0 这种主板原生串口内核都会把它们当成一种“终端设备”来管理而 stty 就是用户态下操作这套终端参数最直接的入口。你不需要去 /dev 下创建设备节点设备节点早就由内核帮你建好了。你需要做的是通过 stty 告诉内核这个串口该用什么波特率、什么帧格式、开不开流控、要不要回显。这些参数直接决定了串口两端能不能正常“对话”。我之前遇到的那个乱码问题说白了就是开发板默认 115200而 minicom 打开的时候用了 9600两边说话节奏对不上收到的东西自然全是乱的。1.1 stty 到底在“改动”什么很多人误以为串口参数是“设备自身的属性”好像硬件烧录之后就固定在那儿了。真实情况完全不是这样。串口通信更像两个人临时约定暗号发送端和接收端都必须在同一套规则下工作谁也不能擅自改变。在硬件层面串口芯片本身并不保存波特率、数据位这些参数真正保存这些的是操作系统内核中对应的串口驱动结构。Linux 里串口设备驱动会维护一个 termios 结构体里面存放着波特率、字符大小、停止位、校验模式、流控模式、回显开关、原始模式等几十项设置。stty 命令行工具的本质就是一个封装好的前端它把你输入的一长串参数翻译成 termios 结构体对应的字段然后通过 ioctl 系统调用发给内核内核再把这些值写入串口控制器芯片的寄存器。明白这一层你就能理解为什么 stty 配置完参数以后立刻生效但设备重启或拔插后又会恢复默认。因为它只改了内核内存里的状态并没有写进 EEPROM 或者 Flash。这种机制也解释了为什么在自动化脚本里必须在程序 open() 串口之后、正式收发数据之前先完成一次 stty 初始化。1.2 stty 在整个串口调试链路中的位置串口调试链路可以分成三层物理层包括晶体振荡器、电平转换芯片、连接线驱动层包括内核里的 UART 驱动和 USB 转串口芯片驱动比如 pl2303、ch340、ft232 这些应用层包括 minicom、picocom、pyserial 脚本或者你自己写的 C 程序。stty 管理的是中间偏下的那一层。它不直接操作硬件寄存器而是通过内核驱动代劳它也通常不会自动收发数据只是给收发立下规则。规则没立对上面三层怎么努力都是白搭应用层打开串口读到的是乱码驱动层每收到一个字节都会产生错误状态位物理层的连接却还绷得紧紧的因为你根本没有按约定去解析对端发来的信号。所以我现在每次接手一个串口项目第一件事永远是先查 stty 参数再谈任何代码。把 stty 当成一面镜子串口设备当前认什么参数它一照便知。2. 串口参数到底在配什么波特率、帧格式、流控逐一拆解stty 的参数名有一大堆stty -a能打出一长串。新手看到容易头大其实真正需要理解的核心只有三大块波特率、帧格式、流控。其余的可以看作“终端行为开关”比如回显开关、规范模式开关、原始模式开关等串口场景下大多数时候直接设成 raw 就行但要理解每个参数为什么那样写还是得把它们归到这三类里来看。2.1 波特率通信双方的“说话节奏”波特率是串口通信里被提起最多、也最容易出问题的参数单位是 bpsbit per second表示串口每秒钟能传送多少个二进制位。常见取值有 9600、19200、38400、57600、115200、460800 等嵌入式领域用得最多的是 115200 和 9600。前者适合快速传输数据后者在长线环境里抗干扰能力更好。有一个细节经常被忽略很多人把波特率理解成“每秒传输的字节数”这不对。串口传输是分帧的每一帧除了数据位还要额外带起始位和停止位部分还要带校验位。以最经典的 8N1 为例也就是 8 个数据位、无校验、1 个停止位如果波特率是 115200那么每一帧实际占用 1 起始位 8 数据位 1 停止位合计 10 位。理论上每秒最多能传输的字节数是 115200 除以 10也就是 11520 字节。如果你想在 1 秒内通过 115200 波特率传输 2 万字节的数据物理上就不可能只能提到 460800 或者换更高效的协议。这种粗略估算在选型和方案评估时非常有用。我见过不少同事在配置 GPS 模块时把波特率设成 9600但模块出厂默认是 38400屏幕上跳出来的$GPGGA语句全是乱码他还在怪卫星信号差。先统一节奏再谈数据这是串口调试的黄金法则。2.2 数据位、停止位与校验位一帧数据的隐形契约串口通信按帧传输数据每一帧由起始位、数据位、停止位组成中间还可能有校验位。stty 命令里控制这些的规则如下数据位用cs5、cs6、cs7、cs8表示对应 5 到 8 位数据。停止位用-cstopb表示 1 位停止位cstopb表示 2 位停止位。校验位用-parenb表示无校验parenb表示启用校验。启用校验后还能继续选parodd表示奇校验-parodd表示偶校验。为什么大多数现代设备默认用 8N1因为 8 个数据位可以完整表达一个字节二进制数据方便而在校验位这个设计上它只能发现单比特翻转错误没法纠错对于现代数字通信来说性价比不高于是无校验成了主流。所以你在 stty 命令里最常见的组合就是115200 cs8 -cstopb -parenb也就是 8N1 帧格式。如果设备文档里要求 7 个数据位、偶校验、2 个停止位stty 命令就要写成这样stty -F /dev/ttyS0 9600 cs7 -cstopb parenb -parodd注意这里停止位是-cstopb还是cstopb很容易看反。在 stty 的语法里带-前缀代表取消该项不带前缀代表启用该项。-cstopb表示“不是一个停止位”也就是 1 个停止位cstopb表示 2 个停止位。我用这个做个小口诀带减号就是“关、小、单”不带减号就是“开、大、双”。2.3 流控防止发得快的那边把收得慢的淹没流控解决的是数据发送速度和接收能力不匹配的问题。发送方疯狂输出接收方的硬件缓冲区装不下数据就会丢。Linux 的 stty 配置里流控分两种硬件流控由 RTS/CTS 两根信号线承担对应 stty 的crtscts和-crtscts。启用后发送方发送前先检查接收方的 CTS 引脚是否有效接收方忙时拉低 CTS发送方便暂停等缓冲区有空再拉高 CTS 恢复。软件流控用 XON/XOFF 字符触发对应ixon、ixoff等参数。接收方缓冲区快满时向对方发 XOFF 字符通常是 0x13对方看到后暂停再发 XON也就是 0x11恢复传输。很多调试串口的人有个误解只要波特率设对数据就不会丢。实际上当数据量一大双方处理速度不一致缓冲区溢出丢包才是最常见的“疑难杂症”。如果设备支持硬件流控建议优先使用crtscts因为软件流控会占用 0x11 和 0x13 两个控制字符万一数据内容恰好出现这两个字节就会引发混乱。2.4 raw、echo、icanon透明传输需要关掉的“终端美化功能”stty -a里还有一些与数据透明性密切相关的开关重点组合是raw、-echo、-icanon。在串口通信里物理层已经帮你按字节收发数据但 Linux 终端子系统默认把串口设备当成“终端设备”对待会做行编辑、回显、信号处理。这些行为对“人机交互”的串口终端是有用的比如你通过串口登录路由器时敲下一个字符需要立刻回显到屏幕上但对于“设备之间通信”来说就是灾难程序可能读到被内核加工过的数据输出也可能被插入换行转换。stty raw会关闭终端行规约里大部分特殊处理把串口变成纯粹的字节管道。-echo关闭回显-icanon关闭规范模式让 read() 调用不用等换行符就能立刻读到数据。标准做法是stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb raw -echo这一行命令几乎能覆盖绝大多数串口设备通信的需求也是我写进无数脚本里的“初始化口诀”。3. stty 指令实战查看、设置、保存与恢复的正确姿势对参数有概念之后就进入动手环节。stty 语法表面看起来很简单但真正遇到问题时一两条命令很难一次到位。建议把下面几个操作练成肌肉记忆。3.1 先学会“看”-a 与 -F 的正确用法查参数有两个层次。不指定设备文件时stty -a显示的是当前终端设备的参数比如你正在用的 SSH 会话对应的 pty。要查看某个具体串口一定要加-F参数指定设备文件stty -F /dev/ttyUSB0 -a输出里关键信息集中在以下几行speed 115200 baud; rows 0; columns 0; line 0; intr ^C; quit ^\; erase ^?; kill ^U; eof ^D; eol undef; ... -parenb -parodd cs8 -cstopb hupcl -crmod crtscts -clocal -crtscts ... -echo -echoe -echok -echonl -icanon -iexten -opost -isig -ixon -ixoff我一般只看三个地方speed 这一行的波特率第二组 parenb、parodd、cs8、cstopb 代表的帧格式最后一行 -echo、-icanon、-ixon 这些终端行为开关。如果 speed 那一行显示speed 9600 baud说明设备当前认的是 9600如果你的程序段里写的是 115200那后面怎么调都白搭。stty -F /dev/ttyUSB0单独执行不带 -a只显示波特率和终端行规约摘要适合快速确认状态。我个人习惯是每次更换硬件或接线后先执行stty -F /dev/ttyUSB0 -a花 10 秒钟把 speed、cs、cstopb、parenb 四项念一遍再开始下一步操作。3.2 一次性配置到位的常用组合串口参数没有万能公式因为不同设备要求的帧格式不一样但常用组合就那么几套。按我开发中碰到频率从高到低列四个可以直接抄的模板设备场景波特率stty 参数绝大多数 MCU 串口、路由器调试口115200115200 cs8 -cstopb -parenb raw -echo老式工控仪表、PLC96009600 cs8 -cstopb parenb parodd -echoGPS 模块、传感器模组3840038400 cs8 -cstopb -parenb raw -echo高速数据透传如 4G 模块 AT 指令460800460800 cs8 -cstopb -parenb raw -echo执行方式stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb raw -echo参数顺序有讲究。我看到有人把波特率写在最后面stty -F /dev/ttyUSB0 cs8 -cstopb -parenb raw -echo 115200这种做法在多数发行版上也能生效但 stty 的参数是按顺序处理的裸数字本身会被解析成 speed 设置与其他标志位混在一起有解析歧义。稳妥起见把波特率放在所有标志位之前或者使用明确的speed 115200语法stty -F /dev/ttyUSB0 speed 115200 cs8 -cstopb -parenb raw -echo两种写法等效选一种固定下来即可。3.3 只想改一个参数时别每次都全量覆盖有时候你只想把校验位从无校验改成偶校验其他参数保持当前状态。最简单的做法是全量重跑一遍设置命令这没问题因为配置一次以后对硬件没有副作用。但如果脚本需要读取当前配置、动态决定修改哪一项就得掌握更精细的写法。查看当前是否开启硬件流控stty -F /dev/ttyUSB0 -a | grep crtscts单独开启或关闭硬件流控stty -F /dev/ttyUSB0 crtscts stty -F /dev/ttyUSB0 -crtscts单独关闭软件流控stty -F /dev/ttyUSB0 -ixon -ixoff这组操作特别适合“前一步临时改参数测试后一步用脚本恢复现场”的动态配置场景。另外提醒一句stty -F里的-F参数是 GNU/Linux 扩展老的 UNIX 和小型嵌入式环境里不一定支持。在 busybox 精简环境里用老式写法stty -a /dev/ttyUSB0和stty 115200 /dev/ttyUSB0兼容性更好。3.4 保存与恢复stty -g 配合脚本一键回滚stty 的配置不会写进任何持久化存储设备拔插或重启后就会回到内核默认值。如果产品要求开机自动把串口初始化成特定参数有两个常规办法一是写 systemd 服务在服务里执行 stty 配置二是程序本身通过 termios API 在 open() 之后立即配置。前者对多语言开发的产品尤其友好因为不需要在 C 代码里重复实现一套配置逻辑。stty 的 -g 选项可以把当前串口配置紧凑地导成一行字符串这是给机器恢复用的不是给人看的stty -F /dev/ttyUSB0 -g输出类似500:5:bf:8a3b:3:1c:7f:15:4:0:1:0:11:13:1a:0:12:f:17:16:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0:0恢复的姿势是包进子命令替换里stty -F /dev/ttyUSB0 $(stty -g -F /dev/ttyUSB0)这在“配置到一半发现参数更乱了”的情况下特别好用先把当前状态 -g 存起来测试完再一键恢复。我给不同的传感器设备保存参数快照时习惯写几个小文件切换测试时用stty -F /dev/ttyUSB0 $(cat snapshot1)这类命令恢复避免反复手敲一长串参数。4. 从 stty 到一套可用的串口工作流权限、工具与脚本配合串口调试不是输一条 stty 就能跑通的它更像一条流水线设备权限分配、串口参数初始化、数据收发工具选择、脚本自动化。这一节把流水线里容易出错的地方串起来讲。4.1 权限卡在 Permission denied 时该做什么Linux 对串口设备的权限管理是新手第一个遇到的坑。默认情况下 /dev/ttyUSB0 和 /dev/ttyS0 归属 dialout 组或 uucp 组不同发行版组名不一样。普通用户不在这个组里连stty -F /dev/ttyUSB0 -a都会报 Permission denied。解决办法有三条路把当前用户加入对应组然后重新登录sudo usermod -aG dialout $USER临时用 sudo 执行命令适合应急sudo stty -F /dev/ttyUSB0 -a用 udev 规则给设备单独授权适合产品部署echo KERNELttyUSB[0-9]*, MODE0666 | sudo tee /etc/udev/rules.d/99-serial.rules开发机推荐用第一种产品部署推荐用第三种。注意加入 dialout 组后必须注销重新登录或者重启会话组权限才会被当前会话接受这是很多人加了组却依然被拒的原因。4.2 与 minicom、picocom 工具配合的细节minicom、picocom 这类串口终端工具有自己的配置界面可以在里面直接设置波特率等参数。但它们的内核实现同样是调用 termios所以如果你在 minicom 里设好参数后开始乱码退出 minicom 后用 stty 查看当前实机参数通常能发现两者不一致。有个更实用的方法先用 stty 把底层参数设好再用 picocom 打开让它不要重复设置参数stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb raw -echo picocom -b 115200 --noreset /dev/ttyUSB0--noreset的意思就是 picocom 打开串口时不会把参数重置成自己的默认值而是沿用当前内核驱动里的配置。排查问题时这样少一个变量。还有一个坑minicom 退出时偶尔会把串口参数改回终端模式。如果你发现调试好好的串口过了一晚上突然变乱先想想是不是上次 minicom 退出时“顺手”改了参数。遇到这种情况重新执行一遍 stty 初始化即可。4.3 不装任何串口软件也能用 shell 直接收发串口调试不一定非得装 minicom。shell 里的 cat 和 echo 配合重定向就能完成基本收发。先把串口设好开一个终端监听cat /dev/ttyUSB0再开一个终端发送echo -n hello\r\n /dev/ttyUSB0如果你在给 4G 模块发 AT 指令发现模块不响应问题很可能是\r\n没带上。AT 指令集严格规定每行以回车换行结束你用默认的echo hi /dev/ttyUSB0只发了个hi\n很多模块根本不认。这种细节在用专门工具时会被透明处理用裸 shell 命令时就暴露出来了。另一种高效方式是使用 Python 的 pyserial它可以在打开串口时直接配置参数但它内部同样走 termios和 stty 管理的底层是一套东西import serial ser serial.Serial(/dev/ttyUSB0, 115200, timeout1) ser.write(bAT\r\n) print(ser.readline())在嵌入式板子的精简 Python 环境里如果 pyserial 没装你可以先用 stty 配好底层参数再配合 select 轮询、直接 read() 设备文件完成测试。理解了 stty 之后你会发现它其实是所有串口工具的地基。4.4 嵌入式 Linux 设备上stty 常驻但工具未必在路由器、开发板、Linux 网关这些嵌入式设备上stty 是 busybox 自带的基础命令即使系统精简到没有 minicom也一定会有 stty。这让我在调试无头设备时格外省心。最常见的嵌入式应用场景是查看某个调试串口当前参数、把系统日志输出到指定串口或者在系统启动脚本里初始化外接传感器串口。举个例子一个使用 systemd 的嵌入式系统可以用 service 在开机时初始化传感器串口[Unit] DescriptionInit sensor uart [Service] Typeoneshot ExecStart/bin/stty -F /dev/ttyS1 115200 cs8 -cstopb -parenb raw -echo ExecStart/bin/stty -F /dev/ttyS1 crtscts RemainAfterExityes [Install] WantedBymulti-user.target这样就能确保后面任何读写 /dev/ttyS1 的程序拿到的都是已经配置好的参数比在应用代码里用不同语言分别实现一套 termios 逻辑要省事得多也更容易在团队内统一维护。5. stty 显示配置正常但串口不工作一次完整的排查链路这一节可能是整篇里最实用的部分。我见过不少同学已经会用 stty波特率也设置对了但串口就是收发不正常。这种“参数对但数据不通”的问题排查链路比想象中要长。我把完整思路写出来每一步都对应一个可操作的方法。5.1 用回环测试快速定位故障层回环测试是串口排查的万金油。找一根杜邦线或者用金属镊子把串口的 TX 和 RX 两个引脚短接。这样设备自己发的数据会原样回到自己。短接之后如果还能正常收发说明串口控制器的收发通路基本没问题如果不通问题就出在硬件或者内核驱动这一层。Linux 下最简单的回环测试stty -F /dev/ttyUSB0 115200 cs8 -cstopb -parenb raw -echo cat /dev/ttyUSB0 echo loopback_test /dev/ttyUSB0几毫秒后cat 那端应该能读到 loopback_test。如果读不到先用 dmesg 看内核有没有报错dmesg | grep -i tty如果是 ft232、ch340、pl2303 这类 USB 转串口芯片驱动加载正常时 dmesg 里能看到设备注册信息。看不到说明驱动没装上或者硬件接触不良。这一步做完就能把问题从“应用层”剥离到“驱动或者硬件层”排查范围瞬间缩小。5.2 TX/RX 接线方向极容易犯的物理层错误回到文章开头那次经历。波特率匹配以后我又遇到过一次模块发数据电脑收不到。回环测试确认 USB 转串口本身没问题接回 MCU 还是没数据。后来拿示波器量 MCU 的 TX 引脚有波形但波形没进到电脑端的 RX。原因很直接——我把 TX 对 TX、RX 对 RX 直连了。两个设备通信必须交叉连接设备 A 的 TX 接设备 B 的 RX设备 A 的 RX 接设备 B 的 TX。如果中间加了交叉线或者转接板接法又不一样。直到今天我看到“能发不能收”或者“能收不能发”这样的问题第一反应永远是去查接线。这不是小白的低级错误我见过干了多年的工程师也犯过。5.3 stty 管参数setserial 管资源别把两者混为一谈有些串口芯片在 Linux 下还需要额外配置。经典例子是标准 16550A UART它的 FIFO 深度和中断触发方式由 setserial 来调整。stty 管的是线路参数setserial 管的是 I/O 端口、IRQ 和 FIFO两者职责不同。如果你操作的是老式板卡自带的 /dev/ttyS0并在高速状态下经常丢数据可以查看 setserial 配置setserial -g /dev/ttyS0然后把 FIFO 打开、自动配置资源sudo setserial /dev/ttyS0 autoconfig sudo setserial /dev/ttyS0 fifo对 USB 转串口设备一般不需要这一步因为驱动已经自动配置好了。但如果你维护的是工控机上的串口扩展板卡这类问题出现的概率会高不少。5.4 应用层读到的不只是乱码还可能是被内核“加工”过的数据最后一个坑比较隐蔽。stty 设置里-opost关闭输出处理、-echo关闭回显、-icrnl关闭回车换行转换、-inlcr关闭换行转回车这几个参数如果不一起设置Linux 终端子系统会在数据流中夹带私货。比如设备发来的\r0x0D被自动转换成\n0x0A上位机解析时就会看到换行符不对程序里输出\n时被自动补成\r\n下位机就会多收一个字节。stty raw会同时关闭输出处理和大部分输入转换所以串口通信推荐先执行 raw。但 raw 也会关闭-isig等信号处理这意味着按 CtrlC 不会像正常终端那样产生中断信号只会把 0x03 当作普通数据发给对方。调试时如果发现 CtrlC 无法中断卡住的读取进程不要惊讶关掉终端窗口或者把 -isig 重新加回来就行。整体排查顺序应该是先做回环测试确认硬件通路再检查 TX/RX 交叉接线然后用 stty -a 核对内核侧参数再看驱动和 setserial 配置最后确认应用层没有二次解析数据。按这个链路走九成以上的串口“假死”都能找到根因。6. 一点经验之谈把 stty 沉淀成自己的串口工具箱写了这么多最后分享几个我在实际项目中养成的习惯。第一永远在代码之外维护一份“串口配置清单”。项目里每接一个设备就把它的参数写进 README设备型号、波特率、帧格式、流控、关键 AT 指令、stty 初始化命令。下次调试时复制粘贴即可不用重新翻几百页的 datasheet。第二stty 配置最好由系统初始化脚本统一管理而不是散落在各种语言程序里。Python 里写一套 termios、C 里写一套 termios、Shell 脚本里再写一套三处定义很容易出现不一致。统一由 stty 的 systemd 初始化服务负责所有应用层代码只关心读写不用关心参数配置。第三调试时别一次改一堆参数。出现乱码先别急着把参数全改一遍先改成最标准的 115200 8N1确认链路通了再加回特殊配置。实测下来这个“先规范化、再特殊化”的流程比在错误参数基础上反复瞎试要快得多。串口调试的乐趣也在于此你以为自己在跟硬件打交道实际上是在跟一套看不见的协议契约打交道。把 stty 吃透了串口这边就再也没什么玄学了。