电赛小车系列前面十篇，我们把电控的零件一个个磨出来了：电机能听话转、传感器看得见路、PID 能把速度和方向调稳、视觉和主控也能对上话。但这些都还只是”零件”。这一篇，我们要做的是把所有零件焊成一台真正能在赛道上跑的车。

你会发现一个有意思的现象：很多队伍每个模块单测都好好的——电机转得欢、灰度读得准、PID 波形漂亮——可一旦合到一起跑整车，就开始抽风：要么卡死不动，要么时灵时不灵，要么过个十字就冲出去了。问题几乎都不在某个模块本身，而在”怎么把它们组织起来、谁先跑谁后跑、出了岔子怎么兜底”。这就是整车软件架构要解决的事。

这一篇我们讲清四件事：分层（代码怎么摆放）、调度（谁在什么时候跑）、控制环时序（一拍里按什么顺序干活）、状态机（整车行为怎么管），最后再钉一遍贯穿全系列的保护逻辑和那条”机械定上限、软件定下限”的硬道理。吃透这几件事，你的车就从”一堆能动的零件”变成”一台能比赛的车”。

一、分层架构：让你的算法”换芯片不换脑子”

先讲个大白话比喻。写整车软件像点外卖：

这正是逐飞、恩智浦那套智能车开源库多年沉淀下来的标准做法。把代码分成四层，上层依赖下层、下层不知道上层的存在：

以逐飞 SeekFree 库为例，它的真实分层是这样的：

层	逐飞里叫什么	放什么	芯片相关吗
公共层	zf_common	时钟、中断、调试配置	弱相关
驱动层	zf_driver	PWM、PIT 定时中断、编码器、ADC、GPIO、UART、SPI	强相关
设备层	zf_device	摄像头、陀螺、编码器、屏的初始化和应用函数	弱相关
应用层	你自己写的 code	状态机、循迹决策、串级 PID 调用	无关

中间件层（PID、滤波、协议、元素识别）这些纯算法，本质上和芯片没有任何关系——它们只是数学，搬到任何平台上都一样跑。

一条必须刻进脑子的铁律

这条铁律还是用打比方理解最快：

为什么值得花这个力气分层？ 因为它直接决定了你前面那些功夫能不能”白嫖”过来。整车搭建那一篇讲过”STM32 练手、MSPM0 比赛”的策略，分层就是这套策略能成立的根。看一组实打实的证据：同一套逐飞库，社区已经移植到了 RT1064、英飞凌 TC264、STC32G144K，甚至 2025 年 TI 板电赛用的 MSPM0G3507。这些版本的 App 层和算法层几乎一字不改，差异全部集中在底层驱动。

想找范本直接抄结构的，推荐 Sakuramdd/SeekFree_RT1064_Opensource_Library，标准三层加上 code 目录（image / control / init），是研究分层与解耦最干净的样本。STM32 与 MSPM0 之间具体怎么对应 API、平移时要注意什么，整车搭建那一篇已经给过对照心法，这里不展开。

二、调度：电赛首选”前后台裸机”，别动不动就上 RTOS

代码摆好了，下一个问题是：这么多任务——读传感器、跑 PID、刷屏、收视觉数据——谁在什么时候跑？这叫调度。常见的有三档，我们从简单到复杂排一下。

第一档：前后台裸机（电赛首选）

这是最常见、最可预测的方案，也是绝大多数电赛车的选择。结构极简：

把这套结构画出来就是：

第二档：时间片轮询

如果你有好几个不同周期的任务（控制环 5ms、读视觉 20ms、刷屏 100ms），可以用一个简单的时间片调度器：用一个 1ms 的定时器统一递减计时，到点就给任务打个”该跑了”的标记，主循环看到标记再去执行。

// 时间片轮询调度器：一个 1ms 的 tick 管多周期任务
typedef struct { uint16_t period, timer; uint8_t run; void(*task)(void); } Task_t;

Task_t tasks[] = {
    {5,   5,   0, Control_Loop},  // 5ms：  控制环
    {20,  20,  0, Read_Vision},   // 20ms： 收视觉
    {100, 100, 0, Update_OLED},   // 100ms：刷屏
};
#define N (sizeof(tasks) / sizeof(tasks[0]))

void SysTick_Handler(void) {          // 1ms tick
    for (int i = 0; i < N; i++) {
        if (tasks[i].timer == 0) { tasks[i].timer = tasks[i].period; tasks[i].run = 1; }
        else tasks[i].timer--;
    }
}

int main(void) {
    Init();
    while (1)
        for (int i = 0; i < N; i++)
            if (tasks[i].run) { tasks[i].run = 0; tasks[i].task(); }
}

这其实是前后台的”加强版”，介于裸机和 RTOS 之间——能管多个不同周期的任务，但仍然透明可控、没有调度器的黑盒。

第三档：RTOS（FreeRTOS / RT-Thread）

只有当任务真的多、真的需要并发的时候才上 RTOS。它的代价不小：

RTOS	内核占用	特点
FreeRTOS	4~9 KB	抢占/协作/时间片可选，支持 30+ 架构，tickless 低功耗
RT-Thread	最小 3K ROM / 1K RAM	基于优先级全抢占、256 优先级 O(1) 调度、自带 TCP/IP
µC/OS-III	6~24K 代码 + 1K 数据	任务数无限、文档全

电赛如果真要上 RTOS，主流就是 FreeRTOS 和 RT-Thread 这两个。

那到底该不该上 RTOS？

更具体地说，宁可用周期性裸机也不上 RTOS 的理由有三条，都很实在：

• 确定性：定时器中断直接管任务，没有 RTOS 那套调度算法和优先级反转，固定周期任务给你严格的时序保证，最坏执行时间也好分析。
• 低开销：省掉内核那几 KB 的 ROM/RAM，省掉每个任务的控制块（TCB）。
• 易验证：任务少（三五个）时，状态机比多线程透明得多，不会有死锁、没有同步 bug。

记住一句话：RTOS 是给”任务多到管不过来”准备的解药，不是给整车软件撑场面的装饰品。

三、控制环时序：5ms 一拍，按死顺序干活

调度定好了，现在聚焦最核心的那个”前台”——控制环。它跑在定时器中断里，是整车的心跳。

为什么是 5ms（也就是 200Hz）？这是智能车社区多年试出来的甜点：够快，能保证控制平滑；又不至于太快，给中断里的计算留足时间。背后有个定量依据——采样定理（Nyquist）：采样频率要大于被控信号变化频率的 2 倍，才不会”漏看”信号的变化。小车的动态没那么快，5ms 一拍绰绰有余。

STM32 上配一个 5ms 中断很简单：在 72MHz 主频下，预分频 PSC = 72（把计数时钟降到 1MHz，即 1µs 一格）、重装载 ARR = 5000（数 5000 格就是 5ms），就是精确的 5ms。

一拍里的标准流程

中断一进来，按这个顺序走，一步都不能乱：

落成代码骨架就是这样（前后台架构里的”前台”）：

// PIT / TIM 5ms 中断 —— 固定周期控制环（前台）
void TIM3_IRQHandler(void) {
    if (TIM_GetITStatus(TIM3, TIM_IT_Update)) {
        TIM_ClearITPendingBit(TIM3, TIM_IT_Update);

        // 1) 采集：读编码器测速，读完立刻清零
        int16_t el = Read_Encoder(L); Clear_Encoder(L);
        int16_t er = Read_Encoder(R); Clear_Encoder(R);
        IMU_Read(&gyro, &acc);

        // 2) 融合：互补滤波出姿态角
        float ang = Complementary_Filter(acc, gyro, 0.005f);

        // 3) 串级 PID：外环速度 → 内环转向
        int16_t ps = Speed_PI(target, (el + er) / 2);   // 外环：速度
        int16_t pt = Turn_PD(line_err, gyro.z);         // 内环：转向

        // 4) 输出：差速 + 限幅后写 PWM
        Set_Motor(LIMIT(ps - pt, -7200, 7200),
                  LIMIT(ps + pt, -7200, 7200));

        // 5) 保护：视觉超时则降级，绝不盲冲
        if (++vision_timeout > VTO) Set_Motor_Safe();
    }
}

内环必须比外环快

讲串级 PID 时埋过一个伏笔，这里再钉一遍：

所以控制环里的铁律是：内环周期 ≤ 外环周期，且内环先调稳。外环的输出是内环的目标，内环都晃晃悠悠，外环再准也没用。具体的调参顺序（先内后外、先 P 后 I 再 D、看波形治百病）在 PID 入门、PID 进阶和 PID 调参实战那几篇已经讲透了，这里只强调时序关系。

最容易踩的两个时序坑

顺手补一个：传感器进 PID 前先滤波

采集到的编码器、陀螺数据有高频噪声，直接喂给 PID 的 D 项会被 Kd 放大成持续抖动。一个又便宜又好用的办法是一阶低通：

// 一阶低通：新值占 0.3，旧值占 0.7，平滑又便宜
Encoder = Encoder * 0.7f + new_value * 0.3f;

融合姿态角同理。互补滤波是工程上最常用的：

// dt = 0.005s；0.98 越大 => 越信陀螺（高通）
float Complementary_Filter(float acc_ang, float gyro_rate, float dt) {
    static float angle = 0;
    angle = 0.98f * (angle + gyro_rate * dt) + 0.02f * acc_ang;
    return angle;
}

四、状态机：把整车行为拆成”一次只演一个角色”

控制环管的是”这一拍怎么打方向”，但整车在赛道上还有更宏观的行为切换：在起跑线待命、起步加速、跑直道、过弯道、到了十字路口要决策、到终点要精确停靠、丢线了要找回、出意外要急停……这些行为怎么管？答案是有限状态机（FSM）。

这就是状态机最大的价值：降耦合、易调试。把复杂行为拆成独立状态，每个状态只管单一功能。智能车国赛代码多年都用状态机管理直道、弯道、十字、丢线、急停；自动驾驶的行为规划也用分层有限状态机（HFSM），状态名都很像，比如 FORWARD_DRIVE、STOP_SIGN_WAIT、CROSS_INTERSECTION。

整车主状态机骨架

注意急停（ESTOP）能从任何状态进入——这是最高优先级，下面代码里会体现（图里只画了几条代表线，实际是所有状态都能转）：

typedef enum {
    ST_IDLE, ST_START, ST_STRAIGHT, ST_CURVE,
    ST_CROSS, ST_PARK, ST_LOST, ST_ESTOP
} CarState;

CarState st = ST_IDLE;

void State_Machine(void) {
    if (estop_flag) { st = ST_ESTOP; }   // 急停最高优先级，先判
    switch (st) {
        case ST_IDLE:     if (start_btn) st = ST_START;       break;
        case ST_START:    if (moving)    st = ST_STRAIGHT;    break;
        case ST_STRAIGHT: if (is_cross())      st = ST_CROSS;
                          else if (is_curve()) st = ST_CURVE;
                          else if (line_lost)  st = ST_LOST;  break;
        case ST_CURVE:    if (!is_curve())     st = ST_STRAIGHT;
                          else if (line_lost)  st = ST_LOST;  break;
        case ST_CROSS:    Cross_FillLine();
                          if (passed) st = ST_STRAIGHT;       break;
        case ST_LOST:     Recover_ByLastError();
                          if (line_found) st = ST_STRAIGHT;   break;
        case ST_PARK:     Precise_Stop();                     break;
        case ST_ESTOP:    Set_Motor(0, 0);                    break;
    }
}

状态机最容易写错的地方

五、保护逻辑：能拿分的车，先得是”摔不死”的车

开篇那一篇讲过电赛的拿分逻辑——有一堆”失败即 0 分”的红线（冲出赛道、超时等等）。所以整车软件里，保护逻辑不是锦上添花，而是保命。前面控制环代码里那行 if (++vision_timeout > VTO) Set_Motor_Safe(); 就是保护段的入口。这里展开两个最关键的。

视觉超时降级：信号断了别闭眼猛踩

这是新手最容易忽略、又最容易翻车的地方。注意一个事实：摄像头帧率（60~100Hz）远低于控制环（200Hz）。也就是说，控制环跑两三拍，视觉才更新一帧。如果某一拍没有新帧，或者连续丢线超过阈值了，你绝不能拿过期的、无效的图像去盲控。

具体做法：设一个看门狗 / 超时计数器，每来一帧新数据就清零，控制环每拍 +1。超过阈值就降级——保持上一个有效打角、减速或限速直行；严重时直接急停。阈值各队按自己车的特性定。视觉那一篇也讲过同款思路：通信超时（比如超过 100ms 没收到包）就降级到灰度或 IMU 兜底，两处其实是一回事。

丢线找回：记住”最后看见路的方向”

丢线之后怎么回到赛道？核心思路是记忆最后一次有效偏差：

• 设一个 last_error，没丢线时持续更新它；
• 一旦判定丢线，就冻结这个值；
• 用冻结的偏差判断车是往哪边出去的，据此朝相反方向打角，把车拽回赛道。

判丢线常用”全行扫描”：从图像底部往上扫，一直扫到最上面一行还找不到赛道边界，就判为丢线。

六、一条贯穿始终的硬道理：机械定上限，软件定下限

最后，讲一个比任何代码都重要的认知，来自哈工大紫丁香队的血泪经验：

他们有两个特别值得记的故事：

还有一条赛场铁律，宁可多说一遍：

想找完整工程当范本？

光看片段不过瘾，下面几个开源仓库可以拿来研究整车是怎么组织的：

• Sakuramdd/SeekFree_RT1064_Opensource_Library：逐飞 RT1064 视觉组开源库，标准三层 + code(image/control/init)，研究分层与解耦的最佳范本。
• woai66/SeekFree_MSPM0G3507_Opensource_Library：逐飞库移植到 TI MSPM0G3507，直接对应 TI 赛道，是芯片解耦平移的活样本。
• Jerrysupreme/XJTU-VISON_SMARTCAR_2025：西安交大 2025 智能视觉组完整参赛级工程，底盘 RT1064 + 摄像头，学整车怎么组织。
• Blight001/SmartCarCameraTrackingSimulation：Unity 做的赛道仿真，10 款赛道含国赛道，还能逐帧回溯复盘”为什么冲出赛道”——没硬件时调循迹、调参、复盘的神器。
• hxk55668/PID_CAR-STM32-FREERTOS-：想用 FreeRTOS 组织控制/通信/显示任务的，可以参考这个。

更全的开源清单和现场调试速查表，留到下一篇集中给。

小结：把这一篇钉进脑子

到这里，整车软件的骨架就立起来了。回顾一下这几条心法：

• ☐ 分层：App / 中间件 / Driver / HAL 四层，上层只调下层、下层不反调，设备层禁碰芯片 API——换芯片只改驱动层。
• ☐ 调度：电赛首选前后台裸机（主循环跑慢任务 + 定时器中断跑控制环），任务真多了再考虑 RTOS。
• ☐ 控制环：5ms 一拍（200Hz），按”采集→融合→串级 PID→输出→保护”死顺序走，内环快于外环，ISR 只做核心、耗时操作甩主循环。
• ☐ 状态机：把整车行为拆成独立状态，急停最高优先级、等待型状态都要超时退出。
• ☐ 保护：视觉超时降级、丢线记忆找回、出界急停——保命优先。
• ☐ 认知：机械定上限、软件定下限；传感器上场前必标定。

软件框架搭好了，但真正决定你能不能拿奖的，是四天三夜里在赛场上把它跑稳、调好、不翻车。下一篇现场作战手册，我们就聊聊四天三夜怎么安排、调试怎么避坑、以及哪些开源仓库值得你现在就 star。