453_J1939命令地址PGN 65240(FED8)的使用

         全部学习笔记汇总: https://github.com/GreyZhang/J1939_basic

         前面了解了一下广播多帧报文的实现分析,当时发送了一个0xFED8(65240)PGN的信息。但是,这种数据的组包顺序以及规则没有弄清楚。

         我没有系统阅读过全部的J1939的资料,因此直接借助了网络资源。找到了一份文件,对此的解释如下:

         这一组报文的发送必须是通过BAM来实现,因此这是之前我们看到的功能的实现原因。之前的报文发送,采用的正好就是BAM多帧报文。相关的代码如下:

         而报文发送的解释,在我找到的文档如下:

         这部分正好是对上面代码的解释。

         这部分是多帧报文的数据包,一共是2包数据。其中,第一帧报文发送了被控CA的NAME的前7个字节。第二帧报文发送了CA的NAME的第8个字节。这样,两帧报文发送了8个字节的NAME。而接下来,第二帧报文还有一个字节的信息,是修改的地址。

         这样,我之前看过的代码再看一下。

         第一段代码,先组装了PGN的信息,BAM发送的目标地址是全局地址。每个消息的第一个字节的信息是数据包的编号,其他的则按照上面的内容进行组装。无效的数据场填充成了0xFF。

修改后的新地址是132,也就是十六进制的0x84。

         相关的功能运行,测试一下。

         首先,各自的地址声明报文。数据场中,是CA的NAME。

         接下来的处理,前面5次请求都是从0x81发送给0x84的。因此,0x80的节点没有任何响应。接下来的按键,触发了命令地址功能。其中,第一条报文就是通过EC00的PGN BAM来通知接下来进行多针报文发送。数据场中,第一个字节的0x20正好是十进制的32,是一个固定值。接下来,09代表9个字节的数据。2则是代表两个报文发完全部的数据。接下来的FF是预留的数据位。00FED8,则是接下来需要利用DT发送数据的PGN。再往下,是两个数据包。其中,33以及一串0与前面的0x80节点的NAME一致。而后面的84,则是新的地址。

         其实,上面截图里面的广播一行是多出来的一行解析显示,并不是多了一份报文。对比最原始的log还是可以看的出来的。

         最后一条报文的功能则是原来的0x80的CA在接收到命令之后,重新进行了地址声明。后续继续测试,两个按键则可以正常通信了。

         在网络资料中看到,一般情况下,这个功能之后,修改软件之后的CA应该修改自己的地址并且存储EEPROM。

已标记关键词 清除标记
©️2020 CSDN 皮肤主题: 编程工作室 设计师:CSDN官方博客 返回首页