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