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。