3. 项目模板设计原则

TinyML 项目与常规嵌入式或云端 AI 项目最大的差异在于：目标硬件资源极度受限、工具链碎片化严重、部署环境多样（从 MCU 到 Linux 网关）。如果没有一套经过深思熟虑的项目模板，开发者在每个新项目中都会重复经历“搭积木”的过程——复制旧代码、修改引脚定义、调整编译脚本、重新适配传感器驱动。这不仅浪费大量时间，更致命的是，每个项目都会形成一套“独有”的代码风格和目录结构，导致团队协作困难、技术债累积。本章将深入剖析构建可复用端侧 AI 工程骨架的六大核心原则，帮助你将项目从“一次性原型”提升为“可持续演进的工程资产”。

上图展示了项目模板六大原则之间的协同关系。可复用性依赖模块化与配置驱动，跨平台兼容需要底层抽象与构建系统支持，而版本控制与文档规范则是保障长期演进的基石。下面我们将逐一深入探讨每个原则的具体落地方法。

3.1 可复用性：从“复制粘贴”到“组件沉淀”

核心原理

可复用性不是简单的代码拷贝，而是对业务逻辑、硬件驱动、算法实现进行分层抽象，提取出与具体项目无关的通用部分。在 TinyML 场景中，可复用的对象包括：传感器数据采集封装（如 IMU 的 I2C 读取）、预处理流水线（均值滤波、归一化）、模型推理接口（统一输入输出张量格式）、以及常见的后处理逻辑（阈值判断、滑动窗口平滑）。

判断方法

• 接口稳定性测试：如果新项目需要修改旧组件的函数签名，说明抽象层次不合理。
• 依赖方向检查：通用组件不应依赖具体项目代码，而应依赖抽象接口或标准库。
• 三处重复原则：同一段逻辑在三个不同项目中出现，就应该提取为公共模块。

案例拆解：加速度计驱动复用

假设你为 STM32F4 开发了 LIS3DH 加速度计驱动，包含初始化、读取 XYZ 轴、配置中断等功能。在下一个基于 ESP32-S3 的项目中，传感器换成了 MPU6050。如果驱动代码与 HAL 库强绑定，复用将非常困难。正确的做法是：

// 抽象传感器接口（模板中定义）
typedef struct {
    int (*init)(void);
    int (*read_accel)(float *x, float *y, float *z);
    int (*read_gyro)(float *x, float *y, float *z);
} imu_ops_t;

// 具体驱动实现（LIS3DH 或 MPU6050）
const imu_ops_t lis3dh_ops = { .init = lis3dh_init, .read_accel = lis3dh_read_accel, ... };
const imu_ops_t mpu6050_ops = { .init = mpu6050_init, .read_accel = mpu6050_read_accel, ... };

// 应用层只依赖 imu_ops_t 指针
void gesture_app(imu_ops_t *imu) {
    float x, y, z;
    imu->read_accel(&x, &y, &z);
    // 处理数据...
}

通过函数指针表（ops 结构体），应用层完全不需要关心底层硬件差异。新项目只需实现新的 ops 实例，即可复用全部上层逻辑（特征提取、模型推理、通信协议）。

3.2 模块化：清晰的分层与边界

核心原理

模块化要求将系统拆分为职责单一、边界清晰的单元。TinyML 项目建议采用四层架构：硬件抽象层（HAL）、中间件层（传感器驱动、通信协议）、算法层（预处理、推理引擎、后处理）、应用层（业务逻辑、状态机）。每层只能依赖其下一层，禁止跨层调用。

操作流程

1. 在模板根目录创建 app/、algo/、mid/、hal/ 四个顶层文件夹。
2. 每个模块内部使用 module_name.h 作为对外接口，module_name_internal.h 或 .c 文件中的静态函数作为私有实现。
3. 在 CMakeLists.txt 中按层级顺序链接库，并设置 target_include_directories 限制可见性。

3.3 配置驱动：代码与参数分离

核心原理

配置驱动意味着将硬件引脚定义、模型路径、阈值参数、网络配置等从代码中剥离，放入独立的配置文件（如 config.yaml 或 board_config.h）。这样，更换硬件平台或调整算法参数时，无需修改逻辑代码，只需编辑配置文件。

实现方式

# config.yaml 示例
board:
  mcu: "esp32s3"
  cpu_freq_hz: 240000000
  i2c:
    sda_pin: 8
    scl_pin: 9
    clock_hz: 400000
model:
  path: "models/gesture.tflite"
  input_size: [1, 64, 3]
  output_size: 5
  threshold: 0.7
preprocessing:
  sample_rate_hz: 50
  window_size: 64
  normalize: true

在 C 代码中，通过构建系统（如 CMake 的 configure_file）将 YAML 转换为 C 头文件，或使用 kconfig 风格生成宏定义。对于资源极紧张的 MCU，推荐使用静态生成的 .h 文件，避免运行时解析开销。

案例拆解：多板卡适配

某项目需要同时支持 STM32L4 和 nRF52840 两款开发板。通过配置驱动，模板中只需维护两份 board_config.h：

// board_config_stm32l4.h
#define I2C_SCL_PIN  PB6
#define I2C_SDA_PIN  PB7
#define UART_TX_PIN  PA2
#define MODEL_QUANT  true

// board_config_nrf52840.h
#define I2C_SCL_PIN  27
#define I2C_SDA_PIN  26
#define UART_TX_PIN  6
#define MODEL_QUANT  false

构建脚本根据 -DBOARD=stm32l4 或 -DBOARD=nrf52840 选择对应的头文件，应用代码统一引用 board_config.h。这样，硬件差异被完全隔离在配置层。

3.4 跨平台兼容：一次编写，多处编译

核心原理

跨平台兼容的目标是让同一套算法代码能在 PC（x86 Linux/Windows）、MCU（ARM Cortex-M）和嵌入式 Linux（ARM64）上编译运行。这需要三个层面的支持：编译器抽象（使用 CMSIS 或自定义宏屏蔽不同编译器的差异）、RTOS 抽象（CMSIS-RTOS2 或 POSIX 兼容层）、浮点/定点运算抽象（在无 FPU 的 MCU 上使用 CMSIS-DSP 的定点函数）。

操作流程

1. 在模板中创建 platform/ 目录，包含 platform.h，内部通过宏区分平台：

#if defined(__ARMCC_VERSION) || defined(__GNUC__) && defined(__arm__)
    #define TARGET_MCU 1
    #include "cmsis_os2.h"
#elif defined(__linux__)
    #define TARGET_LINUX 1
    #include "pthread.h"
#endif

2. 使用 CMake 的 toolchain 文件区分交叉编译链与本地编译链。
3. 算法层禁止直接调用 printf，统一使用 LOG_DEBUG 宏，在 PC 上映射到标准输出，在 MCU 上映射到 RTT 或串口。

常见误区

• 误区一：认为跨平台就是加 #ifdef。实际上，过多的条件编译会降低可读性，应优先使用抽象接口。
• 误区二：忽略字节序问题。在 PC 上测试通过的代码，移植到小端 MCU 上可能因结构体对齐或位域问题出错。
• 误区三：浮点运算在无 FPU 的 MCU 上性能骤降。模板应提供 USE_FLOAT 宏，允许切换为 q15_t 或 q31_t 定点格式。

3.5 版本控制与文档规范

核心原理

版本控制不仅管理代码，还要管理模型文件、训练数据集和配置文件。由于 Git 对二进制文件不友好，需要使用 Git LFS（Large File Storage）跟踪 .tflite、.h5、.bin 等文件。文档规范则要求每个模块有清晰的 README、API 注释和变更日志。

模板中的落地清单

案例拆解：模型版本回滚

假设你在开发手势识别功能，v1.0 模型准确率 92%，v1.1 模型在增加夜间模式后准确率降至 88%。由于模板中 models/ 目录使用 Git LFS 管理，你可以轻松执行 git checkout v1.0 -- models/gesture.tflite 回滚模型，同时 CHANGELOG.md 中记录了 v1.1 的改动细节（增加了图像增强预处理）。这种可追溯性在调试现场问题时至关重要。

3.6 综合实战：构建一个可复用的模板骨架

下面我们整合上述原则，设计一个最小但完整的模板目录结构。假设目标平台为 ESP32-S3 和 STM32L4，算法为基于 IMU 的跌倒检测。

tinyfall_template/
├── app/                  # 应用层
│   ├── main.c            # 入口，初始化各模块
│   └── fall_detector.c   # 状态机：待机→检测→报警
├── algo/                 # 算法层
│   ├── preprocess.c      # 滑动窗口、归一化
│   ├── inference.c       # TFLite 推理封装
│   └── postprocess.c     # 阈值判断、去抖
├── mid/                  # 中间件层
│   ├── imu_ops.c         # 调用 HAL 层接口
│   ├── ble_notify.c      # 报警通知
│   └── led_ctrl.c
├── hal/                  # 硬件抽象层
│   ├── i2c_hal.c         # 平台相关 I2C 实现
│   ├── uart_hal.c
│   └── timer_hal.c
├── config/
│   ├── board_config.h    # 引脚、时钟配置
│   └── model_config.h    # 模型路径、阈值
├── models/
│   ├── fall_detect.tflite
│   └── README.md
├── docs/
│   └── api/              # Doxygen 输出
├── tests/                # 单元测试（PC 上运行）
│   └── test_preprocess.c
├── CMakeLists.txt        # 顶层构建脚本
├── cmake/
│   ├── toolchain_esp32.cmake
│   └── toolchain_stm32.cmake
├── .gitattributes
├── .gitignore
├── CHANGELOG.md
└── README.md

该模板的核心优势在于：可复用性体现在 algo/ 和 mid/ 层完全与硬件无关；模块化通过四层目录强制实施；配置驱动将所有板级差异集中在 config/；跨平台兼容通过 CMake 工具链和 platform.h 实现；版本控制通过 LFS 管理模型；文档规范由 README 和 Doxygen 注释保障。

最后需要强调的是，模板不是一成不变的。随着项目积累，应定期将重复出现的代码模式提炼回模板中，形成正向循环。但每次模板更新都必须同步更新 CHANGELOG 和迁移指南，避免破坏已有项目。