LIN总线学习手记

* LIN概况
LIN（Local Interconnect Network）是一种面向汽车用低速网络的单主多从、异步串行总线标准，定位于需要互连但不需要强调实时性和可靠性的部件，作为CAN网络的补充和末梢。

目标是以低廉的价格联接车上的传感器、执行器和处理器，并且允许不同厂家的模块随时添加进来。

LIN目前不但用于多种型号的汽车上，而且日益广泛地用在智能传感器领域。

* LIN组织核心成员
5个车厂+1个半导体公司+1个测试工具公司。

A(udi)，B(MW)，DC(戴克)，V(ol vo)，VW(大众)，Freescale和VCT（已并入Mentor Graphics）。

研、产、测、用一体化，这似乎是现代工业标准化的一种通行道路了。

* LIN规范
完全免费。

最新版本是2.0。

2.0与1.3目前都被广泛采用，2.0可以兼容1.3，但反过来不行。

定义完整，对应OSI的下三层。

入门阶段应该掌握下2层。

LIN规范包含6个模块，可以分“接口”、“通信协议”、“软件开发接口”和“开发语言”四个部分。

入门阶段应该掌握“接口”和“通信协议”，了解“软件开发接口”。

* LIN的通信协议
基于状态机：FPGA或CPLD
基于单片机
Bit-Bang方法：就是用IO口线模拟异步串口。

成本最低，但C PU负担最重，代码最多。

SCI+Timer方法：就是利用UART硬件和Timer组合。

成本适中，CPU负担减轻。

专门LIN模块：由功能完备的LIN模块完成通信。

成本较高，C PU负担最轻，代码最少。

* LIN的接口
+12V 单端非平衡信号。

最高通信速率20kbps。

主节点输入阻抗1K，从节点30K。

* LIN的前生今世与来生
源自ISO9141；目前是LIN 2.0和1.3并行发展，很快就要兼容24V电源系统；未来可能会变成SAE J2602。

*LIN的竞争对手
按照SAE的分类法，10K以下是A类网，125K以上是C类网，中间是B类网。

L IN属于A类和B类的过渡。

低速网络标准从来都是群雄并起，厂商、SAE行会和ISO组织分分合合，天下动荡。

目前比较强势的标准有3：LIN、J2602和TTP/A。

LIN是欧洲车厂主导的标准，J2602则是代表美国车厂利益的简化版LIN2.0（物理层通信速率固定为10.4kbps，诊断接口功能缩减）。

TTP/A是维也纳理工大学提出的，采用TDMA技术，实时性优于LIN，但是应用似乎没有LIN顺利。

值得一提的是，同门的TTP/C是一种可以与CAN竞争的高速网络协议。

LIN总线学习手记3
*个人观点：LIN适合国内汽车电子行业
国内汽车电子行业的主力我觉得有2，一个是中控锁，另一个是汽车诊断仪。

汽车音响和GPS导航我觉得与汽车关联松散，不能算吧。

中控锁可以借助LIN总线，与电动车窗等捆绑成为一个产品。

汽车诊断仪为了生存，要支持OBD/OBD-II/EOBD，2008后要开始支持ISO15 765。

目前的诊断仪，其物理层和数据链路层仍然是ISO9141-1或者ISO14230-1之类（看过标准之后发现，除了不能支持24V系统，最高速度限制在20K，其余指标LIN可胜任）。

未来的ISO15765将选择ISO11898规定的CAN作为物理层和数据链路层，那时候，天生作为CAN子网的LIN就体现出它的“嫡系”价值了。

当然，LIN只是定义了OSI的下三层，高层协议是继续使用ISO14230-2/3还是I SO15765-5，需要拭目以待。

BTW，今天登陆LIN协会网站，赫然发现LIN已经升级到2.1了！明天要好好学习一下它，看看比2.0先进多少，嘿嘿。

LIN总线学习手记4
* LIN 2.1
据LIN协会的说法，LIN 2.1相比2.0，主要的变化有4：
1. 明确了LIN
2.0中表述不够清晰的概念；
2. 取消了诊断接口中的Message Identifier相关服务；
3. 物理层指标加严。

4. 单独定义传输层。

一些自己总结的差异点：截至第2章体现了诊断标准的进展。

从LIN的引用资料就可以看出来，ISO14229和ISO15765赫然在目。

个人认为这些都是下一代基于CAN的车辆诊断系统的基础标准。

增补术语，部分术语更加准确。

看过LIN 2.0的DIAG和CLS这2部分的人，可能会和我一样对各种各样的identifier不知所云。

仅从PROT来看，LIN 2.1对于这些词汇的限制清楚多了，我想可以帮助理解。

LIN 2.1对那些具有1个以上LIN接口的节点考虑地更多。

体现在术语、通信时序等多个方面。

在阅读PROT时可以感觉到作者的高度，是站在应用层来考虑，以前读LIN 2.0的时候没有这个感觉。

哈哈，是不是说明我提高了呢？
CLS = Configuration Language Specification
NLS = Node Capability Language Specification
API = Application Program Interface
DIAG = Diagnostic and Configuration Specification
PROT = Protocol Specification
PHY = Physical Layer Specification
LIN总线学习手记5 - 通信硬件
写在前面：本篇内容源自我在瑞萨编写的《LIN入门》应用笔记。

该文档尚未正式发布。

作为作者，本人出于结交同行、征求意见的目的，提前发布这个资料。

如需转载，请注明出处。

正文：uploadfile-/2007-8/830548856.rar
摘要：
帧收发的硬件实现
本章着重介绍与LIN帧收发相关的硬件的组成、特点以及应用设计时的注意事项。

本章内容对应着LIN规范的以下部分：
•LIN Protocol Specification（部分内容）
•LIN Physical Layer Specification
简易收发器电路
市售LIN收发器
LIN总线学习手记6
LIN的API
内容简介
API是应用程序接口的缩写。

LIN的API是一套标准化的软件包，用户只需要按照使用要求调用API，就可以实现LIN通信功能。

使用API可以加速LIN节点开发进程。

有了API的帮助，软件设计者不必关心LIN的工作细节，可以集中精力实现节点的功能。

LIN规范并不提供API的完整代码，它只是规定了API的接口和功能。

LIN规范用C语言定义API，用户也可以用其他编程语言编写。

API通常以.lib文件的形式、在编译阶段添加到用户代码中。

API与LIN节点的硬件规格有关，不能简单挪用。

这是由于为了适应不同形式的LI N控制器硬件（SLIC、SCI和Bit-Bang），API通常会内置硬件驱动程序。

驱动程序针对特定的硬件进行了优化，是API不可分割的组成部分，LIN规范没有对驱动程序进行规定。

这些因素决定了API也与硬件规格有关，不同的硬件平台应使用各自的API。

API的类别
LIN的API按照用途可分为3类，分别是核心API、传输层API和节点配置与识别API。

三类API相对独立又彼此关联。

核心API是连接应用层与硬件电路的桥梁，协议层的所有工作都在这里实现，是A PI的基础。

核心API的功能包括初始化、进度表调度注、帧时隙控制注、信号量读写、报告LIN工作状态注等。

根据对硬件规格的依赖程度，可以把核心API分成功能部分和驱动部分。

功能部分负责实现LIN的进度表调度和帧时隙控制等关键任务，驱动部分即驱动程序（或硬件IP），控制LIN硬件协调工作，实现比特流的正常收发、帧校验、缓存管理和故障检测。

从信息处理的角度来看，核心API与应用程序的接口是进度表（帧），与传输层API的接口是PDU，与硬件电路的接口可以是字节，也可以是位。

注：仅主机节点
传输层API是专门为实现配置、识别和诊断这三项服务设置的。

传输层API可以建立并管理PDU队列、收发PDU以及检查PDU的通信状态。

传输层API从应用程序接收指令，然后调用核心API来发送主机请求帧和接收从机应答帧。

对于识别或配置服务，因为用于识别和配置的帧已经预先安排在进度表内，所以传输层API只是在有关帧时隙到来时才工作，不会影响核心API的进度表调度，不影响LIN的确定性。

对于诊断服务，因为诊断需求来自诊断仪表或者上级网络（例如CAN），具有不可预测性，所以传输层API要能动态地产生诊断帧，并能控制核心API将诊断帧插入到进度表里执行，这会影响到LIN的确定性。

LIN规范定义了两种传输层API——RAW和COOKED，二者功能一致，区别在于处理信息时的数据格式。

RAW以PDU为单位处理信息，每次调用时总是处理1个PD U，
格式从信息处理的角度来看，传输层API与应用程序的接口是PDU，与核心API 的接口也是PDU。

LIN总线学习手记7 - 软件
写在前面：本篇内容源自我在瑞萨编写的《LIN入门》应用笔记。

该文档尚未正式发布。

作为作者，本人出于结交同行、征求意见的目的，提前发布这个资料。

如需转载，请注明出处。

正文：uploadfile-/2007-8/829806197.rar
摘要：
信号处理、配置、识别和诊断
本章从应用需求入手，介绍了信号处理、配置、识别和诊断的概念、功能和实用价值。

本章内容对应于LIN规范的以下部分：
●LIN Transport Layer Specification
●LIN Node configuration and Identification Specification
●LIN Diagnostic Specification
从使用的角度来看，LIN提供四项功能——信号处理、配置、识别和诊断，这四项功能共同构成了LIN的应用层。

传输层是配置、识别和诊断这三项功能的通信载体，实现应用层消息与帧之间的格式转换和传输。

为了规范使用，LIN为应用层和传输层定义了API接口，参照第7章。

为了使读者从整体上把握LIN，本章侧重于功能之间的关联，略去了LIN规范中已经描述地较清楚的细节，如数据结构、状态转移等。

LIN总线学习手记8 - 理解位速率指标
LIN的位速率误差决定着通信双方同步的成败，是一个关键指标。

受同事启发，对物理层规范规定的的“位速率误差”加深了理解。

• Ftol_res_slave = +-1.5%和Ftol_sync = +-2%
在收到帧头包含的同步信息(0x55)后，从节点修正自身位速率并不是必须的。

是否修正，取决于从节点自身位速率的精度。

如果从节点可以确保自身位
速率误差低于+-1.5%（或者更普遍些，2% - 主节点位速率误差），就不需要修正。

• Ftol_sl_to_sl = 2%
从节点相互通信时，要提高对从节点位速率误差的要求。

例如，A和B 两个从节点通信，如果A允许误差<+-0.5%，则B允许误差应<+-1.5%（2% - A 的误差）。

公平起见，可以规定A和B的位速率误差<+-1%。

LIN总线学习手记9 –API
此文档全文已经在瑞萨网站发布。

/eng/ products/region/rtcn/mpumcu/apn/r01an0348cc_automotive.pdf -------------- 2007-5-16 -------------------------
写在前面：本篇内容源自我在瑞萨编写的《LIN入门》应用笔记。

该文档尚未正式发布。

作为作者，本人出于结交同行、征求意见的目的，提前发布这个资料。

如需转载，请注明出处。

正文：uploadfile-/2007-8/829269735.rar
摘要：
LIN的API
本章介绍LIN的API的概念、功能和一般用法，并以例子的形式介绍了调用API的一般流程。

本章内容对应LIN规范的以下部分：
LIN Application Program Interface Specification
Freescale在LIN方面有不少开放的资料，不愧是LIN协议的奠基人！LIN0 8和LIN12分别是面向HC08（8位MCU）和HC12（16位MCU）的LIN API 软件包。

这两个包各有2个版本，分别符合LIN 1.3和LIN 2.0。

两个包我都粗略看过，由于FS在LIN 2.0版API开发时放弃了自己的API，采用了“第三方”的API库（怀疑是Mentor的），使API部分成了黑盒子，无法深入研究。

所以，符合LIN 1.3版的更适合学习。

以下是我学习FS的1.3版源代码的心得：
例程简介：
从节点；
功能符合LIN1.3规范, 支持Unconditional 和Sporadic ；
使用了FS自定义的FS API，同时提供符合LIN规范的API供参考；
硬件资源使用ESCI模块及中断，TIM定时器模块及中断。

流程图：uploadfile-/2007-8/88787631.rar
-------------- 2007-8-29 -------------------------
偶然发现瑞萨也免费提供LIN 2.0的API代码，十分感叹，自己身在瑞萨都不能第一时间获得这个消息！叹归叹，立刻看了看，发现瑞萨这个程序的可读性挺好，包含大量详细的代码注释，是学习API实现方法的好教材！
和先前看过的FS LIN相比，感受如下：
•优点1：透明度更高：瑞萨的代码都是.c格式，注释多。

而FS的API封在.lib里（可能来自Mentor Graphic的LCT工具），只在外层留着各种映射，无法深究；
•优点2：标准化，API的定义完全符合LIN协议。

•缺点1：对RAM的利用不如FS节省，甚至可以说是“奢侈”。

•缺点2：硬件资源占用比较多，实现一个主节点需要四个硬件：H W LIN、2个Timer、UART，对应4个中断要处理
•缺点3：公开的部分不支持偶发帧、诊断帧和事件触发帧。

流程图：uploadfile-/2007-8/829529040.rar
-------------- 2007-11-28 -------------------------
提供一个最近发布的LIN 1.3 API，是由日本的一个研究机构TOPPER S开发的。

该API提供2个版本，一个是在RTOS环境下运行，另一个不需要RTOS（见附件）。

最近忙, 详细的分析打算明年1月进行。

源代码：uploadfile-/2007-11/1128642790.rar
-------------- 2008-05-13 -------------------------
英飞凌把LIN的软件划分为“用户代码”和“驱动代码”两部分。

英飞凌提供某些型号单片机的LIN驱动(low-level-driver, LLD)，还提供了一个叫做D AvE的自动代码生成工具，完成用户代码与驱动代码的“关联”。

驱动代码和D AvE都可以免费下载，但是只能找到LIN 1.x版的驱动代码（见应用笔记A160 8613），LIN 2.0版（见应用笔记1610710）的需要单独申请。

值得一提的是，根据应用笔记的介绍，支持LIN 2.0的驱动代码已经通过了权威机构的一致性测试。

除了实用价值，应用笔记本身也有助于理解LIN的网络生成过程。

-------------- 2008-07-09 -------------------------
最近看了看瑞萨的“代码自动生成和组合工具”SANGO所包含的LIN驱动，发现一处设计错误，提醒正在使用该驱动的朋友注意一下。

另外也提出一些我觉得可以改进的点，与朋友们讨论。

这个驱动是用于带有Hardware LIN Module的MCU的，通用性强是一个特色。

目前可以用于R8C/Tiny系列中的22/23/24/25/26/27/2C/2D等型号，稍加改动，新出的34/36/38等型号的MCU也能用。

设计错误：
LIN帧校验和算法不符合LIN规范。

可以提高的部分：
处理好驱动部分的软件状态机，使其在处理完一次通信后能够恢复到就绪状态，继续处理下一个帧。

处理好通信错误/异常，使其在发生通信错误之后，能够在帧结束前恢复到就绪状态，继续处理下一个帧。

在接收ID后，节点应该有2种可能的行为，一个是发送应答，一个是继续接收。

在目前的代码里，除了0x3c这个诊断ID，从节点对其余ID都只做接收。

那么从机什么时候才能给主机发信息？
去掉ID与数据段长度的关联，使其支持LIN 2.x版；
如果要用在汽车电子产品上，需要进行MISRA规则检查。

目前的代码还不符合汽车行业的要求。