嵌入式技术论坛
直播中

王艳

7年用户 1232经验值
私信 关注
[经验]

浅析基于serialX串口驱动移植libmodbus

关于 serialX
上一篇我们基于 serialX 驱动,移植 freemodbus 并填了几个坑。今天换 libmodbus 看看会遇到什么。

测试环境
开发板: 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 <sys/errno.h>

modbus-rtu.c 修改 #include <errno.h> -> #include <sys/errno.h>
modbus.c 修改 #include <errno.h> -> #include <sys/errno.h>

然后,第二种错误是:
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 <sys/select.h> ,也可以 #include <dfs_select.h>,因为后者文件也只有一行内容就是 #include <sys/select.h>。

modbus.c 添加 #include <sys/select.h>

至此,应该是把所有版本升级引起的兼容错误修正了。

第一次运行测试程序
开始跑测试程序之前,去掉 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 顺序引起的外设工作异常的问题。

原作者:出出啊

更多回帖

发帖
×
20
完善资料,
赚取积分