第一章：课程导论与全景图——为什么嵌入式软件需要架构重构？

各位工程师朋友，咱们直接开门见山。

做了十几年嵌入式，我见过太多项目从“能跑就行”一步步走到“改一行代码崩三个功能”的境地。说实话，这不是代码写得烂，而是架构从一开始就没想清楚。今天这第一讲，我想跟你聊聊三个核心问题：为什么非得重构？实时性到底在争什么？解耦到底图什么？

1.1 为什么嵌入式软件需要架构重构？

先讲个我自己的经历。几年前我接手一个车载控制器的项目，代码量大概30万行，全是裸机加中断写的。功能倒是都能跑，但每次加一个新传感器，就得翻遍整个main.c去改中断优先级、调整时序。有一次客户要求增加一个CAN报文转发功能，我算了算，至少要动7个模块的接口。嗯，那个周末我是在调试器前度过的。

你想想看，这种“牵一发而动全身”的滋味，是不是很熟悉？

嵌入式软件需要重构，根本原因就三个：

• 硬件迭代太快——芯片从单核变多核，外设从SPI变PCIe，老架构根本跑不满新硬件。
• 需求越来越复杂——以前一个MCU控制一个电机，现在要同时处理传感器融合、网络通信、OTA升级。
• 团队协作成本爆炸——模块之间耦合得像一团意大利面，新人入职三个月还不敢改代码。

1.2 实时性优化的核心矛盾是什么？

实时性，说白了就是“在规定时间内必须干完活”。但这里有个天然矛盾——确定性 vs. 吞吐量。

我举个例子。一个电机控制任务，要求每1ms执行一次，误差不能超过50μs。这是硬实时。但如果你同时还要跑一个TCP/IP协议栈，它可能偶尔会占用CPU几百微秒去处理重传。这时候怎么办？

你可能会说：“把中断优先级调高不就行了？”嗯，没那么简单。中断嵌套多了，低优先级任务可能永远得不到CPU时间——这叫优先级反转。我在一个工业控制项目里就踩过这个坑，一个低优先级的温度采集任务被高优先级的中断反复抢占，结果温度数据每5秒才更新一次，差点导致过热保护失效。

实时性优化的核心矛盾，其实就一句话：如何在保证最坏情况执行时间（WCET）的前提下，最大化系统吞吐量？

维度	硬实时	软实时
截止时间错过后果	系统崩溃/安全事故	性能下降/用户体验差
典型场景	刹车控制、航空电子	多媒体播放、人机交互
调度策略	优先级抢占+时间触发	CFS/EDF 可接受少量抖动
我常用的分析工具	WCET分析 + 中断延迟测量	响应时间分布统计

1.3 模块解耦的终极目标

模块解耦，听起来很抽象。其实说白了就是：让每个模块只关心自己的事，别管别人怎么实现。

我见过最典型的反面教材是什么？一个驱动函数里直接调用了业务逻辑的全局变量。比如：

// 错误示范：驱动层直接访问业务数据
void uart_isr(void) {
    if (UART->DR & 0x80) {
        extern uint8_t g_temperature_buffer[256];
        g_temperature_buffer[g_temperature_index++] = UART->DR;
    }
}

这种代码，一旦业务逻辑要改缓冲区大小或者存储方式，你就得去翻中断服务程序。你说危不危险？

模块解耦的终极目标，我认为有三个层次：

1. 编译期解耦——修改一个模块不需要重新编译其他模块。用接口抽象、依赖注入来实现。
2. 运行期解耦——一个模块崩溃不会拖垮整个系统。用任务隔离、看门狗、健康管理来实现。
3. 团队协作解耦——A组写驱动，B组写业务，两边只需要对齐接口文档。用契约式设计来实现。

1.4 本章知识体系全景图

下面这张图，是我对本章核心逻辑的总结。你可以把它当作整个课程的导航地图。

这张图其实就讲了一件事：硬件、需求、团队这三座大山压下来，你只有通过架构重构、实时优化、模块解耦这三把刀，才能把系统从“能跑就行”变成“好改、好测、好维护”。