測試環境
開發板： NK-980IOT V1.0 的開發板
rt-thread 版本：4.1.1
IDE：keil + env

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

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

然后使用 serialX 中提供的 測試程序 serialX_test.c 簡單測試了一下，收發回環沒發現嚴重問題（沒有數據丟失，沒有數據錯誤）。

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

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

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

libmodbus 的源碼文件數量比 freemodbus 少很多了。看起來清晰很多。

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

首先，第一類錯誤是：
error: #20: identifier "EBADF" is undefined
error: #20: identifier "ECONNRESET" is undefined
...
這幾個宏定義在 “errno.h” 頭文件，這個文件呢，在某個版本移動過路徑，沒記錯的話也是從 4.0.3 之后開始的。現在的用法是 #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 ，因為后者文件也只有一行內容就是 #include 。

modbus.c 添加 #include

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

第一次運行測試程序
開始跑測試程序之前，去掉 RS485 的所有相關代碼。添加 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 端的調試信息是：

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"
分析兩端的調試信息， slave 端既接收到了請求 ADU，也正常回復了響應 ADU。但是 libmodbus 的 master 端并沒有收到任何響應！

問題定位過程

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

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

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

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

第二次運行測試程序

注釋掉這句代碼后，再跑 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>

終于看到想要的信息了。

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

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

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

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

結束語
使用 libmodbus 的代價是很高的，從前邊提到過的函數調用過程，就夠人頭疼的

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

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