LIN总线与CAN总线的传输方式有什么不同?
关注菲益科公众号—>对话窗口发送 “CANoe ”或“INCA”，即可获得canoe入门到精通电子书和INCA软件安装包（不带授权码）下载地址。
LIN，Interconnect Network，适用于速度和可靠性要求不高、低成本的场合，LIN的使用场景包括车窗、天窗、座椅、门锁、空调、照明等舒适性相关的地方
LIN网络
主机节点/从机节点
不同协议的网络需要网关相连接，所以LIN网络与CAN总线相连时，需要加入CAN-LIN网关，这个网关一般由LIN网络的主机节点充当
LIN是单线总线，最大传输速率为20kbps，它采用的是一主多从的概念，就是一个LIN网络只会有一个主机，多个从机
由于物理层限制，一个LIN网络最多有16个节点，那么除去一个主机节点是有且唯一，从机节点的数量就是1到15个
主机任务/从机任务
主机节点（Master Node）包含主机任务（Master Task）和从机任务（Slave Task），从机节点（Slave Node）只有从机任务（Slave Task）
主机任务负责
- 调度总线上帧的传输次序
- 监测数据，处理错误
- 作为标准时钟参考
- 接收从机节点发出的总线唤醒命令
从机任务不能够主动发送数据，需要接收主机发送的帧头，根据帧头所包含的信息判断：
- 发送应答
- 接收应答
- 既不接收也不发送应答
帧的结构
帧包括帧头和应答两个部分，主机节点里的主机任务负责发送帧头，主机节点或从机节点里的从机任务接收帧头，并对帧头所包含的信息进行解析，然后决定是发送应答，还是接收应答，还是不作任何反应
帧的结构
帧头
帧头包括同步间隔段、同步段和PID段
同步间隔段
同步间隔段的作用：
这里就要讲到LIN总线的显性电平和隐性电平
上图中，值0为显性电平，值1为隐性电平，当总线上有大于等于一个节点发送显性电平时，总线呈显性电平；当所有的节点都发送隐性电平或不发送信息时，总线呈隐性电平，所以能看出显性电平起主导作用
同步间隔段由同步间隔和同步间隔段间隔符组成，同步间隔是至少13位的显性电平，除了同步间隔段，没有任何其他情况会发出大于9个的显性电平，那么13个显性电平的同步间隔段，就可以作为一个帧的开始的标志
同步间隔段间隔符是一个隐性电平
同步段
在讲同步段之前，先了解一个概念，字节域
字节域以显性电平开始，以隐性电平结束，是一种标准的UART数据传输格式
在LIN的帧中，除了同步间隔段以外，其他各段都是以字节域的格式传输的
这里也可以看到数据段里的各byte字节，也是按照字节域的格式传输的
LIN总线为了节约成本，没有采用高精度时钟，采用了精度和成本相对较低的时钟，这样就会导致从机节点与主机节点的时钟误差，而同步段就是为了调整从机节点数据的位速率与主机节点一致
PID
“PID，Protected Identifier Field，受保护的ID
”
为什么叫受保护的ID？
PID有8个bit，其中只有前6个bit是实际位，叫帧ID，后面两个bit是前6个bit奇偶校验后得到的值，叫奇偶校验位
从机任务是根据收到的帧ID作出反应的，所以需要验证帧ID是否正确，就是根据奇偶校验位，这也就是为什么叫作PID的原因
校验位P0 = ID0 @ ID1 @ ID2 @ ID3 @ ID4
校验位P1 = ~(ID1 @ ID2 @ ID3 @ ID4 @ ID5)
@表示异或运算，~表示取反
“由此可以看出，PID不可能出现全0或全1的情况，如果从机任务收到了0xFF或0x00，可以判断为传输错误
”
根据帧ID的不同，将LIN帧分为
应答
应答包括数据段和校验和段
数据段
数据段是节点发送的数据，1到8个字节不等，它承载着信号或诊断消息两种数据类型
信号由信号携带帧传递，一个帧ID对应的数据段可能包含一个或多个信号，发送信号的节点称为发布节点，接收信号的节点称为收听节点
一般情况下，对于一个帧中的应答，总线上只存在一个发布节点，否则就会出现错误
但是对于事件触发帧，可能存在0个、1个或多个发布节点
诊断消息由诊断帧传递
校验和段
校验和段是对数据段内容进行校验，它只有1个字节
校验和根据不同的场景分为：标准型校验和、增强型校验和
采用哪种校验和是由主机节点管理的，发布节点和收听节点根据帧ID判断采用哪种校验和
计算方法很简单：数据段内的各字节依次相加，如果有进位，则加到低位，最终得出的值取反
收听节点如何校验呢？同样地，把数据段内的各字节依次相加，如果有进位，则加到低位，得到的值不取反，与接收到的校验和相加，最终得到0xFF，校验无误
帧传输时间的计算
这里有几个需要注意的时间，由于帧里面的各段间有间隔，这也是要花掉时间的
所以
帧头的余量T_Header_Rest包含字节间间隔，规定为T_Header_Nominal的百分之40
应答的余量T_Response_Rest包含应答间隔以及字节间间隔，规定为T_Response_Nominal的百分之40
N_data为数据段内的字节数
帧的类型
无条件帧
无条件帧的帧头从主机任务发出后，必定有从机任务应答，也就是说必定有从机任务发出无条件帧中的信号，无论信号是否发生变化
有且只有一个从机任务对无条件帧的帧头作出应答，发出信号
从这里是否可以明白一些东西
“主机节点里的主机任务负责发送帧头，主机节点和从机节点里从机任务根据事先设计好的规则，负责对接收到的帧头信息进行分析，以确定自己是否要把这个帧的数据发出去，或是否要接收这个帧的数据（来自其他从机任务的）
”
这和CAN总线通信还是很不一样的，后面我会进行分析和总结
无条件帧的典型应用场景如下
这里其实有很多的细节没画出来
第一个场景
“
- 主机节点的主机任务发送了一条LIN帧的帧头给所有的从机任务(包括主机节点里的从机任务)，所有的从机任务收到帧头后分析帧ID=0x30，判断是要发这个帧的数据，还是收这个帧的数据，或者是不作处理
- 从机节点1的从机任务收到帧ID 0x30，发现自己需要把某些信号值发出去，这些信号值就是属于帧ID 0x30的
- 主机节点的从机任务收到帧ID 0x30，发现自己需要接收别人发来的信号值并作处理
- 从机节点2的从机任务收到帧ID 0x30，发现自己既不需要发送信号，也不需要接收信号
- 这个场景的典型应用就是从机节点1向主机节点报告自身某信号的状态
”
从上面的分析中我们能总结出LIN总线通信方式
“
- 一条帧的帧头和数据段不是一起发出的，也不一定是同一个节点发出的
- 帧头必定是由主机节点的主机任务发给从机任务，从机任务根据帧ID判断是要发出信号值，还是接收信号值，或是不作反应
- 由此看出从机任务负责发送数据、接收数据或不作反应，一切都是根据收到的帧ID做判断
- 虽然帧ID和数据是分开发送的，但是它们在LIN数据库内也是一条完整的帧，只是帧ID由主机任务发送，数据放在某个节点里由从机任务发送
- 主机节点除了主机任务以外，还有从机任务，因为主机节点也是节点，它也是需要发送信号和接收信号的
- 不管是帧头还是数据，除了发送节点以外的其他节点都会收到，只是是否要做处理，需要根据帧ID按照自己的内部规则作出判断
”
第二个场景
“
- 主机节点的主机任务把帧头(帧ID 0x31)发给主机节点、从机节点1和从机节点2的从机任务，它们收到帧头后分析帧ID 0x31发现
- 主机节点的从机任务需要发出帧ID 0x31的数据
- 从机节点1的从机任务需要接收发来的数据
- 从机节点2的从机任务需要接收发来的数据
- 这个场景的典型应用就是主机节点向从机节点发布信息
”
第三个场景
“
- 主机节点的主机任务把帧头(帧ID 0x32)发给主机节点、从机节点1和从机节点2的从机任务，它们收到帧头后分析帧ID 0x32发现
- 主机节点的从机任务不作反应
- 从机节点1的从机任务需要接收发来的数据
- 从机节点2的从机任务需要发出帧ID 0x32的数据
- 这个场景的典型应用就是从机节点间的通信
”
事件触发帧
当节点里的信号发生变化的频率较低时，再用无条件帧一遍又一遍地让它应答，这样做很不合适，因为会占用LIN总线的带宽
与无条件帧不论信号是否发生变化必定有从机任务应答不同，事件触发帧只有信号发生变化才需要应答，所以事件触发帧允许无节点应答(只有帧头无应答)，也允许两个以上的节点对帧头作应答
当两个以上的节点同时应答时，不会被视为错误，但是主机节点需要解决这个冲突，怎么办呢？
主机节点的主机任务需要立刻中断当前的进度表，然后启动冲突解决进度表，调用这些冲突信号关联的无条件帧，发送帧头，获得应答
由上图可以看出
“
- 主机节点的主机任务发送事件触发帧的帧头0x10，请求从机任务的应答，但是由于信号没有变化，从机任务不应答
- 下一个循环，主机节点的主机任务又发送帧头0x10，只有从机节点1的信号发生变化，从机节点1的从机任务作应答
- 下一个循环，主机节点的主机任务又发送帧头0x10，从机节点1和2的信号同时变化，同时应答，造成冲突
- 中断当前进度表，启动冲突解决进度表
- 主机任务发送从机节点1的事件触发帧的信号相关联的无条件帧的帧头0x11，从机节点1的从机任务就会把信号发给主机节点的从机任务
- 主机任务发送从机节点2的事件触发帧的信号相关联的无条件帧的帧头0x12，从机节点2的从机任务就会把信号发给主机节点的从机任务
”
可以总结出
“
- 事件触发帧的信号必须有变化，信号所属的从机任务才会发送
- 事件触发帧的信号，也和无条件帧相关联，换句话说，也是无条件帧里的信号，这样做的目的是当事件触发帧的应答冲突时，还可以用无条件帧去请求信号值
- 事件触发帧的每一个应答节点对应一个不同的无条件帧
”
事件触发帧的信号发生变化才应答的特点，很适合应用在对车门的开关状态进行检测的场景
对于事件触发帧来说，由于有可能有多个节点应答，如何知道是哪个节点发来的应答呢？
这个其实也简单
“既然应答冲突时会轮询调用事件触发帧的所有对应的无条件帧，说明一个无条件帧代表一个节点，那么只需要把事件触发帧的应答中第一个字节设置为无条件帧的PID即可
”
由于事件触发帧的长度固定，所以各节点的应答固定，那么对应的无条件帧的应答长度也就固定了
所以
与事件触发帧对应的所有无条件帧需要满足
- 数据段长度相同
- 数据段的校验和类型相同
- 数据段的第一个字节为该无条件帧的PID
- 由不同的从机节点发布
- 不能与事件触发帧处于同一个进度表
偶发帧
事件触发帧是主机节点为了获取从机节点的信号状态而发送的帧
那么主机节点里的信号状态又要如何让从机节点知道呢
这里就引入了偶发帧，偶发帧可以当作是主机节点的事件触发帧
当主机节点的信号发生变化时，主机节点的主机任务就会发送偶发帧的帧头，主机节点的从机任务收到帧头后，发送信号，其他从机节点根据自身需要选择是否接收(其实也是分析帧ID后判断的)
上面说的是一个应答，一个偶发帧可能对应多个应答信号，如果同时有多个应答时，怎么办？
和解决事件触发帧的应答冲突一样，一个偶发帧也关联多个无条件帧，每个无条件帧对应一个应答，当同时有多个应答时，主机节点会根据LDF(LIN的数据库文件)中定义好的优先级顺序，依次在同一时隙时发送
偶发帧的无条件帧的发送方式，和事件触发帧的还有所不同
事件触发帧的无条件帧是启用的冲突解决进度表来发送，会一个挨着一个发送，冲突解决进度表中的所有无条件帧发送完毕后，才会重新回到主进度表中继续调度
而偶发帧的应答冲突时，并不会启动冲突解决进度表，还是在主表内，在这个偶发帧的时隙时，调用优先级最高的无条件帧，然后等下一个轮询，又轮到了偶发帧的机会时，再调用优先级次高的无条件帧
由于是主机节点的信号，如果它的信号没有变化，偶发帧都没必要发出去，因为信号没变化，从机节点也没必要判断是否要接收，那主机节点也没必要发偶发帧的帧头，那么这个时隙就会保持沉默
诊断帧
诊断帧分为：主机请求帧、从机应答帧
主机请求帧
帧ID = 0x3C
应答由主机节点的从机任务发布
从机应答帧
帧ID = 0x3D
应答由从机节点的从机任务发布
保留帧
保留帧的帧ID为0x3E和0x3F，为将来扩展用
以上，就是LIN协议的部分内容，关注、点赞、转发，行不行
了解更多产品信息，请致菲益科电子官网查询