嵌入式与单片机的分层——硬件能力如何逐层变成应用能力

服务器、CLI、GUI 分层是从「代码职责」出发的；嵌入式程序多了一个根本性的东西——硬件。嵌入式最好不要直接套 Web 那套 Controller / Service / Infrastructure，更自然的是按 硬件 → 驱动 → 系统能力 → 应用 拆。这一条线是拆解与组织原则在嵌入式领域的完整案例：Driver 是接口，RTOS 是框架，Middleware 是子系统，Application 是功能——「分层」在这里不是目录层级，而是硬件能力如何逐层变成应用能力。

一、嵌入式软件的基本分层

1
2
3
4
5
6
7
8
9
10
Embedded System
├── Hardware
├── BSP / Driver
│   ├── GPIO / UART / SPI / I2C / CAN / ADC / PWM / Timer
├── System / Runtime
│   ├── RTOS / Task / Queue / Mutex / Timer / Memory
├── Middleware / Protocol
│   ├── TCP/IP / USB / MQTT / File System / Serialization
└── Application
    ├── Service / Control / State / Algorithm

每一层用「框架 / 接口 / 子系统 / 组件」模型都能对上：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
1. 驱动是硬件的接口
   UART Hardware ↑ UART Driver ↑ Application
   uart.write(data); uart.read(buffer);
   应用不需要知道寄存器、中断号、DMA、时钟、GPIO 复用
   → Driver 本质上是硬件能力的封装接口

2. RTOS 是框架
   FreeRTOS 的 Task / Scheduler / Queue / Semaphore / Mutex / Timer
   应用 create_task(...) 之后，RTOS → Scheduler → 调用 Task
   控制权部分交给 RTOS → 符合「运行框架」而不是单纯的 API 库

3. Middleware 是子系统 / 库
   TCP/IP 协议栈是网络能力库/子系统，Ethernet Driver 是硬件接口
   Application → TCP/IP API → Network Stack → Ethernet Driver → Ethernet Controller

4. Application 才是产品功能（温控器）
   Temperature Sensor → Sensor Driver → TemperatureService
   → ControlAlgorithm → PWM Driver → Heater

嵌入式的「分层」不是简单的目录层级，而是硬件能力如何逐层变成应用能力：硬件 → 驱动接口 → 系统运行能力 → 中间件/协议 → 应用功能。

二、单片机程序的分层（C/C++ 项目）

1
2
3
4
5
6
MCU Application
├── Application    Service / StateMachine / Control / Algorithm
├── Middleware     Protocol / Communication / FileSystem / RTOS
├── Drivers        Sensor / Display / Motor / Storage
├── BSP            GPIO / UART / SPI / I2C / Timer / PWM / ADC
└── Hardware

1. Hardware：物理硬件（不是 C++ 类）

2. BSP / Driver：把硬件封装成接口

应用不应该直接操作寄存器：

1
2
3
4
5
// 不好：UART->DR = ...; UART->CR = ...;
// 好：
uart.write(data);
gpio.set(); gpio.clear();
adc.read();

Driver 的核心作用之一，就是把硬件组件封装成软件接口。

3. Middleware：多个底层组件组装出来的能力

1
2
UART Driver + RingBuffer + Timer + Interrupt → Serial Communication
再往上：UART → Modbus；CAN Protocol；USB；TCP/IP；File System

这里开始出现子系统。

4. RTOS：特殊的运行框架

1
2
3
RTOS：Scheduler / Task / Queue / Semaphore / Mutex / Timer
你的程序：xTaskCreate(...); xQueueSend(...);
然后 RTOS：Scheduler → Task → Task Function

RTOS 不是单纯的硬件接口，而是运行时框架。

5. Application：产品真正的功能

温控器：TemperatureService + ControlAlgorithm + Alarm + DisplayService + StateMachine，数据流：

1
Sensor → Driver → Service → Algorithm → PWM Driver → Heater

6. 没有 RTOS 时 main 承担组装

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
int main()
{
    gpio_init();
    uart_init();
    adc_init();
    sensor_init();
    display_init();

    while (1)
    {
        sensor_update();
        control_update();
        display_update();
        communication_update();
    }
}

此时 main 承担了系统组装和控制流——与服务器里 Server 组装、游戏里 GameApplication 组装是同一件事。

7. 单片机总结图

1
2
3
4
5
6
7
8
9
10
MCU → Hardware
    → BSP/Driver → 底层软件接口
    → Middleware（Protocol / USB / FileSystem）
    → Application（Service / Control / Algorithm）

RTOS 是一条横向的运行基础（Task/Queue/Mutex/Timer/Scheduler），
服务于整个软件，而不是某一个具体业务层：
              RTOS
         ↙      ↓      ↘
      Driver  Middleware Application

三、与服务器对比

1
2
服务器：Socket → Network API → Protocol → Router/Dispatcher → Service → Application
单片机：Hardware → Driver API → Middleware/Protocol → Service → Application

区别是单片机下面多了一层非常重要的 Hardware 以及可能存在的 RTOS。

1
2
服务器缺少的一层（硬件）恰恰是嵌入式分层的第一层；
服务器多的一层（入口解析/分发）在嵌入式里由通信中间件部分承担。

单片机软件最核心的结构：硬件 → 驱动接口 → 中间件/系统能力 → 应用功能；如果使用 RTOS，RTOS 负责整个程序的运行调度。 这比强行套 Controller/Service/Infrastructure 更符合实际结构。

四、这一条线的位置

1
2
3
4
5
6
7
8
9
10
11
12
拆解与组织（主题）：
  01 元原则
  02 边界（在哪切）
  03 游戏拆解与组装（非 ECS 案例）
  04 ECS 与注册机制（运行时组装案例）
  05 只有组件的子系统如何被加载（接口化/框架化落点）
  06 模块-组织与复用
  07 嵌入式与单片机的分层（本线：拆解与组织在嵌入式领域的案例）
  08 Linux 的分层与组装（三种组装：编译期/启动期/注册）
  09 裸机 hypervisor 的系统组织（无 OS 时的完整系统案例）
  10 微服务与组装边界（子系统提升为独立进程）
  11 软件组织知识与四个层次（收束）

本线与 05 的关系：嵌入式里「Driver 是接口」就是接口化、「RTOS 是框架」就是框架化——main 组装是顶层组装，与「入口启动、入口不管理生命周期」一致。

收束

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
嵌入式分层：
  Hardware → BSP/Driver（接口）→ Middleware（子系统）
  → RTOS（框架，可无）→ Application（功能）

每一层的本质：
  Driver     = 硬件能力的封装接口
  Middleware = 多个底层组件组装出的能力（子系统）
  RTOS       = 运行时框架（控制权交给调度器）
  Application= 产品真正的功能（Service/Control/Algorithm）

没有 RTOS 时 main 承担组装和控制流——
  与服务器 Server、游戏 GameApplication 是同一件事

与服务器对比：
  单片机多一层 Hardware + 可能有的 RTOS
  其余分层（驱动接口 → 中间件/协议 → 业务）结构相同

嵌入式的分层 = 硬件能力逐层变成应用能力；Driver 是接口，RTOS 是框架，Middleware 是子系统，Application 是功能。 这是拆解与组织原则在嵌入式领域的完整案例——它验证了「接口化/框架化/子系统/组装」这套概念不依赖操作系统，在裸机上也成立。