關(guān)于 serialX
之前，筆者寫過多篇 serialX 的文章，已經(jīng)把它的原理和理念完完全全明明白白講了，包括它的優(yōu)勢以及使用它需要注意的方面和可能遇到的問題。

到目前為止，筆者只介紹了 finsh/msh 使用 serialX ，實現(xiàn)了中斷接收中斷發(fā)送模式打開串口設(shè)備，這次嘗試讓筆者堅信了即便使用 DMA 收發(fā)也能在 finsh 里應(yīng)付自如。今天我們嘗試一下在 freemodbus 里使用 serialX 。

注：筆者寫過文章，討論在控制臺或者 finsh 里完全的中斷收發(fā)或者完全的 DMA 收發(fā)會有哪些問題。有興趣的大家可以找找看。

測試環(huán)境
筆者手里有一塊兒 NK-980IOT V1.0 的開發(fā)板，這是去年 rt-thread 論壇搞的測評活動送的。一方面，它吃灰很久了，另一方面，serialX 的驅(qū)動很久沒新增了。趁此機會，筆者把 NUC980 的 serialX 驅(qū)動加上，然后在此基礎(chǔ)上調(diào)試出 console 和 finsh，最后移植 freemodbus 試試會遇到什么問題。

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

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

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

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

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

啟用 freemodbus
env 環(huán)境里啟用 freemodbus，打開 modbus master 并添加 master 的測試程序。
使用命令 pkgs --update 下載 freemodbus 源碼。

打開項目后，我們可以看到 “sample_mb_master.c” “port” 開頭的以及幾個 “mb” 開頭的?！眘ample_mb_master.c” 文件是測試樣例程序，”port” 開頭的文件是 freemodbus 在 rt-thread 系統(tǒng)上的接口，剩余的是 freemodbus 的核心程序。

這里面 “sample_mb_master.c” “portserial_m.c” 這兩個文件是今天我們最關(guān)心的。我們可以打開看看這倆文件都做了啥。

“sample_mb_master.c”
這個文件的主要工作是創(chuàng)建了兩個線程。

一個用來循環(huán)調(diào)用 eMBMasterPoll 函數(shù)，這個函數(shù)是 freemodbus 工作引擎。不循環(huán)執(zhí)行這個函數(shù) freemodbus 跑不起來。

另一個模式應(yīng)用層線程，用來發(fā)送多寄存器寫請求（在這個樣例程序里只用這個來做演示）。

“portserial_m.c”
這個文件里是串口設(shè)備操作相關(guān)的。比如初始化、打開、關(guān)閉，寫數(shù)據(jù)到串口設(shè)備，從串口設(shè)備讀數(shù)據(jù)等等。

xMBMasterPortSerialInit
筆者第一次打開這個文件，滿眼看到的 serial->config. serial->ops->configure 等操作把我驚呆了。

初始化過程最后創(chuàng)建了子線程 serial_soft_trans_irq ，它的工作就是發(fā)送數(shù)據(jù)。

serial_soft_trans_irq
發(fā)送子線程入口函數(shù)，這個函數(shù)只關(guān)心 EVENT_SERIAL_TRANS_START 事件，接收到事件后調(diào)用 xMBMasterRTUTransmitFSM 函數(shù)，如果數(shù)據(jù)沒發(fā)送完，調(diào)用 xMBMasterPortSerialPutByte->xMBMasterPortSerialPutByte 往串口寫 1 個字節(jié)數(shù)據(jù)。循環(huán)執(zhí)行直到把所有需要發(fā)送的數(shù)據(jù)寫完。

第一次測試
經(jīng)過簡單瀏覽后，筆者想盡快運行程序，做進一步觀察。

計算機端，筆者用一個 Qt5 寫的 modbus slave 終端。如果一切順利，NK-980IOT 開發(fā)板上發(fā)的多寄存器寫請求會對 Qt5 modbus slave 終端里的數(shù)據(jù)修改，并界面上顯示到數(shù)據(jù)變化。

很幸運，筆者這一步也很順利。

進一步測試
因為自帶的 master 樣例程序僅僅測試了一個多寄存器寫，而且，我們可以看到原來只對 eMBMasterReqWriteMultipleHoldingRegister 返回錯誤代碼計數(shù)，并沒有區(qū)分判斷會出現(xiàn)哪種錯誤，我們把這個錯誤碼處理一下

rt_uint32_t err_no = 0, err_reg = 0, err_arg = 0, err_data = 0, err_tout = 0;
switch (error_code) {
case MB_MRE_NO_ERR:
    err_no++;
break;
case MB_MRE_NO_REG:
    err_reg++;
break;
case MB_MRE_ILL_ARG:
    err_arg++;
break;
case MB_MRE_REV_DATA:
    err_data++;
break;
case MB_MRE_TIMEDOUT:
    err_tout++;
break;
default:
    rt_kprintf("n:%d; r:%d; a:%d; d:%d; t:%dn", err_no, err_reg, err_arg, err_data, err_tout);
break;
}

這幾種返回碼，只有 MB_MRE_NO_ERR 是正常和完美的，如果出現(xiàn)其它幾個都是有問題的。

筆者經(jīng)過關(guān)閉 slave 端，可以測試出現(xiàn) MB_MRE_TIMEDOUT 。但是，經(jīng)常還會出現(xiàn) MB_MRE_REV_DATA 這個錯誤?。?！

MB_MRE_REV_DATA 錯誤跟蹤
這個錯誤字面含義是，有接收數(shù)據(jù)，但是接收的數(shù)據(jù)有異常！我們上面的測試只有一個“多寄存器寫”，master 發(fā)寫請求了以后，只有可能收到成功響應(yīng)（MB_MRE_NO_ERR），或者錯誤響應(yīng)信息（MB_MRE_NO_REG MB_MRE_ILL_ARG）。不應(yīng)該會出現(xiàn) slave 給 master 主動發(fā)請求的。

為了觀察 slave 端接收和發(fā)送數(shù)據(jù)，筆者計劃把 slave 端的調(diào)試打開，檢查一下它是不是回復(fù)響應(yīng)出現(xiàn)錯誤了。

因為筆者的 slave 端是 Qt 寫的，當前使用的這個 exe 是很久之前用 Qt5.9 版本編譯出來的。筆者需要重新編譯一下這個 exe 程序（現(xiàn)在安裝的版本有 Qt5.12 Qt5.15 兩個）。編譯出來新程序之后，筆者得到如下調(diào)試信息（無論是 Qt5.12 還是 Qt5.15），

qt.modbus.lowlevel: (RTU server) Received ADU: "01100000000408000f0049000200003574"
qt.modbus: (RTU server) Request PDU: 0x100000000408000f004900020000
qt.modbus: (RTU server) Response PDU: 0x1000000004
qt.modbus.lowlevel: (RTU server) Response ADU: "011000000004c1ca"
qt.modbus.lowlevel: (RTU server) Received ADU: "011000000004080013004b000200009175"
qt.modbus: (RTU server) Request PDU: 0x1000000004080013004b00020000
qt.modbus: (RTU server) Response PDU: 0x1000000004
qt.modbus.lowlevel: (RTU server) Response ADU: "011000000004c1ca"
qt.modbus.lowlevel: (RTU server) Received ADU: "011000000004080027004d000200006cb6"
qt.modbus: (RTU server) Request PDU: 0x1000000004080027004d00020000
qt.modbus: (RTU server) Response PDU: 0x1000000004
qt.modbus.lowlevel: (RTU server) Response ADU: "011000000004c1ca"

slave 斷得到了完整正確的 ADU，響應(yīng)的 ADU 也是正常的。接下來再回過頭看看開發(fā)板接收響應(yīng) ADU 時得到的數(shù)據(jù)是什么。
在 eMBMasterRTUReceive 函數(shù)體內(nèi) if 條件語句之前添加一句代碼 od_mem((unsigned int)ucMasterRTURcvBuf, (unsigned int)ucMasterRTURcvBuf + usMasterRcvBufferPos);。這句代碼將在控制臺打印輸出接收到的 ADU 。

筆者看到了很多 “01040004 70F9C1” “01040004 70F9F9” 或者其它數(shù)據(jù)，但是正確的應(yīng)該是 “01100000 0004C1CA”，很多次才出現(xiàn)一次正確的。為什么從串口發(fā)出去的數(shù)據(jù)是正確的，能被遠端正常接收，遠端響應(yīng)回來的數(shù)據(jù)就出現(xiàn)接收錯誤了？！

為了確定開發(fā)板和驅(qū)動工作還是正常的，筆者又切換到 serialX 的測試程序，用收發(fā)回環(huán)測試一遍沒有問題，再測試 freemodbus 接收仍然異常！

修改 xMBMasterPortSerialInit
前邊筆者說過，當看到 serial->config. serial->ops->configure 等操作時驚呆了。這一步，讓上帝的歸上帝吧。

serial_dev = rt_device_find(uart_name);
if(serial_dev == RT_NULL)
{
    /* can not find uart */
    return FALSE;
}
/* set serial configure parameter */
uart_conf.baud_rate = ulBaudRate;
/* set serial configure */
rt_device_control(serial_dev, RT_DEVICE_CTRL_CONFIG, &uart_conf);
/* open serial device */
if (!rt_device_open(serial_dev, RT_DEVICE_OFLAG_RDWR | RT_DEVICE_FLAG_INT_RX | RT_DEVICE_FLAG_INT_TX)) {
    rt_device_set_rx_indicate(serial_dev, serial_rx_ind);
} else {
    return FALSE;
}

全局變量 static struct rt_serial_device *serial; 改成 static rt_device_t serial_dev = RT_NULL;。所有使用 serial 這個變量的地方全換成使用 serial_dev 。

這樣修改了以后，一切變得明朗了起來。

總結(jié)

除了上面提到的那個問題，筆者還遇到一種情況，slave 端接收串口數(shù)據(jù)經(jīng)常出現(xiàn)斷幀，而且字符接收間隔長達 10+ms 。這種情況，當筆者將 rt_device_write(serial_dev, 0, pucByte, 1); 改成 rt_device_write(serial_dev, 0, pucByte, sz); 后得到解決。但是，之后再也沒復(fù)現(xiàn)。

得益于 serialX 的框架理念，我們可以從“一個字節(jié)一個字節(jié)的寫”提升到“寫一批字節(jié)”。而且放到發(fā)送緩存里的數(shù)據(jù)，無論使用中斷發(fā)送還是 DMA 發(fā)送都不會對應(yīng)用層帶來任何壓力。

另一方面，讀 modbus ADU 的時候，其實也可以“讀一批字節(jié)”。不是一個字節(jié)中斷，read 一個字節(jié)，下一個接收字節(jié)中斷，再 read 一個字節(jié)…

freemodbus 還有很多可圈可點的地方。但是拿它來驗證 serialX 驅(qū)動可能是最簡單的一個了。

最后，筆者把修改過后的 ‘portserial_m.c’ 文件上傳上來，但是請大家注意，不止這一個文件需要修改，但是其它修改都是因為這個文件引起的。