📚 课程目录第1章课程导入与学习地图

1. 课程导入与学习地图

各位同学，欢迎来到《嵌入式软件架构》的第一讲。

我做了十几年嵌入式开发，从最早的8位单片机一路做到现在的多核ARM、RISC-V。说实话，这个行业变化太快了。但有一点没变——架构设计始终是决定项目成败的关键。今天咱们就来聊聊嵌入式软件架构的来龙去脉，以及这门课能带给你什么。

嵌入式系统不是一天长成现在这样的。我把它分成四个阶段，每个阶段都对应着不同的软件架构思路。

我刚开始做项目那会儿，用的还是8051。4KB ROM、128字节RAM，写个串口驱动都得抠字节。那时候哪有什么架构？一个main函数里塞满所有逻辑，中断一来就跳转，跳完再回来。说白了，就是“能跑就行”。

后来到了ARM7时代，有了uC/OS-II这样的RTOS。我记得第一次用任务调度的时候，感觉打开了新世界的大门——原来代码可以这么组织！但问题也来了：任务之间怎么通信？驱动怎么分层？ 那时候大家开始摸索，但还没有成熟的套路。

现在呢？一个智能座舱系统里，Linux跑着QT界面，Cortex-M核跑着实时控制，中间还要通过RPMSG通信。软件规模从几千行膨胀到几百万行。没有架构，根本玩不转。

嵌入式软件的架构演进，说白了就是对抗复杂度的过程。我把它总结成三个时代。

这是最原始的状态。所有代码揉在一起，驱动、业务逻辑、协议栈全在一个文件里。优点是简单直接，缺点是牵一发而动全身。

我曾经踩过的坑： 一个智能家居项目，所有代码都在main.c里，大概8000行。客户要改一个LED闪烁频率，结果改出了三个bug——因为定时器中断里同时处理了按键扫描和通信超时。从那以后，我发誓再也不写“大泥球”代码。

分层架构的出现，是嵌入式软件走向工程化的标志。典型的四层模型是这样的：

你想想看，分层之后最大的好处是什么？换硬件不用重写应用。我做过一个项目，MCU从STM32F4换到GD32，只改了HAL层，应用代码一行没动。这就是分层的力量。

分层解决了模块化问题，但层与层之间的耦合还是太紧。组件化更进一步：每个功能模块都是独立的“组件”，有自己的接口契约，可以独立开发、测试、部署。

举个例子，一个物联网终端设备，它的组件可能是：

每个组件都可以单独替换。比如客户要从Wi-Fi换成4G，我只需要换通信组件，其他组件完全不受影响。这才是真正的“高内聚、低耦合”。

    架构演进的核心驱动力： 不是技术本身，而是可维护性和复用性的需求。单体架构适合原型验证，分层架构适合中等规模项目，组件化架构适合产品线化和长期维护。

这门课不是讲理论，而是讲实战。我会带着你从零开始，搭建一个完整的嵌入式软件架构。

我个人习惯把学习路径分成三步走：

我的建议： 每章学完后，一定要动手写代码。光看不练，等于白学。我在每个章节都准备了可运行的示例工程，你可以在STM32或QEMU上直接跑。

下面这张图，是我对嵌入式软件架构的总体理解。它涵盖了从硬件到应用的完整层次，也是我们这门课要覆盖的全部内容。

这张图里，中间件层和驱动封装层是这门课的核心。应用层和硬件层我们也会涉及，但重点放在中间件集成和驱动封装上。性能调优则贯穿所有层次——从硬件配置到应用代码，每一个环节都有优化空间。

我见过太多嵌入式工程师，写了好几年代码，还是停留在“能跑就行”的阶段。遇到问题就加延时、加中断、加全局变量，最后系统变得一团糟。这不是能力问题，是缺少架构思维。

这门课要做的，就是帮你建立这种思维。学完之后，你会：

    一句话总结： 这门课不是教你写代码，而是教你设计代码。从“能跑”到“好改、好扩、好维护”，这就是我们要走的路。