3、核心概念：硬件抽象层（HAL）的设计原则、分层架构、设备驱动模型、回调机制、中断与轮询模式
TinyML 设备通常运行在 Cortex-M 级 MCU 或 RISC-V 低功耗处理器上，资源以 KB 级 RAM 和 MB 级 Flash 计。在这种约束下，硬件抽象层（HAL）不是简单的“封装寄存器”，而是决定模型推理能否稳定运行、传感器数据能否准时到达、功耗预算能否达标的工程基石。本章从设计原则出发，剖析分层架构、驱动模型、回调机制以及中断与轮询的取舍，并结合实际传感器接口案例给出可落地的边界设计方法。
3.1 HAL 设计原则：最小边界与最大内聚
HAL 的本质是在硬件与算法之间划出一条“可替换、可测试、可预测”的边界。TinyML 场景下，这条边界必须满足三个核心原则：最小接口面（应用层只看到 3~5 个函数）、确定性时序（每次调用耗时可控）、资源显式化（内存、外设、功耗全部显式声明）。
| 原则 | 含义 | 违反时的后果 |
|---|---|---|
| 最小接口面 | 传感器、推理、存储各暴露不超过 5 个 API | 接口膨胀导致耦合，无法单元测试 |
| 确定性时序 | read() 最坏耗时 ≤ 2ms，推理耗时固定 | 实时性崩溃，音频/振动场景丢数据 |
| 资源显式化 | 缓冲区、DMA 通道、中断优先级全部由 HAL 分配 | 内存碎片、外设冲突、死锁 |
设计时建议采用“三明治模型”：底层是芯片厂商 SDK（如 STM32Cube HAL、ESP-IDF），中间是我们的轻量 HAL（约 200~500 行 C 代码），上层是算法与业务。中间层不直接操作寄存器，而是将厂商 SDK 的差异封装成统一接口。例如，读取 IMU 加速度，应用层只调用 hal_sensor_read(ACCEL, &data)，内部根据编译宏选择 I2C 或 SPI 实现。
3.2 分层架构：从寄存器到推理引擎的清晰路径
推荐四层结构，每层职责单一，依赖方向严格向下：
- 硬件层：物理传感器、MCU 外设、电源芯片。
- 驱动层：实现寄存器读写、总线协议（I2C/SPI）、DMA 传输。每个驱动一个 .c/.h 文件，不包含业务逻辑。
- HAL 服务层：提供传感器数据聚合、时间戳管理、中断统一入口、功耗状态切换。这是本章设计的重点。
- 应用/推理层：TFLite Micro 解释器、特征提取、分类器。只通过 HAL 接口获取数据，不感知硬件细节。
分层的关键在于依赖倒置：HAL 层定义接口（如 sensor_ops_t 结构体），驱动层实现这些接口，应用层只依赖接口。这样更换传感器时，只需新增一个驱动文件并注册到 HAL，无需改动推理代码。
3.3 设备驱动模型：结构体封装与注册机制
TinyML 不适合面向对象的 C++ 虚函数（开销大），推荐用 C 语言的结构体函数指针实现“轻量多态”。每个设备驱动是一个 device_t 实例：
typedef struct {
uint8_t id;
int (*init)(void);
int (*read)(uint8_t *buf, uint16_t len);
int (*ioctl)(uint32_t cmd, void *arg);
void (*irq_handler)(void);
} device_t;
// 注册表
static device_t *dev_table[MAX_DEVICES];
int hal_device_register(device_t *dev);注册机制带来三个好处：启动时统一初始化（遍历表调用 init）、运行时动态查找（按 id 获取设备）、测试时注入 mock（将 dev_table 中的指针替换为模拟设备）。实际项目中，建议将注册表放在独立的 RAM 段，避免与推理张量缓冲区冲突。
3.4 回调机制：异步数据流的桥梁
传感器数据到达时，如果采用轮询，CPU 会浪费大量时间在等待上。回调机制允许驱动层在数据就绪时主动通知 HAL，再由 HAL 调用应用层注册的函数。典型流程：
- 应用层调用
hal_sensor_register_callback(accel_id, my_cb)。 - 驱动层在 DMA 完成中断中调用
hal_trigger_callback(accel_id)。 - HAL 将回调放入待处理队列，在
hal_process()中统一执行（避免在中断上下文直接运行用户代码）。
回调设计必须注意上下文切换：回调函数运行在任务上下文（如主循环或 RTOS 任务），而非中断上下文。中断只做“标记数据就绪”和“拷贝到 HAL 缓冲区”，实际处理延迟到主循环。这样既保证实时性，又避免在中断里调用复杂逻辑导致优先级反转。
3.5 中断与轮询模式：场景驱动的选择策略
| 模式 | 适用场景 | CPU 占用 | 延迟 | 典型示例 |
|---|---|---|---|---|
| 轮询 | 数据率低（<10Hz）、时序要求宽松 | 低（但空转浪费） | 高（取决于轮询周期） | 温湿度传感器（SHT30） |
| 中断 | 事件触发、低延迟要求 | 极低（事件驱动） | 低（微秒级） | 按键唤醒、运动检测 |
| DMA+中断 | 高数据率（>1kHz）、块传输 | 极低（硬件搬运） | 低（批量完成） | 麦克风 PDM 数据、IMU 突发读取 |
选择策略：先算数据率。若传感器输出 100Hz、每次 6 字节，轮询周期 10ms 完全可行；若音频 16kHz/16bit 双通道（64KB/s），必须 DMA。其次看功耗预算：轮询需要 CPU 周期性唤醒，中断可以让 CPU 深度睡眠直到事件发生。最后考虑优先级反转：多个中断嵌套时，HAL 要统一管理优先级分组，避免传感器中断阻塞定时器中断。
背景：设计一款可穿戴运动检测设备，使用 BMI270 IMU（加速度+陀螺仪）、BME280 环境传感器、NRF52832 MCU。目标：待机电流 <10μA，运动检测延迟 <50ms，推理准确率 >95%。
初始方案：所有传感器轮询，主循环 10ms 周期读取。实测待机电流 120μA（超标 12 倍），且 CPU 占用 40%。
分析：BMI270 支持硬件中断（运动唤醒），BME280 数据率仅 1Hz，无需中断。推理模块需要 20ms 连续 CPU 时间。
操作步骤：
1. 将 BMI270 配置为中断模式，加速度阈值 0.5g 触发，中断引脚接入 P0.08。
2. HAL 中注册
motion_irq_handler，仅设置事件标志并唤醒 CPU。3. 主循环中检测到事件标志后，调用
hal_sensor_read(ACCEL) 获取 100Hz 数据（突发读取 10ms 数据），然后执行推理。4. BME280 保持轮询，周期 1s，放在低优先级任务。
结果：待机电流降至 8.5μA，运动检测延迟 35ms，CPU 占用 12%。
风险：中断触发频率过高时（如剧烈运动），事件标志可能堆积。解决：HAL 中增加环形缓冲区，最多缓存 16 次事件，溢出时丢弃最旧事件并置位错误标志。
复盘：核心经验是“中断负责唤醒，轮询负责搬运”。中断里绝不读传感器数据，只做标记；数据读取放在主循环，避免长时间关中断影响 BLE 协议栈。
3.6 常见误区与设计复盘
- 误区一：所有外设都用中断。中断过多导致上下文切换开销超过轮询，且嵌套中断难以调试。建议中断数量 ≤ 5 个，且优先级分组明确。
- 误区二：HAL 层直接暴露寄存器地址。这破坏了封装性，应用层可能误操作导致硬件故障。应只暴露语义化接口（如
set_sample_rate()）。 - 误区三：回调函数在中断上下文执行。如果回调里调用
printf()或动态内存分配，会导致系统崩溃。必须通过标志位或队列延迟处理。 - 误区四：忽略 DMA 缓冲区对齐。许多 MCU 要求 DMA 缓冲区 4 字节对齐，否则触发 HardFault。HAL 中应使用
__ALIGNED(4)声明缓冲区。
总结：TinyML 的 HAL 设计不是“越抽象越好”，而是在资源约束下找到最简边界。建议每增加一个抽象层，都要问自己：它是否减少了耦合？是否增加了可测试性？是否让功耗更可控？如果答案是否定的，就果断砍掉。最终目标是让算法工程师面对一个“虚拟传感器”，让驱动工程师面对一个“虚拟应用”，双方通过 HAL 契约协作，互不干扰。