LIN 入门(1)-CSDN博客
4、帧收发的硬件实现
本章着重介绍与 LIN 帧收发相关的硬件的组成、特点以及应用设计时的注意事项。本章内容对应着 LIN 规 范的以下部分: ● LIN Protocol Specification(部分内容) ● LIN Physical Layer Specification
4.1 组成
收发 LIN 帧需要的硬件包括协议控制器(Protocol Controller)、总线收发器(Bus Transceiver)和 LIN 总线三部 分,如图 4.1 所示。
LIN 规范并未限定传输介质的类型和连接器的规格。目前 LIN 网络主要使用铜线作为传输介质,针对铜线 的总线收发器也是市场主流。鉴于这种情况,下文如无特别说明,均是针对铜线介质展开。
4.2 LIN 的硬件特点
● 单线通信 ● 从机节点无需高精度时钟源 ● EMI 低而且可控 ● 最高通信速率 20kbps
4.3 协议控制器
协议控制器的主体是一个基于 UART/SCI 的通信控制器,工作方式是半双工。协议控制器既可以使用专用 模块实现,也可以用“UART/SCI+定时器”实现。
发送时,协议控制器把二进制并行数据转变成高-低电平信号, 并按照规定的串行格式(8 数据位,1 停止位,无校验位)送往总线收发器;接收时,协议控制器把来自总线收发 器的高-低电平信号按照同样的串行格式储存下来,然后再将储存结果转换成二进制并行数据。 协议控制器要能产生和识别帧的同步间隔段。如第 3 章所述,同步间隔段包含一个低电平脉冲,长度至少 为 13 位。发出和识别同步间隔段虽然增加了硬件设计的复杂度,但是从接收方的角度看,这样做能把同步间隔 段与普通的数据字节区别开,确保了同步信息的特殊性。 协议控制器要能执行本地唤醒(Local Wakeup)。需要唤醒总线时,协议控制器通过总线收发器向 LIN 总线 送出唤醒信号(参照 3.5.1 节)。 协议控制器要能识别总线唤醒(Bus Wakeup)。当收到来自 LIN 总线的唤醒信号时,协议控制器能够正确动 作,进入规定的通信状态(注 1)。
注:1. 例如,主机节点延迟 100ms,然后查询唤醒来源。
4.3.1 实现方案
依据硬件资源不同可以分为 3 类: UART/SCI+定时器+外部中断、硬件 LIN(Hardware LIN)和 LIN 模块(LIN Module),分别面向对成本和性能有不同侧重的应用。
4.4 总线收发器
总线收发器的主体是一个双向工作的电平转换器,完成协议控制器的高-低电平与 LIN 总线的隐性-显性电 平(注 1)之间的转换。显性-隐性电平的定义如表 4.2 所示。
LIN 规范规定:LIN 总线的电平参考点是总线收发器的电源参考点。为了克服电源波动和参考点漂移的影 响,LIN 规范要求总线收发器要能承受±11.5%的电源波动和参考点电平波动,并且能承受电源和参考点之间 8% 的电位差波动。收发双方的电平鉴别门限也设置了较大的冗余度。参照参考资料[9]的表 6.6。 总线收发器还包括一些附加的功能,例如总线阻抗匹配、压摆率(Slew-rate)控制等。 此外,LIN 规范要求总线收发器具备这样一种特性:本地节点掉电或工作异常时,不能影响总线上其他节 点工作。 注:1. “显性-隐性”此处有两个含义,一是突出 LIN 总线“线-与”的本质,二是与协议控制器的“高-低电平” 相区别。
4.4.1 实现方案
在一些要求不高的场合,可以采用简单的收发器电路,如图 4.2 所示
不少半导体厂商提供集成化的总线收发器,这些产品功能完善,环境适应能力强,设计产品时建议优先考 虑。
4.5 LIN 总线
LIN 总线是衔接所有 LIN 节点的通信介质。 LIN 总线的特征阻抗——尤其是容抗——会影响信号的波形,在设计产品时应予以重视,参照 4.8.2 节。 为汽车电子产品增加 LIN 功能所花费的成本与获得的灵活性相比,往往后者更为显著。汽车上大多数传感 器、执行器除至少要接 1 根电源线和 1 根地线外,此外还有一些模拟/数字信号线,这些接口往往存在兼容性的 问题。如果采用 LIN 规范,仅用 3 根线(电源、地和 LIN)就可以实现标准化的数字接口。传感器、执行器通过 总线连接,汽车结构设计可以更加灵活,线束的数量(重量)不但不会增加,还可能减少。
4.6 时钟源
LIN 网络的主机节点必须设置较高精度的时钟,而从机节点则不必。换句话说,主机节点是 LIN 网络的时间基准,这保证了位速率的准确性。LIN 规范规定一个 LIN 网络里只有一个主机节点,这保证了位速率的唯一 性。LIN 规范规定所有通信都由主机节点发起,并在帧头中加入同步段,这就给从机节点提供了主机节点位速 率的信息。只要所有从机节点都能在 LIN 通信时与主机节点采用同样的位速率,LIN 网络就能正常工作。这种 做法虽然降低了传输效率,但是一方面减少了高精度时钟数量,降低了成本;另一方面不需要仲裁,降低了软 硬件设计复杂度。 主机节点、从机节点位速率要满足表 4.3 的要求。
4.7 EMI 及其控制
EMI 这里指电磁干扰。对于 LIN 而言,EMI 主要由位速率和压摆率共同决定。位速率决定单位时间内电平 变化次数,压摆率决定电平跳变的快慢。
单位时间内跳变次数越多,每次跳变持续时间越短,跳变过程包含的 谐波成分就越丰富,EMI 也越大;相反,跳变持续时间越长,单位时间跳变次数越少,其谐波成分越少,EMI 也较低。
LIN 可以控制 EMI。这是因为协议控制器可以控制 LIN 总线位速率,总线收发器可以控制压摆率。另外, LIN 协会把 LIN 的最高位速率限制在 20kbps。值得一提的是,这个速度远非 LIN 物理层的极限,而是在数据速 率与 EMI 之间权衡的结果.
5、信号处理、配置、识别和诊断
本章从应用需求入手,介绍了信号处理、配置、识别(Identification)和诊断的概念、功能和用途。本章内容 对应于 LIN 规范的以下部分: ● LIN Transport Layer Specification ● LIN Node configuration and Identification Specification ● LIN Diagnostic Specification 从使用的角度来看,LIN 提供四项功能——信号处理、配置、识别和诊断,这四项功能共同构成了 LIN 的 应用层。传输层是配置、识别和诊断这三项功能的通信载体,实现应用层消息与帧之间的格式转换和传输。为 了规范使用,LIN 为应用层和传输层定义了 API 接口,参照第 6 章。
5.1 传输层
传输层的任务单一,就是充当一个“翻译官”,把来自诊断服务的消息(Message)“翻译”成协议层可以处理的 PDU (Packet Data Unit,分组数据单元),或者反过来,把协议层收到的 PDU“翻译”成诊断服务需要的消息。消 息到 PDU 的转换过程称为拆分(Packing),PDU 到消息的转换过程称为重组(Unpacking)。PDU 对应着帧结构的 数据段,并通过诊断帧发送或接收。
5.1.1 PDU 结构
为满足汽车行业的要求,LIN 传输层 PDU 的格式与 ISO 制定的基于 CAN 网络的诊断标准(参照参考资料[9]) 非常相似(是 ISO 标准的子集)。这种兼容性大大减少了在 CAN 和 LIN 之间转换数据格式的工作量,降低了对节 点计算能力的要求。 从发送格式上,PDU 单元可分为单帧(Single Frame,SF)、首帧(First Frame,FF)和续帧(Consecutive Frames, CF)三种。从发送源上,主机发送请求 PDU,从机发送应答 PDU。 如图 5.1 所示,为 PDU 格式,包括节点地址(NAD),协议控制信息(PCI),LEN,服务 ID(SID),应答服务 ID(RSID), 消息字节段(D1~D6)。首字节 NAD 首先发送,末字节 D4,D5,D6 最后发送。
5.1.1.1 NAD
PDU 单元的第一个字节是 NAD(node address),用于区分不同从机节点的地址。 如表 5.1 所示,列出了 NAD 的取值范围.
5.1.1.2 PC1
PDU 单元的第二个字节是 PCI(Protocol Control Information)信息,包含了 PDU 单元类型和消息字节长度 的信息。如表 5.2:
单帧中,附加信息 Length 表示消息字节数加 1。首帧中,附加信息只表示 Length 的高 4 位,低 8 位在 LEN 中表示。因此在消息长度为 12 位数据,最大长度为 4095(0xFFF)。 续帧中的附加信息表示首帧后,跟随的续帧的编号,第一个续帧编号为 1,之后累加 1。如果续帧数多于 15 个,那么帧计数器在第 16 个续帧时从 0 重新计数。
5.1.1.3 SID 与 RSID
SID(Service Identifier)表示了从机节点应完成的服务请求。节点配置服务的 SID 区间为 0xB0~0xB7,诊断 服务的 SID 区间为 0x00~0xAF,0xB8~0xFE。 RSID(Response Service Identifier)表示从机节点应答的内容,它的值是 SID+0x40。
5.1.1.4 消息字节段
消息字节段的内容取决于服务的种类。在单帧中,消息字段最多 6 个字节。在首帧和续帧中,所有 PDU 的 消息字段,经过“重组”组成一个完成的消息。
5.2 LIN 应用层
5.2.1 概述
LIN 应用层提供信号处理、配置、识别和诊断四项功能。配置、识别和诊断功能又包含若干项目,称为服 务(Service)。为了区别,每项服务都有固定、唯一的服务代号(Service ID,SID)。图 5.2 描述了 LIN 应用层及其 关联。
为便于理解本图,后文对每项功能都分别进行了详细描述并提出了工作模型的概念。 LIN 应用层的配置、识别和诊断都是针对逻辑节点(Logical Node)的。逻辑节点是能够对来自主机节点和/ 或诊断设备的服务请求作出响应的功能实体。为了区别不同的逻辑节点,LIN 定义了 NAD(Node Address for Diagnose,诊断地址)。第 1 章介绍了物理节点(Physical Node)、从机任务和接口(Interface)的概念。对于一个物 理节点来说,从机任务和接口对应着实现帧收发的软件和硬件实体,而逻辑节点则代表了配置、识别和诊断方 面的能力。物理节点、从机任务以及接口是一一对应的,但是物理节点可以包括 1 个或者多个逻辑节点。 为了规范地使用应用层的功能,LIN 规范定义了一套 API。下文会提到各项功能与 API 的关联,API 的内 容参照第 6 章。
5.2.2 信号处理功能
信号处理功能是指应用层可以不经过传输层,直接从协议层获取或修改网络中的信号。这些信号由 NCF(Node Capability File,节点性能文件)定义,既可以是工作参数(例如温度、压力的测量值、继电器的开合状 态等),也可以是状态标志(例如某信号携带帧的收发状态)。 信号处理功能的工作模型如图 5.3 所示。信号携带帧在 LIN 网络的节点之间传递,每个节点既可以是信号 的发布者,也可以是信号的收听者。
信号处理功能由核心 API 完成,参照 6.3 节。表 5.4 列出了信号处理功能与 API 的对应关系,API 的内容 参照第 6 章。
5.2.3 配置功能
LIN 规范规定,每个逻辑节点都应该有 NAD。在网络运行期间,任意两个逻辑节点的 NAD 都必须不同, 否则就会产生冲突。此外,每个逻辑节点都要能处理带有某些 PID 的帧。由此可见,NAD 和 PID 分别与逻辑 节点建立了一种映射关系,LIN 规范把 NAD 和 PID 的这样一种组合称为逻辑节点的配置项(Configuration)。一 个逻辑节点可以有一个以上的配置项,但在网络运行期间,每个逻辑节点只能有一个配置项有效。 配置功能是指 LIN 的主机节点能自动地给所有逻辑节点选择配置项,消除 NAD 和 PID 分配中存在的冲突, 使网络正常工作。配置功能是确保各节点协调运作的内部功能,包含分配 NAD、分配 PID 等服务。配置功能通 过传输层完成配置服务。 为了适应汽车行业的需要,LIN 规范定义配置功能的服务时,参照了 ISO 制定的 UDS(Unified Diagnostic Services,车辆统一诊断服务)标准(参照参考资料[7])和 OBD(On-board Diagnostic,车载自动诊断)标准(参照参考 资料[9])。配置功能各项服务及其 SID 都是 ISO 标准的子集。 配置功能的工作模型与计算机局域网的“客户机-服务器”模型很相似,如图 5.4 所示。主机节点可以被视为 客户机,逻辑节点被视为服务器。客户机首先向服务器发出服务请求,服务器依照请求执行操作,然后向客户 机返回应答。
5.2.3.1 节点存储模型
如图 5.5,节点存储模型
如同商品包装上的条形码,每个物理节点都有一个固定的编码,叫做 LIN 产品代号(LIN Product Identification)。产品代号是出厂时赋予的,除非修改产品,否则其内容不变。产品代号保存在不需要电源就能 维持记录的地方,例如 ROM 或者非易失性存储器(Non-volatile Random Accessible Memory,NVRAM)。在进行 配置服务时,从主机接收的产品代号必须和从机节点保存的产品代号一致,才能正常进行配置服务。
另外,从机节点还可以有一个序列号,用于识别特殊的节点。序列号大小为 4 字节。 从机节点可以将配置信息保存起来,重启后调用保存的配置信息,而无需主机节点再次分配。 针对配置项的存储类型,LIN 规范定义了三种从机节点配置模型: 第一种,无配置节点,这种从机节点在重启后,自身没有配置项,每次重启都需要主机进行配置。 第二种,预配置节点,这种从机节点在重启后,调用预先设置的配置项。但是在主机重新对其进行配置后, 不能存储新配置项。
第三种,全功能配置节点,这种从机节点可以保存主机对其的配置,并在重启后调用此配置。
5.2.3.2从机节点 NAD 配置
有三种方法生成配置 NAD,如果初始 NAD 等于配置 NAD,那么不需要进行其他配置操作。如果配置 NAD需要从从机节点存储的保留配置中提取,需要调用 ld_set_configuration 进行配置,如果 NAD 需要变更,则需要主机发送配置 NAD 请求。
图 5.6 配置 NAD
主机节点给从机节点分配 NAD 是通过Assign NAD 服务完成的。首先主机节点向从机节点发送配置NAD请求,如果从机节点配置成功,从机节点会应答。分配NAD 服务的 PDU 结构如表 5.7 所示
表 5.7 分配 NAD 请求与应答
主机请求 | NAD | PCI | SID | D1 | D2 | D3 | D4 | D5 |
初始 NAD | 0x06 | 0xB0 | 厂商 ID LSB | 厂商 ID MSB | 功能 ID LSB | 功能 ID MSB | 新分配 NAD | |
从机应答 | NAD | PCI | RSID | 未定义 | ||||
初始 NAD | 0x01 | 0xF0 | 0xFF | 0xFF | 0xFF | 0xFF | 0xFF |
注意,应答时,仍然使用初始 NAD。
每个从机节点有一个初始 NAD,初始 NAD 是从一个初始 NAD 列表中选择的。初始 NAD 列表是在编写节点性能文件(NCF)时设置的。LIN 协议没有对生成初始 NAD 的具体方法进行限制。
5.2.3.3从机节点 PID 配置
从机节点各个帧的 PID,是主机进行分配的。通过分配 PID 列服务,主机一次最多可给从机节点分配 4 个帧的 PID。
分配 PID 列服务的 PDU 结构如表 5.8 所示:
表 5.8 从机节点 PID 配置请求与应答
主机请求 | NAD | PCI | SID | D1 | D2 | D3 | D4 | D5 |
NAD | 0x06 | 0xB7 | 开始 index | PID (index) | PID (index+1) | PID (index+2) | PID (index+3) | |
从机应答 | NAD | PCI | RSID | 未定义 | ||||
NAD | 0x06 | 0xF7 | 0xFF | 0xFF | 0xFF | 0xFF | 0xFF |
其中,消息字节段的第一字节是开始帧索引,表示分配第一个帧的排列号。从机节点中各帧的排列顺序是按照节点性能文件(NCF)和 LIN 描述文件(LDF)中定义的顺序定义的。第一帧的索引编号是 0。
后续四个字节是给从机节点分配的 PID。如果分配的 PID 值为 0,表示对应的信号携带帧无效。如果分配的 PID 值为 0xFF,表示保持对应帧的 PID 不变。
5.2.3.4其它服务
除了对从机节点 NAD 和 PID 的配置,LIN 规范还定义了其他配置服务,如条件变更 NAD,数据导入,保存配置。
配置功能由配置与识别 API 完成,参照 6.5 节。表 5.9 列出了配置服务与API 的对应关系,API 的内容参照第 6 章。
服务名称 | 用途 | 识别与配置 API |
Assign NAD | 为逻辑节点分配新的 NAD。 | ld_assign_NAD |
Conditional change NAD | 为 NAD 有冲突的逻辑节点分配新的 NAD。 | ld_conditional_change_NAD |
Assign frame ID range | 为逻辑节点可以处理的帧分配新的 PID。 | ld_assign_frame_id_range |
Save configuration | 请求逻辑节点保存当前的配置项。 | ld_save_configuration ld_read_configuration |
5.2.4 识别功能
识别功能是指主机节点能够获取逻辑节点的信息,例如产品代号等。借助识别功能,主机节点和逻辑节点还可以实现一些自定义的操作。
识别功能与上面介绍的配置功能使用同样的工作模型,如图 5.4 所示。识别服务中,主机发送的请求 PDU 单元结构如表 5.10:
表 5.10 识别功能的请求与应答
主机请求 | NAD | PCI | SID | D1 | D2 | D3 | D4 | D5 |
NAD | 0x06 | 0xB2 | 识别 ID | 厂商 ID LSB | 厂商 ID MSB | 功能 ID LSB | 功能 ID MSB | |
从机应答 | NAD | PCI | RSID | D1 | D2 | D3 | D4 | D5 |
识别 ID=0 | NAD | 0x06 | 0xF2 | 厂商 ID LSB | 厂商 ID MSB | 功能 ID LSB | 功能 ID MSB | 可变 ID |
识别 ID=1 | NAD | 0x05 | 0xF2 | 序列号 0 LSB | 序列号 1 | 序列号 2 | 序列号 3 MSB | 0xFF |
识别 ID=32~63 | NAD | 0x05 | 0xF2 | 用户定义 | 用户定义 | 用户定义 | 用户定义 | 用户定义 |
失败应答 | NAD | 0x03 | 0x7F | 请求 SID (=0xB2) | 错误代码 (=0x12) | 0xFF | 0xFF | 0xFF |
其中,从机根据目标 ID 的值来回应相应的信息。目标 ID 指定的相关信息如表 5.11:
目标 ID | 指定读出的内容 | 应答消息长度 |
0 | LIN 产品 ID | 6 = 5+RSID |
1 | 序列号 | 5 = 4+RSID |
2-31 | 保留 | - |
32-63 | 用户自定义 | 用户自定义 |
64-255 | 保留 | - |
识别功能由识别 API 完成,参照 6.5 节。表 5.12 列出了识别服务与 API 的对应关系,API 的内容参照第 6章。
表 5.12 识别服务及与 API 的关联
服务名称 | 用途 | 识别与配置 API |
Read by identifier | 读取逻辑节点的信息,或者实现自定义的操作。 | ld_read_by_id ld_read_by_id_callout |
5.2.5诊断功能
诊断功能是指 LIN 网络之外的诊断设备可以直接连接 LIN 的主机节点,或者通过外部的其它网络(例如 ISO11898 定义的 CAN 网络,参照参考资料[8])连接主机节点,连接后,诊断设备可以按规定的诊断协议(例如 ISO15765 规范,参照参考资料[9])与 LIN 的逻辑节点通讯。与配置功能相比,诊断功能是 LIN 网络作为一个整体对外呈现的可配置、可访问的属性。
为了适应汽车行业的需要,LIN 规范定义诊断服务时,参照了ISO 制定的 UDS 标准(参照参考资料[7])和OBD 标准(参照参考资料[9])。LIN 诊断功能是以上两个标准的子集,相同服务的 SID 也相同。
诊断功能的工作模型如图 5.7 所示,它是配置功能工作模型的扩展。主机节点在此扮演了一个“网关”的角色,在诊断设备和 LIN 网络之间传递服务请求和应答。
图 5.7 诊断模型
诊断功能的实用意义可以用一个例子来说明:假设采用 LIN 子网的车门连接在底盘 CAN 网络上,诊断车门故障时,只需要把OBD 设备连接于车载计算机的 CAN 接口即可,而不需要拆下车门;确定车门故障点后,拆下车门维修完毕,只需把 OBD 设备连接于车门的 CAN 接口,就能确认门是否已被修好,而不需要事先把车门装回。
一般而言,节点的计算能力与成本成正比。应用层的四项功能中,只有诊断功能可以根据具体产品而灵活裁减,其余的功能都是固定而且必须的。
诊断功能的可裁减性体现在两方面:实现方式以及支持的服务种类,这些都是直接影响着节点计算负荷的因素。
诊断方式
LIN 网络有三种方式来实现诊断功能,它们的差别在于传输层的复杂度,因为拆分/重组需要一定的计算量,这些方式如下表 5.13 所示,另外可参考图 5.2。
表 5.13 诊断功能的实现方式
方式 A | 方式 B | 方式C | |
传输层 | 支持 SF/FF/CF | 视设计而定 | |
协议层 | 信号携带帧 | 诊断帧 | 诊断帧(使用自定义 NAD) |
计算量 | 最小 | 大 | 视设计而定 |
可移植性 | 好 | 好 | 差 |
诊断类型(Diagnostic Class)
逻辑节点功能越复杂,支持的服务越多,对逻辑节点的计算能力要求就越高。
依据诊断服务的数量,LIN 规范划分出三种不同的诊断类型——I 类、II 类和 III 类,适用于不同条件的逻辑节点。I 类最低,III 类最高,较高类型完全包含较低类型的功能。
I 类是所有诊断类型的公共部分,提供信号处理、识别、配置功能,诊断功能采用表 5.12 中的方式A,这也是每个逻辑节点必备的服务。II 类节点增加了 UDS 定义的识别服务(注 1),诊断方式一般采用表 5.12 中的方式 B。III 类节点相比 II 类节点,又增加了UDS 定义的部分其它服务,此外,还增加了通过 LIN 总线在线升级的功能。
注:1. 请注意区别 UDS 定义的识别服务与 5.2.4 描述的识别服务。
诊断类型的关联如图 5.8 所示。
6、LIN 的API
本章介绍 LIN 的 API 的概念、功能和一般用法,并以例子的形式介绍了调用 API 的一般流程。本章内容对应 LIN 规范的以下部分:
- LIN Application Program Interface Specification
API 是一组“规约”,用来定义软件模块的使用方法。API 既可以是数据结构,也可以是若干个函数,还可以是它们的混合。
软件开发者可以把API 看作是与软件模块的会话方式。应用程序和程序员既可以使用该模块的功能,又无需访问其源代码,或者理解其内部工作机制的细节。
API 对软件开发意义重大。软件规模日益庞大,常常需要把复杂系统划分成小的组成部分,或者重复使用代码,这时都会涉及到 API。
LIN 规范用 C 语言定义了 LIN 的API,但未定义 API 的内部实现。
LIN 协会规定:对于采用 LIN 规范 2.x 版的 LIN 节点,如果用 C 语言开发应用程序,那么就必须使用 API,对采用 LIN 规范 1.x 版的 LIN 节点,可以不使用标准规定的API。
按照用途,可以把 LIN 的 API 分为 3 类——核心 API、传输层 API 和配置与识别 API。三类 API 相对独立,彼此关联,如图 6.1 所示。
核心API 是 API 的基础,除了完成协议层的帧收发,LIN 应用层各项功能都要用到核心API。
核心API 包含多个函数,其中,l_sch_tick()(时基节拍管理)和 l_sch_set()(进度表管理)是与进度表相关的两个函数。其他的函数负责控制各种硬件协调工作,完成初始化、中断响应、比特流收发、字节缓冲、休眠、唤醒以及物理层的差错报告等功能。
LIN 规范把核心 API 分成 6 个组,如表 6.1 所示。
表 6.1 核心 API 的分类
类别 | 名称 | 说明 |
驱动与网络管理 | l_sys_init | 初始化整个 LIN 节点,包含应用层、传输层和协议层。在调用其它 API 函数前,必须首先调用此函数,例如在应用程序初始化阶段调用。 |
信号处理 | l_bool_rd/l_bool_wr l_u8_rd/l_u8_wr l_u16_rd/l_u16_wr l_bytes_rd/l_bytes_wr | 读写信号,用于信号处理功能。所有信号长度之和不超过一帧的容量。每个信号的长度可以是 1 比特(bool)、2~8 比特(u8)、9~16 比特(u16)和 2~8 字节(bytes)。 |
状态操作 | l_flg_tst l_flg_clr | 查询/清除状态标志,用于基本的诊断功能。为加强应用层与核心 API的联系,允许自定义一些标志,由核心 API 置位,应用层可以查询和清除。 |
进度表管理(注 1) | l_sch_tick l_sch_set | l_sch_tick 是一个时间触发的函数,应该在每个时基节拍(参照3.3 节 )处调用。如果调用时恰逢帧时隙的开始,此函数将启动下一个入口;其他情况将完成诸如信号更新、读取通信状态报告(Status Word)、指示下一个进度表入口等功能。请参照参考资料[4]的 2.2.4 节和参考 资料[3]的 6.2.5.8 节。 l_sch_set 用于选择当前有效的进度表(l_sch_tick 就是根据当前有效的进度表工作的)。l_sch_set 不但可以选择进度表,而且可以精确地选择某个进度表入口。 |
接口管理 | l_ifc_init l_ifc_goto_sleep(注 1) l_ifc_wake_up l_ifc_ioctl l_ifc_rx l_ifc_tx l_ifc_aux l_ifc_read_status | l_ifc_init 用于物理层初始化。在执行“接口管理”的其它 API 函数之前必须首先调用。 l_ifc_goto_sleep 和 l_ifc_wake_up 分别实现休眠和唤醒操作。 l_ifc_ioctl 执行一些底层的自定义操作。 l_ifc_rx 和 l_ifc_tx 控制帧的收发。 l_ifc_aux 用于捕获帧头,这是个可选的函数,其功能可以包含在 l_ifc_rx 中。 l_ifc_read_status 用来读写状态报告。 |
逆向调用 | l_sys_irq_disable l_sys_irq_restore | 可选择的功能。某些物理层驱动可能不允许被中断打断,这两个函数用来屏蔽和恢复系统的中断。 |
注:1. 仅适用于主机节点。
从 LIN 规范 2.0 版开始,增加了传输层 API。
传输层API 是为配置、识别和诊断这三项服务设置的,是应用层与协议层的接口。传输层 API 的功能包括:建立并管理 PDU 队列、收发 PDU 以及检查 PDU 的通信状态。传输层API 接收应用层消息,调用核心 API 发送主机请求帧;收到从机应答帧时,传输层剥离协议层的帧头信息获得 PDU,送往应用层处理。
对于识别或配置服务,因为用于识别和配置的诊断帧已经预先安排在进度表内,所以传输层 API 只是在有关帧时隙到来时才工作,不影响核心 API 的进度表调度,不影响 LIN 的确定性。对于诊断服务,因为诊断请求通常来自诊断仪表或者上级网络(例如 CAN),发生时机和频次不可预测,所以传输层 API 要能动态地产生诊断帧,并将诊断帧插入到当前的进度表里,这会影响 LIN 的确定性。
LIN 规范定义了两种传输层 API——Raw API 和 Cooked API,二者功能一致,区别在于对应用层消息的处理方式。两种 API 不建议混用,用户宜根据需要选用一种。如果节点需要监视通信细节,那么应该用 Raw API,它允许节点以 PDU 为单位处理信息。如果节点只需要转发消息而不需要关心消息内容,那么适合使用 Cooked API,它允许节点以消息为单位处理信息。
传输层API 如表 6.2 所示。
表 6.2 传输层 API
类别 | 名称 | 说明 |
初始化 | ld_init | ld_init 用于传输层初始化。 |
Raw | ld_put_raw ld_get_raw | 完成 PDU 到帧的相互转换,并且在 MRF/SRF 的帧时隙到来时传输。 |
ld_raw_tx_status ld_raw_rx_status | 查询传输层的工作状态。 | |
Cooked | ld_send_message ld_receive_message | 完成消息到帧的相互转换,并且在MRF/SRF 的帧时隙到来时传输。 |
ld_tx_status ld_rx_status | 查询传输层的工作状态。 |
-
- 配置与识别 API
从 LIN 规范 2.0 版开始,增加了配置与识别 API。用于支持应用层的配置功能和识别功能。配置与识别 API 如表 6.3 所示。表 6.3 配置与识别 API
类 别 | 名称 | 说明 |
配置 | ld_is_ready(注 1) ld_check_response(注 1) | ld_is_ready 用来检查上一次的服务请求的执行状况。调用 ld_check_response 读取服务的执行情况。 |
ld_assign_NAD(注 1) ld_conditional_change_NAD(注 1) ld_assign_frame_id_range(注 1) | 给指定的从机节点分配 NAD/PID。 | |
ld_set_configuration(注 2) ld_save_configuration(注 1) ld_read_configuration(注 2) | 从机节点调用ld_set_configuration 设置初始配置项(NAD 和PID)。主机节点调用 ld_save_configuration,请求从机节点保存当前的配置项。 从机节点调用 ld_read_configuration,整理当前配置项并保存。 | |
识别 | ld_read_by_id(注 1) | 读取从机节点的产品代号或者其他参数。 |
ld_read_by_id_callout(注 2) | 向主机节点发送自定义的数据。 |
注:1. 仅适用于主机节点。2. 仅适用于从机节点。
配置API 除了实现具体的服务项目,还可以向应用程序报告服务的执行情况。
识别API 包含两个函数:ld_read_by_id 和 ld_read_by_id_callout。ld_read_by_id 仅供主机节点使用,主机节点只能通过它获得从机节点的硬件信息,例如产品代号等等;ld_read_by_id_callout 仅供从机节点使用,这是一个从API 向节点应用程序的逆向调用,它并不是必须的,专门用于实现用户自定义的服务。
兼容性
API 的兼容性体现在两个方面,一是不同版本API 之间的兼容性,二是 API 对帧收发硬件的兼容性。
API 版本之间的兼容性如表 6.4 所示。
表 6.4 不兼容的 API 列表
服务 | 名称 | LIN 1.X | LIN 2.0 | LIN 2.1 |
接口管理 | l_ifc_connect l_ifc_disconnect | YES | YES | N/A |
l_ifc_goto_sleep l_ifc_wake_up l_ifc_read_status | N/A | YES | YES | |
识别 | ld_read_by_id | N/A | YES | YES |
ld_read_by_id_callout | N/A | N/A | YES | |
通信管理 | ld_is_ready ld_check_response | N/A | YES | YES |
传输层 | ld_put_raw ld_get_raw ld_raw_tx_status ld_raw_rx_status ld_send_message ld_receive_message ld_tx_status ld_rx_status | N/A | YES | YES |
给指定的从机节点分配 NAD | ld_assign_NAD ld_conditional_change_NAD | N/A | YES | YES |
给指定的从机节点分配 PID | ld_assign_frame_id | N/A | YES | N/A |
配置项相关操作 | ld_assign_frame_id_range | N/A | N/A | YES |
ld_save_configuration ld_read_configuration ld_set_configuration | N/A | N/A | YES |
不同的硬件需要使用不同的 API。LIN API 的实现通常都是与帧收发硬件密切相关的,不能简单挪用。
开发工具
目前已经有一些商品化的 LIN 开发工具。要开发 LIN 的应用,商品化的开发工具并不是必须的,不过,此类工具确实能提高开发效率,尤其是处理那些同时容纳不同 LIN 规范版本的节点的网络。
图 6.2 显示了此类开发工具的工作原理。API 的实现可以是独立的若干个库文件,也可能包含在某种开发工具之中。API 通常不能直接被调用,需要配合若干外部附属模块(例如驱动函数)以及映射文件(例如用宏定义实现节点端口与 API 库文件之间的衔接)。库文件与附属模块、映射文件一起,在编译阶段添加到用户代码中,请参照参考资料[11]、[12]。
API 使用示例
参考资料[11]给出了一个 LIN 2.0 版的 API 的示例,从中可以看出 API 的调用次序。该示例包括两部分:在从机节点初始化阶段需要执行的API,以及在从机节点应用程序中调用 API 的方法。
从机节点初始化
extern unsigned char lin_SomeCotrol_init( void ); void PowerON_Reset(void)
{
HardwareSetup();/* 系统初始化 */ if( l_sys_init() ) {
/* LIN API 初始化失败 */ sleep();
}
else {
if( lin_SomeCotrol_init() ) {
/* LIN 相关的模块初始化失败,例如传感器、执行器 */ sleep();
}
}
/* 其他系统要求的功能 */ main();
return;
}
/* 帧收发硬件的驱动程序入口 */
const T_Lib_Slave_Handle Slave_handle = { Lin_Drv_Init,
Lin_Drv_HeaderIn, Lin_Drv_Pid_RecvReq, Lin_Drv_SendData, Lin_Drv_RecvData, Lin_Drv_SendRecvFinish, Lin_Drv_LinBus_Enable, Lin_Drv_LinBus_Disable, Lin_Drv_WakeUp
};
/* LIN 网络初始化 */
unsigned char lin_SomeCotrol_init( void )
{
unsigned char rtn;
rtn = 0;
if( l_ifc_ioctl( 0, LIN_ENTRY_SLAVE_DRV, &Slave_handle ) ) {
/* 帧收发硬件的驱动程序初始化失败 */ rtn = 1u;
}
else {
l_ifc_init(0); /* LIN 端口初始化 */ if( l_ifc_connect(0) ) {
/* LIN 端口初始化失败 */ rtn = 1u;
}
else {
/* 其他必要的操作 */
}
}
return rtn;
}
从机节点主程序
#include "sfr_r825.h"
#include "Lin_DrvR8C.h"
#include "lin20.h"
void lin_application( void );
/***************************/
/* Main Function */
/***************************/ void main(void)
{
while( 1 ) {
/* Something to do */
lin_application();
/* Something to do */
}
}
/*******************************/
/* LIN Application Function */
/*******************************/
extern l_flg Lin_Frm_FrameMst0_flg;
extern l_flg Lin_Frm_FrameU1_flg;
extern l_flg Lin_Frm_FrameU2_flg;
extern l_flg Lin_Frm_FrameU3_flg;
extern l_flg Lin_Frm_FrameEve0_flg;
extern l_flg Lin_Frm_FrameSlv0_flg;
extern l_flg Lin_Sig_Command_flg;
extern T_Signal Lin_Sig_Status_Slv0;
extern T_Signal Lin_Sig_Status_Slv1;
extern T_Signal Lin_Sig_Command;
void lin_application( void )
{
l_u8 data[8];
l_u16 status;
/* 判断:是否收到了新的帧? */
if( 0 != l_flg_tst(&Lin_Frm_FrameU1_flg) ) { l_flg_clr( &Lin_Frm_FrameU1_flg );
/* 根据收到的帧执行相应的操作 */
}
else if( 0 != l_flg_tst(&Lin_Frm_FrameMst0_flg) ) { l_flg_clr( &Lin_Frm_FrameMst0_flg );
/* 根据收到的帧执行相应的操作 */
}
/* 判断:帧是否已经发出? */
if( 0 != l_flg_tst(&Lin_Frm_FrameU2_flg) ) { l_flg_clr( &Lin_Frm_FrameU2_flg );
/* 执行发送结束之后的操作 */
}
else if( 0 != l_flg_tst(&Lin_Frm_FrameU3_flg) ) { l_flg_clr( &Lin_Frm_FrameU3_flg );
/* 执行发送结束之后的操作 */
}
else if( 0 != l_flg_tst(&Lin_Frm_FrameEve0_flg) ) { l_flg_clr( &Lin_Frm_FrameEve0_flg );
/* 执行发送结束之后的操作 */
}
else if( 0 != l_flg_tst(&Lin_Frm_FrameSlv0_flg) ) { l_flg_clr( &Lin_Frm_FrameSlv0_flg );
/* 执行发送结束之后的操作 */
}
status = l_ifc_read_status( 0 );
/* 处理可能出现的应答错误 */ if( status & 0x0001u ) {
/* 出现应答错误,执行相关操作 */
}
if( LD_DATA_AVAILABLE == ld_raw_rx_status(0) ) { ld_get_raw( 0, data );
}
/* 判断:来自主节点的信号被更新了吗? */ if( 0 != l_flg_tst(&Lin_Sig_Command_flg) ) {
l_flg_clr( &Lin_Sig_Command_flg );
if( 0x1234u == l_u16_rd(&Lin_Sig_Command) ) { l_u16_wr( &Lin_Sig_Status_Slv0, 0x0101u ); l_u16_wr( &Lin_Sig_Status_Slv1, 0x0201u );
/* 其他相关操作 */
}
else if( 0x5678u == l_u16_rd(&Lin_Sig_Command) ) { l_u16_wr( &Lin_Sig_Status_Slv0, 0x0100u ); l_u16_wr( &Lin_Sig_Status_Slv1, 0x0200u );
/* 其他相关操作 */
}
}
/* 监测休眠命令 */ if( status & 0x0008u ) {
/* LIN 端口休眠的相关操作 */
}
return;
}
参考资料
- LIN API Recommended Practice Revision 1.3, LIN Consortium, 2002
- LIN Application Program Interface Specification Revision 2.0, LIN Consortium, 2003
- LIN Application Program Interface Specification Revision 2.1, LIN Consortium, 2006
- LIN Protocol Specification Revision 2.1, LIN Consortium, 2006
- H8/300H Tiny Series H8/36049 Group LIN(Local Interconnect Network) : Master Volume, Renesas Technology, 2003
- H8/300H Tiny Series LIN(Local Interconnect Network) Application Note: Master, Renesas Technology, 2003
- H8/300H Tiny Series H8/36014 Group LIN(Local Interconnect Network) : Slave Volume, Renesas Technology, 2003
- H8/3664F/3694F/36014F Series LIN(Local Interconnect Network) Application Note: Slave, Renesas Technology, 2003
- H8/3687F Series LIN(Local Interconnect Network) Application Note: Slave, Renesas Technology, 2003
- R8C/Tiny Series R8C/11 Group LIN(Local Interconnect Network) Application Note: Slave Volume,Renesas Technology, 2006
- R8C/Tiny Series R8C/25 Group LIN(Local Interconnect Network) Application Note: Slave Volume,Renesas Technology, 2006
- LINkits LIN Evaluation Boards, Freescale Semiconductors, 2007
7、工作流
本章介绍了 LIN 工作流的概念,以及节点性能文件和 LIN 描述文件的内容,对应着 LIN 规范的以下部分:
- LIN Node Capability Language Specification
- LIN Configuration Language Specification
为了实现从机节点入网的“即插即用”,LIN 规范标准化了 LIN 网络从设计到生成的工作流程,如图 7.1 所示。
图 7.1 工作流
其中节点性能文件(NCF)定义了节点名称和节点的属性值,包括产品代号、位速率、帧的定义等信息。LIN子网设计工具收集到节点性能文件的信息,自动生成 LIN 描述文件(LDF)。LDF 包含了整个子网的信息,包括所有的信号和帧的声明,以及进度表等信息。LDF 文件还可以作为调试时总线分析仪和仿真器的输入。LIN 子网生成工具根据 LDF 生成各种通信驱动,可以建立起通信子网,也可以将具备节点性能文件的现成节点加入到已经建立好的通信子网中,并在网络进入运行前排除掉可能产生的冲突
节点性能文件
节点性能文件包含节点的物理特性、帧和信号的定义等内容,如表 7.1 所示。
表 7.1 节点性能文件
节点性能文件 | ||||
全局定义 | LIN 语言版本 | |||
节点定义(注 1) | ||||
节点名称 | 概要定义 | LIN 协议版本 | ||
厂商 ID(Suppliler ID) | ||||
功能 ID(Function ID) | ||||
可变 ID(Variant ID) | ||||
位速率 | ||||
发送唤醒使能 | ||||
诊断定义 | 初始NAD | |||
诊断类型 | ||||
P2_min(注 2) | ||||
ST_min(注 3) | ||||
N_As_timeout(注 4) | ||||
N_Cr_timeout(注 5) | ||||
支持的 SID | ||||
诊断传输层最大消息长度(单位:字节) | ||||
帧定义 | 帧类别(发布或收听) | |||
帧名称 | ||||
帧属性 | 长度 | |||
最小时间 | ||||
最大时间 | ||||
事件触发帧 | ||||
信号定义 | 信号名称 | |||
信号属性 | 初始值 | |||
保留位数 | ||||
偏移量(注 6) | ||||
编码类型名称 | ||||
信号编码类型定义 | 编码类型名称 | |||
逻辑值 | 逻辑值 | |||
信号值 | ||||
文本信息 | ||||
物理值 | 物理值 |
最大值
缩放倍数(注 7)
偏移量(注 7)
文本信息
BCD 值
ASCII 值
状态管理
应答错误名称
错误状态信号
发布节点
自由文本定义
(蓝色笔标出的部分为可选项,红色笔标出的部分为选择其中的一项或几项。)
注:1. 一个节点描述文件可以定义多个节点,在同一个文件中的节点不能重名。
- P2_min: 从 LIN 子网接收到主机请求帧到 LIN 的从机节点准备好数据发送应答之间的最小时间间隔。
- ST_min: 从机节点准备接收下一个帧(主机请求帧)或准备发送下一个帧(从机应答帧)的应答部分所需要的最小准备时间。
- N_As_timeout: 从传输层向 LIN 子网请求一个帧开始到传输层确认请求的帧传输结束之间的超时间隔,即从发送方看,发送 LIN 帧(MRF 或 SRF)的超时间隔。
- N_Cr_timeout: 在复合帧(首帧+续帧的形式,参照 5.3 节)的传输中,传输层接收到的首帧和续帧、续帧和续帧之间的超时间隔。
- 信号在字节中的偏移量如表 7.2 举例。
表 7.2 信号在字节中的偏移量示例
物理值 = 缩放倍数 × 原始值 + 偏移量
节点性能文件举例说明
以下为一个节点性能文件的例子和说明。
node_capability_file; //节点性能文件
LIN_language_version = “2.1”; //LIN 语言版本 2.1
node step_motor { //节点定义。节点名称 step_motor
general { //摘要定义
LIN_protocol_version = “2.1”; //LIN 协议版本 2.1
supplier = 0x0005; function = 0x0020; variant = 1; //厂商 ID,功能 ID,可变 ID
bitrate = automatic min 10 kbps max 20 kbps; //比特率自动选择范围[10kbps-20kbps]
sends_wake_up_signal = “yes”; //该节点可以发送wakeup 信号
}
diagnostic { //诊断定义
NAD = 1 to 3; //初始 NAD 可以选择的值:1~3
diagnostic_class = 2; //支持的诊断类别为第 2 类
P2_min = 100 ms; ST_min = 40 ms; //参照表 7.1 注释
support_sid { 0xB0, 0xB2, 0xB7 }; //节点支持的全部 SID
}
frames { //帧定义
publish node_status { //帧名称为node_status,作为发布节点
length = 4; min_period = 10 ms; max_period = 100 ms;
//帧长度 4 字节,传输最小、最大时间
signals { //信号定义(该帧中包含的信号)
state {size = 8; init_value = 0; offset = 0;} //state 信号:长度 8bit,
//初始值为 0,偏移量为 0(即 bit[7:0])
fault_state {size = 2; init_value = 0; offset = 9; fault_enc;}
error_bit {size = 1; init_value = 0; offset = 8;}
angle {size = 16; init_value = {0x22, 0x11}; offset = 16;}
}
}
//fault_state 信号:长度 2bit,初始值为 0,
//偏移量为 9(即 bit9、bit10),
//编码类型名称为 fault_enc
//error_bit 信号:长度 1bit,
//初始值为 0,偏移量为 8
//angle 信号:长度 16bit,
//初始值为 0x22,0x11,偏移量 16
subscribe control { //帧名称为 control,作为收听节点
length = 1; max_period = 100 ms; //帧长度 1 字节,传输最大时间 100ms
signals { //信号定义(该帧中包含的信号)
command {size = 8; init_value = 0; offset = 0; position;}
//command 信号:长度 8bit,初始值为 0,
//偏移量为 0,编码类型名称为position
}
}
}
encoding { //信号编码类型
position {physical_value 0, 199, 1.8, 0, “deg”;} //编码类型名称为 position:
//物理值,最小值 0,最大值 199,
//缩放倍数 1.8,偏移量为 0,
//文本信息为“deg”
fault_enc {logical_value, 0, “no result”;
//编码类型名称为 fault_enc:
//逻辑值,信号值 0,文本信息为“no result”
logical_value, 1, “failed”; //逻辑值,信号值 1,文本信息为“failed”
logical_value, 2, “passed”;} //逻辑值,信号值 2,文本信息为“passed”
}
status_management { response_error = error_bit; //状态管理:表示 response_error 的信号名称 fault_state_signals = fault_state; } //表示 fault_state_signals 的信号名称 free_text { “step_motor signal values outside 0 - 199 are ignored” }
//自由文本定义
}
LIN 描述文件
LIN 描述文件对整个 LIN 网络进行了描述,也包含了要监测 LIN 网络所必需的信息,包含 LIN 网络内所有节点、帧和信号的信息以及进度表等内容,如表 7.3 所示。
表 7.3 LIN 描述文件
LIN 描述文件 | |||
全局定义 | LIN 协议版本 | ||
LIN 语言版本 | |||
LIN 位速率定义 | |||
通道后缀名称定义(注 1) | |||
节点定义 | 参与节点 | 主机节点 | 节点名称 |
时基 | |||
抖动 | |||
从机节点 | 节点名称列表 | ||
节点属性 | 节点名称 | ||
LIN 协议版本 | |||
配置 NAD(从机节点地址) | |||
初始NAD | |||
属性定义 | 产品 ID | ||
应答错误名称 | |||
错误状态信号 | |||
P2_min | |||
ST_min | |||
N_As_timeout | |||
N_Cr_timeout | |||
符合 LIN2.0 的可配置的帧 | |||
符合 LIN2.1 的可配置的帧 | |||
节点组合定义(注 2) | 配置名称 | 组合节点名称(物理节点) | |
逻辑节点名称列表 (包含于该物理节点中) | |||
信号定义 | 标准信号 | 信号名称 | 信号大小 |
初始值 | |||
该信号的发布节点 | |||
该信号的收听节点列表 | |||
诊断信号 | 信号名称 | ||
信号大小 | |||
信号在帧中的偏移量 | |||
信号组(注 3) | 信号组名称列表 | 组大小 | |
信号名称及在组中的偏移量列表 |
帧定义 | 无条件帧定义 | 帧名称 | |
帧 id | |||
该帧的发布节点 | |||
帧大小 | |||
信号名称及在帧中的偏移量列表 | |||
偶发帧定义 | 偶发帧名称 | ||
关联的无条件帧名称列表 | |||
事件触发帧定义 | 事件触发帧名称 | ||
冲突解决进度表 | |||
事件触发帧的帧 ID | |||
关联的无条件帧名称列表 | |||
诊断帧定义 | 主机请求帧 | 主机请求帧包含信号及偏移量 | |
从机应答帧 | 从机应答帧包含信号及偏移量 | ||
进度表定义 | 进度表名称 | ||
命令 | 帧名称 | ||
主机请求帧 | |||
从机应答帧 | |||
分配NAD | |||
条件改变 NAD | |||
数据 DUMP | |||
保留配置 | |||
分配 PID 范围 | |||
自由格式 | |||
分配 PID | |||
命令延迟时间(即帧时隙) | |||
附加信息 | 信号编码类型定义 | 信号编码类型名称 | |
逻辑值 | |||
物理值 | |||
BCD 值 | |||
ASCII 值 | |||
信号表示定义 | 信号编码类型名称 | ||
该编码类型对应的信号名称列表 |
(蓝色笔标出的部分为可选项,红色笔标出的部分为选择其中的一项或几项。)
注:1. 当一个主机 ECU 与多个 LIN 通信子网相连时,会包含多个 LDF 文件,为了避免命名冲突,规定 LDF
文件中的所有对象必须使用通道后缀名称。
- 当存在从机物理节点对应多个逻辑节点时,节点组合定义可以让主机节点用同一软件无需作任何改变就可处理多个从机节点的配置。
- 只应用于依据 LIN1.3 版本设计的节点。
LIN 描述文件举例说明
以下为一个 LIN 描述文件的例子和说明。
LIN_description_file; //LIN 描述文件
LIN_protocol_version = “2.1”; //LIN 协议版本
LIN_language_version = “2.1”; //LIN 语言版本
LIN_speed = 19.2 kbps; //LIN 通信速度
Channel_name = “DB”; //通道后缀名称“DB”
Nodes { //节点定义
Master: CEM, 5 ms, 0.1 ms; //主机节点,名称:CEM,时基:5ms,抖动:0.1ms Slaves: LSM, RSM; //从机节点,LSM,RSM
}
Node_attributes { //节点属性定义
LSM { //节点名称为LSM 的节点的定义
LIN_protocol = “2.1”; //该节点依据 LIN 协议 2.1 设计
configured_NAD = 0x20; //配置 NAD 为 0x20
initial_NAD = 0x01; //初始 NAD 为 0x01
product_id = 0x4A4F, 0x4841; //产品 ID:厂商 ID 为 0x4A4F,功能 ID 为 0x4841 response_error = LSMerror; //应答错误名称为:LSMerror
fault_state_signals = IntTest; //错误状态信号为 IntTest
P2_min = 150 ms; //参照节点性能文件注释
ST_min = 50 ms; //参照节点性能文件注释
configurable_frames { CEM_Frm1; LSM_Frm1; LSM_Frm2;}
//可配置的帧列表
}
RSM { //节点名称为 RSM 的节点的定义
LIN_protocol = “2.0”; //该节点依据 LIN 协议 2.0 设计
configured_NAD = 0x20; //配置 NAD 为 0x20
product_id = 0x4E4E, 0x4553, 1; //产品 ID:厂商 ID 为 0x4E4E,
//功能 ID 为 0x4553,可变 ID 为 1
response_error = RSMerror; //应答错误名称:RSMerror
P2_min = 150 ms; //参照节点性能文件注释
ST_min = 50 ms; //参照节点性能文件注释
configurable_frames {CEM_Frm1 = 0x0001; LSM_Frm1 = 0x0002; LSM_Frm2 = 0x0003;}
//可配置的帧列表
}
}
Signals { //信号定义
IntLightsReq: 2, 0, CEM, LSM, RSM; //信号名称:IntLightsReq,
//长度:2,初始值:0,
//发布节点:CEM,收听节点:LSM、RSM
RightIntLightsSwitch: 8, 0, RSM, CEM; //信号名称:RightIntLightsSwitch,
//长度:8,初始值:0,
//发布节点:RSM,收听节点:CEM
LeftIntlLightsSwitch: 8, 0, LSM, CEM; //信号名称:LeftIntlLightsSwitch,
//长度:8,初始值:0,
//发布节点:LSM,收听节点:CEM
LSMerror, 1, 0, LSM, CEM; //信号名称:LSMerror,长度:1,初始值:0,
//发布节点:LSM,收听节点:CEM
RSMerror, 1, 0, LSM, CEM; //信号名称:RSMerror,长度:1,初始值:0,
//发布节点:LSM,收听节点:CEM
IntTest, 2, 0, LSM, CEM; //信号名称:IntTest,长度:2,初始值:0,
//发布节点:LSM,收听节点:CEM
}
Frames { //帧定义
CEM_Frm1: 0x01, CEM, 1 { //帧名称:CEM_Frm1,帧 ID:0x01,
//该帧的发布节点:CEM,数据段为 1 个字节
InternalLightsRequest, 0; //包含的信号名称
//为 InternalLightsRequest,
//在帧中的偏移量为 0
}
LSM_Frm1: 0x02, LSM, 2 { //帧名称:LSM_Frm1,帧 ID:0x02,
//该帧的发布节点:LSM,数据段为 2 个字节
LeftIntLightsSwitch, 0; //包含的信号名称为 LeftIntLightsSwitch,
//在帧中的偏移量为 0
}
LSM_Frm2: 0x03, LSM, 1 { //帧名称:LSM_Frm2,帧 ID:0x03,
//该帧的发布节点:LSM,数据段为 1 个字节
LSMerror, 0; //包含的信号名称为 LSMerror,帧中偏移量为 0
IntError, 1; //包含的信号名称为 IntError,帧中偏移量为 1
}
RSM_Frm1: 0x04, RSM, 2 { //帧名称:RSM_Frm1,帧 ID:0x04,
//该帧的发布节点:RSM,数据段为 2 个字节
RightIntLightsSwitch, 0; //包含的信号名称为 RightIntLightsSwitch,
//在帧中的偏移量为 0
}
RSM_Frm2: 0x05, RSM, 1 { //帧名称:RSM_Frm2,帧 ID:0x05,
//该帧的发布节点:RSM,数据段为 1 个字节
RSMerror, 0; //包含的信号名称为 RSMerror,帧中偏移量为 0
}
}
Event_triggered_frames { //事件触发帧定义 Node_Status_Event : Collision_resolver, 0x06, RSM_Frm1, LSM_Frm1;
//事件触发帧名称:Node_Status_Event,
//冲突解决进度表:Collision_resolver,
//事件触发帧的帧 ID:0x06
//关联的无条件帧为 RSM_Frm1,LSM_Frm1
}
Schedule_tables { //进度表定义
Configuration_Schedule { //进度表名称为:Configuration_Schedule
AssignNAD {LSM} delay 15 ms; //给节点 LSM 分配NAD,帧时隙为 15ms AssignFrameIdRange {LSM, 0} delay 15 ms;
AssignFrameId {RSM, CEM_Frm1} delay 15 ms;
AssignFrameId {RSM, RSM_Frm1} delay 15 ms;
AssignFrameId {RSM, RSM_Frm2} delay 15 ms;
}
//给节点 LSM 从第 0 帧开始分配 PID,
//帧时隙为 15ms
//给节点 RSM 的帧 CEM_Frm1 分配 PID,
//帧时隙为 15ms
//给节点 RSM 的帧 RSM_Frm1 分配 PID,
//帧时隙为 15ms
//给节点 RSM 的帧 RSM_Frm2 分配 PID,
//帧时隙为 15ms
Normal_Schedule { //进度表名称为:Normal_Schedule
CEM_Frm1 delay 15 ms; //帧 CEM_Frm1,帧时隙 15ms
LSM_Frm2 delay 15 ms; //帧 LSM_Frm2,帧时隙 15ms
RSM_Frm2 delay 15 ms; //帧 RSM_Frm2,帧时隙 15ms
Node_Status_Event delay 10 ms; //事件触发帧 Node_Status_Event,
//帧时隙 10ms
}
MRF_schedule { /进度表名称为:MRF_schedule
MasterReq delay 10 ms; //主机请求帧,帧时隙 10ms
}
SRF_schedule { //进度表名称为:SRF_schedule
SlaveResp delay 10 ms; //从机应答帧,帧时隙 10ms
}
Collision_resolver { //发生冲突时需保证非事件触发帧的传输时序
//进度表名称:Collision_resolver
CEM_Frm1 delay 15 ms; //帧 CEM_Frm1,帧时隙 15ms
LSM_Frm2 delay 15 ms; //帧 LSM_Frm2,帧时隙 15ms
RSM_Frm2 delay 15 ms; //帧 RSM_Frm2,帧时隙 15ms
RSM_Frm1 delay 10 ms; //轮询 RSM 节点
//帧 RSM_Frm1,帧时隙 10ms
CEM_Frm1 delay 15 ms; //帧 CEM_Frm1,帧时隙 15ms
LSM_Frm2 delay 15 ms; //帧 LSM_Frm2,帧时隙 15ms
RSM_Frm2 delay 15 ms; //帧 RSM_Frm2,帧时隙 15ms
LSM_Frm1 delay 10 ms; //轮询 LSM 节点
//帧 LSM_Frm1,帧时隙 10ms
}
}
Signal_encoding_types { //信号编码类型:Signal_encoding_types
Dig2Bit { //信号编码类型名称:Dig2Bit
logical_value, 0, “off”; //逻辑值 0,代表“off”
logical_value, 1, “on”; //逻辑值 1,代表“on”
logical_value, 2, “error”; //逻辑值 2,代表“error”
logical_value, 3, “void”; //逻辑值 3,代表“void”
}
ErrorEncoding { //信号编码类型名称:ErrorEncoding
logical_value, 0, “OK”; //逻辑值 0,代表“OK”
logical_value, 1, “error”; //逻辑值 1,代表“error”
}
FaultStateEncoding { //信号编码类型名称:FaultStateEncoding
logical_value, 0, “No test result”; //逻辑值 0,代表“No test result”
logical_value, 1, “failed”; //逻辑值 1,代表“failed”
logical_value, 2, “passed”; //逻辑值 2,代表“passed”
logical_value, 3, “not used”; //逻辑值 3,代表“not used”
}
LightEncoding { //信号编码类型名称:LightEncoding
logical_value, 0, “Off”; //逻辑值:0,代表:“Off”
hysical_value, 1, 254, 1, 100, “lux”; //物理值:1,最小值:1,
//最大值:254,缩放倍数:1,
//偏移量:100,文字信息:“lux”
logical_value, 255, “error”; //逻辑值:255,代表:“error”
}
}
Signal_representation { //信号表示定义
Dig2Bit: InternalLightsRequest; //应用信号编码类型为 Dig2Bit 的信号
//InternalLightsRequest
ErrorEncoding: RSMerror, LSMerror; //应用信号编码类型为 ErrorEncoding 的
//信号 RSMerror,LSMerror
FaultStateEncoding: IntError; //应用信号编码类型为
//FaultStateEncoding 的信号 IntError
LightEncoding: RightIntLightsSwitch, LefttIntLightsSwitch;
//应用信号编码类型为 LightEncoding 的
//信号 RightIntLightsSwitch,
//LefttIntLightsSwitch
}
关键词对照表 | |
英文 | 中文 |
API (Application Program Interface) | 应用编程接口 |
BRG (Baud Rate Generator) | 波特率发生器 |
Bitrate | 位速率 |
Break | 同步间隔 |
Break Delimiter | 同步间隔段间隔符 |
Break Field | 同步间隔段 |
Bus Transceiver | 总线收发器 |
Bus Wakeup | 总线唤醒 |
Byte Field | 字节域 |
Checksum | 校验和 |
Classic Checksum | 标准型校验和 |
Cluster | 子网,网络 |
Cluster Design | 子网设计,参照图 7.1 的 LIN 子网设计工具 |
Cluster Generation | 子网生成,参照图 7.1 的 LIN 子网生成工具 |
Collision Resolving Schedule | 冲突解决进度表 |
Configuration | 配置项 |
CF (Consecutive Frames) | 续帧 |
CAN (Controller Area Network) | 控制器局域网 |
Data | 数据 |
Diagnostic Class | 诊断类型 |
Diagnostic Frame | 诊断帧 |
Dominant | 显性电平 |
EMC (Electromagnetic Compatibility) | 电磁兼容性 |
EMI (Electromagnetic Interference) | 电磁干扰 |
ECU (Electronic Control Unit) | 电子控制单元 |
ESD (Electrostatic Discharge) | 静电放电 |
Enhanced Checksum | 增强型校验和 |
Entry | 入口 |
Event Triggered Frame | 事件触发帧 |
FF (First Frame) | 首帧 |
Frame ID | 帧 ID |
Frame Slot | 帧间隔 |
Function ID | 功能 ID |
Hardware LIN | 硬件 LIN |
Header | 帧头 |
Identification | 识别 |
Inter-byte Space | 字节间间隔 |
Inter-frame Space | 帧间隔 |
Interface | 接口 |
Jitter | 抖动 |
Jump-start | 蓄电池串联 |
LSB (Least Significant Bit) | 最低有效位 |
Limp Home Mode | 自我保护/安全模式 |
LDF (LIN Description File) | LIN 描述文件 |
LIN Module | LIN 模块 |
LIN Product Identification | LIN 产品代号 |
Load Dump | 负载突降 |
Logical Node | 逻辑节点 |
LIN (Local Interconnect Network) | 本地互连网 |
Local Wakeup | 本地唤醒 |
Master Node | 主机节点 |
Message | 消息 |
MRF (Master Request Frame) | 主机请求帧 |
Master Task | 主机任务 |
MSB (Most Significant Bit) | 最高有效位 |
Node | 节点 |
NAD (Node Address for Diagnose) | 诊断地址 |
NCF (Node Capability File) | 节点性能文件 |
NVRAM (Non-volatile Random Accessible Memory) | 非易失性随机存储器 |
Off-the-shelf Node | 现成节点 |
OBD (On-board Diagnose) | 车载自动诊断 |
Operational | 运行状态 |
Packing | 拆分 |
PCI(Protocol Control Information) | 协议控制信息 |
PDU (Packet Data Unit) | 分组数据单元 |
Physical node | 物理节点 |
Product ID | 产品 ID |
PID (Protected identifier) | 受保护 ID |
Protocol Controller | 协议控制器 |
Publisher | 发布节点 |
Recessive | 隐性电平 |
Reserved Frame | 保留帧 |
Response | 应答 |
Response Space | 应答间隔 |
RSID(Response Service ID) | 应答服务 ID |
Schedule | 进度表 |
Service | 服务 |
SID (Service ID) | 服务代号 |
Signal | 信号 |
Signal Carrying Frame | 信号携带帧 |
SF (Single Frame) | 单帧 |
Slave Node | 从机节点 |
SRF (Slave Response Frame) | 从机应答帧 |
Slave Task | 从机任务 |
Sleep | 休眠 |
Slew-rate | 压摆率 |
Sporadic Frame | 偶发帧 |
Start Bit | 起始位 |
State Machine | 状态机 |
Status Word | 状态报告 |
Stop Bit | 停止位 |
Subscriber | 收听节点 |
Supplier ID | 厂商 ID |
Sync Byte Field | 同步段 |
Tick | 节拍 |
Time Base | 时基 |
TVS (Transient Voltage Suppressor) | 瞬态电压抑制器件 |
Transport Layer | 传输层 |
Unconditional Frame | 无条件帧 |
Unconditional frames associated with the event triggered frame | 事件触发帧关联的无条件帧 |
Unconditional frames associated with the sporadic frame | 偶发帧关联的无条件帧 |
Unpacking | 重组 |
UDS (Unified Diagnostic Services) | 车辆统一诊断服务 |
UART/SCI (Universal Asynchronous Receiver-Transmitter / Serial Communication Interface) | 通用异步收发器/串行通信接口 |
Variant ID | 可变 ID |
Wakeup | 唤醒 |
Work Flow | 工作流 |