基于serialX串口驱动移植freemodbus

关于 serialX
之前，笔者写过多篇 serialX 的文章，已经把它的原理和理念完完全全明明白白讲了，包括它的优势以及使用它需要注意的方面和可能遇到的问题。

到目前为止，笔者只介绍了 finsh/msh 使用 serialX ，实现了中断接收中断发送模式打开串口设备，这次尝试让笔者坚信了即便使用 DMA 收发也能在 finsh 里应付自如。今天我们尝试一下在 freemodbus 里使用 serialX 。

注：笔者写过文章，讨论在控制台或者 finsh 里完全的中断收发或者完全的 DMA 收发会有哪些问题。有兴趣的大家可以找找看。

测试环境
笔者手里有一块儿 NK-980IOT V1.0 的开发板，这是去年 rt-thread 论坛搞的测评活动送的。一方面，它吃灰很久了，另一方面，serialX 的驱动很久没新增了。趁此机会，笔者把 NUC980 的 serialX 驱动加上，然后在此基础上调试出 console 和 finsh，最后移植 freemodbus 试试会遇到什么问题。

NUC980 serialX 驱动
之前，笔者介绍 serialX 的时候，曾详细的讲解过 struct rt_uart_ops 接口中的每一个函数的功能。完全按照每一个函数功能定义去做，后面的事情就是水到渠成的。

花了小半天的时间从 drv_uart.c 改成 drv_uartX.c 。

然后使用 serialX 中提供的 测试程序 serialX_test.c 简单测试了一下，收发回环没发现严重问题（没有数据丢失，没有数据错误）。

启用控制台和 finsh 。改成“中断收发读写”模式，试了几个命令，打印结果完整。

可以说，验证了这次写的驱动还是很不错的，是成功的。

启用 freemodbus
env 环境里启用 freemodbus，打开 modbus master 并添加 master 的测试程序。
使用命令 pkgs --update 下载 freemodbus 源码。

打开项目后，我们可以看到 “sample_mb_master.c” “port” 开头的以及几个 “mb” 开头的。”sample_mb_master.c” 文件是测试样例程序，”port” 开头的文件是 freemodbus 在 rt-thread 系统上的接口，剩余的是 freemodbus 的核心程序。

这里面 “sample_mb_master.c” “portserial_m.c” 这两个文件是今天我们最关心的。我们可以打开看看这俩文件都做了啥。

“sample_mb_master.c”
这个文件的主要工作是创建了两个线程。

一个用来循环调用 eMBMasterPoll 函数，这个函数是 freemodbus 工作引擎。不循环执行这个函数 freemodbus 跑不起来。

另一个模式应用层线程，用来发送多寄存器写请求（在这个样例程序里只用这个来做演示）。

“portserial_m.c”
这个文件里是串口设备操作相关的。比如初始化、打开、关闭，写数据到串口设备，从串口设备读数据等等。

xMBMasterPortSerialInit
笔者第一次打开这个文件，满眼看到的 serial->config. serial->ops->configure 等操作把我惊呆了。

初始化过程最后创建了子线程 serial_soft_trans_irq ，它的工作就是发送数据。

serial_soft_trans_irq
发送子线程入口函数，这个函数只关心 EVENT_SERIAL_TRANS_START 事件，接收到事件后调用 xMBMasterRTUTransmitFSM 函数，如果数据没发送完，调用 xMBMasterPortSerialPutByte->xMBMasterPortSerialPutByte 往串口写 1 个字节数据。循环执行直到把所有需要发送的数据写完。

第一次测试
经过简单浏览后，笔者想尽快运行程序，做进一步观察。

计算机端，笔者用一个 Qt5 写的 modbus slave 终端。如果一切顺利，NK-980IOT 开发板上发的多寄存器写请求会对 Qt5 modbus slave 终端里的数据修改，并界面上显示到数据变化。

很幸运，笔者这一步也很顺利。

进一步测试
因为自带的 master 样例程序仅仅测试了一个多寄存器写，而且，我们可以看到原来只对 eMBMasterReqWriteMultipleHoldingRegister 返回错误代码计数，并没有区分判断会出现哪种错误，我们把这个错误码处理一下

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 是正常和完美的，如果出现其它几个都是有问题的。

笔者经过关闭 slave 端，可以测试出现 MB_MRE_TIMEDOUT 。但是，经常还会出现 MB_MRE_REV_DATA 这个错误！！！

MB_MRE_REV_DATA 错误跟踪
这个错误字面含义是，有接收数据，但是接收的数据有异常！我们上面的测试只有一个“多寄存器写”，master 发写请求了以后，只有可能收到成功响应（MB_MRE_NO_ERR），或者错误响应信息（MB_MRE_NO_REG MB_MRE_ILL_ARG）。不应该会出现 slave 给 master 主动发请求的。

为了观察 slave 端接收和发送数据，笔者计划把 slave 端的调试打开，检查一下它是不是回复响应出现错误了。

因为笔者的 slave 端是 Qt 写的，当前使用的这个 exe 是很久之前用 Qt5.9 版本编译出来的。笔者需要重新编译一下这个 exe 程序（现在安装的版本有 Qt5.12 Qt5.15 两个）。编译出来新程序之后，笔者得到如下调试信息（无论是 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，响应的 ADU 也是正常的。接下来再回过头看看开发板接收响应 ADU 时得到的数据是什么。
在 eMBMasterRTUReceive 函数体内 if 条件语句之前添加一句代码 od_mem((unsigned int)ucMasterRTURcvBuf, (unsigned int)ucMasterRTURcvBuf + usMasterRcvBufferPos);。这句代码将在控制台打印输出接收到的 ADU 。

笔者看到了很多 “01040004 70F9C1” “01040004 70F9F9” 或者其它数据，但是正确的应该是 “01100000 0004C1CA”，很多次才出现一次正确的。为什么从串口发出去的数据是正确的，能被远端正常接收，远端响应回来的数据就出现接收错误了？！

为了确定开发板和驱动工作还是正常的，笔者又切换到 serialX 的测试程序，用收发回环测试一遍没有问题，再测试 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 。

这样修改了以后，一切变得明朗了起来。

总结

除了上面提到的那个问题，笔者还遇到一种情况，slave 端接收串口数据经常出现断帧，而且字符接收间隔长达 10+ms 。这种情况，当笔者将 rt_device_write(serial_dev, 0, pucByte, 1); 改成 rt_device_write(serial_dev, 0, pucByte, sz); 后得到解决。但是，之后再也没复现。

得益于 serialX 的框架理念，我们可以从“一个字节一个字节的写”提升到“写一批字节”。而且放到发送缓存里的数据，无论使用中断发送还是 DMA 发送都不会对应用层带来任何压力。

另一方面，读 modbus ADU 的时候，其实也可以“读一批字节”。不是一个字节中断，read 一个字节，下一个接收字节中断，再 read 一个字节…

freemodbus 还有很多可圈可点的地方。但是拿它来验证 serialX 驱动可能是最简单的一个了。

最后，笔者把修改过后的 ‘portserial_m.c’ 文件上传上来，但是请大家注意，不止这一个文件需要修改，但是其它修改都是因为这个文件引起的。