在实际嵌入式项目中，很多开发者会陷入一个误区：认为嵌入式开发就是“单片机编程”，只要功能能跑起来，代码堆在一起也无所谓。然而，当项目规模从简单的LED闪烁扩展到需要处理网络通信、文件系统、用户界面和复杂业务逻辑的智能设备时，缺乏设计的代码会迅速演变成一场灾难。模块之间高度耦合，改一处功能引发多处崩溃；添加新特性举步维艰；排查一个低级BUG需要通读数万行代码。这些问题背后的核心，往往不是算法不够优化，而是缺少一个清晰、稳固的软件架构。

软件架构不是大型互联网项目的专利，它同样是嵌入式系统，尤其是资源受限的MCU或Linux嵌入式设备长期稳定、可维护、可扩展的基石。本文将从一个资深嵌入式开发者的视角，深入探讨为什么嵌入式项目同样需要软件架构设计。我们会从概念入手，分析无架构代码的典型痛点，然后通过一个模拟的“智能温控器”项目，展示如何从零开始进行分层架构设计，并给出具体的代码模块划分、接口定义和编译管理示例。最后，我们会讨论在资源受限环境下进行架构设计的权衡之道，并提供一套可落地的架构评估与演进方法。

1. 嵌入式软件架构究竟是什么？为什么它容易被忽视？

在深入设计之前，我们必须先统一对“嵌入式软件架构”这个概念的理解。它并非一个遥不可及的理论。

1.1 架构的本质：应对复杂性的设计决策

软件架构是一系列关于软件系统如何被组织的 重要决策的集合 。这些决策定义了系统的结构、组件之间的关系、以及它们如何协作以实现系统目标。在嵌入式领域，这些决策尤其关键，因为它们直接受到硬件资源（如有限的RAM、ROM、CPU主频）、实时性要求、功耗约束和物理环境的影响。

一个典型的嵌入式软件架构会回答以下问题：

  • 系统如何分层？ 例如，硬件驱动层、操作系统抽象层、中间件层、应用层如何划分？
  • 模块之间如何通信？ 是通过函数调用、消息队列、发布/订阅模型，还是共享内存？
  • 数据如何流动？ 传感器数据从采集到处理再到上报，经过哪些模块，格式如何转换？
  • 全局资源如何管理？ 如中断、定时器、内存堆、日志系统由谁统一管理？
  • 系统如何启动和初始化？ 各模块的初始化顺序依赖如何解决？
  • 错误和异常如何处理？ 是就地处理，还是统一上报？

1.2 嵌入式领域忽视架构的常见原因

许多嵌入式开发者，尤其是从单片机裸机开发入门的工程师，可能会认为架构设计“太重了”、“没必要”，这通常源于以下几个误解：

  1. 资源有限论 ：“我的MCU只有64KB Flash和8KB RAM，搞什么架构？代码能塞进去就不错了。” 这是一种典型的因果倒置。正是因为资源有限，才更需要清晰的架构来避免资源浪费在低效的、重复的、耦合的代码上。架构设计本身消耗的是设计时的脑力，而非运行时的内存。
  2. 项目简单论 ：“我这个项目就几个传感器和继电器，几百行代码搞定。” 很多复杂的系统都是从简单的原型演变而来的。如果没有初始的结构设计，当需求增加（例如，需要增加无线通信、本地存储、OTA升级）时，代码将难以扩展，最终可能不得不推倒重来。
  3. 性能至上论 ：“分层和抽象会引入函数调用开销，影响实时性。” 这确实是一个需要权衡的点。但好的架构不是教条地分层，而是在清晰和性能之间找到平衡。关键路径（如高速ADC采样中断服务程序）可以直接操作硬件，而业务逻辑则应该位于架构上层，通过清晰的接口进行调用。
  4. 个人习惯论 ：“我一直这么写，也没出过大问题。” 这在单人开发、生命周期短的小项目中或许可行。一旦项目需要团队协作、长期维护或交付给客户进行二次开发，缺乏架构的代码将成为沟通和维护的噩梦。

忽视架构的代价是隐性的，但会随着时间推移而急剧放大，最终体现为高昂的维护成本、极低的开发效率和不可预测的系统风险。

2. 无架构设计的典型痛点：从“能跑”到“难维护”

让我们通过一个虚构但非常典型的场景，来看看没有架构设计的嵌入式项目会变成什么样。

假设我们要开发一个基于STM32的智能温控器，最初需求很简单：读取DS18B20温度传感器，在OLED屏幕上显示，并通过继电器控制加热器。一个急于求成的开发者可能会写出类似下面的 main.c ： 

// 伪代码，展示一种典型的“面条式”代码
#include “stm32f1xx_hal.h”
#include “ds18b20.h”
#include “oled.h”
#include “relay.h”

DS18B20_HandleTypeDef ds18b20;
OLED_HandleTypeDef oled;
Relay_HandleTypeDef heater;

float current_temp = 0;
float set_temp = 25.0;
uint8_t display_buffer[20];

int main(void) {
    HAL_Init();
    SystemClock_Config();
    MX_GPIO_Init();
    MX_I2C1_Init();
    MX_TIM2_Init(); // 用于DS18B20延时

    // 初始化各种硬件，代码混杂
    DS18B20_Init(&ds18b20, &htim2, GPIOA, GPIO_PIN_0);
    OLED_Init(&oled, &hi2c1, 0x78);
    Relay_Init(&heater, GPIOC, GPIO_PIN_13);

    while (1) {
        // 业务逻辑、硬件操作、UI更新全部揉在一起
        if (DS18B20_ReadTemperature(&ds18b20, ¤t_temp) == HAL_OK) {
            // 控制逻辑
            if (current_temp < set_temp - 0.5) {
                Relay_On(&heater);
            } else if (current_temp > set_temp + 0.5) {
                Relay_Off(&heater);
            }

            // 显示逻辑
            sprintf((char*)display_buffer, “Temp: %.1fC”, current_temp);
            OLED_Clear(&oled);
            OLED_ShowString(&oled, 0, 0, display_buffer);
            // 可能还想画个图标，代码越来越长...
        }
        HAL_Delay(1000); // 阻塞延时，浪费CPU
    }
}

这段代码在功能上“能跑”，但隐藏了诸多问题，我们将其归纳为“无架构代码七宗罪”：

问题 现象与后果 在示例中的体现
1. 高耦合 模块间直接依赖具体实现。改传感器型号（如换为I2C的SHT30）需要重写 main 中多处代码。 main 函数直接调用了 DS18B20_Init , OLED_ShowString 等具体驱动函数。
2. 低内聚 相关功能没有组织在一起。温度读取、控制逻辑、显示更新全部堆在 main 的循环里。 温度采集、阈值判断、继电器控制、屏幕刷新代码混杂在一个代码块中。
3. 阻塞式处理 使用 HAL_Delay 等阻塞函数，CPU利用率低，无法响应其他紧急事件。 HAL_Delay(1000) 让CPU空转1秒，期间无法处理按键等输入。
4. 全局变量滥用 使用全局变量在各函数间传递数据，导致数据流不清晰，容易发生意外修改。 current_temp , set_temp , display_buffer 都是全局变量。
5. 缺乏错误处理 对硬件故障、通信超时等异常情况处理不足或不一致。 仅检查了 DS18B20_ReadTemperature 的返回值，未处理OLED显示失败等情况。
6. 难以测试 业务逻辑与硬件强绑定，无法在PC上进行单元测试或模拟测试。 控制逻辑 if (current_temp < set_temp - 0.5) 无法脱离真实硬件运行验证。
7. 无法复用 代码高度定制化，无法移植到其他项目或平台。 整个 main 函数逻辑与STM32 HAL、特定型号传感器和屏幕绑定。

当需求变更时，例如需要增加：

  • 按键设置温度 ：需要加入按键扫描和去抖，逻辑会更混乱。
  • 通过Wi-Fi上报数据 ：需要加入网络协议栈处理，阻塞延时将成为致命问题。
  • 本地存储历史数据 ：需要操作Flash，错误处理将更加复杂。
  • 支持OTA升级 ：整个系统需要模块化以支持动态更新。

此时，开发者会发现每加一个功能都如履薄冰，牵一发而动全身。项目最终会变成无人敢动的“屎山”代码。这正是软件架构设计要解决的核心问题： 管理复杂性，以应对变化 。

3. 为嵌入式项目设计一个分层架构：以智能温控器为例

好的架构不是凭空产生的，它源于对业务和硬件的深刻理解。我们为上述智能温控器设计一个经典的分层架构。这个架构遵循“依赖倒置”原则：上层模块定义接口，下层模块实现接口，核心业务逻辑不依赖具体硬件。

3.1 架构蓝图：四层模型

我们采用一个清晰的四层模型，从下到上依赖关系明确： 

+-------------------------------------+
|           应用层 (Application)      |  // 纯业务逻辑：温控策略、数据记录、用户交互流程
+-------------------------------------+
|           服务层 (Service)          |  // 功能模块：温度管理、设备控制、显示服务、网络服务
+-------------------------------------+
|         硬件抽象层 (HAL) / BSP      |  // 设备驱动封装：提供统一的传感器、执行器、屏幕接口
+-------------------------------------+
|    MCU HAL / 操作系统 (OS) / 裸机   |  // 芯片原厂SDK、RTOS API 或 裸机调度器
+-------------------------------------+

各层职责详解：

  • MCU/OS层 ：这是基础，可能是STM32 CubeMX生成的HAL库、FreeRTOS的API，或者是你自己编写的裸机调度器。这一层我们尽量不动，直接使用。
  • 硬件抽象层 ： 这是关键的一层 。它为上层提供稳定的、硬件无关的接口。例如，定义一个 temperature_sensor_t 接口，它有 init , read 等方法。 ds18b20.c 和 sht30.c 分别是这个接口的实现。这样，应用层只需要调用 sensor->read() ，而不关心底层是单总线还是I2C。
  • 服务层 ：基于HAL层提供的稳定接口，构建可复用的功能模块。例如 TemperatureManager 负责定时采集、滤波、报警判断； DisplayService 负责管理屏幕的刷新和界面渲染。服务层模块之间可以通过消息、事件或直接调用进行通信。
  • 应用层 ：这是系统的“大脑”，包含具体的业务逻辑。它协调各个服务层模块，完成具体的产品功能。例如， ThermostatApp 这个应用，它会订阅 TemperatureManager 的温度更新事件，然后根据策略调用 DeviceControl 服务来开关加热器，并通知 DisplayService 更新界面。

3.2 从蓝图到代码：模块划分与接口定义

现在，我们将这个架构转化为具体的项目目录和文件。一个结构清晰的项目目录本身也是架构的一部分。 

smart_thermostat/
├── CMakeLists.txt / Makefile        # 构建系统
├── docs/                            # 设计文档
├── drivers/                         # 芯片厂商HAL/特定外设驱动 (可视为MCU/OS层的一部分)
│   ├── stm32f1xx_hal_msp.c
│   └── ...
├── bsp/                             # 板级支持包 (硬件抽象层 HAL/BSP)
│   ├── inc/
│   │   ├── bsp_temperature.h       # 温度传感器抽象接口
│   │   ├── bsp_display.h           # 显示设备抽象接口
│   │   ├── bsp_relay.h             # 执行器抽象接口
│   │   └── bsp_button.h            # 输入设备抽象接口
│   └── src/
│       ├── bsp_ds18b20.c           # DS18B20的具体实现
│       ├── bsp_ssd1306_i2c.c       # SSD1306 OLED的具体实现
│       └── ...
├── middleware/                      # 中间件/服务层 (Service Layer)
│   ├── inc/
│   │   ├── temp_manager.h          # 温度管理服务
│   │   ├── display_service.h       # 显示服务
│   │   ├── device_controller.h     # 设备控制服务
│   │   └── event_manager.h         # 事件管理服务（可选）
│   └── src/
│       └── ...                     # 各服务的实现
├── application/                     # 应用层
│   ├── inc/
│   │   └── thermostat_app.h        # 温控器主应用
│   └── src/
│       └── thermostat_app.c
├── utils/                          # 通用工具（日志、队列、链表、调试）
│   ├── inc/
│   └── src/
└── main.c                          # 系统入口，负责初始化和启动调度

接下来，我们来看关键接口如何定义。以 温度传感器抽象 为例： 

// bsp/inc/bsp_temperature.h
#ifndef BSP_TEMPERATURE_H
#define BSP_TEMPERATURE_H

#include <stdint.h>
#include <stdbool.h>

// 定义温度传感器驱动的操作函数指针类型
typedef bool (*temp_init_func_t)(void *handle);
typedef bool (*temp_read_func_t)(void *handle, float *temperature_c);

// 定义温度传感器驱动结构体
typedef struct {
    void *handle;                   // 指向具体驱动实例的句柄（如 ds18b20_dev_t）
    temp_init_func_t init;          // 初始化函数指针
    temp_read_func_t read;          // 读取温度函数指针
    const char *name;               // 传感器名称，用于日志
} temperature_sensor_t;

// 对外提供的API：初始化传感器
bool bsp_temperature_sensor_init(temperature_sensor_t *sensor);
// 对外提供的API：读取温度
bool bsp_temperature_sensor_read(temperature_sensor_t *sensor, float *temp);

// 以下函数由具体的传感器驱动实现并注册
// 例如在 bsp_ds18b20.c 中实现
bool ds18b20_init(void *handle);
bool ds18b20_read(void *handle, float *temperature_c);

#endif // BSP_TEMPERATURE_H

// bsp/src/bsp_ds18b20.c
#include “bsp_temperature.h”
#include “ds18b20.h” // 第三方的或自己写的底层驱动

// 具体的设备结构体
typedef struct {
    GPIO_TypeDef *gpio_port;
    uint16_t gpio_pin;
    TIM_HandleTypeDef *htim;
    // ... 其他DS18B20特定参数
} ds18b20_dev_t;

bool ds18b20_init(void *handle) {
    ds18b20_dev_t *dev = (ds18b20_dev_t *)handle;
    // 调用底层 DS18B20_Init 函数
    return DS18B20_Init(dev->htim, dev->gpio_port, dev->gpio_pin) == HAL_OK;
}

bool ds18b20_read(void *handle, float *temperature_c) {
    ds18b20_dev_t *dev = (ds18b20_dev_t *)handle;
    // 调用底层 DS18B20_ReadTemperature 函数
    return DS18B20_ReadTemperature(dev->htim, temperature_c) == HAL_OK;
}

// 创建一个DS18B20的实例并配置接口
temperature_sensor_t temp_sensor = {
    .handle = &ds18b20_device_instance, // 全局的 ds18b20_dev_t 实例
    .init = ds18b20_init,
    .read = ds18b20_read,
    .name = “DS18B20”,
};

在 服务层 ，温度管理模块将使用这个抽象接口，而不关心具体型号： 

// middleware/inc/temp_manager.h
typedef struct {
    temperature_sensor_t *sensor; // 依赖抽象，而非具体实现
    float current_temp;
    float setpoint_temp;
    float hysteresis;
    bool alarm;
    // ... 其他状态
} temp_manager_t;

void temp_manager_init(temp_manager_t *manager, temperature_sensor_t *sensor);
void temp_manager_task(void *arg); // 被RTOS任务或主循环调用
float temp_manager_get_current(temp_manager_t *manager);
bool temp_manager_is_alarm(temp_manager_t *manager);

最后， 应用层 的业务逻辑变得非常清晰： 

// application/src/thermostat_app.c
#include “temp_manager.h”
#include “device_controller.h”
#include “display_service.h”

void thermostat_app_run(void) {
    temp_manager_t temp_manager;
    device_controller_t heater_controller;
    display_service_t display;

    // 初始化：依赖注入，将具体的传感器实例传入管理器
    temp_manager_init(&temp_manager, &temp_sensor); // temp_sensor 来自 bsp_ds18b20.c
    device_controller_init(&heater_controller, DEVICE_TYPE_RELAY, &heater_gpio_config);
    display_service_init(&display);

    while (1) {
        // 1. 更新温度（非阻塞方式，例如在RTOS任务中）
        // temp_manager_task(&temp_manager) 会在内部调用 sensor->read()

        // 2. 获取当前温度并决策
        float current = temp_manager_get_current(&temp_manager);
        if (current < (temp_manager.setpoint_temp - temp_manager.hysteresis)) {
            device_controller_turn_on(&heater_controller);
        } else if (current > (temp_manager.setpoint_temp + temp_manager.hysteresis)) {
            device_controller_turn_off(&heater_controller);
        }

        // 3. 更新显示
        display_service_show_temperature(&display, current);

        // 4. 系统延时或等待事件
        vTaskDelay(pdMS_TO_TICKS(1000)); // FreeRTOS 延时
        // 或 systick_delay_non_blocking(1000); // 非阻塞延时
    }
}

通过这样的设计，我们实现了：

  • 可替换性 ：更换温度传感器只需在 bsp/ 层新增一个实现（如 bsp_sht30.c ），并修改一行实例化代码，上层业务逻辑完全不变。
  • 可测试性 ：我们可以为 temp_manager 编写单元测试，通过模拟一个 temperature_sensor_t （Mock对象）来注入测试数据，无需真实硬件。
  • 关注点分离 ：驱动工程师关注 bsp_ds18b20.c 的时序和寄存器；应用工程师关注 thermostat_app.c 的业务规则。

4. 在资源受限环境下的架构权衡与实践建议

嵌入式架构设计永远是在清晰度、灵活性、性能、资源占用之间做权衡。没有“最好”的架构，只有“最适合”当前项目和团队的架构。

4.1 关键权衡点与决策表

设计决策 偏向清晰/灵活的做法 偏向性能/资源的做法 嵌入式场景下的建议
模块通信 使用消息队列、发布/订阅事件总线。解耦彻底，易于扩展。 直接函数调用。开销最小，实时性最高。 混合策略 。关键实时路径（如中断到控制）用函数调用+全局标志。复杂业务逻辑（如状态更新到UI刷新）用轻量级消息队列（如循环数组实现）。
硬件抽象 完整的接口层，支持运行时多态（函数指针表）。 编译时选择（通过宏定义 #ifdef USE_DS18B20 ）。 编译时抽象 。对于MCU项目，外设在生命周期内通常不变。使用头文件定义统一API，不同源文件实现，通过编译链接选择，避免运行时虚函数开销。
内存管理 动态内存分配（ malloc/free ），灵活。 静态内存分配（全局数组、静态变量），确定性强。 静态分配为主 。在启动时一次性分配好所有模块所需内存（结构体、缓冲区）。如需动态，使用固定大小的内存池（Memory Pool）管理，防止碎片化。
错误处理 统一的错误码枚举和传递机制，可能使用长跳转（setjmp/longjmp）。 简单的返回值检查或直接断言（ assert ）。 分级处理 。底层驱动使用返回值或断言快速失败。服务层记录错误日志并尝试恢复。应用层决定降级策略（如使用上次有效值）。
第三方库 引入完整的协议栈或框架（如LwIP, FatFs）。 自己实现最简功能或使用裸机轮询。 按需裁剪 。许多开源库（如LwIP, FreeRTOS）可高度裁剪。只编译需要的模块，关闭不需要的功能（如调试、统计）。

4.2 给中小型裸机项目的简易架构模式

如果你的项目没有RTOS，资源非常紧张，可以采用一种简化的“ 状态机+模块化 ”架构。

  • 核心思想 ：主循环是一个超级循环（Super Loop），但每个功能模块被组织成“状态机”或“任务函数”。
  • 实现方式 ：
    1. 为每个模块（如按键扫描、温度采集、显示刷新）定义一个结构体，包含其状态、数据、和上次执行的时间戳。
    2. 每个模块提供一个 xxx_task(void *arg) 函数，该函数必须是 非阻塞 的，执行一次就立即返回。
    3. 在主循环中，依次检查每个模块是否到了其规定的执行周期（通过系统滴答计时），如果到了，就调用其 task 函数。
    4. 模块间通过共享的、加了访问保护（如开关中断）的全局数据结构进行通信。 
// 简易的基于时间片的裸机调度架构示例
typedef struct {
    void (*task_func)(void*); // 任务函数指针
    void *arg;                // 任务参数
    uint32_t interval_ms;     // 执行间隔
    uint32_t last_run_ticks;  // 上次运行的系统滴答
} sched_task_t;

sched_task_t g_tasks[] = {
    {key_scan_task, NULL, 20, 0},   // 20ms扫描一次按键
    {temp_sample_task, NULL, 1000, 0}, // 1s采样一次温度
    {display_refresh_task, NULL, 500, 0}, // 500ms刷新一次显示
    {control_logic_task, NULL, 100, 0}, // 100ms执行一次控制逻辑
    // ... 更多任务
};

void main_super_loop(void) {
    system_init();
    while (1) {
        uint32_t current_ticks = get_system_ticks();
        for (int i = 0; i < ARRAY_SIZE(g_tasks); i++) {
            if (current_ticks - g_tasks[i].last_run_ticks >= g_tasks[i].interval_ms) {
                g_tasks[i].task_func(g_tasks[i].arg);
                g_tasks[i].last_run_ticks = current_ticks;
            }
        }
        // 可以在这里进入低功耗模式
        enter_idle_mode();
    }
}

这种模式虽然没有RTOS强大，但它强制了模块化和非阻塞设计，为未来迁移到RTOS打下了良好基础，其结构清晰度远胜于最初那个“面条式”的 main.c 。

4.3 架构设计的启动清单与检查点

开始一个新项目或重构旧项目时，可以遵循以下清单来推动架构设计：

  1. 需求分析阶段 ：

    • 列出所有硬件外设（传感器、执行器、通信接口）。
    • 明确核心功能与非核心功能。
    • 定义关键性能指标（实时性要求、功耗预算、内存上限）。

  2. 高层设计阶段 ：

    • 绘制系统框图，划分硬件抽象层（HAL/BSP）。
    • 识别核心业务实体（如“温度”、“设备”、“用户”），设计服务层模块。
    • 确定模块间通信机制（函数调用、消息、事件）。
    • 设计关键数据流（数据从哪里产生，经过哪些处理，到哪里去）。

  3. 详细设计阶段 ：

    • 为每个模块设计头文件（ .h ），明确其对外接口（API）。
    • 定义关键的数据结构。
    • 规划错误码和日志格式。
    • 设计初始化顺序和依赖关系。

  4. 实现与验证阶段 ：

    • 从下往上或从上往下实现（建议先实现HAL和核心业务逻辑）。
    • 为HAL层编写模拟（Mock）实现，以便在PC上测试服务层和应用层。
    • 使用调试器或日志验证数据流是否符合设计。

  5. 持续演进阶段 ：

    • 定期回顾架构，检查是否有模块变得过于臃肿（职责过多）。
    • 当添加新功能时，首先思考它属于哪一层、哪个现有模块，而不是随意添加代码。
    • 记录下每一次因为架构清晰而节省调试时间，或因架构混乱而增加成本的案例，作为团队的经验。

嵌入式软件架构设计的终极目标，不是追求理论的完美，而是在有限的资源内，构建一个让团队能够高效协作、让系统能够长期稳定演进、让代码能够经受住时间考验的坚实基底。它始于对“为什么需要架构”的深刻认识，并最终体现在每一行清晰、模块化、可测试的代码之中。当你下次面对一个新的嵌入式项目时，不妨先从画一张简单的架构图开始，这将是通往成功开发最重要的一步。

Logo
乐奇 Rokid 开放社区

更多推荐

cover

AR 智能眼镜并不是简单地在眼前放一块屏幕，而是把**摄像头、传感器、计算机视觉、空间定位、语音交互和云端服务**连接起来

avatar 乐奇 Rokid 开放社区
cover

让界面替我“摇“一次：一个AR祈愿智能体的AIUI实践

avatar 乐奇 Rokid 开放社区

智能眼镜市场全景解析：从技术演进到产业格局

本文系统梳理智能眼镜市场，涵盖产品形态、技术演进、市场规模、产业链结构及竞争格局。指出智能眼镜正从音频交互向AR显示与空间计算演进，受AI大模型、供应链成熟与生态延伸驱动，呈现分层发展态势。虽面临场景刚需不足、续航重量矛盾与隐私挑战，但B端应用先行、AI原生设计与标准完善将推动行业迈向规模化渗透，未来需关注核心技术突破与真实使用数据。

avatar 乐奇 Rokid 开放社区