做嵌入式Linux開發(fā)的朋友遲早會和Modbus打交道。我最初接觸這個協(xié)議是因?yàn)槭诸^一塊板子要采集一組RS485接口的溫濕度傳感器廠家給的技術(shù)資料只寫了Windows下的Demo滿屏的MFC控件。Linux下沒法直接跑只能自己用C把Modbus RTU完整扒了一遍。做完之后最大的感受是Modbus RTU本身不難難的是串口配置、時序控制、異常排查這些外圍細(xì)節(jié)任何一個環(huán)節(jié)出問題數(shù)據(jù)讀上來的結(jié)果都是錯的。這篇文章不是Modbus協(xié)議的教科書式講解而是一個嵌入式Linux開發(fā)者的落地筆記。我會從串口配置開始講再到RTU報(bào)文組幀、CRC16計(jì)算、傳感器數(shù)據(jù)解析最后把RS485方向切換和排錯方法一起說清楚。內(nèi)容偏實(shí)戰(zhàn)每一步都是我在板子上驗(yàn)證過的代碼可以直接拿來改。1. 為什么選擇自寫Modbus RTU而不是移植libmodbus先聊一個很多人都會糾結(jié)的問題傳感器數(shù)據(jù)采集這種場景到底要不要引入libmodbus這種開源庫1.1 先看需求你手頭是什么類型的傳感器我在做這個項(xiàng)目時傳感器數(shù)量不多一共5個RS485節(jié)點(diǎn)每個節(jié)點(diǎn)的數(shù)據(jù)格式固定讀取邏輯非常簡單——就是幾個功能碼輪詢。這種情況下Modbus報(bào)文收發(fā)只需要拼幾個字節(jié)、解析幾個字節(jié)本質(zhì)工作是很輕量的。如果一上來就移植libmodbus你需要處理交叉編譯依賴、配置項(xiàng)裁剪、線程模型調(diào)試光是把庫跑通可能就要花半天。而且libmodbus本身是個通用庫為了兼容各種功能碼和場景代碼規(guī)模不小很多功能對這個項(xiàng)目來說完全用不到。反過來講如果項(xiàng)目中傳感器種類很多、功能碼覆蓋很廣、對可靠性和健壯性要求極高那libmodbus確實(shí)能省不少事。它有現(xiàn)成的超時處理、錯誤重試、廣播支持邊界情況考慮得比我花一晚上寫的代碼周全。1.2 libmodbus的交叉編譯成本與取舍嵌入式Linux開發(fā)中交叉編譯一個庫要先解決依賴鏈問題。libmodbus依賴系統(tǒng)頭文件本身編譯難度不高在buildroot里也能直接選上但如果你用的是廠商提供的獨(dú)立交叉編譯器就得自己處理各種路徑前綴問題。我在評估時發(fā)現(xiàn)libmodbus源碼在板子上跑出來的二進(jìn)制體積大約會增加幾十KB到幾百KB不等這個在Flash空間緊張的項(xiàng)目里需要留意。另一個隱性成本是調(diào)試成本庫里的代碼不是自己寫的報(bào)錯日志風(fēng)格也不一定適合你的板子真出了詭異問題時你還要翻庫源碼排查。1.3 什么情況下建議自己寫協(xié)議棧就我個人經(jīng)驗(yàn)下面這幾種情況更適合自己寫節(jié)點(diǎn)數(shù)量少、功能碼固定比如就讀取3/4功能碼的寄存器數(shù)據(jù)。需要深度定制超時邏輯比如傳感器響應(yīng)特別慢或者485鏈路有強(qiáng)干擾需要加特殊重試策略。調(diào)試需求強(qiáng)想把每一幀收發(fā)細(xì)節(jié)都打印出來自己寫的代碼改起來最快。對二進(jìn)制體積和依賴數(shù)量有要求不想引入額外動態(tài)庫。這個項(xiàng)目的需求正好落在這些條件里。于是我決定自寫一個精簡版的Modbus RTU主站200行代碼解決后面所有邏輯我都心里有數(shù)出問題也只看自己的代碼。2. 串口配置termios里的那些隱藏細(xì)節(jié)Modbus RTU跑在串口上串口配置是第一道關(guān)卡。Linux下串口操作不復(fù)雜但有幾個細(xì)節(jié)一旦忽略后續(xù)調(diào)試會非常折磨人。2.1 打開串口時的三個標(biāo)志位怎么選我第一次寫串口程序時用open(/dev/ttyS1, O_RDWR)直接打開結(jié)果發(fā)現(xiàn)程序被掛起后來才知道必須加O_NOCTTY和O_NDELAY。int fd open(dev, O_RDWR | O_NOCTTY | O_NDELAY);O_NOCTTY防止串口成為控制終端。如果不加這個標(biāo)志程序讀串口時一旦收到某些特殊字符終端會向進(jìn)程發(fā)送SIGHUP信號進(jìn)程莫名其妙就退了。O_NDELAY相當(dāng)于非阻塞打開。這樣open函數(shù)不會因?yàn)榇诰€路狀態(tài)異常而卡住比如設(shè)備未ready時open會一直等待。打開之后再用fcntl恢復(fù)成阻塞模式或保持非阻塞都行具體看接下來的讀寫策略。O_RDWR讀寫都要用Modbus主站既要發(fā)請求又要收響應(yīng)。打開后要把文件描述符的O_NDELAY標(biāo)志清掉不然read會立即返回0影響后面用select處理超時的邏輯fcntl(fd, F_SETFL, 0);2.2 raw模式與cfmakeraw串口默認(rèn)處于所謂“規(guī)范模式”canonical mode在這模式下內(nèi)核會對輸入做行緩沖處理讀到換行符才返回還會處理很多特殊字符這對二進(jìn)制幀數(shù)據(jù)來說是災(zāi)難。Modbus RTU報(bào)文是一串可能包含任意字節(jié)值的幀絕對不能經(jīng)過這些轉(zhuǎn)換。cfmakeraw()這個函數(shù)非常方便它會一次性把如下參數(shù)設(shè)置好關(guān)閉ICANON規(guī)范模式關(guān)閉ECHO回顯關(guān)閉ISIG信號生成關(guān)閉IEXTEN把輸入輸出都改成raw字節(jié)流但cfmakeraw()默認(rèn)會關(guān)閉CRTSCTS之外的很多標(biāo)志建議在調(diào)用后自己再補(bǔ)兩個關(guān)鍵項(xiàng)cfmakeraw(opt); opt.c_cflag | (CLOCAL | CREAD); opt.c_cflag ~CSTOPB; opt.c_cflag ~CRTSCTS;CLOCAL忽略調(diào)制解調(diào)器控制線不監(jiān)聽DCD等信號避免斷線時內(nèi)核發(fā)送SIGHUP。CREAD允許讀取數(shù)據(jù)這個不打開read收到了數(shù)據(jù)也不會交給應(yīng)用層。CSTOPB保證是1位停止位位標(biāo)志置1表示2位停止位。Modbus RTU標(biāo)準(zhǔn)是8數(shù)據(jù)位、1停止位無校驗(yàn)或2停止位有校驗(yàn)時按手冊大多數(shù)RS485傳感器是8N1。CRTSCTS關(guān)閉硬件流控。485鏈路是半雙工不能靠RTS/CTS做常規(guī)流控這個后面章節(jié)細(xì)說。校驗(yàn)位和停止位的關(guān)系很多初學(xué)者容易繞暈。Modbus RTU在串口上常用的配置是8N18數(shù)據(jù)位、無校驗(yàn)、1停止位但也有設(shè)備是8E1偶校驗(yàn)配置時務(wù)必看傳感器手冊。無校驗(yàn)時RTU報(bào)文里的CRC16已經(jīng)承擔(dān)了數(shù)據(jù)校驗(yàn)所以8N1是絕對主流很少見到帶校驗(yàn)位的Modbus。2.3 波特率和VMIN、VTIME的正確配置波特率用cfsetispeed和cfsetospeed設(shè)置或者直接用cfsetspeed一次設(shè)置收發(fā)一致cfsetspeed(opt, B9600);波特率要和傳感器嚴(yán)格一致常見的是9600和115200也有一些工業(yè)傳感器用4800。我遇到過一個客戶現(xiàn)場的傳感器手冊寫9600實(shí)際上默認(rèn)是19200這種地方只能靠抓波形確認(rèn)后面調(diào)試章節(jié)再展開。然后是VMIN和VTIME這兩個參數(shù)決定了read的阻塞行為和超時行為很多人的串口程序卡就卡在這VMINread返回前需要讀取的最小字節(jié)數(shù)。VTIME接收到第一個字節(jié)后等待后續(xù)字節(jié)的超時時間單位是0.1秒。常用的組合有兩種VMINVTIME行為00非阻塞read立即返回沒數(shù)據(jù)返回010阻塞直到讀到1個字節(jié)11讀到1個字節(jié)后等待下一個字節(jié)最多0.1秒對Modbus RTU主站來說我習(xí)慣用VMIN1、VTIME1然后配合select做總超時。這種組合的好處是read最少能返回1個字節(jié)不會因?yàn)椤耙粋€字節(jié)都沒有”而返回0導(dǎo)致上層誤判連接斷開。VTIME1能讓每次read盡量把內(nèi)核緩沖里的數(shù)據(jù)一次取出來減少多次read造成的幀分割。實(shí)際上RTU幀的間隔時間對幀解析影響很大但termios層面的VTIME控制不了幀間3.5字符的靜默時間這個要靠協(xié)議層的定時和緩沖區(qū)管理來解決不能依賴read超時來切幀。2.4 先用stty繞開代碼驗(yàn)證串口本身在寫C代碼之前我強(qiáng)烈建議先用命令行工具驗(yàn)證一遍串口和傳感器鏈路。這個方法在嵌入式板子上特別好用因?yàn)槟苎杆賲^(qū)分問題是出在硬件鏈路還是出在協(xié)議代碼stty -F /dev/ttyS1 9600 raw -echo printf \x01\x04\x00\x00\x00\x01\x31\xCA /dev/ttyS1stty命令設(shè)置波特率、raw模式、關(guān)閉回顯。printf按照Modbus RTU幀字節(jié)流發(fā)送這是04功能碼讀1個輸入寄存器的示例幀CRC后面會教怎么算。如果傳感器正常用cat或hexdump看返回timeout 1 cat /dev/ttyS1 | xxd如果能看到數(shù)據(jù)幀返回說明串口硬件和傳感器都OK接下來可以放心寫協(xié)議代碼。如果返回的是亂碼先檢查波特率和A/B線是否接反。如果什么都沒返回用萬用表量RS485的A、B線間電壓正常應(yīng)該有個零點(diǎn)幾伏的差分。3. RTU報(bào)文拆解地址、功能碼、數(shù)據(jù)、CRC16串口配置好了接下來就是Modbus RTU協(xié)議本身。RTU報(bào)文的結(jié)構(gòu)不復(fù)雜但每個字段都值得認(rèn)真對待特別是CRC16的計(jì)算很多人在這一步出錯。3.1 幀格式與典型示例一個完整的Modbus RTU請求幀無論是主站發(fā)給從站還是從站響應(yīng)都遵循同一個結(jié)構(gòu)字段長度說明從站地址1字節(jié)1~247對應(yīng)傳感器節(jié)點(diǎn)地址功能碼1字節(jié)03/04/06/10等數(shù)據(jù)N字節(jié)具體請求或響應(yīng)內(nèi)容CRC162字節(jié)對整個幀做校驗(yàn)低字節(jié)在前最常見的讀輸入寄存器04功能碼請求幀是8個字節(jié)。比如讀地址1的傳感器起始寄存器0讀1個寄存器01 04 00 00 00 01 CRC_L CRC_H03功能碼讀保持寄存器格式完全一樣只把04換成03。06是寫單個保持寄存器10是寫多個寄存器日常和傳感器打交道讀操作占絕大多數(shù)先把03/04吃透基本夠用。3.2 CRC16計(jì)算移位法和查表法的取舍CRC16是Modbus RTU最容易出錯的地方。算錯一個字節(jié)從站直接忽略請求或者返回異常碼而且看起來毫無規(guī)律。很多新手第一次調(diào)試Modbus反復(fù)檢查線路但就是沒數(shù)據(jù)最后發(fā)現(xiàn)是CRC算反了或者初值不對。Modbus RTU的CRC16算法參數(shù)是固定的初值0xFFFF多項(xiàng)式0xA001對應(yīng)的標(biāo)準(zhǔn)多項(xiàng)式是x^16 x^15 x^2 1反射形式0xA001輸出低字節(jié)在前移位法的C語言實(shí)現(xiàn)如下#include stdint.h static uint16_t crc16_modbus(uint8_t *buf, size_t len) { uint16_t crc 0xFFFF; for (size_t i 0; i len; i) { crc ^ buf[i]; for (int j 0; j 8; j) { if (crc 0x0001) { crc (crc 1) ^ 0xA001; } else { crc 1; } } } return crc; }驗(yàn)證一個幀是否正確可以用我上面那個例子01 04 00 00 00 01把6個字節(jié)喂進(jìn)這個函數(shù)得到的CRC應(yīng)該是0xCA31發(fā)送時低字節(jié)在前所以幀尾是31 CA。這個值是正確的可以用任何在線CRC計(jì)算器核對。如果對性能有要求比如采集頻率很高、每秒鐘上百次輪詢可以用查表法。查表法把256個CRC中間值預(yù)先算好存在數(shù)組里計(jì)算時每個字節(jié)只需查表一次并做兩次異或速度比移位法快好幾倍。但在大多數(shù)嵌入式Linux板子上移位法跑幾千幀也就幾毫秒完全不是瓶頸我建議先用移位法邏輯清晰好調(diào)試真出現(xiàn)性能問題再換查表法不遲。CRC計(jì)算時有個常見的坑有些網(wǎng)上代碼把多項(xiàng)式寫成0x8005那對應(yīng)的是Modbus之外的其他CRC16變體算出來的結(jié)果永遠(yuǎn)對不上。判斷標(biāo)準(zhǔn)只有一個初值0xFFFF多項(xiàng)式0xA001結(jié)果低字節(jié)在前。3.3 異常響應(yīng)從站告訴你錯在哪了當(dāng)請求幀格式正確但操作不被支持時從站會返回異常響應(yīng)。判斷規(guī)則很簡單響應(yīng)幀的功能碼把最高位置1加上0x80然后緊跟著一個異常碼字節(jié)。比如請求01 03 00 00 00 01 CRC如果從站認(rèn)為這個操作非法會返回01 83 02 CRC其中01是從站地址83是03的異常版本02是異常碼表示非法數(shù)據(jù)地址常見的異常碼含義異常碼含義常見原因01非法功能碼從站不支持該功能碼02非法數(shù)據(jù)地址寄存器地址或數(shù)量超出從站范圍03非法數(shù)據(jù)值請求數(shù)據(jù)字段超范圍04從站設(shè)備故障從站內(nèi)部錯誤調(diào)試時遇到異常響應(yīng)別急著懷疑線路先看功能碼和地址范圍是否匹配傳感器手冊。我遇到過好幾次“讀不到數(shù)據(jù)”實(shí)際上是寄存器起始地址寫錯了一位傳感器默默返回了02異常碼而我的解析代碼沒有處理異常響應(yīng)一直在死等正常數(shù)據(jù)白白卡了很久。4. 主站讀寫傳感器完整實(shí)現(xiàn)與代碼解讀串口和CRC都搞定后核心的讀寫邏輯就簡單了。我通常把Modbus主站的讀寫封裝成一個獨(dú)立模塊接口清晰一點(diǎn)后面接業(yè)務(wù)邏輯也方便。4.1 讀取保持寄存器03功能碼的核心實(shí)現(xiàn)下面這個函數(shù)實(shí)現(xiàn)了從指定從站讀取N個保持寄存器的完整流程包括組幀、發(fā)送、接收、CRC校驗(yàn)和響應(yīng)解析。代碼里每一步都有注釋可以直接拷貝到自己的項(xiàng)目里改。#include stdio.h #include stdint.h #include stdlib.h #include string.h #include unistd.h #include fcntl.h #include termios.h #include sys/select.h static int read_full_frame(int fd, uint8_t *buf, size_t expect_len, int timeout_ms); int modbus_read_holding_registers(int fd, uint8_t slave_addr, uint16_t start_reg, uint16_t reg_cnt, uint16_t *out_regs) { uint8_t req[8]; uint8_t resp[256]; uint16_t crc; /* 1. 組幀地址 功能碼03 起始寄存器 寄存器數(shù)量 */ req[0] slave_addr; req[1] 0x03; // 讀保持寄存器 req[2] (start_reg 8) 0xFF; req[3] start_reg 0xFF; req[4] (reg_cnt 8) 0xFF; req[5] reg_cnt 0xFF; /* 2. 計(jì)算CRC并填充到幀尾低字節(jié)在前 */ crc crc16_modbus(req, 6); req[6] crc 0xFF; req[7] (crc 8) 0xFF; /* 3. 清一下接收緩沖避免讀到上一幀殘留數(shù)據(jù) */ tcflush(fd, TCIOFLUSH); /* 4. 發(fā)送請求 */ ssize_t n write(fd, req, sizeof(req)); if (n ! sizeof(req)) { perror(write modbus req); return -1; } /* 5. 等待完整響應(yīng)幀 * 正常響應(yīng)長度 從站地址(1) 功能碼(1) 字節(jié)計(jì)數(shù)(1) 寄存器數(shù)據(jù)(reg_cnt*2) CRC(2) * 異常響應(yīng)長度 從站地址(1) 功能碼(1) 異常碼(1) CRC(2) 5 */ int expect_len 3 reg_cnt * 2 2; int r read_full_frame(fd, resp, expect_len, 500); if (r 0) { fprintf(stderr, recv modbus resp timeout or error, ret%d\n, r); return -1; } /* 6. 校驗(yàn)從站地址 */ if (resp[0] ! slave_addr) { fprintf(stderr, slave addr mismatch: expect %02X got %02X\n, slave_addr, resp[0]); return -1; } /* 7. 處理異常響應(yīng) */ if (resp[1] (0x03 | 0x80)) { fprintf(stderr, modbus exception: code0x%02X\n, resp[2]); return -1; } /* 8. 校驗(yàn)功能碼和長度 */ if (resp[1] ! 0x03) { fprintf(stderr, unexpected function code: 0x%02X\n, resp[1]); return -1; } if (resp[2] ! reg_cnt * 2) { fprintf(stderr, byte count mismatch: %d\n, resp[2]); return -1; } /* 9. 校驗(yàn)接收幀CRC對除CRC外的整幀計(jì)算 */ uint16_t recv_crc (uint16_t)resp[expect_len - 2] | ((uint16_t)resp[expect_len - 1] 8); uint16_t calc_crc crc16_modbus(resp, expect_len - 2); if (recv_crc ! calc_crc) { fprintf(stderr, crc mismatch: recv0x%04X calc0x%04X\n, recv_crc, calc_crc); return -1; } /* 10. 提取寄存器數(shù)據(jù)大端字節(jié)序 */ for (int i 0; i reg_cnt; i) { out_regs[i] ((uint16_t)resp[3 i * 2] 8) | resp[4 i * 2]; } return 0; }對應(yīng)的接收函數(shù)如下它用select做總超時循環(huán)讀取直到湊夠一幀static int read_full_frame(int fd, uint8_t *buf, size_t expect_len, int timeout_ms) { size_t got 0; while (got expect_len) { 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) { perror(select); return -1; } if (ret 0) { /* 超時未收到數(shù)據(jù) */ fprintf(stderr, select timeout, got %zu bytes\n, got); return -2; } ssize_t n read(fd, buf got, expect_len - got); if (n 0) { got n; } else if (n 0) { perror(read serial); return -1; } } return (int)got; }這里有幾個設(shè)計(jì)細(xì)節(jié)值得特別注意。第一個是tcflush(fd, TCIOFLUSH)的位置。發(fā)送請求前清空緩沖區(qū)是為了避免把上一次沒讀完的殘留數(shù)據(jù)帶到這次解析里。如果不清空比如上次超時后緩沖區(qū)里還有半個幀下一幀拼接時就會錯位出現(xiàn)“偶爾能讀對偶爾讀不對”的詭異現(xiàn)象。第二個是select總超時的設(shè)定。500毫秒是給絕大多數(shù)RS485傳感器留的余量如果傳感器響應(yīng)慢或者鏈路干擾強(qiáng)可以放寬到1000毫秒。但有個原則要記牢超時不能太短否則幀還沒接收完就被截?cái)嗔?。RS485鏈路在9600波特率下一個字節(jié)約1ms就算讀50字節(jié)的幀也就是50ms500ms的超時綽綽有余。第三個是異常響應(yīng)的判斷要放在正常響應(yīng)解析之前。如果只按正常幀格式解析異常幀會把異常碼當(dāng)成字節(jié)計(jì)數(shù)導(dǎo)致后面全部錯位。這個小分支往往決定整個調(diào)試體驗(yàn)。4.2 讀輸入寄存器04功能碼和寫寄存器04功能碼和03功能碼的代碼幾乎完全一致只需把req[1] 0x03改成req[1] 0x04把resp[1] ! 0x03的檢查改成resp[1] ! 0x04異常碼判斷改成0x04 | 0x80。有些傳感器把數(shù)據(jù)放在輸入寄存器區(qū)比如數(shù)據(jù)采集模塊的模擬量輸入通道這時就必須用04。06功能碼寫單個寄存器請求幀固定為8字節(jié)字段值從站地址01功能碼06寄存器地址2字節(jié)寫值2字節(jié)CRC2字節(jié)響應(yīng)幀和請求幀完全一致就是原樣返回。判斷寫成功的方式是比對響應(yīng)幀和請求幀是否逐字節(jié)相等。10功能碼寫多個寄存器稍微復(fù)雜一點(diǎn)請求幀要多一個“字節(jié)數(shù)”字段但嵌入式Linux下純采集場景很少用理解原理即可。4.3 浮點(diǎn)數(shù)怎么還原寄存器字序與IEEE754轉(zhuǎn)換不少溫濕度、壓力、流量傳感器用浮點(diǎn)數(shù)表示測量結(jié)果在Modbus里就是占用兩個16位寄存器的IEEE754單精度浮點(diǎn)數(shù)?？雌饋砗唵蔚總€廠家的寄存器順序習(xí)慣不一樣踩坑率很高。常見的兩種字序是這樣的假設(shè)要表示的浮點(diǎn)數(shù)是1.5在IEEE754下編碼為0x3FC00000。傳感器的兩個寄存器可能是字序大端Motorola順序多數(shù)國產(chǎn)傳感器用這個寄存器0 0x3FC0寄存器1 0x0000字序小端寄存器0 0x0000寄存器1 0x3FC0讀取后的轉(zhuǎn)換方法如下#include string.h float regs2float(uint16_t reg0, uint16_t reg1, int little_endian_word) { uint32_t raw; if (little_endian_word) { raw ((uint32_t)reg1 16) | reg0; } else { raw ((uint32_t)reg0 16) | reg1; } float f; memcpy(f, raw, sizeof(f)); return f; }這里必須用memcpy做位模式的轉(zhuǎn)換不能直接f (float)raw因?yàn)槟鞘前颜麛?shù)數(shù)值轉(zhuǎn)成浮點(diǎn)數(shù)數(shù)值而不是解釋IEEE754位模式。用指針強(qiáng)轉(zhuǎn)會涉及類型別名type punning問題嚴(yán)謹(jǐn)起見也建議memcpy。如果你的傳感器返回的是32位無符號整數(shù)而不是浮點(diǎn)比如脈沖計(jì)數(shù)器類的設(shè)備轉(zhuǎn)換思路完全一樣只是最后按uint32_t解釋即可。多讀幾個寄存器把原始值打印出來對比傳感器顯示值很快就能摸清廠家的字節(jié)序習(xí)慣。我的經(jīng)驗(yàn)是先用串口助手手工發(fā)一幀把返回的明文寄存器的值記下來再用傳感器面板的數(shù)值去反推它的字序不要猜直接驗(yàn)證。5. RS485方向切換硬件聯(lián)動與時序控制RS485是半雙工總線同一時刻只能有一個方向的數(shù)據(jù)在線上傳輸。對嵌入式Linux主站來說發(fā)完請求后要把總線從發(fā)送模式切換到接收模式這個過程如果處理不好數(shù)據(jù)會莫名其妙丟字節(jié)。5.1 為什么需要方向切換與全雙工的RS232不同RS485用兩根差分線A、B傳輸數(shù)據(jù)發(fā)送和接收共用物理線路。多數(shù)USB轉(zhuǎn)485模塊在電腦上能直接工作是因?yàn)槟K內(nèi)部根據(jù)收發(fā)緩沖區(qū)自動切換方向。但在嵌入式板子上如果用純TTL轉(zhuǎn)485模塊方向控制引腳DEDriver Enable通常要由MCU或Linux系統(tǒng)來控制。常見的TTL轉(zhuǎn)485模塊上DE和RE往往合并成一個引腳高電平為發(fā)送模式低電平為接收模式。如果不控制這個引腳發(fā)送請求時數(shù)據(jù)根本不會出現(xiàn)在總線上的傳感器什么都收不到或者一直處于發(fā)送模式接收時會把自己發(fā)的數(shù)據(jù)也讀回來。5.2 兩種控制方式RTS引腳和GPIO嵌入式Linux下控制485方向最典型的兩種方式第一種是利用串口的RTS引腳。很多底板設(shè)計(jì)時就把RTS接在485模塊的DE上這種方式的好處是驅(qū)動層面就能控制應(yīng)用層代碼不用管時序細(xì)節(jié)。用ioctl操作TIOCMBIC和TIOCMBIS分別拉低和拉高RTS電平#include sys/ioctl.h static void uart485_set_dir_rts(int fd, int tx_mode) { unsigned int flag TIOCM_RTS; if (tx_mode) { ioctl(fd, TIOCMBIS, flag); /* 拉高RTS進(jìn)入發(fā)送模式 */ } else { ioctl(fd, TIOCMBIC, flag); /* 拉低RTS進(jìn)入接收模式 */ } }要注意的是這里用TIOCM_RTS控制的是物理RTS引腳的電平和termios里的CRTSCTS硬件流控不是一回事。你需要確認(rèn)板卡上RTS引腳確實(shí)和485模塊的DE連接了而且拉高/拉低的極性對不對。我的板子上是拉高發(fā)送、拉低接收但有些模塊是反的極性調(diào)反的情況能用示波器量出來發(fā)送期間DE引腳波形和預(yù)期相反。第二種是用普通GPIO控制比如用sysfs或gpiod庫操作一個GPIO管腳。這種方式靈活性強(qiáng)不受串口控制器限制但需要底層把GPIO的驅(qū)動和應(yīng)用層接口打通。GPIO控制在時序上不如RTS精確因?yàn)閼?yīng)用層從write返回到GPIO翻轉(zhuǎn)之間可能有不小的延遲。不過在實(shí)際使用中配合tcdrain等函數(shù)等數(shù)據(jù)真正從物理口發(fā)完再翻轉(zhuǎn)完全夠用。5.3 切換時序修改完方向馬上讀還是延時一下方向切換最大的坑是發(fā)送完成不等于物理線路上的字節(jié)已經(jīng)發(fā)完。write系統(tǒng)調(diào)用只是把數(shù)據(jù)拷貝到內(nèi)核的發(fā)送緩沖區(qū)函數(shù)返回時UART外設(shè)甚至可能還沒開始逐字節(jié)往外發(fā)。如果寫完后立刻把方向切成接收最后一兩個字節(jié)可能剛好卡在緩沖區(qū)里發(fā)不出去。正確做法是先等待數(shù)據(jù)真正發(fā)送完成再切換到接收模式。Linux下用tcdrain完成這個等待static int uart485_send_then_recv(int fd) { /* 1. 切換為發(fā)送方向 */ uart485_set_dir(fd, 1); /* 2. 發(fā)送請求幀 */ ssize_t n write(fd, req, sizeof(req)); if (n ! sizeof(req)) { return -1; } /* 3. 等待發(fā)送緩沖區(qū)的數(shù)據(jù)全部推上物理線路 */ tcdrain(fd); /* 4. 稍微再等1~2個字符時間防止485模塊發(fā)送結(jié)束的邊沿不穩(wěn)定 */ usleep(2000); /* 5. 切回接收方向 */ uart485_set_dir(fd, 0); /* 6. 開始read等待響應(yīng) */ ... }tcdrain(fd)會阻塞直到所有數(shù)據(jù)從串口寫出去。之后我習(xí)慣再加2毫秒的延時給485模塊的收發(fā)切換電路留一點(diǎn)裕量尤其是那些比較古老的隔離型模塊其方向切換延遲可能高達(dá)1毫秒以上。這個延時不是越大越好因?yàn)榧釉诿看握埱笄皶下傒喸冎芷趯?shí)測2毫秒在9600波特率下足夠穩(wěn)定。還有一點(diǎn)容易被忽略如果采用RTS自動方向控制有些UART控制器的FIFO會在最后字節(jié)發(fā)出后自動拉低RTS省掉了應(yīng)用層的時序操作但這種情況對驅(qū)動配置要求比較高。如果你發(fā)現(xiàn)RTS方向切換不穩(wěn)定建議先切到GPIO或全應(yīng)用層手動控制跑通了再優(yōu)化。6. 調(diào)試心得從亂碼到正確解析的排錯路徑Modbus RTU調(diào)試說難不難但問題往往一層套一層沒有清晰的排查思路會花很多冤枉時間。我把自己常用的排錯路徑整理成三層檢查法從物理層、幀層到協(xié)議層逐級縮小問題范圍。6.1 第一層物理層與字符層檢查先確認(rèn)串口能收到字節(jié)。用stty配置好串口然后用printf發(fā)送一個已知的Modbus請求幀在另一個終端用hexdump觀察從站返回。這步能回答三個基本問題串口本身有沒有數(shù)據(jù)收發(fā)如果沒有問題在硬件連接、RS485方向控制或波特率。收到的字節(jié)是亂碼嗎亂碼基本就是波特率不匹配或者總線上A/B接反。A/B接反時通常能收到字節(jié)但全是0xFF或0x00這種規(guī)律性數(shù)據(jù)。返幀里有沒有CRC如果你發(fā)的請求幀CRC算錯了從站不會回復(fù)任何東西這也會被誤判成硬件問題所以必須確保你手工發(fā)的幀確實(shí)是合法的。這個階段還有一個高頻問題RS485兩端共地。如果A、B線之間沒有參考地長距離傳輸時會出現(xiàn)偶發(fā)誤碼。我的一個項(xiàng)目里傳感器離板子大約30米起初用的是兩線制接法只接A、B不接地速率一高就出亂碼。后來在傳感器端和主站端都接了屏蔽層地線數(shù)據(jù)才穩(wěn)定。短距離1米調(diào)試時可以不接地但超過幾米就要認(rèn)真對待地電位問題。6.2 第二層幀層檢查CRC和幀分割字符能收能發(fā)了下一步看幀。寫一個簡單的抓包工具把每一次read到的原始字節(jié)都打印出來重點(diǎn)觀察兩件事幀是否被分割Modbus RTU是流式協(xié)議Linux的read按串口驅(qū)動緩沖區(qū)的可用數(shù)據(jù)量返回可能一次read只拿到半個幀。如果解析代碼指望一次read讀完整幀就會出現(xiàn)偶發(fā)解析失敗。正確做法是用緩沖區(qū)累積數(shù)據(jù)并依據(jù)幀長度字段和CRC來判斷一幀是否完整。CRC是否對得上如果CRC校驗(yàn)一直失敗先檢查CRC實(shí)現(xiàn)用已知幀驗(yàn)證。我見過有人把多項(xiàng)式搞錯結(jié)果每一幀都校驗(yàn)失敗從站側(cè)則根本不響應(yīng)。幀分割問題特別隱蔽因?yàn)楹芏嗾{(diào)試板上數(shù)據(jù)量小、時序撞在一起時一次read剛好能讀完整幀看起來很正常。一旦傳感器多了、輪詢快了幀就會被拆開這時如果代碼不做累積讀取就會翻車。上面代碼里的read_full_frame函數(shù)就是為了解決這個問題每次讀取前先知道期望長度然后循環(huán)read直到湊滿。6.3 第三層協(xié)議層檢查數(shù)據(jù)解析和異常響應(yīng)幀解析無誤數(shù)據(jù)值卻有錯問題往往在協(xié)議層。排查順序是打印功能碼和字節(jié)計(jì)數(shù)字段確認(rèn)響應(yīng)符合預(yù)期格式。檢查從站地址匹配有些傳感器默認(rèn)地址是1有些是247和主站代碼寫死的不一致時會收到“地址不匹配”的報(bào)錯。檢查異常碼如果響應(yīng)是03 83 02這種異常幀說明寄存器地址或數(shù)量超出范圍需要細(xì)讀傳感器手冊確認(rèn)寄存器的地址和功能碼類型。比如有些溫濕度傳感器溫度在保持寄存器區(qū)03功能碼濕度卻在輸入寄存器區(qū)04功能碼用錯功能碼就永遠(yuǎn)讀不到正確數(shù)據(jù)。確認(rèn)字節(jié)序整型數(shù)據(jù)是大端還是小端浮點(diǎn)數(shù)據(jù)是哪種字序多讀幾個值打印出來比對。6.4 工具輔助Modbus Poll和USB轉(zhuǎn)串口對比驗(yàn)證PC端的Modbus Poll是排查從站問題的好幫手。我習(xí)慣在PC上先用USB轉(zhuǎn)485接傳感器在PC上通過Modbus Poll直接用圖形界面讀數(shù)據(jù)。這樣能確認(rèn)傳感器本身工作正常、地址和寄存器配置正確然后再回嵌入式Linux板子上聯(lián)調(diào)把問題范圍縮小到主站側(cè)。Modbus Poll還能直觀地看到異常響應(yīng)碼不用自己解析二進(jìn)制幀。至于網(wǎng)上流傳的各種Key、注冊碼個人調(diào)試用評估版完全夠不要花心思去折騰這些重點(diǎn)在數(shù)據(jù)核對。在PC上驗(yàn)證通過后回到板子上用同樣的參數(shù)跑自己的代碼如果數(shù)據(jù)不一致問題必然在自己代碼側(cè)照著上面三層逐項(xiàng)排查即可。6.5 兩個對我?guī)椭艽蟮恼{(diào)試習(xí)慣第一個是日志分級打印。調(diào)試階段我會把每幀的原始字節(jié)、CRC、解析后的寄存器值全部打印出來一級一級開著調(diào)試。比如基礎(chǔ)日志只打印每次讀到的溫濕度結(jié)果。幀日志打印收發(fā)幀的十六進(jìn)制、CRC校驗(yàn)結(jié)果。驅(qū)動日志打印每一次read返回的字節(jié)數(shù)和內(nèi)容。線上定位問題時先開基礎(chǔ)日志問題時隱時現(xiàn)就開幀日志再不行開驅(qū)動日志基本能把問題圈定在一個很小的范圍內(nèi)。第二個是污染測試。在調(diào)試過程中故意發(fā)送寄存器地址越界、長度超限的請求確保從站返回的異常響應(yīng)能被代碼正確處理。有些模塊對異常響應(yīng)的處理邏輯寫得糊里糊涂正常數(shù)據(jù)時沒事異常時就會卡死或崩潰這種問題在實(shí)際運(yùn)行中比協(xié)議錯誤更可怕。代碼里處理異常響應(yīng)的分支值得專門寫一個測試函數(shù)去觸發(fā)。7. 實(shí)際項(xiàng)目中容易忽略的幾個工程細(xì)節(jié)前面講的都是單幀收發(fā)的技術(shù)細(xì)節(jié)最后再把視角拉高一點(diǎn)聊幾個工程層面的細(xì)節(jié)。這些不是協(xié)議范疇但在實(shí)際項(xiàng)目中踩一次就夠頭疼很久。7.1 485總線的終端電阻和節(jié)點(diǎn)數(shù)量RS485總線理論上可以掛32個節(jié)點(diǎn)但每增加一個節(jié)點(diǎn)總線阻抗和信號質(zhì)量都在變化。如果你的總線長度超過幾十米或者節(jié)點(diǎn)數(shù)量多就要在總線的兩端各接一個120歐姆終端電阻用于匹配特性阻抗、減少反射。我發(fā)現(xiàn)很多工程師習(xí)慣性地只在主站端接一個120歐姆電阻另一端不接。短距離調(diào)試沒問題長距離或者干擾大的環(huán)境下波形反射會導(dǎo)致誤碼。規(guī)范做法是兩個端點(diǎn)各接一個120歐姆如果設(shè)備本身內(nèi)部已經(jīng)內(nèi)置了終端電阻很多工業(yè)模塊有跳線帽選擇就不要再另外接了否則等效阻抗變成60歐姆驅(qū)動負(fù)擔(dān)會增加。7.2 采集輪詢周期的設(shè)計(jì)Modbus主站做輪詢時不是輪詢發(fā)得越快越好。每個傳感器的響應(yīng)都需要時間而且RS485是共享總線兩個請求之間要有足夠的間隔避免請求幀重疊。我的經(jīng)驗(yàn)是每幀之間的最小間隔至少留50毫秒。如果傳感器數(shù)量多比如10個節(jié)點(diǎn)輪詢一圈就是500毫秒左右這個頻率對大多數(shù)溫濕度、壓力傳感器完全夠用。如果對實(shí)時性要求高可以縮短到20毫秒但必須先實(shí)測傳感器手冊里的最大響應(yīng)時間否則就會頻繁發(fā)生超時重試。7.3 掉線和恢復(fù)的容錯邏輯RS485鏈路在工業(yè)現(xiàn)場偶發(fā)掉線很正常。最糟糕的處理是主站發(fā)現(xiàn)超時后不停地快速重發(fā)這樣會加劇總線擁塞。更好的做法是單次采集失敗后把該節(jié)點(diǎn)的輪詢周期拉長比如正常1秒輪詢一次失敗后變成10秒輪詢一次連續(xù)3次成功后再恢復(fù)1秒周期。這種背靠背重試策略可以有效降低總線上的無效數(shù)據(jù)幀。另外每個節(jié)點(diǎn)的錯誤計(jì)數(shù)要有上限累計(jì)到一定次數(shù)后主動告警提示維護(hù)人員檢查該節(jié)點(diǎn)接線而不是在終端日志里無限刷屏。7.4 系統(tǒng)啟動階段別急著發(fā)數(shù)據(jù)嵌入式Linux板子上電后串口驅(qū)動初始化、485模塊上電穩(wěn)定都需要時間。如果應(yīng)用層剛啟動就立刻向傳感器發(fā)請求此時485模塊可能還沒進(jìn)入正常工作狀態(tài)第一幀通常會丟。建議應(yīng)用啟動后先延時數(shù)百毫秒再開始第一輪輪詢。這個細(xì)節(jié)看著不起眼但能避免系統(tǒng)啟動時日志里出現(xiàn)一大堆藍(lán)色超時錯誤。我個人實(shí)際調(diào)試中還有個習(xí)慣應(yīng)用啟動后先用診斷模式跑一輪把所有節(jié)點(diǎn)的地址掃描一遍確認(rèn)哪些節(jié)點(diǎn)在線然后才進(jìn)入正常輪詢邏輯。這個掃描過程慢一點(diǎn)沒關(guān)系但能讓后面的采集邏輯不用處理那么多“節(jié)點(diǎn)離線”的異常情況整體代碼更干凈。Modbus RTU在嵌入式Linux上做傳感器采集技術(shù)上確實(shí)不復(fù)雜但整條鏈路從串口參數(shù)、CRC計(jì)算、幀組包到485方向控制和超時策略每一個環(huán)節(jié)都有坑。把基礎(chǔ)原理吃透再按層次逐步排查你會發(fā)現(xiàn)大多數(shù)問題其實(shí)都是小細(xì)節(jié)。希望這篇筆記能幫你少走點(diǎn)彎路一次性把數(shù)據(jù)穩(wěn)定讀上來。