课程导入：TinyML运动检测项目背景、学习目标与课程框架

TinyML（微型机器学习）是边缘计算与嵌入式系统交叉领域中最具工程落地价值的方向之一。它解决的核心矛盾是：如何在功耗受限、算力有限、内存以KB计的微控制器（MCU）上，部署经过训练的机器学习模型，并使其在真实物理环境中稳定运行。运动检测是TinyML最典型的应用场景之一——它涉及传感器数据采集、信号预处理、模型推理、功耗管理、无线通信等多个工程环节，且对实时性和电池寿命有明确要求。本课程以一个完整的运动检测项目为载体，从ONNX模型部署和功耗调优两个核心维度展开，帮助学习者建立从模型到硬件的全链路工程思维。

1.1 TinyML运动检测的项目背景与工程挑战

运动检测在可穿戴设备、工业状态监测、智能家居、康复医疗等领域有广泛需求。以智能手环为例，设备需要持续采集加速度计和陀螺仪数据，实时判断用户当前处于走路、跑步、静止、跌倒等状态，并在检测到异常时触发告警。这类应用对MCU的算力要求不高（通常只需数十至数百MIPS），但对功耗极其敏感——一颗CR2032纽扣电池（标称容量约220mAh）需要支撑设备连续工作6个月以上，这意味着系统平均功耗必须控制在1mW以内。

传统嵌入式运动检测依赖阈值判断或简单规则引擎，例如通过加速度幅值超过设定阈值来判定剧烈运动。这种方法实现简单、功耗低，但准确率有限，难以区分相似动作（如走路与慢跑），也无法适应不同用户的个体差异。机器学习方法（尤其是深度学习）能够从原始传感器数据中自动学习特征，显著提升分类准确率，但代价是模型推理需要额外的计算资源和内存开销。TinyML的核心价值在于：通过模型压缩、量化、算子优化等手段，将原本运行在服务器或手机端的神经网络模型，压缩到可以在MCU上实时运行的规模，同时保持可接受的精度。

从工程角度看，TinyML运动检测项目面临四个核心挑战：其一是模型体积与内存限制，主流MCU的Flash通常在256KB-1MB之间，RAM在64KB-256KB之间，而一个简单的全连接网络参数就可能超过100KB；其二是推理延迟约束，运动检测通常要求100ms以内的响应时间，否则用户体验会明显下降；其三是功耗预算，MCU在活跃模式下的功耗通常在5-20mA，而待机模式可低至1-5μA，如何合理安排采样、推理、通信的时序是功耗设计的关键；其四是传感器噪声与数据漂移，真实环境中的传感器数据与训练数据集存在分布差异，模型需要具备一定的鲁棒性。

1.2 课程学习目标与能力模型

本课程的学习目标分为三个层次：知识理解层、工程实践层和优化创新层。在知识理解层，学习者需要掌握TinyML的基本概念、ONNX模型格式的规范与转换流程、MCU上模型推理的运行时机制，以及嵌入式系统功耗的组成与测量方法。在工程实践层，学习者需要能够独立完成从Python训练脚本到MCU部署的完整链路，包括模型训练、导出ONNX、量化、生成C数组、编写推理代码、配置传感器驱动、实现低功耗调度等具体操作。在优化创新层，学习者需要具备分析系统瓶颈的能力，能够针对特定硬件平台调整模型结构、优化推理算子、设计功耗管理策略，并能够使用逻辑分析仪和功耗测量工具进行量化评估。

为了帮助学习者建立清晰的能力预期，下表列出了课程结束后应达到的具体技能指标：

1.3 课程整体框架与知识模块划分

本课程共30章，按照工程实施的自然流程划分为五个阶段。第一阶段（第1-5章）为基础与准备，涵盖TinyML概念、硬件平台介绍、开发环境搭建、传感器数据采集与可视化。第二阶段（第6-12章）为模型开发与转换，包括Python端模型训练、ONNX导出、量化与优化、模型验证。第三阶段（第13-20章）为MCU端部署，深入讲解ONNX Runtime Micro的移植与集成、内存管理、算子实现、推理性能优化。第四阶段（第21-26章）为功耗分析与调优，涉及功耗测量方法、低功耗模式配置、动态电压频率调整（DVFS）、通信功耗优化。第五阶段（第27-30章）为系统集成与项目实战，完成一个完整的跌倒检测与上报系统，并进行为期一周的长期稳定性测试。

课程内容的设计遵循"理论-实践-复盘"的闭环逻辑。每一章都包含核心原理讲解、操作步骤演示、常见问题分析三个部分。例如，在模型量化章节中，我们不仅会讲解对称量化和非对称量化的数学原理，还会演示如何使用ONNX Runtime的量化工具进行实际操作，并分析量化后模型精度下降的常见原因（如激活值分布不均匀、敏感层识别等）。在功耗调优章节中，我们会使用真实的功耗测量数据，展示不同配置下的电流波形，帮助学习者建立"功耗是设计出来的，不是测量出来的"这一工程理念。

1.4 前置知识要求与学习资源准备

为了确保学习效果，建议学习者在正式开始课程前完成以下准备工作。首先是硬件环境：一块STM32L4系列开发板（推荐NUCLEO-L476RG）、一个BMI270传感器模块（或集成在开发板上的IMU）、一个ST-Link调试器（NUCLEO板载）、一台逻辑分析仪（建议8通道以上，采样率≥100MHz）、一台功耗分析仪（如Joulescope或Otii Arc，如果没有也可以用万用表配合低侧采样电阻进行粗略测量）。其次是软件环境：STM32CubeIDE（版本≥1.10）、Python 3.8+（建议使用Anaconda环境）、ONNX Runtime（CPU版本即可）、PyTorch 1.12+或TensorFlow 2.8+、以及Git版本控制工具。

在开发环境搭建过程中，有一个常见的误区需要特别说明：很多初学者会直接在STM32CubeIDE中编写所有代码，包括模型推理部分。但实际上，ONNX Runtime Micro是一个独立的运行时库，需要先通过CMake交叉编译生成适用于目标MCU的静态库，然后在STM32CubeIDE中链接该库。这个流程涉及工具链的配合，如果配置不当，会出现链接错误或运行时崩溃。本课程第13章会详细演示完整的移植过程，并提供一份经过验证的CMake工具链文件。

另外，关于传感器数据的采集，我们推荐使用DMA（直接内存访问）配合FIFO（先进先出）缓冲区的方案。BMI270内置了一个1KB的FIFO，可以缓存多组传感器数据，MCU可以在FIFO半满或全满时通过中断批量读取数据，这样可以显著减少CPU的唤醒次数，降低功耗。课程中会提供完整的驱动代码，并对比轮询模式和中断模式的功耗差异。

1.5 案例拆解：从零开始搭建运动检测原型系统

为了帮助学习者建立对TinyML运动检测项目的整体认知，我们以一个简化的原型系统为例，展示从需求分析到初步验证的完整过程。假设我们需要为一个老年人家居环境设计一个跌倒检测设备，要求如下：设备佩戴在腰部，能够识别站立、行走、弯腰、跌倒四种状态；跌倒检测的灵敏度≥95%，特异性≥90%；设备使用两节AAA电池（总容量约800mAh）供电，目标续航≥3个月；检测到跌倒后，设备通过BLE发送告警信号到附近的网关。

首先进行需求分析与指标分解。根据续航目标，我们可以计算出平均功耗预算：800mAh / (3个月 × 30天 × 24小时) ≈ 0.37mA。考虑到电池的自放电率（约每年5%）和电源转换效率（约85%），实际可用平均电流约为0.3mA。在3.3V供电下，这对应约1mW的平均功耗。接下来，我们需要估算各功能模块的功耗占比：IMU传感器在正常采样模式下的功耗约为0.7mA（BMI270在2.4kHz采样率、正常量程下），MCU在活跃模式下的功耗约为4mA（80MHz主频），在睡眠模式下的功耗约为1μA，BLE模块在广播模式下的峰值功耗约为10mA（但平均功耗取决于广播间隔）。

基于这些数据，我们可以设计初步的功耗调度策略：IMU以50Hz采样率连续工作，每次采样后数据存入FIFO；MCU每2秒唤醒一次，从FIFO读取100个样本（2秒数据），执行一次模型推理（耗时约5ms），然后根据推理结果决定是否发送BLE广播。在这种方案下，MCU的活跃时间占比约为5ms/2000ms = 0.25%，平均功耗约为4mA × 0.25% + 1μA × 99.75% ≈ 11μA。IMU的功耗为0.7mA（如果支持低功耗模式，可以降低到0.3mA）。BLE如果每10秒广播一次，每次广播时间约5ms，平均功耗约为10mA × 0.05% = 5μA。系统总平均功耗约为0.7mA + 0.011mA + 0.005mA ≈ 0.716mA，已经接近0.3mA的目标，需要进一步优化。

优化方向包括：降低IMU采样率至25Hz（功耗减半）、使用IMU内置的运动唤醒功能（仅在检测到显著运动时才唤醒MCU）、优化BLE广播参数（增大广播间隔至30秒）、以及使用MCU的待机模式（在无运动时进入Standby模式，功耗降至0.3μA）。经过这些优化，系统平均功耗可以降至0.25mA左右，满足续航要求。这个案例展示了TinyML项目设计的核心方法论：先做功耗预算，再设计系统架构，最后进行细节优化。