LIN总线学习手记1
* LIN概况
LIN（Local Interconnect Network）是一种面向汽车用低速网络的单主多从、异步串行总线标准，定位于需要互连但不需要强调实时性和可靠性的部件，作为CAN网络的补充和末梢。目标是以低廉的价格联接车上的传感器、执行器和处理器，并且允许不同厂家的模块随时添加进来。LIN目前不但用于多种型号的汽车上，而且日益广泛地用在智能传感器领域。
* LIN组织核心成员
www.lin-subbus.org
5个车厂+1个半导体公司+1个测试工具公司。A(udi)，B(MW)，DC(戴克)，V(olvo)，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口线模拟异步串口。成本最低，但CPU负担最重，代码最多。
SCI+Timer方法：就是利用UART硬件和Timer组合。成本适中，CPU负担减轻。
专门LIN模块：由功能完备的LIN模块完成通信。成本较高，CPU负担最轻，代码最少。
* LIN的接口
+12V 单端非平衡信号。最高通信速率20kbps。
主节点输入阻抗1K，从节点30K。
LIN总线学习手记2
* LIN的前生今世与来生
源自ISO9141；目前是LIN 2.0和1.3并行发展，很快就要兼容24V电源系统；未来可能会变成SAE J2602。
*LIN的竞争对手
按照SAE的分类法，10K以下是A类网，125K以上是C类网，中间是B类网。LIN属于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后要开始支持ISO15765。目前的诊断仪，其物理层和数据链路层仍然是ISO9141-1或者ISO14230-1之类（看过标准之后发现，除了不能支持24V系统，最高速度在20K，其余指标LIN可胜任）。未来的ISO15765将选择ISO118规定的CAN作为物理层和数据链路层，那时候，天生作为CAN子网的LIN就体现出它的“嫡系”价值了。
当然，LIN只是定义了OSI的下三层，高层协议是继续使用ISO14230-2/3还是ISO15765-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节点的硬件规格有关，不能简单挪用。这是由于为了适应不同形式的LIN控制器硬件（SLIC、 SCI和Bit-Bang），API通常会内置硬件驱动程序。驱动程序针对特定的硬件进行了优化，是API不可分割的组成部分，LIN规范没有对驱动程序进行规定。这些因素决定了API也与硬件规格有关，不同的硬件平台应使用各自的API。
API的类别
LIN的API按照用途可分为3类，分别是核心API、传输层API和节点配置与识别API。三类API相对又彼此关联。
核心API是连接应用层与硬件电路的桥梁，协议层的所有工作都在这里实现，是API的基础。核心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个PDU，
格式从信息处理的角度来看，传输层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
此文档全文已经在瑞萨网站发布。http://documentation.renesas.com/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协议的奠基人！LIN08和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：硬件资源占用比较多，实现一个主节点需要四个硬件：HW LIN、2
个Timer、UART，对应4个中断要处理
•
缺点3：公开的部分不支持偶发帧、诊断帧和事件触发帧。
流程图：uploadfile-/2007-8/829529040.rar -------------- 2007-11-28 -------------------------
提供一个最近发布的LIN 1.3 API，是由日本的一个研究机构TOPPERS开发的。该API提供2个版本，一个是在RTOS环境下运行，另一个不需要RTOS（见附件）。
最近忙, 详细的分析打算明年1月进行。
源代码：uploadfile-/2007-11/11282790.rar -------------- 2008-05-13 -------------------------
英飞凌把LIN的软件划分为“用户代码”和“驱动代码”两部分。英飞凌提供某些型号单片机的LIN驱动(low-level-driver, LLD)，还提供了一个叫做DAvE的自动代码生成工具，完成用户代码与驱动代码的“关联”。驱动代码和DAvE都可以免费下载，但是只能找到LIN 1.x版的驱动代码（见应用笔记A1608613），LIN 2.0版（见应用笔记161071
0）的需要单独申请。
值得一提的是，根据应用笔记的介绍，支持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规则检查。目前的代码还不符合汽车行业的要求。
