1、课程导论：为什么需要分层架构？嵌入式软件的痛点与挑战。

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

先问大家一个问题：你手头的嵌入式项目，代码量到多少行开始让你头疼？

我个人的经验是，当项目超过 5 万行 C 代码，或者团队超过 3 个人同时维护同一个 MCU 工程时，混乱就会成为常态。今天这堂课，我们就来聊聊嵌入式软件最真实的痛点，以及为什么分层架构是解决这些问题的关键。

1.1 嵌入式开发的“三座大山”

我在这个行业摸爬滚打了十几年，见过太多项目从“跑起来就行”变成“改不动了”。说白了，嵌入式软件有三大天生的痛点，几乎每个工程师都会遇到。

1.2 为什么“裸奔”架构走不远？

很多初学者喜欢用“超级循环”架构——一个大 while(1) 里塞满所有功能。你想想看，这种架构有什么问题？

// 典型的“裸奔”架构
int main(void) {
    HAL_Init();
    while(1) {
        // 读取传感器
        sensor_value = read_sensor();  // 直接操作 I2C 寄存器
        // 处理数据
        if(sensor_value > THRESHOLD) {
            // 控制执行器
            HAL_GPIO_WritePin(RELAY_GPIO_Port, RELAY_Pin, GPIO_PIN_SET);
        }
        // 显示
        display_show(sensor_value);  // 直接操作 LCD 时序
        delay_ms(100);
    }
}

这种代码，跑起来没问题，改起来要命。为什么？

• 职责不分：传感器读取、业务判断、显示输出全混在一起
• 移植困难：换个 LCD 屏幕，整个显示逻辑都要改
• 无法测试：你想单独测试阈值判断逻辑？必须接上传感器和继电器

1.3 分层架构：把混乱变成秩序

分层架构不是什么新概念。说白了，就是给代码划分“楼层”。每一层只做自己的事，层与层之间通过接口通信。

我习惯把嵌入式软件分成三层：

1. 应用层：业务逻辑、状态机、算法
2. 中间层：操作系统抽象、文件系统、协议栈
3. 硬件抽象层：MCU 驱动、外设驱动、BSP

下面这张图，就是本课程的核心架构模型：

1.4 分层架构带来的实际收益

说了这么多理论，我们来看看分层架构到底能带来什么实实在在的好处。

1.5 本课程的学习路径

这门课一共 30 章，我们会从最基础的分层概念讲起，逐步深入到实战。

• 基础篇：分层架构的核心原则、接口设计、模块划分
• 实战篇：用真实项目案例，一步步搭建分层架构
• 进阶篇：多任务、低功耗、安全性与测试策略

嗯，这里要提醒大家：不要指望一节课就学会所有东西。架构能力是靠“踩坑”积累出来的。我会在每节课里分享我踩过的坑，你们少走弯路就好。