LIN通信入门二

本连载作为嵌入式开发入门的一部分，将通过3个部分介绍LIN通信。

第一讲的基础知识中已经介绍了LIN协议的特征，硬件和通信方式。这一讲将介绍“LIN 报文结构”，“网络管理”，“LIN描述文件LDF”。

LIN 报文结构

如上一讲介绍所说LIN采用的是“主从”通信方式。LIN报文的一帧由“Header”和“Response”组成，“Header”由主任务（主节点）发送，“Response”由从任务（主节点或者从节点）发送。下面将分别介绍“Header”和“Response”。

Header

“Header”又可以分为“Break”、“Synch”和“PID”3个场（图1）。

图1　header 结构 （参照VectorJapan资料作成）

Break场

Break场不同与其他场，它有意的造成UART通信中的FramingError（从起始位到第10位没有检出停止位时的错误）来提示LIN总线中的所有从节点之后要开始进行LIN报文的传输了。

Break场又可以分为“Break”，“Break-delimiter”，“Break”为13位以上的显性位，“Break-delimiter”为1位的隐形位，“Break-delimiter”是“Break”结束的标志。

Synch场

Synch场即同步场，第一讲在介绍同期信号时提到过同步场。同步场是为了修正各个节点间时钟的误差，固定发送0x55的UART数据（包含起始位/停止位）。从节点根据最初和最终的下降沿除以8来算出1位的时间，并以此作为基准来调整自己的时钟误差（图 2）。如果从节点使用的是高精度时钟的话（允许误差±1.5%），则不需要调整时钟的误差。

图2synch结构 （参照VectorJapan资料作成）

PID场

PID场标识LIN报文识别信息，由6位（位0~位5）的报文ID和2位（位6、位7）的奇偶校验位，合计8位组成（图3）。

Response

Response由“数据”和“和校验”2个场组成。都可以通过UART的形式进行传输。

图4数据场结构 （参照VectorJapan资料作成）

数据场

数据场最大可以传输8Byte数据

和校验场

和校验即我们通常说的Checksum，用来确认接收的数据是否正常。和校验场的具体值为各个数据场的和的反数，如果有溢出的话，则需要取余运算（mod256）。和校验有“标准和校验（Classic Checksum）”和“扩张和校验（Enhanced Checksum）”两种形式：

标准和校验（CLASSIC）

计算对象为所有数据场

LIN1.x为所有报文都使用

LIN2.x为诊断报文（ID60~61）使用

扩张和校验（ENHANCE）

计算对象为PID场和数据场

LIN2.x为报文ID0~59使用

通过上述结构，各个报文在LIN总线上传输。通过Header调整时钟误差，确认报文信息，进行数据的接收和发送，并且有奇偶校验与和校验来确保数据的正确性。

时间规定

LIN报文的传输是根据LIN的时间表执行的。按照LIN的硬件结构，报文的传输时间可以分为“Response时间”和“间隔时间”，设计时间表时需要考虑两者的误差（图5）。

图5时间规定（参照VectorJapan资料作成）

LIN报文的传输时间可以用下式求出。“标称时间”是不包括“Response时间”和“间隔时间”，基于Break场计算的位时间。

“Response时间”和“间隔时间”的允许时间最大占LIN报文的40%。因此，LIN报文的最大时间可以通过下式求出。

LIN时间表的单位时间被称为“基准时间（Time_Base）”，表示LIN时间表的最小处理时间。一般常用的有5ms和10ms等。

另外，一个LIN报文传输所需的基准时间合计被称作“报文槽（Frame Slot）”

报文种类

LIN的报文种类有“普通报文（Unconditional）”、“事件触发报文（Event triggered）”、“零星报文（Sporadic）”和“诊断报文（Diagnostic）”4种。

普通报文（ID0~59）

通常使用的报文种类，在各节点间传输数据时使用。

事件触发报文（ID0~59） （LIN2.0追加）

对于从节点上发生频度较低的事件，1个Header可以对应多个Response，Header按照时间表发送，Response只有在需要的时候才会发送。为了判断是某个节点发送的Response，数据的第一位会发送自己的PID。

因为事件触发报文的ID对应多个Response，所以可能会有冲突发生，发生冲突会导致数据的丢失，所以，主节点需要根据冲突发送对每一个从节点发送普通报文的Header。LIN2.1中追加了事件触发报文冲突发生时使用“冲突解决时间表”的内容。

作为事件触发报文的常用使用场景，车身控制器监视4个车门的状态。如果利用事件触发报文可以在一个Slot里处理4个门的状态监视，但是，4个门中有多个门同时开启关闭这样的事情也是偶尔会发生的。如果发生冲突，就对4个门要求轮流发送数据，避免状态丢失。

零星报文（ID0~59） （LIN2.0追加）

对于主节点上特定信号更新的时候使用此报文。1个零星报文的Header可以对应多个Response，当有多个零星报文需要发送时，按照优先级进行发送。信号没有更新时，零星报文的Header也可以不用发送。

诊断报文（ID60~61）

LIN网络的诊断，节点的配置，睡眠模式等使用的报文，ID60被称为“主Request”，主节点发送Response，ID61被称为“从Response”，从节点发送Response。

预留报文（ID62~63）

预留的报文ID，LIN2.x还未使用。

错误处理

在LIN报文中检测出错误时，将通过主任务、从任务丢弃数据。LIN协议中没有错误处理的定义，因此需要通过应用程序来定义。在LIN1.3的规格书中，定义了以下错误。

Bit Error

Checksum Error

Identifier Parity Error

Slave Not Responding Error

Inconsistent Synch Field Error

Physical Bus Error

LIN 2.x除了上述内容之外，还增加了从节点检测到错误后向主节点通知的“状态管理”。关于状态管理，将放在本系列的第三讲中说明。

网络管理

唤醒信号/休眠帧

本连载第一讲已经介绍过LIN主要用于车内舒适性系统，根据车辆状态会有不需要通信的场景。比如，车门在无钥匙系统中处于上锁状态时，接收远程钥匙上锁的接受传感器单元在解锁前不需要进行LIN通信。

当这个不需要通信的状态发生时，可以切换到省电模式（唤醒/休眠），从而控制LIN节点的消费电能。

负责切换这种省电模式的就是网络管理。

休眠帧（Go-to-Sleep Command）

休眠模式帧是指主任务（主节点）要求从节点进入休眠模式的命令。主节点发送主请求帧（报文ID 60），数据第1字节为0x00，2～8字节为0xFF（在LIN 1.x中，没有规定2～8字节固定0xFF）。检测到该帧的从节点停止通信（转移到休眠模式）（图6）。

图6休眠帧（参照VectorJapan资料作成）

唤醒信号

唤醒信号是从任务（主节点或从节点）要求各节点向唤醒模式（初始化/动作中）切换的信号。唤醒信号是总线短显性。0.25～5ms的显性，即0xF0（在LIN 1.x中为0x80）。

对于主节点，发送Break字段时也可以切换到唤醒模式。

如果发送了唤醒信号后未进入调度（未检测到Break），则从任务可以重复发送唤醒请求。唤醒信号的间隔（复位状态）是150～250ms（在LIN 1.x中最多128 bit）。如果发送3次唤醒信号也没有开始调度，则在1.5秒（在LIN 1.x中为1万5000比特）以上的暂停状态之后，可以发送第4次唤醒信号（图7）。

图7唤醒信号（参照VectorJapan资料作成）

网络管理的时间参数因LIN协议版本而异。每个LIN协议版本的时间参数汇总如下（表1）。

在LIN 1.x中，时间参数由位时间（TBit）定义。也就是说，在LIN 1.x中，时间参数根据通信速度而不同 。

LIN描述文件（LDF）

LIN描述文件是定义LIN网络的标准格式，在LIN的规格书中有所规定。LIN描述文件定义通信速度、节点、帧、信号、通信时间表等LIN通信所需的信息。

LIN描述文件的格式是基于文本的，和LIN的通信标准一样，非常简单。

LIN描述文件作为各开发工程间、整车厂和供应商之间的通用接口发挥作用，可减轻兼容性等问题。另外，可用于系统生成器生成LIN通信驱动程序、以及解析和模拟工具的设置。解析・模拟工具可以根据时间表简单地进行Header发送、时间表切换、以信号为单位的解析和值变更等。这样，使用LIN描述文件可以使LIN的软件开发更加效率。