基于serialX串口驅(qū)動(dòng)移植freemodbus

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

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

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

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

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

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

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

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

可以說，驗(yàn)證了這次寫的驅(qū)動(dòng)還是很不錯(cuò)的，是成功的。

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

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

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

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

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

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

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

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

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

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

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

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

很幸運(yùn)，筆者這一步也很順利。

進(jìn)一步測試
因?yàn)樽詭У?master 樣例程序僅僅測試了一個(gè)多寄存器寫，而且，我們可以看到原來只對(duì) eMBMasterReqWriteMultipleHoldingRegister 返回錯(cuò)誤代碼計(jì)數(shù)，并沒有區(qū)分判斷會(huì)出現(xiàn)哪種錯(cuò)誤，我們把這個(gè)錯(cuò)誤碼處理一下

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)其它幾個(gè)都是有問題的。

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

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

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

因?yàn)楣P者的 slave 端是 Qt 寫的，當(dāng)前使用的這個(gè) exe 是很久之前用 Qt5.9 版本編譯出來的。筆者需要重新編譯一下這個(gè) exe 程序（現(xiàn)在安裝的版本有 Qt5.12 Qt5.15 兩個(gè)）。編譯出來新程序之后，筆者得到如下調(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í)得到的數(shù)據(jù)是什么。
在 eMBMasterRTUReceive 函數(shù)體內(nèi) if 條件語句之前添加一句代碼 od_mem((unsigned int)ucMasterRTURcvBuf, (unsigned int)ucMasterRTURcvBuf + usMasterRcvBufferPos);。這句代碼將在控制臺(tái)打印輸出接收到的 ADU 。

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

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

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

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 這個(gè)變量的地方全換成使用 serial_dev 。

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

總結(jié)

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

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

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

freemodbus 還有很多可圈可點(diǎn)的地方。但是拿它來驗(yàn)證 serialX 驅(qū)動(dòng)可能是最簡單的一個(gè)了。

最后，筆者把修改過后的 ‘portserial_m.c’ 文件上傳上來，但是請(qǐng)大家注意，不止這一個(gè)文件需要修改，但是其它修改都是因?yàn)檫@個(gè)文件引起的。