本文主要是介绍LIN总线协议，对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

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总线通信方式

“

1. 一条帧的帧头和数据段不是一起发出的，也不一定是同一个节点发出的

2. 帧头必定是由主机节点的主机任务发给从机任务，从机任务根据帧ID判断是要发出信号值，还是接收信号值，或是不作反应

3. 由此看出从机任务负责发送数据、接收数据或不作反应，一切都是根据收到的帧ID做判断

4. 虽然帧ID和数据是分开发送的，但是它们在LIN数据库内也是一条完整的帧，只是帧ID由主机任务发送，数据放在某个节点里由从机任务发送

5. 主机节点除了主机任务以外，还有从机任务，因为主机节点也是节点，它也是需要发送信号和接收信号的

6. 不管是帧头还是数据，除了发送节点以外的其他节点都会收到，只是是否要做处理，需要根据帧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的从机任务就会把信号发给主机节点的从机任务

”

可以总结出

“

1. 事件触发帧的信号必须有变化，信号所属的从机任务才会发送

2. 事件触发帧的信号，也和无条件帧相关联，换句话说，也是无条件帧里的信号，这样做的目的是当事件触发帧的应答冲突时，还可以用无条件帧去请求信号值

3. 事件触发帧的每一个应答节点对应一个不同的无条件帧

”

事件触发帧的信号发生变化才应答的特点，很适合应用在对车门的开关状态进行检测的场景

对于事件触发帧来说，由于有可能有多个节点应答，如何知道是哪个节点发来的应答呢？

这个其实也简单

“

既然应答冲突时会轮询调用事件触发帧的所有对应的无条件帧，说明一个无条件帧代表一个节点，那么只需要把事件触发帧的应答中第一个字节设置为无条件帧的PID即可

”

由于事件触发帧的长度固定，所以各节点的应答固定，那么对应的无条件帧的应答长度也就固定了

所以

与事件触发帧对应的所有无条件帧需要满足

• 数据段长度相同

• 数据段的校验和类型相同

• 数据段的第一个字节为该无条件帧的PID

• 由不同的从机节点发布

• 不能与事件触发帧处于同一个进度表

偶发帧

事件触发帧是主机节点为了获取从机节点的信号状态而发送的帧

那么主机节点里的信号状态又要如何让从机节点知道呢

这里就引入了偶发帧，偶发帧可以当作是主机节点的事件触发帧

当主机节点的信号发生变化时，主机节点的主机任务就会发送偶发帧的帧头，主机节点的从机任务收到帧头后，发送信号，其他从机节点根据自身需要选择是否接收(其实也是分析帧ID后判断的)

上面说的是一个应答，一个偶发帧可能对应多个应答信号，如果同时有多个应答时，怎么办？

和解决事件触发帧的应答冲突一样，一个偶发帧也关联多个无条件帧，每个无条件帧对应一个应答，当同时有多个应答时，主机节点会根据LDF(LIN的数据库文件)中定义好的优先级顺序，依次在同一时隙时发送

偶发帧的无条件帧的发送方式，和事件触发帧的还有所不同

事件触发帧的无条件帧是启用的冲突解决进度表来发送，会一个挨着一个发送，冲突解决进度表中的所有无条件帧发送完毕后，才会重新回到主进度表中继续调度

而偶发帧的应答冲突时，并不会启动冲突解决进度表，还是在主表内，在这个偶发帧的时隙时，调用优先级最高的无条件帧，然后等下一个轮询，又轮到了偶发帧的机会时，再调用优先级次高的无条件帧

由于是主机节点的信号，如果它的信号没有变化，偶发帧都没必要发出去，因为信号没变化，从机节点也没必要判断是否要接收，那主机节点也没必要发偶发帧的帧头，那么这个时隙就会保持沉默

诊断帧

诊断帧分为：主机请求帧、从机应答帧

主机请求帧

帧ID = 0x3C

应答由主机节点的从机任务发布

从机应答帧

帧ID = 0x3D

应答由从机节点的从机任务发布

保留帧

保留帧的帧ID为0x3E和0x3F，为将来扩展用

这篇关于LIN总线协议的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！