4、LIN总线协议层（二）：报文调度表（Schedule Table）与帧时隙（Frame Slot）机制

好，咱们接着聊LIN总线的协议层。上一章我们把帧的结构、字节场、校验这些基础概念过了一遍。这一章要聊的，是LIN总线里一个非常核心的调度机制——报文调度表和帧时隙。

说白了，LIN总线为什么能这么稳定、这么低成本地跑在20kbps的速率上？靠的就是这套严格的时间调度机制。你想想看，CAN总线是事件触发的，谁抢到总线谁说话。但LIN不一样，它是主从结构，时间触发。什么时候该发什么报文，都是提前规划好的。

4.1 报文调度表（Schedule Table）是什么？

报文调度表，英文叫Schedule Table。我个人习惯叫它“时刻表”。它就像火车站的列车时刻表一样，规定了什么时间点（或者说在哪个时隙），主节点应该发送哪个帧头，哪个从节点应该响应。

一个调度表由若干个帧时隙（Frame Slot）组成。每个帧时隙里，只做一件事：主节点发一个帧头，对应的从节点发一个帧响应。一个时隙结束，下一个时隙开始，依次执行。

我举个例子，一个典型的LIN调度表可能长这样：

Schedule Table: "NormalOperation"
  Slot 0: Frame ID = 0x01 (车速信号)  -> 从节点1响应
  Slot 1: Frame ID = 0x02 (车门状态)  -> 从节点2响应
  Slot 2: Frame ID = 0x03 (灯光控制)  -> 从节点3响应
  Slot 3: Frame ID = 0x04 (空调状态)  -> 从节点4响应
  Slot 4: Frame ID = 0x05 (诊断请求)  -> 从节点5响应
  ... 循环执行

嗯，这里要注意：调度表是可以循环执行的。执行完最后一个时隙，自动回到第一个时隙重新开始。这就是LIN总线“确定性”的来源——每个报文都有固定的发送周期。

4.2 帧时隙（Frame Slot）的组成

每个帧时隙，在时间轴上占据一段固定的时间。这个时间长度由三部分组成：

• 帧传输时间：发送一个完整帧（帧头+响应）所需的时间。取决于数据长度和波特率。
• 帧间间隔：两个帧之间的空闲时间，至少需要几个位的间隔。
• 响应空间：从节点收到帧头后，准备响应数据的时间。这个时间由从节点的处理能力决定。

我记得在早期的一个项目中，有个同事把响应空间算得太紧了。结果从节点还没来得及把数据准备好，主节点就已经超时了。嗯，从那以后我设计时隙长度时，都会留出至少20%的余量。

4.3 调度表的执行规则

调度表的执行，说白了就是主节点在“打拍子”。主节点内部有一个定时器，每到一个时隙的起始时刻，它就发送一个帧头。然后等待从节点响应。如果从节点没响应，主节点会怎么做？

这里有个关键点：LIN协议规定，如果从节点没有响应，主节点不会重发。它直接进入下一个时隙。为什么？因为LIN总线追求的是“确定性”，而不是“可靠性”。你想想看，如果主节点一直重发，整个调度表就乱套了。后面的报文全都会延迟。

我曾经在一个项目中遇到过这种情况：某个从节点偶尔会丢帧，导致主节点收不到响应。但调度表依然在跑，其他节点不受影响。这就是LIN总线的容错设计——单个节点故障，不影响整个网络的时间确定性。

4.4 多调度表切换

一个LIN网络里，可以定义多个调度表。比如：

• 正常模式调度表：循环发送常规信号，如车速、车门状态等。
• 诊断模式调度表：专门用于诊断通信，发送诊断请求和响应。
• 休眠模式调度表：只发送唤醒帧和休眠帧，其他时间总线空闲。
• 配置模式调度表：用于从节点的初始配置和参数设置。

主节点可以在运行过程中，动态切换调度表。比如，当诊断工具连接时，主节点从“正常模式调度表”切换到“诊断模式调度表”。诊断结束后，再切回来。

4.5 帧时隙的时序计算

咱们来算一个实际的例子。假设LIN总线波特率为20kbps，一个帧包含：

• 帧头：同步间隔场(13位) + 同步场(1字节) + 标识符场(1字节) = 13 + 8 + 8 = 29位
• 帧响应：数据场(假设4字节) + 校验和场(1字节) = 32 + 8 = 40位
• 帧间间隔：4位
• 响应空间：4位

总位数 = 29 + 40 + 4 + 4 = 77位
总时间 = 77 / 20000 = 3.85ms

所以，每个帧时隙至少需要3.85ms。实际设计中，我一般会取整到4ms或5ms，方便定时器配置。

// 伪代码示例：调度表执行逻辑
void ScheduleTable_Execute(void)
{
    uint8_t slotIndex = 0;
    while(1)
    {
        // 获取当前时隙的帧ID
        uint8_t frameID = scheduleTable[slotIndex].frameID;
        
        // 主节点发送帧头
        LIN_SendHeader(frameID);
        
        // 等待从节点响应（带超时）
        if(LIN_WaitResponse(timeout) == SUCCESS)
        {
            // 处理接收到的数据
            ProcessReceivedData(frameID);
        }
        else
        {
            // 超时处理：记录错误，继续下一个时隙
            LogError("Frame timeout: ID = 0x%02X", frameID);
        }
        
        // 进入下一个时隙
        slotIndex++;
        if(slotIndex >= SCHEDULE_TABLE_SIZE)
        {
            slotIndex = 0;  // 循环
        }
        
        // 等待时隙结束
        WaitForSlotEnd();
    }
}

4.6 避坑指南

最后，我分享几个实际项目中踩过的坑：

• 时隙长度不一致：不同帧的数据长度不同，时隙长度也要不同。比如，1字节数据的帧和8字节数据的帧，传输时间差很多。如果统一用一个时隙长度，要么浪费带宽，要么不够用。
• 调度表切换时机：我曾经在切换调度表时，没有等待当前时隙结束，结果导致一个不完整的帧被发送出去，整个总线都乱了。后来我加了一个“切换等待标志”，确保切换只在时隙边界发生。
• 从节点响应超时：有些从节点在初始化阶段，响应时间会变长。如果调度表里的响应空间留得太短，就会频繁超时。我建议在从节点上电后的前几个周期，适当放宽超时时间。

下一章，咱们聊聊LIN总线的诊断协议和休眠唤醒机制。到时候我会结合一个实际的车门控制项目，把整个通信流程串起来讲。敬请期待。