4、LIN总线调度表：调度表的定义、时隙分配、主节点如何控制报文发送顺序

好，咱们今天聊聊LIN总线里一个挺核心的概念——调度表。

说实话，我刚接触LIN的时候，觉得这东西不就是个低速CAN吗？后来做项目才发现，完全不是那么回事。LIN的调度表，说白了就是整个网络的“交通指挥员”。没有它，节点之间就乱套了。

4.1 调度表到底是什么？

调度表，英文叫Schedule Table。它是一张预定义好的表格，存放在主节点里。

这张表规定了：什么时间，由哪个节点，发送哪条报文。

你想想看，LIN总线只有一根线。所有节点都挂在上面。如果大家想发就发，那肯定撞车。所以必须有个“老大”来安排顺序。这个老大就是主节点。它手里的那张表，就是调度表。

我个人习惯把调度表理解成“剧本”。主节点是导演，其他节点是演员。导演按照剧本喊“Action”，演员就按剧本说台词。谁先说，谁后说，说多久，都写得清清楚楚。

4.2 时隙分配——给每个报文一个“时间窗口”

调度表里最关键的参数，就是时隙（Slot）。

每个时隙对应一个报文帧的发送机会。主节点会为每个时隙分配一个固定的时间长度。这个长度必须足够完成一帧报文的完整收发。

一个典型的LIN帧需要多长时间？我算给你看：

• 同步间隔场：至少13个显性位
• 同步场：1个字节
• 标识符场：1个字节
• 数据场：2、4或8个字节（取决于配置）
• 校验和场：1个字节

假设波特率是19.2kbps，数据场是8个字节。那么一帧报文大概需要：

帧长度 = 1(同步间隔) + 1(同步场) + 1(标识符) + 8(数据) + 1(校验和) = 12字节
帧时间 = 12 * 10位/字节 / 19200 bps ≈ 6.25ms

嗯，这里要注意。实际分配时隙时，不能卡着这个理论值算。我在项目中遇到过，有些从节点处理速度慢，或者晶振有偏差。如果你把时隙卡得太死，就会丢帧。

我的建议是：给每个时隙留出20%~30%的余量。比如上面算出来6.25ms，我一般会分配8ms到10ms。

时隙编号	报文ID	数据长度	时隙长度(ms)	发送节点
0	0x01	8字节	10	主节点
1	0x02	4字节	8	从节点1
2	0x03	2字节	6	从节点2
3	0x04	8字节	10	从节点3

4.3 主节点如何控制报文发送顺序？

这个问题问得好。主节点到底是怎么“指挥”的？

其实原理很简单。主节点内部有一个定时器。它按照调度表，一个时隙一个时隙地往下走。

具体流程是这样的：

1. 进入新时隙：主节点的定时器触发，进入时隙0。
2. 发送报头：主节点在总线上发送一个报头（Header）。报头里包含了同步间隔、同步场和标识符。
3. 等待响应：报头发送完后，主节点等待从节点响应。
4. 接收数据：如果这个报文是某个从节点发布的，那个从节点就会自动发送数据场。主节点接收数据。
5. 时隙结束：定时器计时到，时隙0结束。主节点立即进入时隙1。
6. 重复循环：重复步骤2~5，直到调度表走完。
7. 循环执行：调度表走完后，主节点会从头开始，再次执行调度表。如此周而复始。

4.4 调度表的几种常见模式

实际项目中，我们不会只用一张调度表跑到底。那样太死板了。

我常用的模式有这几种：

• 单表循环模式：最简单。一张表，从头到尾循环。适合功能固定的系统，比如简单的灯光控制。
• 多表切换模式：主节点里存了多张调度表。根据系统状态（比如点火开关、车门状态）切换不同的表。举个例子，车门没关时，执行“唤醒调度表”，只发送门锁和车窗相关的报文。车门关了，切换到“正常运行调度表”。
• 条件跳转模式：在调度表里设置条件。如果某个条件满足，就跳转到另一个时隙继续执行。这种模式比较灵活，但实现起来也复杂一些。

4.5 实战中的一点心得

最后，分享一点我个人的经验。

设计调度表时，别光盯着技术参数。你得想想，这个LIN网络最终要服务什么功能？

比如，车窗控制。用户按一下开关，希望车窗立刻动。那车窗相关的报文，就应该放在调度表的前面，并且时隙要短一些。

再比如，车灯状态反馈。这个慢个几百毫秒无所谓。那就把它放在调度表的后面，或者放到一个低频的调度表里。

说白了，调度表的设计，本质上是对系统实时性需求的权衡。你给每个报文分配的时间，就是你对它的“重视程度”。

好了，关于调度表，今天就聊这么多。下一节，咱们聊聊LIN的帧结构，看看报文里到底装了些什么东西。