Local Interconnect Network(LIN)基础和STM32的USART模块的LIN模式

     $LIN(LocalInterconnectNetwork)$是一种串行网络协议，它主要用于汽车上各个模块之间的通信。它提出的原因是随着汽车工业的发展如果汽车上的所有模块都使用$CAN$总线的话性价比太低，简直就是杀鸡用牛刀。$LIN$就是$CAN$总线的一种互补协议，但是$LIN$协议代价更低，但是足以满足一些不太重要的汽车上的模块的需求。
     $LIN$网络一般由一个主节点和至多15或16个从节点组成，如果从节点再多的话，通信的稳定性将得不到保证，整个网络只需要一根信号线和另外的一根地线就可以了。网络中的所有通信都由主节点发起，主节点也管理着整个网络的通信。图1是一张来至于这里的简单示意图。

　 图1.

     $LIN$消息由消息头部和消息响应所组成，如图2所示。消息头部一般由主节点发送，消息响应由从节点发送，主节点也可以发送消息响应。$SyncBreak$和$SyncField$域是用来和从节点进行同步用的，因为网络中没有使用时钟线。$PIDField$域用来标示哪个从节点来响应该消息头部以及响应的方式（发送消息还是接收消息）。$Datan$域就是从节点具体发送的消息了，一个字节一个字节的发送，最多8个字节。$CheckSum$域就是和$CRC$类似的一种判断接收到的数据是否有误的一种机制。

　 图2.

     这里有必要先提一下$LIN$可能一般没有专门针对其的硬件模块，像一般的具有$USART$模块的$MCU$就可以实现$LIN$协议，因为在$LIN$协议中一个字节的传输也是按照一个起始位（低电平），8个数据位（最低位优先发送）和一个停止位（高电平）这个模式来进行的，因此像$STM32$这样的$MCU$的$USART$模块足以完成这样的任务。$STM32$的$USART$模块也有$LIN$模式。
     $SyncBreak$域是比较特殊的一个，它由至少13个低电平的比特时间构成。这个就和$STM32$的$USART$模块的$BreakCharacters$比较像，但是就算$STM32$的$USART$模块设置数据位为9比特，$BreakCharacters$也只持续11个低电平。当$STM32$的$USART$模块开启$LIN$模式之后$BreakCharacters$就变成了13个持续的低电平。当从节点检测到13个低电平后它就会等待着一个高电平的，因为这个高电平标示着$SyncField$域将要到来。$SyncField$域是固定的字节数据$0x55$。$PIDField$域的最低6个比特就标示着哪个从节点来响应该消息头部以及响应的方式（发送消息还是接收消息），最高两个比特位是奇偶校验位，也就是用来判断接收的$PIDField$域的最低6个比特是否有错。详见图3。

　 图3.

     数据响应相关的域就比较简单了这里就不每一个域来细讲了，只要知道其中每一个字节也都是按照一个起始位（低电平），8个数据位（最低位优先发送）和一个停止位（高电平）这个模式来发送的就可以。至于$PIDField$域的最高两个比特位的奇偶校验位和$CheckSum$域值的计算我这里就不细讲了，其它相关博客中都有介绍，比如这位大哥的和这位大哥的。
     当然数据头部和数据响应，或者数据头部中的每一个域，又或者数据响应中的每一个域或数据之间并不是无缝衔接的发送的，这位$LIN$属于是异步串行的，因此数据头部和数据响应，或者数据头部中的每一个域，又或者数据响应中的每一个域或数据之间是允许有时间间隔的，只是不要超过一定的上限就好。如图4所示。

　 图4.

     这里我个人认为如果$LIN$的具体硬件如果使用$STM32$的$USART$模块的话，具体的协议的收发流程还是得软件来实现，下面来看一看$LIN$的主节点和从节点的通信的状态图,如图5和图6所示。这里参考了官方的一个PDF文件。

　 图5.

　 图6.

     因为$LIN$没有仲裁器所以主节点控制所有的发送和接收通信，一般是通过$SCHEDULE$来实现控制的。如图7所示。$SCHEDULE$规定了每一个数据头部的发送时刻和$PIDField$域，发送时刻保证了数据响应的时间。根据应用的需求，在完成$SCHEDULE$表规定的$t_n$时刻的消息头部的发送之后又可以从$SCHEDULE$表规定的$t_1$时刻开始发送。在出现通信碰撞冲突时也是采用类似的$SCHEDULE$来实现控制的。

　 图7.

     接下来来看一看$LIN$的消息的类型，这里只是根据网络上的资料并结合我自己的理解做出的总结，并不保证百分百正确，我自己也没有去实践过$LIN$协议，所以要有深刻认识的话还是得自己去亲自实践一下的好：

• 无条件帧$(Unconditionalframe)$:它的$PIDField$域的低六位的范围是 0 to 59 (0x00 to 0x3b)，它的典型特征是主节点发送一个消息头，从节点根据是否和主节点发送的$PIDField$域的低六位的值匹配选择是否发送数据。一般无条件帧只会有一个从节点或主节点发送消息响应，所以不会有冲突发生。如图8所示。
• 事件触发帧$(Event-triggeredframe)$ ：事件触发帧以我的理解是主节点想要知道各个从节点的状态是否变化，比如车门是否打开、车窗是否关闭以及雨刮是否开启。这里与无条件帧不同的是主节点发送消息头部之后当多个节点的状态发生变化时就会有多个从节点发送相应。当一个节点的状态发生变化时就只有一个从节点发送相应。当没有节点的状态发生变化时就没有节点发送相应。当没有节点或只有一个节点的状态发生变化时和无条件帧一样没什么差别，但是当多个节点的状态都发生变化时，这样就会同时有多个从节点去响应，这样就出现冲突了。主机节点解决冲突的办法是，使用无条件帧将所有从节点轮询一遍来查看哪些节点的状态发生了变化，也就是给每一个从节点发送一条无条件帧。因为同时有多个节点的状态发生变化这样的事件的概率是比较小的，如果不使用事件触发帧，每次想知道每一个节点的状态是否发生变化就需要给米一个节点发送一个无条件帧，这样的做法对带宽的消耗是很大的，使用事件触发帧的目的就是为了减少这样不必要的带宽消耗。如图9所示。
• 偶发帧（Sporadic Frame): 自我觉得是当主节点想要改变某些从节点的状态时发送的，所以又称为针对主节点的事件触发帧。当主节点只想改变一个从节点的状态时，跟一般的无条件帧也没啥区别，但是如果想改变多个从节点的状态的话，如果同时发送多个针对多个从节点的无条件帧的话就会出现冲突，这时主节点处理冲突的方法是根据每一个从节点在对应的优先级表中优先级来逐一发送对应于每一个从节点的无条件帧。如图10所示。
• 诊断帧（Diagnostic frame）：它又分为主机请求帧和从机应答帧，用来携带诊断或配置数据。主机请求帧的$PIDField$域的低六位的值为60 (0x3C), 这里主机既发送消息头部也发送消息响应。从机应答帧的$PIDField$域的低六位的值为61(0x3D), 这里主机发送消息头部，从机发送消息响应。
• 用户自定义帧(User-defined frame)：它可以携带任何类型的信息，其$PIDField$域的低六位的值为 62 (0x3E)。
• 保留帧（Reserved frame）： 其$PIDField$域的低六位的值为0x3F，其留待以后使用。

　 图8.

　 图9.

　 图10.