3、裸机工程基础：裸机开发概念、与RTOS的区别、典型裸机工程结构

在嵌入式系统开发中，尤其是当我们准备将 TensorFlow Lite Micro（TFLite Micro）部署到资源受限的微控制器（MCU）上时，首先需要明确目标平台的软件运行环境。绝大多数 MCU 应用（如传感器节点、电机控制器、便携式仪表）都运行在裸机（Bare-Metal）环境上。裸机开发意味着没有操作系统（OS）作为中间层，你的应用程序代码直接运行在硬件之上，通过操作寄存器、外设驱动和中断系统来完成所有任务。理解裸机开发的概念、它与实时操作系统（RTOS）的本质区别，以及典型的工程文件组织方式，是后续进行 TFLite Micro 移植和内存布局规划的重要基石。本章将系统梳理这些基础内容，帮助你建立清晰的裸机工程思维。

上图从软件分层和调度机制两个维度对比了裸机与 RTOS 环境的差异。在裸机环境中，应用程序、驱动和中断服务程序直接与硬件交互，没有中间层；而在 RTOS 中，内核负责任务调度和资源管理。对于 TFLite Micro 而言，它本身是一个静态链接库，不依赖操作系统，因此两种环境都可以运行。但裸机环境更简单、更可控，是理解 TFLite Micro 底层内存分配和算子执行的理想起点。

3.1 裸机开发核心概念与运行模型

裸机开发的核心思想是“直接操作硬件”。你的代码（C 或 C++）通过访问 MCU 的寄存器来控制 GPIO、UART、SPI、I2C、定时器等外设。程序的基本结构通常由一个无限主循环（Super Loop）和若干个中断服务程序（ISR）组成。主循环负责处理非实时性任务，如数据解析、状态机切换；中断负责处理实时性要求高的任务，如捕获外部脉冲、接收串口数据。

在裸机系统中，没有“进程”或“线程”的概念，只有一个执行流。这意味着代码必须按照顺序执行，如果某个函数阻塞（例如等待一个标志位），整个系统就会卡住。因此，裸机编程非常强调非阻塞设计和状态机编程。例如，读取传感器数据时，不能使用 while(!flag); 这样的忙等待，而应该启动一次异步转换，在中断中设置标志位，主循环检测到标志位后再处理数据。

3.2 裸机与 RTOS 的深度对比

选择裸机还是 RTOS，取决于项目的复杂度、实时性要求和资源限制。下表从多个维度进行了详细对比，帮助你做出合理决策。

对于 TFLite Micro 的移植，裸机环境往往更具优势。因为推理过程是一个计算密集型任务，它不需要频繁的任务切换，只需要一个足够大的调用栈和静态内存池。在裸机中，你可以将整个推理过程放在主循环中，或者放在一个高优先级的中断里（如果推理时间足够短）。而在 RTOS 中，你需要为推理任务分配独立的栈空间，并考虑任务切换时的上下文保存开销。

3.3 典型裸机工程结构拆解

一个规范的裸机工程，其目录结构和文件组织直接影响代码的可维护性和可移植性。以 STM32 或 ESP32 等主流 MCU 为例，一个典型的裸机工程通常包含以下目录：

project_root/
├── core/                 # 核心启动文件与系统初始化
│   ├── startup.s         # 汇编启动文件，定义中断向量表
│   ├── system.c          # 系统时钟配置 (SystemInit)
│   └── main.c            # 主函数，包含主循环
├── drivers/              # 外设驱动层
│   ├── gpio.c/h
│   ├── uart.c/h
│   ├── spi.c/h
│   └── timer.c/h
├── middleware/           # 中间件，如 TFLite Micro
│   ├── tflite-micro/
│   │   ├── tensorflow/lite/micro/
│   │   └── third_party/
│   └── model_data/       # 转换后的模型数组 (.cc 或 .h)
├── app/                  # 应用层逻辑
│   ├── inference_engine.c/h  # 封装 TFLite Micro 初始化与推理
│   ├── data_preprocess.c/h   # 数据预处理（如归一化）
│   └── post_process.c/h      # 输出后处理（如 softmax）
├── utils/                # 工具函数
│   ├── ring_buffer.c/h
│   └── crc16.c/h
├── config/               # 配置文件
│   ├── project_config.h  # 宏定义，如时钟频率、引脚映射
│   └── memory_map.ld    # 链接脚本，定义 RAM/Flash 布局
└── Makefile 或 CMakeLists.txt  # 构建脚本

这种分层结构的好处是：驱动层与硬件相关，中间件层（TFLite Micro）与硬件无关，应用层只调用中间件和驱动提供的接口。这样，当你更换 MCU 平台时，只需要修改驱动层和链接脚本，而 TFLite Micro 的代码和模型文件可以完全复用。

3.4 案例拆解：在裸机工程中集成 TFLite Micro 的初始化流程

为了让你更直观地理解裸机工程如何承载 TFLite Micro，我们以一个基于 STM32F407 的语音关键词识别项目为例，展示其初始化与推理的代码骨架。该项目的硬件约束是：主频 168MHz，RAM 192KB，Flash 1MB。模型为一个简单的 2 层全连接网络，参数量约 10KB。

初始现象与目标：我们需要在裸机环境下，每 20ms 采集一次音频特征（MFCC），并送入 TFLite Micro 进行推理，输出“是/否”的唤醒词判断。初始代码中，推理一次耗时约 15ms，主循环总耗时 35ms，导致音频采集中断（10ms 周期）偶尔丢失数据。

分析判断过程：通过逻辑分析仪发现，主循环中 tflite::MicroInterpreter::Invoke() 占用了 15ms，而 MFCC 特征提取占用了 10ms，其余 10ms 为 GPIO 操作和系统开销。由于音频中断优先级最高，它可以在推理过程中打断 CPU，但中断服务程序中的缓冲区写入操作与主循环中的读取操作存在竞争，导致数据覆盖。

实际操作步骤：

1. 优化中断处理：在音频中断中仅将 DMA 搬运的数据放入环形缓冲区，不进行任何计算。
2. 调整推理时机：将推理任务拆分为两步：第一步在主循环中检查环形缓冲区是否有完整的一帧数据（20ms 音频），第二步调用推理引擎。这样，推理过程不会被中断打断，因为中断只负责填充缓冲区。
3. 内存池分配：在 main.c 中定义静态内存池 static uint8_t tensor_arena[80 * 1024];，用于 TFLite Micro 的张量存储。

// main.c 中的核心初始化与推理循环
#include "tensorflow/lite/micro/micro_interpreter.h"
#include "tensorflow/lite/micro/micro_mutable_op_resolver.h"
#include "model_data.h"  // 包含模型数组

static uint8_t tensor_arena[80 * 1024];  // 80KB 内存池

void setup_tflite() {
    // 1. 加载模型
    tflite::MicroMutableOpResolver<10> resolver;
    resolver.AddFullyConnected();
    resolver.AddSoftmax();
    // 2. 创建解释器
    static tflite::MicroInterpreter static_interpreter(
        g_model, resolver, tensor_arena, sizeof(tensor_arena));
    interpreter = &static_interpreter;
    // 3. 分配张量内存
    TfLiteStatus allocate_status = interpreter->AllocateTensors();
    if (allocate_status != kTfLiteOk) {
        // 错误处理：内存不足或模型不匹配
    }
}

void loop() {
    // 检查是否有完整音频帧
    if (ring_buffer_has_frame()) {
        // 预处理：将音频数据填充到输入张量
        float* input = interpreter->input(0)->data.f;
        extract_mfcc(input);  // 耗时约 10ms
        // 推理
        interpreter->Invoke();  // 耗时约 15ms
        // 后处理：获取输出
        float* output = interpreter->output(0)->data.f;
        if (output[0] > 0.5f) {
            set_led_on();
        }
    }
}

结果对比与复盘：优化后，主循环单次迭代耗时约 25ms（10ms 预处理 + 15ms 推理），但音频中断始终能及时响应，因为中断只做简单的缓冲区写入。通过示波器观察，GPIO 翻转测试点显示中断响应时间稳定在 3μs 以内。此次优化的关键教训是：在裸机中，中断服务程序应保持极短，所有耗时操作必须放在主循环中，并通过标志位或缓冲区与中断通信。

3.5 常见误区与总结复盘

在裸机开发中，初学者容易陷入以下几个误区，需要特别警惕：

• 误区一：使用阻塞式延时（如 HAL_Delay）。在裸机主循环中，长时间的阻塞延时会导致中断响应延迟。应使用定时器或系统节拍（SysTick）来管理时间片。
• 误区二：忽视中断优先级配置。如果多个中断同时触发，错误的优先级设置会导致实时性任务被低优先级任务阻塞。例如，音频采集中断应高于串口发送中断。
• 误区三：全局变量滥用。在裸机中，全局变量是任务间通信的主要手段，但必须使用 volatile 关键字修饰，并考虑临界区保护（如关中断或使用原子操作）。
• 误区四：内存分配不规划。TFLite Micro 要求使用静态内存池，不能使用 malloc。在裸机工程中，应提前规划好 tensor_arena 的大小，并通过 interpreter->arena_used_bytes() 检查实际使用量。

总结复盘：裸机工程是 TFLite Micro 部署的最简环境，它要求开发者对硬件有深入理解，并具备良好的代码组织能力。通过本章的学习，你应该能够区分裸机与 RTOS 的适用场景，掌握裸机工程的标准目录结构，并理解如何将 TFLite Micro 的推理任务嵌入到主循环中。在下一阶段的移植工作中，你将基于这个裸机框架，逐步添加 TFLite Micro 的依赖库和模型文件，最终实现端侧推理。