1. 为什么串口编程是C语言基本功的试金石做了几年嵌入式开发回头看串口编程我越来越确信一件事串口是检验C语言基础是否扎实最直接、最省钱的考场。很多人学C语言学完指针、结构体、内存管理觉得都会了一上手串口就露馅。不是串口难而是串口编程把所有C语言的核心知识点——指针、数组、结构体、位运算、文件I/O、内存布局——全部串在了一起逼着你用真功夫去解决一个又一个具体问题。串口UART到今天依然是嵌入式设备之间通信最常用的接口。传感器采集板、GPS模块、蓝牙模组、工业控制设备几乎都靠串口和主控芯片对话。而C语言作为嵌入式领域无可替代的第一语言写串口程序本身就是最正统的实践路径。热词里有人问Python这么火为什么计算机第一门专业课还是从C语言讲起答案很大程度就在这里语言的语法能速成但对内存、指针、底层机制的理解只有在C语言这种不遮遮掩掩的语言里才能练出来。串口编程则是最好的练兵场——你要直接操作文件描述符、配置终端参数、管理缓冲区、解析字节流每一个环节逃不掉。这篇笔记我尽量按实际开发中会遇到的问题来讲覆盖从API使用到数据帧解析再到排查踩坑的完整链路。适合正在学C语言但还没接触过嵌入式编程的人也适合写过串口程序但经常被莫名丢数据乱码折磨的开发者。我会把原理和代码放在一起说尽量说人话别的地方讲不清的我就拿自己踩过的坑来讲。2. 先搞懂串口在操作系统里到底是个什么东西在Linux环境里用C语言写串口程序第一件需要扭转认知的事情是串口在操作系统中是被当成一个文件来管理的具体来说是一个字符设备文件通常位于/dev/ttyS0、/dev/ttyUSB0、/dev/ttyAMA0之类的路径。你往这个文件里写字节数据就从串口TX引脚发出去别人往串口发数据你从这个文件里读字节就能拿到。这层抽象非常优雅但它也带来了很多既然它是文件那就得按文件的方式来理解的隐含规则。2.1 为什么说串口设备是字符设备而不是普通文件字符设备的特点是数据按字节流方式读写没有固定块大小没有随机访问能力。你可以把普通文件想象成一个图书馆可以在任意楼层任意书架取书随机读写但串口更像一条传送带货物按顺序流过来你只能站在传送带末端一件一件拿拿慢了就过去了。所以它的读写天然是顺序的而且数据不会自己等你。内核里对应的是tty层teletypewriter的缩写这个名字是从早期电传打字机时代传下来的一串协议栈帮你在用户空间和硬件之间做缓冲、调度。Linux内核的tty架构从上到下大致是用户空间的应用程序 → tty核心tty_core → 线路规程line discipline → 底层驱动uart driver → 物理串口控制器。线路规程是很多人忽略的一层它默认工作在N_TTY模式下会对输入数据做行缓冲、回显、信号字符处理等一堆面向人机交互的加工。我们做设备通信时要的只是裸的字节流所以必须关掉这些加工——这就是后面配置termios的原因。2.2 串口和普通文件的三个行为差异理解了串口是字符设备文件之后再看它和普通文件的区别就很重要了因为这几个差异直接决定代码怎么写普通文件读完了会返回EOF串口读不到数据时不会返回EOF而是阻塞默认行为或者返回-1。很多新手把串口当文件读理所当然地判断读返回0就是读完了结果程序卡死或者逻辑错乱。普通文件可以lseek到任意位置串口不能lseek数据流是单向消耗的。那字节读走了就没了不可能回头再读一遍。普通文件的写入基本靠内核帮你管理串口的写入速度受波特率限制可能写进去但没发完也可能缓冲区满导致写阻塞。这三条差异理解了后面遇到各种怪现象心里就有底了。串口程序写不好九成问题不是API没背会而是没理解它本质上是一个实时的、有速度限制的、单向消耗的字节管道。3. 核心API的正确打开方式open、read、write里的门道3.1 打开串口时最容易忽略的两个参数串口编程第一步是用open()打开设备文件。代码长这样int fd open(/dev/ttyUSB0, O_RDWR | O_NOCTTY | O_NDELAY); if (fd 0) { perror(open serial port failed); return -1; }三个标志缺一不可我逐个说说为什么。O_RDWR以读写方式打开这个不用解释。O_NOCTTY告诉系统这个终端不要成为本进程的控制终端。如果没有这个标志当进程是会话首进程比如守护进程时串口可能变成控制终端收到CtrlC之类的信号程序直接退出。做嵌入式采集程序经常要后台运行不加这个标志迟早踩坑。O_NDELAY等价于O_NONBLOCK表示打开时不等待DCD数据载波检测信号。有些串口设备上电后DCD不稳定不加这个标志open会一直阻塞看起来像程序卡死。加上之后open立即返回后面再单独用fcntl设置阻塞/非阻塞。打开之后别急着读写先保存一下当前的串口配置以便程序退出时恢复struct termios oldtio, newtio; tcgetattr(fd, oldtio); // 保存当前配置这个习惯非常值得养成因为如果程序异常退出串口留在原始模式终端会变得很怪尤其是不回显、不处理换行下次打开还是要重新配置甚至影响别的程序。3.2 read的阻塞与非阻塞直觉是反的很多人默认串口有数据才返回没数据就等于是把read放在一个while(1)循环里。但在默认阻塞模式下这句话没错问题在于等的方式——如果对端一直不发数据read就一直卡着你的程序什么都干不了。这对简单的收发demo没问题但要同时处理超时、显示、按键等逻辑就不够用了。所以实际项目中我通常用fcntl切换非阻塞模式int flags fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK);非阻塞模式下read的返回值有几种情况需要想清楚返回值 0实际读到的字节数。返回值 0没有数据可读不是读到文件末尾。这是新手最常误解的地方串口不会EOF返回0就是这会儿没数据。返回值 -1且errno EAGAIN或EWOULDBLOCK同样表示暂时没数据这是正常情况不是错误。正确的非阻塞读取套路是这样char buf[256]; int n read(fd, buf, sizeof(buf)); if (n 0) { // 处理读到的n个字节 } else if (n 0 (errno EAGAIN || errno EWOULDBLOCK)) { // 没有数据去做别的事情稍后再来读 } else { // 真正的错误比如fd被关闭 perror(read error); }3.3 write也不是每次都一次写完和read一样write也存在语义陷阱。write返回的字节数可能小于你请求写入的字节数尤其在串口缓冲区紧张或波特率很低时更容易出现。比如你调用write(fd, buf, 100)它可能只返回了34剩下66个字节还没写进去。如果你不检查返回值直接认为已经发出去了那对端永远等不到完整数据。所以稳妥的做法是循环写直到写完ssize_t write_all(int fd, const unsigned char *buf, size_t len) { size_t written 0; while (written len) { ssize_t n write(fd, buf written, len - written); if (n 0) { if (errno EAGAIN || errno EWOULDBLOCK) { usleep(1000); // 非阻塞模式下缓冲区满稍等再写 continue; } return -1; } written n; } return (ssize_t)written; }有经验的工程师写串口发送几乎都会封装一个类似的write_all函数。这不是过度设计是实际踩过write返回不完整的坑之后的条件反射。4. termios配置把串口调教成原始模式4.1 从行模式到原始模式一台终端到一根管道的转变默认情况下串口被内核当作一个终端设备来管理这意味着内核会做很多为人服务的处理。比如你从串口读到的是以换行符为边界的一行数据而不是原始字节流特殊字符比如CtrlC、CtrlZ会被解释成信号输入还会回显回发送端。这些特性在人用终端登入Linux的场景下非常好用但在单片机与Linux板卡通信的场景下全是灾难。所以做设备通信的第一件事就是把串口设置成原始模式raw mode。原始模式的含义是尽量不做任何加工数据原样进、原样出。代码一般像这样集中配置tcgetattr(fd, newtio); cfsetispeed(newtio, B115200); // 输入波特率 cfsetospeed(newtio, B115200); // 输出波特率 // 或者用 cfsetspeed(newtio, B115200); 一次设置两个方向 newtio.c_cflag | CLOCAL | CREAD; newtio.c_cflag ~CSIZE; newtio.c_cflag | CS8; // 8个数据位 newtio.c_cflag ~PARENB; // 无校验位 newtio.c_cflag ~CSTOPB; // 1个停止位 newtio.c_cflag ~CRTSCTS; // 禁用硬件流控 newtio.c_lflag ~(ICANON | ECHO | ECHOE | ISIG); // ICANON关闭规范模式读原始字节而不是按行读 // ECHO 关闭回显 // ISIG 关闭特殊字符产生的信号CtrlC等 newtio.c_iflag ~(IXON | IXOFF | IXANY | ICRNL | INLCR | IGNCR); // 关闭软件流控关闭回车换行转换 newtio.c_oflag ~OPOST; // 关闭输出处理不做\n到\r\n的转换 tcsetattr(fd, TCSANOW, newtio);这段代码基本是串口程序的标准开局。很多教程直接贴出来但不解释为什么。我拆开说一下最关键的几点c_cflag里的CLOCAL和CREADCLOCAL表示不监视调制解调器的状态线忽略DCD避免因为线路断开导致进程收到SIGHUP信号退出CREAD表示启用接收器允许串口接收数据。这俩不加通信行为会非常诡异。c_lflag的ICANON一定要关这是行模式和原始模式的分水岭。开着ICANON时内核会把收到的数据缓存到换行符或者缓冲区满才交给用户空间对设备通信来说延迟不可控。c_iflag的IXON/IXOFF这是软件流控XON/XOFF如果开着收到0x13XOFF会暂停发送收到0x11XON恢复发送。你的设备如果恰好要传输这类字节数据流会被莫名其妙中断。做数据链路时必须关掉。c_oflag的OPOST开着的话内核会把输出数据里的\n自动改成\r\n对二进制帧是致命的破坏。4.2 波特率、数据位、校验位、停止位一次说透串口通信的参数本质上就是通信双方的握手协议两边必须完全一致否则收出来的全是乱码。参数就四个参数常见取值说明波特率9600、57600、115200、921600每秒传输的符号数决定传输速度数据位5、6、7、8一帧中有效数据的位数常用8校验位无、奇校验、偶校验错误检测用增加1个校验位停止位1、1.5、2帧结束标志的电平持续时间这里要澄清一个长期存在的误解虽然CFLAG里有一个CBAUD位掩码来表示波特率但termios里设置波特率的正路是cfsetispeed和cfsetospeed而不是直接给c_cflag赋值。因为波特率值在不同平台上的编码不完全一致直接用数字#define宏更安全。另外需要注意在现代Linux上非标准波特率比如250000用cfsetispeed设不了需要用到termios2和BOTHER标志这是另一个话题初学者先用标准波特率就好。校验位是个有意思的取舍。加了校验位能检测单比特错误但代价是每帧多1个比特有效吞吐下降。更重要的是很多嵌入式设备默认就是8N18数据位、无校验、1停止位通信协议栈里本身有CRC校验所以物理层的偶校验/奇校验意义不大。我自己的项目绝大多数都是8N1除非设备手册明确要求别的格式。4.3 VTIME和VMIN阻塞式读取的超时保险丝termios结构体里有一对参数cc_t数组下标分别是VTIME和VMIN它们就像阻塞读取的超时保险丝。很多人不知道非阻塞模式下这俩参数是无效的只有在阻塞模式即fcntl里没设O_NONBLOCK下才有意义。VMIN和VTIME的组合规则如下VMIN 0, VTIME 0立即返回读不到数据返回0。和O_NONBLOCK行为类似。VMIN 0, VTIME 0阻塞直到读到VMIN个字节才返回。对端如果只发一半read可能长期卡住。VMIN 0, VTIME 0阻塞直到VTIME个0.1秒的超时时间过去期间只要有1个字节到达就立即返回。适合等不定长数据的场景。VMIN 0, VTIME 0读到至少VMIN个字节或者累计空闲时间超过VTIME才返回。这是我最常用的组合。注意这里的计时是从收到第一个字节后开始算的如果一直没有字节到达read会永远等下去。我用得比较多的是VMIN1, VTIME5含义是至少读1个字节读满前如果超过0.5秒没有新字节到达就返回已读到的内容。这样既能保证一次至少读到一个字节又不会因为帧尾迟迟不来而无限期阻塞非常契合串口协议帧不定长但帧间有间隔的特点。设置方法newtio.c_cc[VMIN] 1; newtio.c_cc[VTIME] 5;注意VTIME单位是0.1秒5就是0.5秒。这个组合理解透了你的串口读取逻辑会清晰很多不需要到处加usleep去猜数据什么时候到齐。5. 数据帧解析把一串裸字节变成有意义的数据配置好串口、能收发字节之后真正的工作才刚刚开始。串口通信不是发个字符串过去就算完真实场景里你要面对的是对端发来一段一段的协议帧你需要从连续不断的字节流里准确切出一帧、解析出字段、处理异常情况。这一节是我的重点也是串口编程里最见功力的一环。5.1 帧格式设计为什么帧头长度数据校验是标配我见过很多串口协议设计不管复杂还是简单几乎都逃不出一个经典模式0xAA 0x55 | LEN | CMD | DATA... | CRC 帧头 | 长度 | 命令 | 数据 | 校验帧头Frame Header一个或两个固定的魔数Magic Number比如0xAA 0x55用来帮助接收方找到一帧的起点。选两个字节做帧头能在一定程度上避免数据里恰好出现帧头字节造成的误判。长度Length指示后面数据部分的长度接收方根据它知道要收多少字节才算完整一帧。命令字CMD表示这一帧要干什么比如读传感器、写配置。数据DATA真正的业务数据可能包含采集值、地址、参数等。校验CRC/SUM对整帧做校验常见的是累加和SUM或者CRC16用来检测传输过程中有没有发生比特翻转。帧格式的设计其实是通信协议设计里最基础也最重要的一件事。我个人的建议是哪怕是内部两个板子之间的调试用协议也别偷懒省掉长度和校验字段。因为调试期间你一定会遇到收到一帧看起来差不多但总觉得有点不对劲的数据有长度字段可以帮你判断一帧是否完整有校验字段可以帮你判断数据有没有被破坏排查问题的速度快十倍。5.2 接收缓冲区的设计环形缓冲区的实用价值在读取串口数据时一个最常见的错误是来一个字节就处理一个字节。这在低速、低频、单任务的场景下勉强能跑但一旦数据量稍微大一点或者主程序还要做别的事情显示、存储、网络上报就会频繁丢数据。原因在于read只是从内核缓冲区拷贝数据拷贝不及时、处理不及时内核缓冲区满了新来的字节就被丢弃了。所以在稍微正式一点的项目里我习惯在应用程序里维护一个环形缓冲区Ring Buffer把read读到的原始数据先一股脑丢进去再用一个独立的状态机从缓冲区里抠帧出来。这样收发和处理解耦不会因为处理一帧数据耗时过长而丢掉后续的字节。一个简单的环形缓冲区实现可以这样#define RING_BUF_SIZE 4096 typedef struct { unsigned char buf[RING_BUF_SIZE]; volatile unsigned int head; // 写入位置 volatile unsigned int tail; // 读取位置 } ring_buffer_t; int rb_is_empty(const ring_buffer_t *rb) { return rb-head rb-tail; } int rb_is_full(const ring_buffer_t *rb) { return ((rb-head 1) % RING_BUF_SIZE) rb-tail; } int rb_write(ring_buffer_t *rb, unsigned char data) { if (rb_is_full(rb)) { return -1; // 缓冲区满丢数据 } rb-buf[rb-head] data; rb-head (rb-head 1) % RING_BUF_SIZE; return 0; } int rb_read(ring_buffer_t *rb, unsigned char *data) { if (rb_is_empty(rb)) { return -1; } *data rb-buf[rb-tail]; rb-tail (rb-tail 1) % RING_BUF_SIZE; return 0; }head指向下一个要写入的位置tail指向下一个要读出的位置。当head追上tail时缓冲区满tail追上head时缓冲区空。留一个空位来区分满和空是常用技巧否则这两个状态无法区分。接收线程里while循环read然后rb_write主逻辑里再从rb_read取字节做协议解析配合得天衣无缝。5.3 粘包和半包问题状态机解析是唯一靠谱的路串口数据的本质是无边界的字节流所以你会遇到两种很典型的现象粘包前一帧的最后一个字节和后一帧的第一个字节一次read全读出来了。半包一帧数据被拆成两次甚至多次read比如第一次只到了帧头和半个长度第二次才到齐。处理这两个问题的正路是用一个状态机来逐字节地组装一帧而不是根据read的返回结果判断一帧是否完整。状态机的核心逻辑是先找帧头找到帧头后进入收数据状态根据长度字段确定还要收多少字节收齐之后做校验校验通过才算完整一帧。用状态机实现帧解析的骨架typedef enum { FRAME_STATE_WAIT_HEAD1, // 等帧头第一个字节 FRAME_STATE_WAIT_HEAD2, // 等帧头第二个字节 FRAME_STATE_WAIT_LEN, // 等长度字段 FRAME_STATE_WAIT_DATA, // 收数据 FRAME_STATE_CHECK // 校验 } frame_state_t; typedef struct { frame_state_t state; unsigned char buf[256]; // 一帧的存储区 unsigned int len; // 长度字段值 unsigned int index; // 当前已收字节数 unsigned char crc; // 累加和 unsigned char crc_recv; // 接收到的校验字节 } frame_parser_t; int frame_parse_byte(frame_parser_t *fp, unsigned char byte, unsigned char *frame_out, unsigned int *frame_len) { switch (fp-state) { case FRAME_STATE_WAIT_HEAD1: if (byte 0xAA) { fp-state FRAME_STATE_WAIT_HEAD2; } break; case FRAME_STATE_WAIT_HEAD2: if (byte 0x55) { fp-state FRAME_STATE_WAIT_LEN; } else if (byte ! 0xAA) { fp-state FRAME_STATE_WAIT_HEAD1; // 不是帧头重新找 } break; case FRAME_STATE_WAIT_LEN: fp-len byte; fp-index 0; fp-crc 0; fp-state FRAME_STATE_WAIT_DATA; break; case FRAME_STATE_WAIT_DATA: fp-buf[fp-index] byte; fp-crc byte; if (fp-index fp-len) { fp-state FRAME_STATE_CHECK; } break; case FRAME_STATE_CHECK: fp-crc_recv byte; if (fp-crc fp-crc_recv) { memcpy(frame_out, fp-buf, fp-len); *frame_len fp-len; fp-state FRAME_STATE_WAIT_HEAD1; return 1; // 解析出完整一帧 } else { fp-state FRAME_STATE_WAIT_HEAD1; return -1; // 校验失败 } break; } return 0; }这个状态机每喂进一个字节就推进一下不依赖一次read读了多少数据天然免疫粘包和半包。主循环里从环形缓冲区读一个字节喂给frame_parse_byte返回1就说明得到一帧。这是我在实际项目中用过无数遍的框架非常稳。5.4 从字节数组到结构体一点对齐的小心机帧解析出数据区之后常见需求是把原始字节转换成C结构体方便业务代码访问。比如收到一帧温度湿度数据数据区是4个字节你自然想定义一个结构体#pragma pack(1) // 取消字节对齐按1字节对齐 typedef struct { int16_t temperature; // 2字节 uint16_t humidity; // 2字节 } sensor_data_t; #pragma pack()注意我在这里加了#pragma pack(1)。因为结构体默认会做内存对齐int16_t成员一般是2字节对齐两个int16_t成员之间通常不会插入填充字节但如果结构体里混着uint8_t和uint32_t默认对齐就会插入大量填充字节导致memcpy出来的数据完全错位。对串口这种逐字节传输的通信来说结构体对齐规则必须显式指定或者干脆不用memcpy而是手动按字节解析uint16_t temperature (uint16_t)buf[0] | ((uint16_t)buf[1] 8); uint16_t humidity (uint16_t)buf[2] | ((uint16_t)buf[3] 8);这种方式不受对齐规则影响可移植性最好也是我最推荐的方式。串口数据是字节流本质上是协议的物理层表现不该和某个具体编译器的内存布局绑定在一起。5.5 数据滤波串口数据里的毛刺怎么处理热词里有一条是c语言adc值滤波函数其实串口收到的传感器数据一样会带毛刺尤其当对端是ADC采集板时。一次采样的值可能因为电磁干扰跳变一下直接使用会带来很差的体验。我的做法是在解析出数据帧之后对关键数值做一次简单的滤波常用的有限幅滤波如果当前值与前一次值的差超过阈值就丢弃当前值用前一次值顶替。中位值滤波连续采集N个值排序后取中间值。适合剔除随机毛刺。滑动平均滤波维护一个长度为N的队列每次取平均值作为有效值。平滑效果好缺点是有滞后。这三种都是轻量级方案单片机或者Linux上都很容易实现不需要引入复杂的算法库。滑动平均滤波的代码很简单#define FILTER_N 8 typedef struct { int buf[FILTER_N]; int index; int count; long sum; } moving_average_t; int moving_average_filter(moving_average_t *ma, int value) { if (ma-count FILTER_N) { ma-buf[ma-count] value; ma-sum value; } else { ma-sum - ma-buf[ma-index]; ma-buf[ma-index] value; ma-sum value; ma-index (ma-index 1) % FILTER_N; } return (int)(ma-sum / ma-count); }每次解析到新的传感器值喂进去出来的就是滤波后的值直接拿去显示或控制。这只是个例子实际滤波方案要根据信号的特性来选择但思路是通用的在协议解析层之上加一个数据处理层把通信和业务剥离开。6. 我踩过的串口坑从乱码到丢数据的完整排查链路这一节算是我真正想写的内容。串口程序的坑很奇怪很多不是语法错误或者逻辑错误能解释的它们藏在系统的底层行为里。我把踩过的几个典型问题按排查思路写出来希望你遇到的时候能走得快一点。6.1 乱码先查波特率再查数据格式乱码是串口通信最经典的故障。我刚开始做的时候一看到乱码就紧张怀疑是不是硬件坏了后来总结出排查顺序基本一两分钟就能定位确认波特率是否一致这是乱码的第一大原因。两台设备设置的波特率不同采样时机错位解出来的全是乱码。确认数据位、校验位、停止位是否一致8N1是最常见的但也有的设备默认7E17数据位偶校验1停止位少了一位解析自然不对。确认是不是接到了错误的引脚TX接TX是另一个经典误区。串口是交叉连接的A设备的TX接B设备的RXA设备的RX接B设备的TX。共地也很重要两边地线不连通信时好时坏乱码概率直线上升。用示波器/逻辑分析仪看波形如果参数全对了还乱码就得用工具看实际波形。示波器能直接读出每一位的电平宽度波特率到底标不标一眼就能看出来。我遇到过一次晶振偏差导致波特率偏移2%的问题就是靠示波器量出来的。6.2 丢数据缓冲区跟不上时先想清楚数据量再动手丢数据分两种一种是偶发丢一两个字节一种是数据一大就丢、一小就不丢。后者通常是缓冲区处理不过来。数据一大就丢的根因多数情况是应用层读取速度跟不上串口硬件接收速度。举个例子波特率115200每个字节10位8数据位1起始位1停止位1秒最多传11520字节。Linux内核串口驱动有自己的缓冲区如果应用层来不及read内核缓冲区满了之后后续来的数据就会被直接丢弃。read调用之间隔了多长时间决定了你最多丢多少字节。假如你每隔50ms才read一次一次最多能读到的字节数大约是11520×0.05576字节超过这个量就会丢。处理思路有几个可以叠加使用提高read的调用频率把串口接收放到独立线程里阻塞等待数据一有read返回就及时拷贝到环形缓冲区。这是最根本的解法。增大内核缓冲区有的平台可以修改线路规程的缓冲策略但可移植性差不如做好应用层及时读取。降低波特率如果业务允许9600波特率下每秒只有960字节处理压力小很多。启用硬件流控如果双方都支持RTS/CTS打开硬件流控可以在接收端缓冲区快满时通知对端暂停发送。这在高速率大数据量传输时很有用但前提是两边都接线并且都支持。6.3 程序退出后串口行为怪异恢复原始配置有一次我写了个串口测试程序运行过程中按CtrlC强制退出再打开串口工具收发数据发现一切正常但就是不回显、发送不出去。重启程序也不行。后来想到是之前程序退出时没有恢复termios配置把串口留在了raw mode。终端工具再打开时tcgetattr读到的是残留的raw mode配置行为当然就不对了。所以有两个习惯一定要养成程序退出前用tcsetattr恢复旧的termios配置。收到SIGINT、SIGTERM信号时在信号处理函数里也做同样的恢复操作。static struct termios g_oldtio; void signal_handler(int sig) { int fd ...; // 保存全局fd tcsetattr(fd, TCSANOW, g_oldtio); close(fd); exit(0); } signal(SIGINT, signal_handler); signal(SIGTERM, signal_handler);6.4 帧同步丢失一处状态复位整条链路恢复还有一个我调试了很久的问题设备重启后主控这边收到的数据突然全是帧头找不到状态机一直卡在WAIT_HEAD1状态。排查发现是设备重启的瞬间发送了一半的帧主控侧状态机收到了帧头第一个字节0xAA但第二个字节没等到因为设备已经重启后面新帧的0xAA 0x55到来时第二个0xAA被当成帧头第二个字节的候选处理了——因为我的状态机里对第二个字节的判断是如果不是0x55就看是不是0xAA是0xAA就留在WAIT_HEAD2所以新帧的0xAA和旧帧残留的0xAA之间错位状态机走不出来了。解决办法也不复杂给状态机加一个如果WAIT_HEAD2状态超过N个字节没有匹配到0x55就强制回到WAIT_HEAD1的超时逻辑或者更简单粗暴——在WAIT_HEAD2状态下如果连续遇到几个非0x55字节就复位。这其实反映了一个通用原则协议解析状态机必须具有自恢复能力任何不匹配的情况都要能回到初始状态重新同步否则故障会让通信永久卡死。7. 从串口聊开去它给你的远不只是会调串口串口编程这门手艺往小了说是几个API的调用往大了说是嵌入式开发思维方式的一个缩影。指针与数组的关系在缓冲区管理那里体现得淋漓尽致结构体和内存对齐在数据帧解析那里逼着你重新看书内存管理和资源释放在open/close、malloc/free的配对里反复强调甚至热词里提到的函数指针、递归、文件读写都能在串口协议栈的场景里找到落点。所以我说串口是C语言基础能力的试金石一点不夸张。如果你正在学C语言学完语法之后不知道下一步练什么我的建议是买一块带串口的开发板或者用电脑USB转串口接一个MCU最小系统板给自己定义一个简单的通信协议从点灯、回显、传感器数据上报开始一步步把收发、帧解析、CRC校验、状态机这些组件写出来。这个过程练的东西比刷一百道PTA字符串逆序题值钱得多。如果你已经写过串口程序我想分享的一个体会是别满足于能跑通试着按可移植、可复用、抗干扰的标准重构一遍。把串口配置抽成独立模块把帧解析写成状态机把缓冲区换成环形缓冲把对数据的处理从收到就用改成校验通过再用。等你做完这些你会发现后面再去做网络通信、USB通信、CAN通信套路惊人的相似——无非是配置物理层 读写接口 协议状态机 数据分发这套组合拳。串口不高级但它足够深。踩过这些坑学到的东西比想象的多。最后再提一句调试阶段先接逻辑分析仪或者示波器确认物理层没问题再谈代码逻辑。这个顺序反了你会在自己的代码和硬件故障之间来回折腾浪费时间不说还容易怀疑人生。 C语言串口编程实战：从字符设备到数据帧解析
1. 为什么串口编程是C语言基本功的试金石做了几年嵌入式开发回头看串口编程我越来越确信一件事串口是检验C语言基础是否扎实最直接、最省钱的考场。很多人学C语言学完指针、结构体、内存管理觉得都会了一上手串口就露馅。不是串口难而是串口编程把所有C语言的核心知识点——指针、数组、结构体、位运算、文件I/O、内存布局——全部串在了一起逼着你用真功夫去解决一个又一个具体问题。串口UART到今天依然是嵌入式设备之间通信最常用的接口。传感器采集板、GPS模块、蓝牙模组、工业控制设备几乎都靠串口和主控芯片对话。而C语言作为嵌入式领域无可替代的第一语言写串口程序本身就是最正统的实践路径。热词里有人问Python这么火为什么计算机第一门专业课还是从C语言讲起答案很大程度就在这里语言的语法能速成但对内存、指针、底层机制的理解只有在C语言这种不遮遮掩掩的语言里才能练出来。串口编程则是最好的练兵场——你要直接操作文件描述符、配置终端参数、管理缓冲区、解析字节流每一个环节逃不掉。这篇笔记我尽量按实际开发中会遇到的问题来讲覆盖从API使用到数据帧解析再到排查踩坑的完整链路。适合正在学C语言但还没接触过嵌入式编程的人也适合写过串口程序但经常被莫名丢数据乱码折磨的开发者。我会把原理和代码放在一起说尽量说人话别的地方讲不清的我就拿自己踩过的坑来讲。2. 先搞懂串口在操作系统里到底是个什么东西在Linux环境里用C语言写串口程序第一件需要扭转认知的事情是串口在操作系统中是被当成一个文件来管理的具体来说是一个字符设备文件通常位于/dev/ttyS0、/dev/ttyUSB0、/dev/ttyAMA0之类的路径。你往这个文件里写字节数据就从串口TX引脚发出去别人往串口发数据你从这个文件里读字节就能拿到。这层抽象非常优雅但它也带来了很多既然它是文件那就得按文件的方式来理解的隐含规则。2.1 为什么说串口设备是字符设备而不是普通文件字符设备的特点是数据按字节流方式读写没有固定块大小没有随机访问能力。你可以把普通文件想象成一个图书馆可以在任意楼层任意书架取书随机读写但串口更像一条传送带货物按顺序流过来你只能站在传送带末端一件一件拿拿慢了就过去了。所以它的读写天然是顺序的而且数据不会自己等你。内核里对应的是tty层teletypewriter的缩写这个名字是从早期电传打字机时代传下来的一串协议栈帮你在用户空间和硬件之间做缓冲、调度。Linux内核的tty架构从上到下大致是用户空间的应用程序 → tty核心tty_core → 线路规程line discipline → 底层驱动uart driver → 物理串口控制器。线路规程是很多人忽略的一层它默认工作在N_TTY模式下会对输入数据做行缓冲、回显、信号字符处理等一堆面向人机交互的加工。我们做设备通信时要的只是裸的字节流所以必须关掉这些加工——这就是后面配置termios的原因。2.2 串口和普通文件的三个行为差异理解了串口是字符设备文件之后再看它和普通文件的区别就很重要了因为这几个差异直接决定代码怎么写普通文件读完了会返回EOF串口读不到数据时不会返回EOF而是阻塞默认行为或者返回-1。很多新手把串口当文件读理所当然地判断读返回0就是读完了结果程序卡死或者逻辑错乱。普通文件可以lseek到任意位置串口不能lseek数据流是单向消耗的。那字节读走了就没了不可能回头再读一遍。普通文件的写入基本靠内核帮你管理串口的写入速度受波特率限制可能写进去但没发完也可能缓冲区满导致写阻塞。这三条差异理解了后面遇到各种怪现象心里就有底了。串口程序写不好九成问题不是API没背会而是没理解它本质上是一个实时的、有速度限制的、单向消耗的字节管道。3. 核心API的正确打开方式open、read、write里的门道3.1 打开串口时最容易忽略的两个参数串口编程第一步是用open()打开设备文件。代码长这样int fd open(/dev/ttyUSB0, O_RDWR | O_NOCTTY | O_NDELAY); if (fd 0) { perror(open serial port failed); return -1; }三个标志缺一不可我逐个说说为什么。O_RDWR以读写方式打开这个不用解释。O_NOCTTY告诉系统这个终端不要成为本进程的控制终端。如果没有这个标志当进程是会话首进程比如守护进程时串口可能变成控制终端收到CtrlC之类的信号程序直接退出。做嵌入式采集程序经常要后台运行不加这个标志迟早踩坑。O_NDELAY等价于O_NONBLOCK表示打开时不等待DCD数据载波检测信号。有些串口设备上电后DCD不稳定不加这个标志open会一直阻塞看起来像程序卡死。加上之后open立即返回后面再单独用fcntl设置阻塞/非阻塞。打开之后别急着读写先保存一下当前的串口配置以便程序退出时恢复struct termios oldtio, newtio; tcgetattr(fd, oldtio); // 保存当前配置这个习惯非常值得养成因为如果程序异常退出串口留在原始模式终端会变得很怪尤其是不回显、不处理换行下次打开还是要重新配置甚至影响别的程序。3.2 read的阻塞与非阻塞直觉是反的很多人默认串口有数据才返回没数据就等于是把read放在一个while(1)循环里。但在默认阻塞模式下这句话没错问题在于等的方式——如果对端一直不发数据read就一直卡着你的程序什么都干不了。这对简单的收发demo没问题但要同时处理超时、显示、按键等逻辑就不够用了。所以实际项目中我通常用fcntl切换非阻塞模式int flags fcntl(fd, F_GETFL, 0); fcntl(fd, F_SETFL, flags | O_NONBLOCK);非阻塞模式下read的返回值有几种情况需要想清楚返回值 0实际读到的字节数。返回值 0没有数据可读不是读到文件末尾。这是新手最常误解的地方串口不会EOF返回0就是这会儿没数据。返回值 -1且errno EAGAIN或EWOULDBLOCK同样表示暂时没数据这是正常情况不是错误。正确的非阻塞读取套路是这样char buf[256]; int n read(fd, buf, sizeof(buf)); if (n 0) { // 处理读到的n个字节 } else if (n 0 (errno EAGAIN || errno EWOULDBLOCK)) { // 没有数据去做别的事情稍后再来读 } else { // 真正的错误比如fd被关闭 perror(read error); }3.3 write也不是每次都一次写完和read一样write也存在语义陷阱。write返回的字节数可能小于你请求写入的字节数尤其在串口缓冲区紧张或波特率很低时更容易出现。比如你调用write(fd, buf, 100)它可能只返回了34剩下66个字节还没写进去。如果你不检查返回值直接认为已经发出去了那对端永远等不到完整数据。所以稳妥的做法是循环写直到写完ssize_t write_all(int fd, const unsigned char *buf, size_t len) { size_t written 0; while (written len) { ssize_t n write(fd, buf written, len - written); if (n 0) { if (errno EAGAIN || errno EWOULDBLOCK) { usleep(1000); // 非阻塞模式下缓冲区满稍等再写 continue; } return -1; } written n; } return (ssize_t)written; }有经验的工程师写串口发送几乎都会封装一个类似的write_all函数。这不是过度设计是实际踩过write返回不完整的坑之后的条件反射。4. termios配置把串口调教成原始模式4.1 从行模式到原始模式一台终端到一根管道的转变默认情况下串口被内核当作一个终端设备来管理这意味着内核会做很多为人服务的处理。比如你从串口读到的是以换行符为边界的一行数据而不是原始字节流特殊字符比如CtrlC、CtrlZ会被解释成信号输入还会回显回发送端。这些特性在人用终端登入Linux的场景下非常好用但在单片机与Linux板卡通信的场景下全是灾难。所以做设备通信的第一件事就是把串口设置成原始模式raw mode。原始模式的含义是尽量不做任何加工数据原样进、原样出。代码一般像这样集中配置tcgetattr(fd, newtio); cfsetispeed(newtio, B115200); // 输入波特率 cfsetospeed(newtio, B115200); // 输出波特率 // 或者用 cfsetspeed(newtio, B115200); 一次设置两个方向 newtio.c_cflag | CLOCAL | CREAD; newtio.c_cflag ~CSIZE; newtio.c_cflag | CS8; // 8个数据位 newtio.c_cflag ~PARENB; // 无校验位 newtio.c_cflag ~CSTOPB; // 1个停止位 newtio.c_cflag ~CRTSCTS; // 禁用硬件流控 newtio.c_lflag ~(ICANON | ECHO | ECHOE | ISIG); // ICANON关闭规范模式读原始字节而不是按行读 // ECHO 关闭回显 // ISIG 关闭特殊字符产生的信号CtrlC等 newtio.c_iflag ~(IXON | IXOFF | IXANY | ICRNL | INLCR | IGNCR); // 关闭软件流控关闭回车换行转换 newtio.c_oflag ~OPOST; // 关闭输出处理不做\n到\r\n的转换 tcsetattr(fd, TCSANOW, newtio);这段代码基本是串口程序的标准开局。很多教程直接贴出来但不解释为什么。我拆开说一下最关键的几点c_cflag里的CLOCAL和CREADCLOCAL表示不监视调制解调器的状态线忽略DCD避免因为线路断开导致进程收到SIGHUP信号退出CREAD表示启用接收器允许串口接收数据。这俩不加通信行为会非常诡异。c_lflag的ICANON一定要关这是行模式和原始模式的分水岭。开着ICANON时内核会把收到的数据缓存到换行符或者缓冲区满才交给用户空间对设备通信来说延迟不可控。c_iflag的IXON/IXOFF这是软件流控XON/XOFF如果开着收到0x13XOFF会暂停发送收到0x11XON恢复发送。你的设备如果恰好要传输这类字节数据流会被莫名其妙中断。做数据链路时必须关掉。c_oflag的OPOST开着的话内核会把输出数据里的\n自动改成\r\n对二进制帧是致命的破坏。4.2 波特率、数据位、校验位、停止位一次说透串口通信的参数本质上就是通信双方的握手协议两边必须完全一致否则收出来的全是乱码。参数就四个参数常见取值说明波特率9600、57600、115200、921600每秒传输的符号数决定传输速度数据位5、6、7、8一帧中有效数据的位数常用8校验位无、奇校验、偶校验错误检测用增加1个校验位停止位1、1.5、2帧结束标志的电平持续时间这里要澄清一个长期存在的误解虽然CFLAG里有一个CBAUD位掩码来表示波特率但termios里设置波特率的正路是cfsetispeed和cfsetospeed而不是直接给c_cflag赋值。因为波特率值在不同平台上的编码不完全一致直接用数字#define宏更安全。另外需要注意在现代Linux上非标准波特率比如250000用cfsetispeed设不了需要用到termios2和BOTHER标志这是另一个话题初学者先用标准波特率就好。校验位是个有意思的取舍。加了校验位能检测单比特错误但代价是每帧多1个比特有效吞吐下降。更重要的是很多嵌入式设备默认就是8N18数据位、无校验、1停止位通信协议栈里本身有CRC校验所以物理层的偶校验/奇校验意义不大。我自己的项目绝大多数都是8N1除非设备手册明确要求别的格式。4.3 VTIME和VMIN阻塞式读取的超时保险丝termios结构体里有一对参数cc_t数组下标分别是VTIME和VMIN它们就像阻塞读取的超时保险丝。很多人不知道非阻塞模式下这俩参数是无效的只有在阻塞模式即fcntl里没设O_NONBLOCK下才有意义。VMIN和VTIME的组合规则如下VMIN 0, VTIME 0立即返回读不到数据返回0。和O_NONBLOCK行为类似。VMIN 0, VTIME 0阻塞直到读到VMIN个字节才返回。对端如果只发一半read可能长期卡住。VMIN 0, VTIME 0阻塞直到VTIME个0.1秒的超时时间过去期间只要有1个字节到达就立即返回。适合等不定长数据的场景。VMIN 0, VTIME 0读到至少VMIN个字节或者累计空闲时间超过VTIME才返回。这是我最常用的组合。注意这里的计时是从收到第一个字节后开始算的如果一直没有字节到达read会永远等下去。我用得比较多的是VMIN1, VTIME5含义是至少读1个字节读满前如果超过0.5秒没有新字节到达就返回已读到的内容。这样既能保证一次至少读到一个字节又不会因为帧尾迟迟不来而无限期阻塞非常契合串口协议帧不定长但帧间有间隔的特点。设置方法newtio.c_cc[VMIN] 1; newtio.c_cc[VTIME] 5;注意VTIME单位是0.1秒5就是0.5秒。这个组合理解透了你的串口读取逻辑会清晰很多不需要到处加usleep去猜数据什么时候到齐。5. 数据帧解析把一串裸字节变成有意义的数据配置好串口、能收发字节之后真正的工作才刚刚开始。串口通信不是发个字符串过去就算完真实场景里你要面对的是对端发来一段一段的协议帧你需要从连续不断的字节流里准确切出一帧、解析出字段、处理异常情况。这一节是我的重点也是串口编程里最见功力的一环。5.1 帧格式设计为什么帧头长度数据校验是标配我见过很多串口协议设计不管复杂还是简单几乎都逃不出一个经典模式0xAA 0x55 | LEN | CMD | DATA... | CRC 帧头 | 长度 | 命令 | 数据 | 校验帧头Frame Header一个或两个固定的魔数Magic Number比如0xAA 0x55用来帮助接收方找到一帧的起点。选两个字节做帧头能在一定程度上避免数据里恰好出现帧头字节造成的误判。长度Length指示后面数据部分的长度接收方根据它知道要收多少字节才算完整一帧。命令字CMD表示这一帧要干什么比如读传感器、写配置。数据DATA真正的业务数据可能包含采集值、地址、参数等。校验CRC/SUM对整帧做校验常见的是累加和SUM或者CRC16用来检测传输过程中有没有发生比特翻转。帧格式的设计其实是通信协议设计里最基础也最重要的一件事。我个人的建议是哪怕是内部两个板子之间的调试用协议也别偷懒省掉长度和校验字段。因为调试期间你一定会遇到收到一帧看起来差不多但总觉得有点不对劲的数据有长度字段可以帮你判断一帧是否完整有校验字段可以帮你判断数据有没有被破坏排查问题的速度快十倍。5.2 接收缓冲区的设计环形缓冲区的实用价值在读取串口数据时一个最常见的错误是来一个字节就处理一个字节。这在低速、低频、单任务的场景下勉强能跑但一旦数据量稍微大一点或者主程序还要做别的事情显示、存储、网络上报就会频繁丢数据。原因在于read只是从内核缓冲区拷贝数据拷贝不及时、处理不及时内核缓冲区满了新来的字节就被丢弃了。所以在稍微正式一点的项目里我习惯在应用程序里维护一个环形缓冲区Ring Buffer把read读到的原始数据先一股脑丢进去再用一个独立的状态机从缓冲区里抠帧出来。这样收发和处理解耦不会因为处理一帧数据耗时过长而丢掉后续的字节。一个简单的环形缓冲区实现可以这样#define RING_BUF_SIZE 4096 typedef struct { unsigned char buf[RING_BUF_SIZE]; volatile unsigned int head; // 写入位置 volatile unsigned int tail; // 读取位置 } ring_buffer_t; int rb_is_empty(const ring_buffer_t *rb) { return rb-head rb-tail; } int rb_is_full(const ring_buffer_t *rb) { return ((rb-head 1) % RING_BUF_SIZE) rb-tail; } int rb_write(ring_buffer_t *rb, unsigned char data) { if (rb_is_full(rb)) { return -1; // 缓冲区满丢数据 } rb-buf[rb-head] data; rb-head (rb-head 1) % RING_BUF_SIZE; return 0; } int rb_read(ring_buffer_t *rb, unsigned char *data) { if (rb_is_empty(rb)) { return -1; } *data rb-buf[rb-tail]; rb-tail (rb-tail 1) % RING_BUF_SIZE; return 0; }head指向下一个要写入的位置tail指向下一个要读出的位置。当head追上tail时缓冲区满tail追上head时缓冲区空。留一个空位来区分满和空是常用技巧否则这两个状态无法区分。接收线程里while循环read然后rb_write主逻辑里再从rb_read取字节做协议解析配合得天衣无缝。5.3 粘包和半包问题状态机解析是唯一靠谱的路串口数据的本质是无边界的字节流所以你会遇到两种很典型的现象粘包前一帧的最后一个字节和后一帧的第一个字节一次read全读出来了。半包一帧数据被拆成两次甚至多次read比如第一次只到了帧头和半个长度第二次才到齐。处理这两个问题的正路是用一个状态机来逐字节地组装一帧而不是根据read的返回结果判断一帧是否完整。状态机的核心逻辑是先找帧头找到帧头后进入收数据状态根据长度字段确定还要收多少字节收齐之后做校验校验通过才算完整一帧。用状态机实现帧解析的骨架typedef enum { FRAME_STATE_WAIT_HEAD1, // 等帧头第一个字节 FRAME_STATE_WAIT_HEAD2, // 等帧头第二个字节 FRAME_STATE_WAIT_LEN, // 等长度字段 FRAME_STATE_WAIT_DATA, // 收数据 FRAME_STATE_CHECK // 校验 } frame_state_t; typedef struct { frame_state_t state; unsigned char buf[256]; // 一帧的存储区 unsigned int len; // 长度字段值 unsigned int index; // 当前已收字节数 unsigned char crc; // 累加和 unsigned char crc_recv; // 接收到的校验字节 } frame_parser_t; int frame_parse_byte(frame_parser_t *fp, unsigned char byte, unsigned char *frame_out, unsigned int *frame_len) { switch (fp-state) { case FRAME_STATE_WAIT_HEAD1: if (byte 0xAA) { fp-state FRAME_STATE_WAIT_HEAD2; } break; case FRAME_STATE_WAIT_HEAD2: if (byte 0x55) { fp-state FRAME_STATE_WAIT_LEN; } else if (byte ! 0xAA) { fp-state FRAME_STATE_WAIT_HEAD1; // 不是帧头重新找 } break; case FRAME_STATE_WAIT_LEN: fp-len byte; fp-index 0; fp-crc 0; fp-state FRAME_STATE_WAIT_DATA; break; case FRAME_STATE_WAIT_DATA: fp-buf[fp-index] byte; fp-crc byte; if (fp-index fp-len) { fp-state FRAME_STATE_CHECK; } break; case FRAME_STATE_CHECK: fp-crc_recv byte; if (fp-crc fp-crc_recv) { memcpy(frame_out, fp-buf, fp-len); *frame_len fp-len; fp-state FRAME_STATE_WAIT_HEAD1; return 1; // 解析出完整一帧 } else { fp-state FRAME_STATE_WAIT_HEAD1; return -1; // 校验失败 } break; } return 0; }这个状态机每喂进一个字节就推进一下不依赖一次read读了多少数据天然免疫粘包和半包。主循环里从环形缓冲区读一个字节喂给frame_parse_byte返回1就说明得到一帧。这是我在实际项目中用过无数遍的框架非常稳。5.4 从字节数组到结构体一点对齐的小心机帧解析出数据区之后常见需求是把原始字节转换成C结构体方便业务代码访问。比如收到一帧温度湿度数据数据区是4个字节你自然想定义一个结构体#pragma pack(1) // 取消字节对齐按1字节对齐 typedef struct { int16_t temperature; // 2字节 uint16_t humidity; // 2字节 } sensor_data_t; #pragma pack()注意我在这里加了#pragma pack(1)。因为结构体默认会做内存对齐int16_t成员一般是2字节对齐两个int16_t成员之间通常不会插入填充字节但如果结构体里混着uint8_t和uint32_t默认对齐就会插入大量填充字节导致memcpy出来的数据完全错位。对串口这种逐字节传输的通信来说结构体对齐规则必须显式指定或者干脆不用memcpy而是手动按字节解析uint16_t temperature (uint16_t)buf[0] | ((uint16_t)buf[1] 8); uint16_t humidity (uint16_t)buf[2] | ((uint16_t)buf[3] 8);这种方式不受对齐规则影响可移植性最好也是我最推荐的方式。串口数据是字节流本质上是协议的物理层表现不该和某个具体编译器的内存布局绑定在一起。5.5 数据滤波串口数据里的毛刺怎么处理热词里有一条是c语言adc值滤波函数其实串口收到的传感器数据一样会带毛刺尤其当对端是ADC采集板时。一次采样的值可能因为电磁干扰跳变一下直接使用会带来很差的体验。我的做法是在解析出数据帧之后对关键数值做一次简单的滤波常用的有限幅滤波如果当前值与前一次值的差超过阈值就丢弃当前值用前一次值顶替。中位值滤波连续采集N个值排序后取中间值。适合剔除随机毛刺。滑动平均滤波维护一个长度为N的队列每次取平均值作为有效值。平滑效果好缺点是有滞后。这三种都是轻量级方案单片机或者Linux上都很容易实现不需要引入复杂的算法库。滑动平均滤波的代码很简单#define FILTER_N 8 typedef struct { int buf[FILTER_N]; int index; int count; long sum; } moving_average_t; int moving_average_filter(moving_average_t *ma, int value) { if (ma-count FILTER_N) { ma-buf[ma-count] value; ma-sum value; } else { ma-sum - ma-buf[ma-index]; ma-buf[ma-index] value; ma-sum value; ma-index (ma-index 1) % FILTER_N; } return (int)(ma-sum / ma-count); }每次解析到新的传感器值喂进去出来的就是滤波后的值直接拿去显示或控制。这只是个例子实际滤波方案要根据信号的特性来选择但思路是通用的在协议解析层之上加一个数据处理层把通信和业务剥离开。6. 我踩过的串口坑从乱码到丢数据的完整排查链路这一节算是我真正想写的内容。串口程序的坑很奇怪很多不是语法错误或者逻辑错误能解释的它们藏在系统的底层行为里。我把踩过的几个典型问题按排查思路写出来希望你遇到的时候能走得快一点。6.1 乱码先查波特率再查数据格式乱码是串口通信最经典的故障。我刚开始做的时候一看到乱码就紧张怀疑是不是硬件坏了后来总结出排查顺序基本一两分钟就能定位确认波特率是否一致这是乱码的第一大原因。两台设备设置的波特率不同采样时机错位解出来的全是乱码。确认数据位、校验位、停止位是否一致8N1是最常见的但也有的设备默认7E17数据位偶校验1停止位少了一位解析自然不对。确认是不是接到了错误的引脚TX接TX是另一个经典误区。串口是交叉连接的A设备的TX接B设备的RXA设备的RX接B设备的TX。共地也很重要两边地线不连通信时好时坏乱码概率直线上升。用示波器/逻辑分析仪看波形如果参数全对了还乱码就得用工具看实际波形。示波器能直接读出每一位的电平宽度波特率到底标不标一眼就能看出来。我遇到过一次晶振偏差导致波特率偏移2%的问题就是靠示波器量出来的。6.2 丢数据缓冲区跟不上时先想清楚数据量再动手丢数据分两种一种是偶发丢一两个字节一种是数据一大就丢、一小就不丢。后者通常是缓冲区处理不过来。数据一大就丢的根因多数情况是应用层读取速度跟不上串口硬件接收速度。举个例子波特率115200每个字节10位8数据位1起始位1停止位1秒最多传11520字节。Linux内核串口驱动有自己的缓冲区如果应用层来不及read内核缓冲区满了之后后续来的数据就会被直接丢弃。read调用之间隔了多长时间决定了你最多丢多少字节。假如你每隔50ms才read一次一次最多能读到的字节数大约是11520×0.05576字节超过这个量就会丢。处理思路有几个可以叠加使用提高read的调用频率把串口接收放到独立线程里阻塞等待数据一有read返回就及时拷贝到环形缓冲区。这是最根本的解法。增大内核缓冲区有的平台可以修改线路规程的缓冲策略但可移植性差不如做好应用层及时读取。降低波特率如果业务允许9600波特率下每秒只有960字节处理压力小很多。启用硬件流控如果双方都支持RTS/CTS打开硬件流控可以在接收端缓冲区快满时通知对端暂停发送。这在高速率大数据量传输时很有用但前提是两边都接线并且都支持。6.3 程序退出后串口行为怪异恢复原始配置有一次我写了个串口测试程序运行过程中按CtrlC强制退出再打开串口工具收发数据发现一切正常但就是不回显、发送不出去。重启程序也不行。后来想到是之前程序退出时没有恢复termios配置把串口留在了raw mode。终端工具再打开时tcgetattr读到的是残留的raw mode配置行为当然就不对了。所以有两个习惯一定要养成程序退出前用tcsetattr恢复旧的termios配置。收到SIGINT、SIGTERM信号时在信号处理函数里也做同样的恢复操作。static struct termios g_oldtio; void signal_handler(int sig) { int fd ...; // 保存全局fd tcsetattr(fd, TCSANOW, g_oldtio); close(fd); exit(0); } signal(SIGINT, signal_handler); signal(SIGTERM, signal_handler);6.4 帧同步丢失一处状态复位整条链路恢复还有一个我调试了很久的问题设备重启后主控这边收到的数据突然全是帧头找不到状态机一直卡在WAIT_HEAD1状态。排查发现是设备重启的瞬间发送了一半的帧主控侧状态机收到了帧头第一个字节0xAA但第二个字节没等到因为设备已经重启后面新帧的0xAA 0x55到来时第二个0xAA被当成帧头第二个字节的候选处理了——因为我的状态机里对第二个字节的判断是如果不是0x55就看是不是0xAA是0xAA就留在WAIT_HEAD2所以新帧的0xAA和旧帧残留的0xAA之间错位状态机走不出来了。解决办法也不复杂给状态机加一个如果WAIT_HEAD2状态超过N个字节没有匹配到0x55就强制回到WAIT_HEAD1的超时逻辑或者更简单粗暴——在WAIT_HEAD2状态下如果连续遇到几个非0x55字节就复位。这其实反映了一个通用原则协议解析状态机必须具有自恢复能力任何不匹配的情况都要能回到初始状态重新同步否则故障会让通信永久卡死。7. 从串口聊开去它给你的远不只是会调串口串口编程这门手艺往小了说是几个API的调用往大了说是嵌入式开发思维方式的一个缩影。指针与数组的关系在缓冲区管理那里体现得淋漓尽致结构体和内存对齐在数据帧解析那里逼着你重新看书内存管理和资源释放在open/close、malloc/free的配对里反复强调甚至热词里提到的函数指针、递归、文件读写都能在串口协议栈的场景里找到落点。所以我说串口是C语言基础能力的试金石一点不夸张。如果你正在学C语言学完语法之后不知道下一步练什么我的建议是买一块带串口的开发板或者用电脑USB转串口接一个MCU最小系统板给自己定义一个简单的通信协议从点灯、回显、传感器数据上报开始一步步把收发、帧解析、CRC校验、状态机这些组件写出来。这个过程练的东西比刷一百道PTA字符串逆序题值钱得多。如果你已经写过串口程序我想分享的一个体会是别满足于能跑通试着按可移植、可复用、抗干扰的标准重构一遍。把串口配置抽成独立模块把帧解析写成状态机把缓冲区换成环形缓冲把对数据的处理从收到就用改成校验通过再用。等你做完这些你会发现后面再去做网络通信、USB通信、CAN通信套路惊人的相似——无非是配置物理层 读写接口 协议状态机 数据分发这套组合拳。串口不高级但它足够深。踩过这些坑学到的东西比想象的多。最后再提一句调试阶段先接逻辑分析仪或者示波器确认物理层没问题再谈代码逻辑。这个顺序反了你会在自己的代码和硬件故障之间来回折腾浪费时间不说还容易怀疑人生。