基于serialX串口驅(qū)動移植libmodbus的步驟

測試環(huán)境
開發(fā)板： NK-980IOT V1.0 的開發(fā)板
rt-thread 版本：4.1.1
IDE：keil + env

NUC980 serialX 驅(qū)動
之前，筆者介紹 serialX 的時候，曾詳細(xì)的講解過 struct rt_uart_ops 接口中的每一個函數(shù)的功能。完全按照每一個函數(shù)功能定義去做，后面的事情就是水到渠成的。

花了小半天的時間從 drv_uart.c 改成 drv_uartX.c 。

然后使用 serialX 中提供的 測試程序 serialX_test.c 簡單測試了一下，收發(fā)回環(huán)沒發(fā)現(xiàn)嚴(yán)重問題（沒有數(shù)據(jù)丟失，沒有數(shù)據(jù)錯誤）。

啟用控制臺和 finsh 。改成“中斷收發(fā)讀寫”模式，試了幾個命令，打印結(jié)果完整。

可以說，驗證了這次寫的驅(qū)動還是很不錯的，是成功的。

啟用 libmodbus
env 環(huán)境里啟用 libmodbus，使能 “Enable libmodbus rtu mode” rtu 模式并使能 “Enable rtu example” rtu 樣例程序。
使用命令 pkgs --update 下載 libmodbus 源碼。

libmodbus 的源碼文件數(shù)量比 freemodbus 少很多了?？雌饋砬逦芏唷?/p>

第一次試編譯
生成項目后先嘗試編譯一次，出現(xiàn)了很多錯誤。

首先，第一類錯誤是：
error: #20: identifier "EBADF" is undefined
error: #20: identifier "ECONNRESET" is undefined
...
這幾個宏定義在 “errno.h” 頭文件，這個文件呢，在某個版本移動過路徑，沒記錯的話也是從 4.0.3 之后開始的。現(xiàn)在的用法是 #include

modbus-rtu.c 修改 #include -> #include
modbus.c 修改 #include -> #include

然后，第二種錯誤是：
error: #20: identifier "fd_set" is undefined
warning: #223-D: function "FD_ZERO" declared implicitly
warning: #223-D: function "FD_SET" declared implicitly
這幾個定義在 “sys/select.h” ，可以 #include ，也可以 #include ，因為后者文件也只有一行內(nèi)容就是 #include 。

modbus.c 添加 #include

至此，應(yīng)該是把所有版本升級引起的兼容錯誤修正了。

第一次運(yùn)行測試程序
開始跑測試程序之前，去掉 RS485 的所有相關(guān)代碼。添加 libmodbus 的 debug modbus_set_debug(ctx, TRUE);。這可以讓我們看到很多的有用信息。

和上次的 freemodbus 樣例程序不一樣的是，這次是讀保持寄存器，并不是寫寄存器。

測試開始以后，筆者在控制臺終端里看到如下信息，

[01][03][00][00][00][0A][C5][CD]
Waiting for a confirmation...
msh >ERROR Unknown error: select

[ 0][read num = -1]<0><0><0><0><0><0><0><0><0><0>

而，在 slave 端的調(diào)試信息是：

qt.modbus.lowlevel: (RTU server) Received ADU: "01030000000ac5cd"
qt.modbus: (RTU server) Request PDU: 0x030000000a
qt.modbus: (RTU server) Response PDU: 0x031400110022003300440055006600770088009900aa
qt.modbus.lowlevel: (RTU server) Response ADU: "01031400110022003300440055006600770088009900aa4584"
分析兩端的調(diào)試信息， slave 端既接收到了請求 ADU，也正常回復(fù)了響應(yīng) ADU。但是 libmodbus 的 master 端并沒有收到任何響應(yīng)！

問題定位過程

首先確定串口接收中斷沒觸發(fā)，也就是給開發(fā)板發(fā)的數(shù)據(jù)并沒有接收中斷；
調(diào)出串口外設(shè)寄存器發(fā)現(xiàn)，中斷使能寄存器的值變成 0 了！串口中斷使能寄存器被某個力量情況復(fù)位了！
再次回到串口驅(qū)動測試程序，筆者很確定是使用的中斷接收模式，并且可以有接收中斷。

問題好像很明顯，libmodbus 在打開串口外設(shè)的過程中，某些操作清理了串口外設(shè)寄存器。

經(jīng)過詳細(xì)比對，libmodbus 打開串口設(shè)備后使用 termios 配置串口設(shè)備的波特率數(shù)據(jù)位等。而筆者上次在測試 posix 接口時使用的默認(rèn)配置，并沒有修改波特率。為了驗證并跟蹤問題位置，筆者在 “serialX_posix.c” 里添加 termios 配置函數(shù)。

經(jīng)過一步步代碼調(diào)試跟蹤，得到函數(shù)調(diào)用鏈 tcsetattr -> ioctl -> fcntl -> dfs_file_ioctl -> serial_fops_ioctl -> rt_device_control -> rt_serial_control -> nu_uart_configure ，最后這個函數(shù)有一句 nu_sys_ip_reset(((nu_uart_t)serial)->rstidx); ，這句會復(fù)位中斷寄存器的值。

第二次運(yùn)行測試程序

注釋掉這句代碼后，再跑 libmodbus 樣例程序，

[01][03][00][00][00][0A][C5][CD]
Waiting for a confirmation...
<01><03><14><00><11><00><22><00><33><00><44><00><55><00><66><00><77><00><88><00><99><00><45><84>

[ 11][read num = 10]<0x11><0x22><0x33><0x44><0x55><0x66><0x77><0x88><0x99><0xaa>

終于看到想要的信息了。

問題復(fù)盤
使用過 rt-thread 串口驅(qū)動框架的人都知道，rt_device_find rt_device_control rt_device_open 是讀寫串口設(shè)備前的三步曲，這三個步驟順序的不能亂的。rt_device_control和rt_device_open執(zhí)行先后的問題

也就是說，配置串口波特率數(shù)據(jù)位等必須在打開設(shè)備之前！

我們再看 libmodbus 的做法，先 open ，然后調(diào)用 tcsetattr … -> rt_device_control。

那么，筆者刪掉的那句代碼是錯誤的嗎？好像也不能這么說，它是“有用的”，可能它是出現(xiàn)在了不該出現(xiàn)的地方。

結(jié)束語
使用 libmodbus 的代價是很高的，從前邊提到過的函數(shù)調(diào)用過程，就夠人頭疼的

但是，libmodbus 更適合系統(tǒng)，它只用了一個線程就能跑起來。freemodbus 用了三個（意味著更多的線程棧耗用）。

這次測試，我們發(fā)現(xiàn)了兩處升級引入的版本兼容錯誤，以及 open configure 順序引起的外設(shè)工作異常的問題。