简介本资源是一份面向嵌入式Linux开发者与工业通信项目工程师的RS485串口通信实战代码包聚焦全志T113-S3平台基于米尔MYD-YT113X开发板解决Linux环境下RS485收发控制、驱动适配及阻塞/非阻塞模式切换等核心问题。压缩包共8个文件6KB含4个C源文件main.c、uart.c、thread.c、log.c、3个头文件uart.h、thread.h、log.h和1个Makefile分别承担主控逻辑、串口配置与读写、多线程调度、日志输出及编译构建功能结构清晰、模块解耦。已有53人学习下载代码已通过实测验证支持快速移植至其他Linux嵌入式平台——仅需调整硬件引脚定义即可复用。读者可直接获取完整可运行工程掌握RS485在Linux中的ioctl控制、termios参数设置、文件描述符阻塞属性切换等关键实践技能并参考双模式实现范式优化自身通信模块设计。 最近在一个工业数据采集项目上用全志T113跑Linux需要和现场的一批电表通过RS485总线通信。这个活儿听着简单真正调起来才发现RS485在Linux下要玩明白涉及的东西远不止打开串口读写那么简单——从内核设备树配置、半双工方向切换时序到总线组网和故障排查每一层都有坑等着你。这篇博文把整个开发过程中最核心的东西完整整理出来从T113平台RS485的硬件原理、内核侧配置到应用层C代码实现再到实测调试和组网经验全部是能直接拿去用的东西。适合正在做全志T113嵌入式Linux开发或者需要在Linux下搞定RS485通信的朋友参考。1. 项目全貌与方案选型为什么用T113做RS485通信1.1 全志T113平台特性与RS485的应用场景全志T113是一颗双核ARM Cortex-A7处理器主频最高1.2GHz内置DDR3还带了一个RISC-V协处理器。这颗芯片在工控领域出镜率很高常见于工业HMI、数据采集终端、电力集中器、楼宇对讲等设备。它引出了多路UART、SPI、TWI、USB、GMAC、CAN等接口其中UART就有8路这对需要同时挂多路串口外设的场景非常友好。我这次的项目是一个数据采集网关需要采集Modbus RTU协议的智能电表数据。为什么选RS485而不是RS232或者CAN核心原因有三个第一RS485是差分信号抗干扰能力强工业现场电机启停、变频器工作带来的电磁干扰很凶RS232在这种环境下基本撑不住第二RS485支持多点组网一条总线上可以挂32个节点用128节点的收发器可以挂更多电表数量多的时候不用每个设备都拉一根线到主机第三传输距离远9600bps下理论距离可以到1200米而RS232通常只能到15米左右。所以在工业现场RS485几乎是仪表通信的事实标准。T113跑Linux系统做RS485通信相比用单片机有什么优势最直接的一点是协议栈开发效率高。单片机裸机或者RTOS下做Modbus协议解析、超时重传、帧校验全得自己写调试工具也弱。而Linux下直接用POSIX标准串口API配合多线程、select/epoll这些机制写一个健壮的采集程序轻松得多。另外T113的性能摆在那里跑个Modbus主站程序绰绰有余还有余力跑MQTT上报、Web配置界面这些功能。1.2 RS485通信方案的整体设计思路整个RS485通信方案我把它分成三层来看硬件层RS485收发器电路设计负责TTL电平与差分电平的转换常见芯片有SP3485、MAX3485、ISL83485等。内核层设备树配置串口引脚、使能RS485模式驱动层面处理数据收发和方向切换。应用层C程序调用POSIX串口API实现Modbus RTU协议的数据组装、发送、接收、解析。为什么要把方向切换放到内核层这是这次开发中最重要的一个设计决策。RS485是半双工通信同一时刻只能发送或者接收。方向切换有两种实现方式一种是应用层用GPIO控制收发器的DE/RE引脚发数据之前拉高发完再拉低另一种是让内核在驱动层面自动处理方向。我强烈建议用第二种让内核的8250串口驱动通过RTS信号自动控制收发器的DE/RE引脚。原因后面详细说这里先记住一个结论应用层用GPIO控制方向在时序上很难做到精确实际使用中容易出现数据丢字节、错位一类的问题。2. RS485底层机制与内核侧配置先把地基打牢2.1 RS485电气特性与半双工方向控制原理RS485标准定义的是A、B两根差分信号线上的电平关系。逻辑1也就是空闲状态时A-B之间的电压差在2V到6V之间逻辑0时A-B电压差在-2V到-6V之间。接收端的判定阈值是±200mV也就是说只要A-B压差大于200mV就认为收到逻辑1小于-200mV就收到逻辑0。这个200mV的滞回区间就是RS485抗干扰能力的来源之一。半双工通信的工作方式可以类比成对讲机同一时间只能有一个人说话其他人听。要说的时候按住PTT键发射按键说完松开回到接收状态。RS485的收发器也有一个方向控制引脚通常叫DEDriver Enable发送使能和REReceiver Enable接收使能很多时候这两个引脚是连在一起的。DE为高电平时收发器把差分总线上的信号驱动出来DE为低电平时收发器处于接收状态把总线上的差分信号转换成TTL电平送给SoC的RX引脚。方向切换的实现方式大致有三种硬件上把SoC的RTS引脚连接到收发器的DE/RE由内核驱动在发送前自动置高RTS、发送后自动拉低这是最推荐的方式。DE/RE接到普通GPIO由应用层程序翻转电平。不想占任何控制引脚用TXD信号经过逻辑电路自动控制DE这种方式省引脚但遇到总线竞争时容易出问题对信号质量要求高。我的板子硬件设计上就是RTS控制DE/RE所以走的是第一种方式配合内核的RS485支持机制应用层完全不需要关心方向切换。2.2 内核串口驱动的RS485支持与设备树配置T113的内核我用的SDK是Tina Linux内核版本5.4。这个版本的8250串口驱动已经原生支持RS485模式会在发送数据时自动控制RTS引脚的电平来切换收发方向。在设备树里打开对应的串口节点时加上RS485相关属性即可。设备树配置典型示例如下uart1 { pinctrl-names default; pinctrl-0 uart1_pb_pins; linux,rs485-enabled-at-boot-time; rs485-rts-active-low; rs485-rts-delay 1 1; status okay; };这里几个属性逐个说明。linux,rs485-enabled-at-boot-time表示内核启动后这个串口就自动处于RS485模式不需要应用层再通过ioctl去使能。rs485-rts-active-low表示RTS信号低电平有效时是发送状态这个取决于你的收发器DE/RE脚和RTS之间的接线方式——如果DE接RTS且高电平有效则不需要这个属性如果DE接的是RTS反相信号比如经过了三极管或者逻辑门反相就得加这个属性。rs485-rts-delay 1 1表示发送前延时1毫秒、发送后延时1毫秒。延时是为了给收发器芯片留出切换时间短了会出现首字节被吞或者末字节被截的怪问题。T113的引脚复用功能和默认串口配置可以在板级dts中找到。以我用的板子为例UART1的引脚被复用到了PB组pinctrl-0 uart1_pb_pins;这个uart1_pb_pins在pinctrl相关dtsi文件中定义选择的是PB0和PB1两个引脚分别对应UART1的TX和RX。设备树配置完成后编译并烧写内核和dtb先在板子上确认一下驱动是否真的以RS485模式初始化了# 查看内核启动日志中与该串口相关的内容 dmesg | grep uart1 dmesg | grep ttyS1 # 确认设备树中RS485属性是否生效 ls /proc/device-tree/uart1/ cat /proc/device-tree/uart1/linux,rs485-enabled-at-boot-time如果设备树里配了但启动日志里没有相关提示优先检查compatible属性是不是snps,dw-apb-uartT113的8250驱动走的是DesignWare UART这个路径。如果本身没有打印RS485相关信息也可以通过应用层ioctl来确认——能成功执行TIOCSRS485 ioctl就是支持。2.3 GPIO方式控制RS485方向作为后备方案如果你的板卡硬件设计上没有把RTS连到收发器的DE/RE而是单独引了一个GPIO出来控制方向那就只能走应用层GPIO控制的方案了。这种方式也能用但在编码和调时序上要多费不少心思。T113上操作GPIO新版SDK推荐用libgpiod比老旧的sysfs方式规范得多。核心逻辑如下/* 发送数据前将DE/RE引脚拉高进入发送模式 */ gpiod_line_set_value(de_line, 1); write(fd, buf, len); tcdrain(fd); /* 必须等待发送完成 */ /* 恢复为接收模式 */ gpiod_line_set_value(de_line, 0);用GPIO方案最需要注意的是方向切换的时序。RTS方案之所以推荐是因为内核驱动在发送数据时会自动精确地在数据发送完成后拉低RTS而应用层GPIO控制则完全依赖程序员的代码质量。tcdrain这里绝对不能省它会让程序阻塞直到发送缓冲区全部数据真正发出去。我曾经偷懒没加这一句结果数据发到一半GPIO就被拉低了总线上出现半截帧从机端直接CRC错误。写完这段再啰嗦一句如果你有板子硬件改板的机会尽量让DE/RE走RTS省掉应用层的麻烦这是无数实践换来的经验。3. 应用层RS485通信代码实现可直接抄作业3.1 串口打开与参数配置应用层开发的第一步是把串口设备打开并配置好参数。全志T113对应的串口设备节点UART0对应/dev/ttyS0UART1对应/dev/ttyS1以此类推。如果SDK里启用了别的别名机制比如/dev/ttyAS1以实际系统为准可以用ls /dev/ttyS*确认。下面是通用的串口打开和配置函数兼容POSIX标准全志平台上直接能用#include stdio.h #include stdlib.h #include string.h #include fcntl.h #include unistd.h #include termios.h #include sys/ioctl.h #include linux/serial.h #include errno.h static int uart_open(const char *path, int baudrate) { int fd; struct termios options; fd open(path, O_RDWR | O_NOCTTY | O_NDELAY); if (fd 0) { perror(open serial); return -1; } /* 恢复为阻塞模式让read在没有数据时挂起等待 */ if (fcntl(fd, F_SETFL, 0) 0) { perror(fcntl F_SETFL); close(fd); return -1; } if (tcgetattr(fd, options) ! 0) { perror(tcgetattr); close(fd); return -1; } /* 原始模式不做行处理、不做特殊字符解析 */ cfmakeraw(options); /* 本地连接使能接收 */ options.c_cflag | (CLOCAL | CREAD); /* 1位停止位无校验8位数据位 */ options.c_cflag ~CSTOPB; options.c_cflag ~PARENB; options.c_cflag ~CSIZE; options.c_cflag | CS8; /* 关闭硬件流控RS485不使用RTS/CTS流控 */ options.c_cflag ~CRTSCTS; /* 设置波特率 */ cfsetispeed(options, baudrate); cfsetospeed(options, baudrate); if (tcsetattr(fd, TCSANOW, options) ! 0) { perror(tcsetattr); close(fd); return -1; } /* 清空缓冲区避免残留数据干扰 */ tcflush(fd, TCIOFLUSH); return fd; }几个关键参数的说明值得展开。cfmakeraw这个函数会把终端设置成“裸”模式——关闭ECHO、关闭ICANON行缓冲模式、关闭ISIG信号生成、关闭IEXTEN等。串口通信必须用raw模式否则你发0x03这样的字节会被系统当成CtrlC信号处理掉数据就丢了。CLOCAL和CREAD一个表示这是本地连接不考虑调制解调器控制信号一个表示使能接收器这两个标志位必须设置否则可能出现打不开或者读不到数据的情况。波特率参数直接调cfsetispeed和cfsetospeed。注意波特率是整数常量比如B9600、B115200。如果要用非标准波特率需要走termios2的接口但RS485应用基本用标准波特率这里不展开。3.2 启用内核RS485模式如果设备树里没有配置linux,rs485-enabled-at-boot-time或者你想在应用层动态控制RS485模式的开关可以通过TIOCSRS485这个ioctl命令来设置。TIOCSRS485是Linux内核提供的一套标准RS485配置接口结构体定义在linux/serial.h中。static int rs485_enable(int fd) { struct serial_rs485 rs485conf; memset(rs485conf, 0, sizeof(rs485conf)); rs485conf.flags | SER_RS485_ENABLED; rs485conf.flags | SER_RS485_RTS_ON_SEND; rs485conf.delay_rts_before_send 1; rs485conf.delay_rts_after_send 1; if (ioctl(fd, TIOCSRS485, rs485conf) 0) { perror(TIOCSRS485); return -1; } return 0; }这里SER_RS485_RTS_ON_SEND的意思是发送时RTS置高。如果你的硬件是反逻辑改成SER_RS485_RTS_AFTER_SEND或者在flags里不设置RTS_ON_SEND。delay_rts_before_send和delay_rts_after_send单位是毫秒分别表示RTS生效后延时多久才开始发数据、数据发送完成后延时多久再释放RTS。收发器芯片的切换时间通常在几百纳秒到几微秒之间但考虑RS485总线电容负载和信号稳定时间设成1毫秒比较稳妥。设备树属性和应用层ioctl是等效的区别只是使能时机。设备树配好后系统起来RS485模式就是开的应用层不用管用ioctl则完全是应用层控制。我建议设备树里就配成linux,rs485-enabled-at-boot-time并配合延时参数调好应用层代码更干净。3.3 发送与接收的核心逻辑RS485通信中发送和接收两个函数是基本功。写发送函数时最关键的一点是发送完成后要调用tcdrain(fd)等待数据真正从串口硬件发出去。因为write只是把数据拷贝到内核发送缓冲区如果写完立刻切方向或者关闭串口数据可能还没发完就被废弃了。static int rs485_send(int fd, const uint8_t *buf, int len) { int ret; if (fd 0 || buf NULL || len 0) return -1; ret write(fd, buf, len); if (ret 0) { perror(write); return -1; } /* 关键等待数据全部发送完成 */ if (tcdrain(fd) ! 0) { perror(tcdrain); return -1; } return ret; }接收函数用select加超时避免阻塞在read上。static int rs485_recv(int fd, uint8_t *buf, int len, int timeout_ms) { fd_set rfds; struct timeval tv; int ret; FD_ZERO(rfds); FD_SET(fd, rfds); tv.tv_sec timeout_ms / 1000; tv.tv_usec (timeout_ms % 1000) * 1000; ret select(fd 1, rfds, NULL, NULL, tv); if (ret 0) { errno ETIMEDOUT; return -1; /* 超时无数据 */ } if (ret 0) { perror(select); return -1; } return read(fd, buf, len); }这里用了select而不是直接read阻塞好处是有超时控制。Modbus RTU主站在发请求帧后需要在规定时间内等待从机应答超时了要重试或者报错。没有超时机制一旦从机掉线程序就会一直卡在read上整个采集逻辑就瘫痪了。下面是一个完整的Modbus RTU读保持寄存器功能码0x03的帧组装和CRC计算实现static uint16_t modbus_crc16(const uint8_t *data, uint16_t len) { uint16_t crc 0xFFFF; uint16_t i; uint8_t j; for (i 0; i len; i) { crc ^ data[i]; for (j 0; j 8; j) { if (crc 0x0001) crc (crc 1) ^ 0xA001; else crc 1; } } return crc; } static int modbus_read_holding_regs(int fd, uint8_t slave_addr, uint16_t reg_addr, uint16_t reg_count, uint8_t *rx_buf, int rx_len, int timeout_ms) { uint8_t tx_buf[8]; uint16_t crc; int len; int ret; /* 组装请求帧地址 功能码 寄存器地址 寄存器数量 CRC */ tx_buf[0] slave_addr; tx_buf[1] 0x03; tx_buf[2] (reg_addr 8) 0xFF; tx_buf[3] reg_addr 0xFF; tx_buf[4] (reg_count 8) 0xFF; tx_buf[5] reg_count 0xFF; crc modbus_crc16(tx_buf, 6); tx_buf[6] crc 0xFF; tx_buf[7] (crc 8) 0xFF; len rs485_send(fd, tx_buf, sizeof(tx_buf)); if (len ! sizeof(tx_buf)) { fprintf(stderr, send modbus frame failed\n); return -1; } ret rs485_recv(fd, rx_buf, rx_len, timeout_ms); if (ret 0) { fprintf(stderr, recv timeout or error\n); return -1; } /* 校验应答帧长度和CRC */ if (ret 5 || (rx_buf[1] 0x80)) { fprintf(stderr, modbus exception or short frame\n); return -1; } if (rx_buf[0] ! slave_addr) { fprintf(stderr, slave address mismatch\n); return -1; } crc modbus_crc16(rx_buf, ret - 2); if ((rx_buf[ret - 2] ! (crc 0xFF)) || (rx_buf[ret - 1] ! ((crc 8) 0xFF))) { fprintf(stderr, crc check failed\n); return -1; } return ret; }这段代码在项目里的角色就是主站发送读请求、校验从站应答实际跑下来很稳。Modbus RTU协议有个需要注意的地方帧和帧之间的间隔要大于等于3.5个字符传输时间。在9600波特率下一个字符约1.04ms3.5个字符约3.6ms。如果连续发两帧的间隔太短从机可能把两帧合并成一帧解析直接导致异常响应。在轮询多个从机时帧间加一点延时是保证稳定的实用小技巧。4. 实测调试过程与组网经验从单机到总线4.1 回环测试与波形验证先确认硬件通路拿到板子后先别急着跑业务代码先做一次串口回环测试。RS485是半双工差分信号不像RS232那样可以粗暴地把TXD和RXD短接。回环测试的目的是验证数据能从T113的UART发出经过收发器芯片转换成差分信号再回来被UART接收——整个过程链路是通的。我做的第一步是在软件层面做回环把RS485收发器的DI和RO短接。这样相当于自发自收数据发出去立刻被自己接收。用一段简单的C程序或者直接命令行验证# 打开一个终端后台接收数据 cat /dev/ttyS1 # 发送一串数据 echo hello rs485 /dev/ttyS1 # 查看是否在cat终端里收到了同样的内容如果能看到自己发的数据说明UART口本身的收发链路没问题RTS方向控制大概率也是正常的。如果收不到先用万用表量一下A、B线上的电压。总线空闲时A-B压差应该大于200mV发送数据时用示波器能看到差分信号波形——一根线上是反相方波另一根线是正相方波两者叠加才是RS485标准的电平。4.2 修改打印串口把调试口腾出来给功能串口之前提到的热词“全志t113修改打印串口”这个需求在实际开发中非常常见。T113默认UART0是调试串口内核的启动日志、/dev/console都挂在ttyS0上。如果硬件设计上把RS485收发器接到了UART0就得把控制台输出挪到别的串口否则RS485收发的数据会跟内核日志混在一起。我的做法是修改内核cmdline中的console参数。在Tina Linux SDK中环境变量一般定义在env.cfg或boot_package相关配置里把consolettyS0,115200改成consolettyS1,115200。同时确认设备树里UART0的status是okay并且没有被串口驱动占用为调试口。改完之后内核启动日志从UART1输出UART0就可以独立做RS485通信了。这个操作建议在开发阶段尽早处理别等应用代码写完了再改因为调试串口一换之前所有依赖console输出定位问题的习惯都得跟着变。4.3 多机轮询通信与总线组网实战回环测试通过后开始接真正的从机设备。一条RS485总线上挂多个从机采用一主多从的轮询模式主机依次向每个从机发送请求帧从机收到与自身地址匹配的请求后应答。Modbus RTU就是典型的这种模式。轮询逻辑的伪代码如下while (1) { for (i 0; i slave_count; i) { ret modbus_read_holding_regs(fd, slave_addr[i], start_reg, reg_num, rx_buf, sizeof(rx_buf), 500); if (ret 0) { /* 解析并保存从机数据 */ parse_and_store(i, rx_buf, ret); } else { /* 记录超时或异常继续下一个从机 */ printf(slave %d read failed\n, slave_addr[i]); } /* 帧间隔避免连续帧间隔过短 */ usleep(10000); } }组网时总线敷设方式直接影响通信可靠性。RS485总线要求手拉手接线也就是菊花链拓扑绝对不能用星型拓扑。总线两端要各接一个120欧姆终端电阻匹配电缆特性阻抗减少信号反射。如果总线上的设备不够密实、有些节点离主线很远那根很长的分支线也要尽量短分支过长会变成一根天线把干扰收进总线。总线长度和波特率成反比关系9600bps可以跑1200米19200bps大概800米115200bps一般不超过300米。项目里如果只是机柜内短距离通信115200bps没问题跨车间长距离就老老实实降到9600bps。4.4 从主机侧观察信号质量在实测过程中我习惯用示波器探头接在A-B之间观察波形。正常通信时能看到明显的差分方波幅值大约在3.5V~5V之间取决于收发器供电电压。如果波形前沿有严重的过冲和振铃说明终端电阻缺失或者阻抗不匹配通信距离稍长就莫名奇偶校验错误。如果发送时A-B电压差只有几百毫伏说明总线负载太重或者偏置电阻设计不合理需要重新计算。还有一个经常被忽视的点RS485收发器的共模电压范围是-7V到12V。当两个设备用的电源地电位差较大时虽然差分信号不受共模干扰影响但一旦共模电压超出芯片允许范围收发器会烧毁。多个设备之间最好做好等电位连接或者使用带隔离的RS485模块比如ADI的ADM2483、国产的MAX14850等。5. 常见问题排查与避坑实录这些坑我都踩过5.1 RS485总线上电死机问题的根因与对策“RS485上电死机”这个现象很容易复现设备一上电屏幕上花屏或者系统起不来拔掉RS485线就恢复正常。我第一次遇到也摸不着头脑后来分析发现根因在收发器的DE/RE引脚上。很多板卡的硬件设计里DE/RE引脚由SoC的GPIO或RTS控制但上电瞬间SoC还没完成GPIO初始化DE/RE引脚处于高阻态。此时收发器的输出状态不确定如果恰好处于发送使能状态它就会把总线上的信号强行驱动出来形成总线竞争如果RO输出接SoC的RX在无有效信号时随机翻转SoC的串口控制器会收到一堆垃圾数据触发中断风暴。在极端情况下这些垃圾数据甚至会让bootloader误判为启动命令导致系统启动异常。解决办法从硬件和软件两个层面同时下手。硬件上DE/RE引脚加一个10kΩ下拉电阻确保上电默认是接收态RE低电平有效DE低电平禁用。软件上应用层程序启动后第一件事就是把方向控制引脚初始化到接收态再打开串口。总线侧A线上加一个上拉电阻到VCCB线加一个下拉电阻到GND保证总线空闲时A-B有一个明确的电平差收发器的RO不会输出随机电平。偏置电阻的典型值在1kΩ到10kΩ之间取值要综合节点数量和收发器输入阻抗计算。5.2 收发错位与数据丢失调试时序问题的独家经验“发一帧数据收到的内容错位几个字节”或者“第一帧正常后面的帧经常丢字节”这类问题几乎都出在方向切换时序上。RS485半双工通信中从发送切到接收或者从接收切到发送都需要时间。一个典型的错误写法是write(fd, buf, len); /* 没有tcdrain直接切GPIO方向 */ gpio_set_value(de_pin, 0);这样数据还没发完收发器就已经被切到接收态了总线上的数据被截断接收方自然解不出完整帧。正确写法是write后必须tcdrain(fd)等内核把数据全部送到硬件FIFO并且移位寄存器发送完毕然后才允许切方向。如果用的是内核RS485模式RTS自动切换也有一个参数要调delay_rts_after_send。有些收发器在RTS拉低后还要一小段时间才能真正释放总线进入接收态如果这个时间设成0紧接着读数据可能读不到完整的响应或者读到噪声。实测中这个延时设1~2毫秒比较合适太快容易出问题。接收丢数据还有一个常见原因应用层读数据不够及时。如果read返回后你没有立即把数据从内核缓冲区取走后续数据会把它覆盖。用selectread的组合读四次直到select超时可以确保把一帧完整取出。5.3 常见问题速查表我把项目调试过程中遇到的典型问题整理成了速查表方便现场排查时快速定位现象可能原因排查方向收不到任何数据AB接线接反、方向未切换、波特率错误量A-B电压确认空闲200mV示波器看发送波形数据乱码波特率误差大、总线反射、收发器损坏示波器观察波形质量降低波特率测试换收发器芯片上电后系统卡死DE/RE引脚悬空、总线空闲时电平不确定DE/RE加下拉电阻A/B加偏置电阻第一帧正常后续异常方向切换时序太短、帧间隔不足调大delay_rts_after_send帧间加延时CRC校验失败发送被截断、接收缓冲溢出、总线干扰用tcdrain确保发完提高读速率检查屏蔽接地从机全部无响应总线短路、终端电阻错放、主机地址配置错误万用表量AB间电阻应约为60Ω两个120Ω并联距离远后偶发错误线缆质量差、缺少终端电阻、波特率过高换屏蔽双绞线加终端电阻降低波特率5.4 关于硬件电路设计的几点补充虽然这篇博文的重点是代码但RS485通信的成败硬件电路至少占一半比重。简单说说我这次的硬件设计经验。收发器选型上我用了SP34853.3V供电和T113的IO电平完全匹配不需要额外的电平转换。SP3485最大支持32个节点对这个项目够用。如果节点更多可以选带1/8负载的芯片比如ISL83485能挂256个节点。收发器的A、B输出端要对地各加一个TVS管型号选SMBJ6.0CA或者类似的防止雷击浪涌和静电打坏芯片。这是工业现场的刚需我见过好几块板子因为省了TVS在打雷天气或者附近有大功率设备启停时RS485芯片一批一批地坏。另外如果总线需要长距离走线建议用屏蔽双绞线屏蔽层单端接地一般在主机端接地不要两端都接否则会形成地环路引入更大的干扰。6. 调试工具与效率提升开发嵌入式Linux下的RS485程序好的调试工具能省一半时间。我常用的工具组合如下。6.1 命令行工具快速验证stty是Linux下查看和设置串口参数的利器。调试初期用下面命令快速配置串口# 查看当前串口参数 stty -F /dev/ttyS1 -a # 设置9600波特率、8N1、raw模式 stty -F /dev/ttyS1 9600 cs8 -cstopb -parenb rawcat和echo配合可以做简单收发测试但只能发ASCII文本不能发任意十六进制字节。要发十六进制数据可以用printf加dd或者直接用Python一行命令printf \x01\x03\x00\x00\x00\x02\xc4\x0b /dev/ttyS1从机响应数据可以用xxd查看十六进制timeout 3 cat /dev/ttyS1 | xxd6.2 总线上抓包分析如果RS485总线上挂了多个设备想知道谁在发数据、数据是否冲突最直接的办法是接一个USB转RS485模块到电脑上用串口助手工具抓包。我习惯用一个小的USB转485模块并联到总线末端注意方向是监听模式模块的DE/RE接低电平固定接收不参与发送配上minicom或者moserial就能实时看到总线上所有设备的数据帧。这里有个细节USB转RS485模块的默认方向控制和普通RS485设备一样需要正确设置。抓包时如果不发送数据它应该一直处于接收态。如果模块同时挂在总线上且它的DE是使能的它也会干扰通信这点要特别注意。6.3 性能压力测试项目验收前做了一次疲劳测试主机以100ms周期轮询总线上64个从机连续运行72小时统计丢包率和异常帧数。测试脚本的核心思路是记录每个从机响应的成功率异常时打点保存现场数据。这个测试很关键很多偶发问题在短时调试中根本暴露不出来只有长时间跑才能看出总线质量和驱动稳定性的真实水平。测试中我发现一个有趣的现象在高温环境45℃下部分从机响应时间明显变慢原本500ms超时足够的请求出现了超时重试。排查后确认是从机设备的电源在高负载下纹波偏大导致其RS485收发器供电异常信号质量下降。后来从机端电源加了滤波电容问题就消失了。这类问题在常温调试时几乎不可能发现但现场真实环境里就是致命的。7. 踩坑心得与后续扩展方向做这个项目前后花了三周踩过的坑比我预想的多。最后分享几个最深刻的体会。第一RS485调试一定要先硬件后软件。总线电平不对、终端电阻没装好软件调得再好也没用。板子到手第一件事是拿示波器看波形把物理层确认了后面所有问题都只是代码层面的。第二方向切换时序是半双工通信的命门。无论你用RTS自动切换还是GPIO手动切换都要把延时参数传准宁可多等1毫秒也不要抢时间。总线响应慢一点可以接受数据帧损坏在工业现场是不可接受的。第三协议层一定要做超时和重试机制。RS485总线环境复杂电磁干扰、节点掉线、线路老化都可能造成通信失败。没有超时重试的代码一个节点掉线就能让整个轮询卡死。我的主循环里每个从机都有独立的超时时间和重试计数连续多次失败会上报告警而不是无限重试拖垮总线。第四如果项目后续要扩展可以考虑把RS485通信程序做成独立的守护进程用消息队列或共享内存跟业务程序解耦。通信层只管收发和协议解析业务层只管逻辑处理。这样一来后期加协议或者换从机设备型号只需要改通信层的解析函数业务层完全不用动。这套代码后来还移植到了另一个基于T113的项目上改动量很小。说明只要按照“设备树配置RS485模式 应用层标准POSIX串口API 协议解析独立模块”这个思路来做可复用性是很高的。如果你正在做类似的T113或者其它全志系列芯片的RS485通信开发希望这篇分享能帮你少走一些弯路。本文还有配套的精品资源点击获取