关注菲益科公众号—>对话窗口发送 “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协议的部分内容,关注、点赞、转发,行不行