448_J1939地址声明设计代码阅读分析

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

         前面看了一个初始化的接口，发现其实跟协议栈相关的更多的还是最后的一个队地址声明接口的调用。

         这个函数是一个静态函数。

         通过这个简单的细节就可以知道，这个是一个协议栈内部的一个功能，也就是跟协议栈的协议实现有着很大的关联度。好在，看了一下这个函数的代码量之后让我舒了一口气。这个函数的实现代码量还是很小的。

         传入参数其实跟两个使用场景有关，一个是自己进行地址声明，另一个其实是做了一个仲裁。

         基础的J1939的消息设置中，控制优先级设置为了默认3级，PF的设置其实是为了组合地址声明的PGN 0x00EE00出来。而地址声明的报文是一个广播类型，发送到全局地址。数据的长度，设置为了8。

         如果是要自己声明地址，那么直接跳转到报文组装和发送即可。否则，继续往下做其他的处理。

         执行上面代码，说明是收到了地址声明。这时候，如果没有出现地址冲突则不需要做任何处理，直接退出即可。

         如果出现了地址冲突，那么得去看看NAME判断一下自己的优先级是否足够高。如果高的话，其实也不需要什么处理，只需要按照自己正常进行地址声明的过程进行一次ACL报文的发送。其实，这样的话，先前进行地址声明的CA能够接收到这条报文然后放弃自己的地址，执行上面的代码。而上面的代码实现的功能包括：1，如果支持地址仲裁，需要看自己是否能够成功计算出来合适的地址； 2，NAME组装到ACL中； 3，放弃地址，也就是具有控制地；4，发送ACL报文说明自己地址声明不成功； 5，后续只接收发给全局地址的报文； 6，更新相关的运行状态。

         如果，仲裁地址支持且成功计算出来了合适的地址，或者地址竞争失败尝试去声明新地址，或者判断出来自己的优先级高那么进行这一段代码的执行。而地址范围的判断，应该是为了服务于具备自动计算CA地址的应用而设计的。如果，地址声明是成功的，那么应该设置滤波器后续只收自己需要接收的消息。

         以上是对这个函数做一个大致的分析，如果要理解透接下来或许我得把每一个用到这个接口的地方给分析一下。