📚 课程目录第3章分层架构基础

分层架构基础：驱动层、中间件层、业务层

很多刚入行的朋友问我，单片机代码到底该怎么组织？说实话，我早年也吃过不少苦头。一个项目写下来，main函数里上千行，GPIO和定时器配置混在一起，算法逻辑和硬件操作搅成一锅粥。后来改个LED闪烁频率，结果把整个系统的时序都搞崩了。

为什么会这样？说白了就是没有分层。

分层架构不是什么高深理论，它就是一套代码组织的规矩。我做了十几年嵌入式，从8位机到Cortex-M系列，项目越复杂，越觉得分层是救命稻草。今天咱们就聊聊这三层：驱动层、中间件层、业务层。

  核心观点：分层不是为了炫技，是为了让代码可维护、可移植、可测试。你想想看，一个产品要迭代三五年，底层芯片换了，上层逻辑不变，这时候分层的好处就出来了。

驱动层是离硬件最近的一层。它直接操作寄存器、处理中断、配置外设。说白了，它就是硬件和软件之间的翻译官。

驱动层的职责很明确：

我记得有一次做电机驱动项目，芯片从STM32F1换到GD32。如果驱动层封装得好，只需要改底层寄存器操作，上层代码一行不动。但当时我偷懒，把GPIO操作直接写在业务逻辑里……结果换芯片时，改了整整三天。

我的习惯：驱动层只做一件事——把硬件能力抽象成函数接口。比如 spi_send_byte()、gpio_set_level()，绝不掺和业务判断。

中间件层夹在驱动和业务之间。它不直接操作硬件，也不处理具体业务，而是提供一些通用服务。

常见的中间件包括：

中间件层的核心价值在于复用。你想想看，一个Modbus协议栈，不管底层是用UART还是SPI，协议解析的逻辑是一样的。中间件层把这种通用逻辑抽出来，换个平台照样用。

我曾经在一个项目里自己手写了一个环形缓冲区，后来发现FreeRTOS自带的消息队列完全够用。嗯，这就是中间件层的意义——别重复造轮子，除非你想练手。

业务层是产品逻辑的所在地。它决定系统做什么、什么时候做、怎么做。

业务层的典型内容：

业务层应该只关心逻辑，不关心硬件细节。比如“温度超过50度就打开风扇”，业务层只需要调用 fan_on()，至于风扇是GPIO控制还是PWM控制，那是驱动层的事。

避坑指南：我曾经见过一个项目，业务层里直接写寄存器地址。结果硬件改版后，寄存器地址变了，业务代码全得重写。记住：业务层永远不要出现硬件相关的宏定义或寄存器操作。

依赖关系是分层的灵魂。规矩很简单：上层依赖下层，下层不依赖上层。

层级	依赖谁	被谁依赖	能否独立测试
业务层	中间件层、驱动层	无	需要Mock下层接口
中间件层	驱动层	业务层	可独立测试
驱动层	无	中间件层、业务层	需要硬件环境

这个依赖方向不是随便定的。你想想看，如果驱动层依赖了业务层，那换个业务场景，驱动层也得跟着改，这还叫什么分层？

我个人的做法是：在代码里用接口指针或者回调函数来解耦。比如驱动层提供一个 uart_rx_callback 注册函数，中间件层注册自己的处理函数。这样驱动层完全不知道上层是谁，只管收数据、调回调。

拿一个温控系统来说：

如果哪天要把DS18B20换成NTC热敏电阻，只需要改驱动层，中间件层的PID算法和业务层的控制逻辑完全不用动。这就是分层带来的好处。

  关键原则：每一层只做自己的事，不越界。驱动层别去判断业务逻辑，业务层别去操作寄存器。这个界限划清楚了，代码质量自然就上去了。

下面这张图展示了三层架构的依赖关系和典型内容。你可以看到箭头方向是从上层指向下层，下层对上层一无所知。

我见过不少团队，嘴上说分层，实际写出来的代码还是乱的。这里列几个常见问题：

我的建议：刚开始做分层时，先画一张依赖关系图。把每个模块的接口列出来，看看箭头方向对不对。这个习惯我一直保持到现在，能避免很多后期返工。

驱动层管硬件，中间件层管通用服务，业务层管产品逻辑。三层之间单向依赖，上层调用下层，下层对上层一无所知。

这个架构不是银弹，但它能解决80%的代码混乱问题。你想想看，一个项目动辄几万行代码，没有分层，后期维护就是噩梦。我早期踩过的坑，希望你能绕过去。