第3章 LIN调度表

3、LIN调度表：调度表概念、调度表配置、调度表执行机制、调度表切换

3.1 调度表概念——说白了就是“时间表”

调度表这个概念，我第一次接触时觉得挺玄乎。其实说白了，它就是一张“时间表”。

LIN总线不像CAN那样可以随时抢着发消息。LIN是主从结构，谁什么时候说话，全由主节点说了算。调度表就是主节点手里的“剧本”，规定了每一帧报文在什么时间点发送。

我习惯把调度表理解成一个循环播放的播放列表。每个表项里放着一条报文的ID，主节点按顺序一条条往外扔。扔完了，再从头开始。

核心要点：

调度表是LIN通信的“时间轴”
每个表项指定了要发送的帧ID
主节点严格按照表项顺序执行
执行完最后一个表项，自动跳回第一个

举个例子，一个最简单的调度表可能长这样：

// 伪代码描述调度表
ScheduleTable: DoorControl
  Entry 0: FrameID = 0x01  // 主节点发送车门状态请求
  Entry 1: FrameID = 0x02  // 从节点1回复车门状态
  Entry 2: FrameID = 0x03  // 从节点2回复车窗状态
  Entry 3: FrameID = 0x04  // 主节点发送控制指令
EndScheduleTable

嗯，这里要注意：调度表里的帧ID，对应的是LIN报文标识符。主节点发Header，从节点根据ID决定要不要回复Data。

3.2 调度表配置——我踩过的坑

配置调度表，说白了就是决定“谁在什么时候说话”。

我在项目中遇到过一个问题：某个从节点总是丢数据。查了半天，发现是调度表里给它的时间片太短了。从节点还没处理完上一个指令，下一个Header就来了。

避坑指南：

我曾经因为调度表配置不合理，导致整个LIN网络出现“帧重叠”。两个从节点同时响应，总线直接乱掉。后来我养成了一个习惯：每个表项之间至少留一个帧时隙的余量。

配置调度表时，有几个参数必须搞清楚：

参数	说明	我的建议
帧时隙	每条报文占用的时间	至少留10%余量
帧ID	报文标识符	按优先级排序
从节点响应时间	从节点收到Header到发出Data的时间	实测为准，别信手册
调度表周期	整个表循环一次的时间	必须小于应用层要求的最大延迟

你想想看，如果调度表周期是100ms，但某个传感器要求50ms内更新数据，那肯定出问题。我一般会先算一遍最坏情况下的总线负载率。

3.3 调度表执行机制——主节点在后台默默干活

调度表的执行，其实是主节点内部的一个定时器在驱动。

主节点维护一个“当前表项指针”。每到一个时间点，它就发送当前表项对应的Header。然后等待从节点回复Data。等收完了，或者超时了，指针就移到下一个表项。

执行流程大致是这样的：

主节点读取当前表项
发送Header（包含帧ID）
等待从节点回复Data（最多等一个帧时隙）
如果收到Data，校验并存储
如果超时，记录错误，继续下一个表项
指针+1，如果到末尾则回到0

小技巧：

我习惯在调试时把调度表执行状态通过UART打印出来。这样能直观看到当前执行到哪个表项，哪个从节点没响应。比看逻辑分析仪省事多了。

这里有个容易忽略的点：调度表的执行是“硬实时”的。主节点不会因为某个从节点没响应就停下来等。它严格按照时间槽往前走。所以，从节点如果慢了，数据就丢了。

3.4 调度表切换——从白天模式切换到夜晚模式

调度表切换，说白了就是换剧本。

车上的工况是变化的。比如白天开车门，灯光控制可能不需要；但晚上开车门，阅读灯得亮。这时候就需要切换调度表。

我做过一个项目，车身控制器有3套调度表：

正常模式： 100ms周期，包含所有常规报文
休眠模式： 1000ms周期，只保留唤醒检测报文
诊断模式： 50ms周期，专门用于刷写和诊断

切换调度表时，有个关键点：切换时机。

注意：

我曾经在调度表执行到一半时强行切换，结果导致某个从节点收到了不完整的报文序列，直接死机了。后来我规定：调度表切换只能在当前表执行完最后一个表项后进行。

切换流程一般是这样：

应用层发出切换请求
主节点等待当前调度表执行完最后一个表项
主节点更新调度表指针，指向新调度表的第一个表项
从下一个帧时隙开始，执行新调度表

嗯，这里还要注意：切换调度表时，最好发一个“模式切换”的广播帧。告诉所有从节点：“我要换剧本了，你们做好准备。” 这样从节点可以提前清空缓冲区，避免数据错乱。

总结一下我的经验：

调度表是LIN网络的“交通指挥员”
配置时留余量，别把时间算得太死
执行时主节点要“冷酷无情”，不等任何人
切换时选好时机，别在半路换剧本