课程导入：学习目标、课程结构、交付物总览及Nordic nRF系列在TinyML中的定位

欢迎进入《Nordic nRF TinyML交付：源码、固件、功耗报告和测试文档》课程。这是整个30章系列课程的开篇，我们将从全局视角审视一次完整的TinyML项目交付需要包含哪些核心资产，以及Nordic nRF系列芯片为何在边缘机器学习领域占据独特地位。在后续29章中，我们将逐一深入源码架构、固件构建、功耗测量、测试策略等具体环节，而本章将为你建立完整的知识地图和交付物框架。

1.1 学习目标：从“能跑模型”到“可交付产品”

本课程的核心目标不是教会你如何在Nordic nRF芯片上运行一个简单的神经网络——那只是起点。真正的交付能力体现在：当客户或上级要求你提交一套完整的TinyML解决方案时，你能够拿出源码、固件、功耗报告和测试文档四类资产，并且每一类都达到工程级质量。具体而言，完成本课程后你将具备以下能力：

• 源码层面：能够组织清晰的嵌入式C/C++工程结构，将TensorFlow Lite Micro（TFLM）或Nordic nRF Connect SDK中的ML运行时正确集成，并管理模型权重、预处理代码、推理调用和后处理逻辑的模块化划分。
• 固件层面：掌握从源码到可烧录固件的完整构建流程，包括CMake配置、链接脚本调整、分区表设计，以及如何生成适用于nRF52840/nRF5340的hex或UF2文件。
• 功耗报告层面：能够使用Nordic Power Profiler Kit（PPK2）或其他工具，测量推理任务在不同工作状态（活跃、空闲、睡眠）下的电流曲线，并计算单次推理的平均功耗和能量消耗。
• 测试文档层面：建立覆盖功能正确性、性能指标（推理延迟、吞吐量）、鲁棒性（输入扰动、温度变化）和合规性（如FCC/CE对无线模块的要求）的测试矩阵，并输出可追溯的测试报告。

1.2 交付物总览：四类资产构成完整闭环

一次专业的TinyML项目交付，绝不是“把代码扔给客户”那么简单。下表列出了四类核心交付物及其关键内容、验收标准和常见问题。

交付物	核心内容	验收标准	常见缺陷
源码	模型文件（.tflite）、C/C++工程、配置文件、构建脚本、README	可独立构建、代码风格统一、依赖完整、有版本记录	缺少模型来源说明、硬编码路径、无构建文档
固件	可烧录的hex/UF2文件、烧录工具说明、固件版本号、校验和	烧录后功能正常、版本可识别、支持回滚	固件与源码不对应、无版本标识、烧录步骤缺失
功耗报告	测试环境描述、电流波形截图、平均/峰值电流、能量消耗、电池寿命估算	测量方法可复现、数据有统计意义、结论明确	未标注测试条件、样本量不足、无对比基线
测试文档	测试计划、用例列表、执行记录、缺陷报告、性能数据	用例覆盖需求、结果可追溯、缺陷已闭环	测试与需求脱节、无失败记录、数据不可复现

这四类交付物之间存在强依赖关系：源码是固件的输入，固件是功耗测试的对象，而测试文档则贯穿整个开发过程并记录所有验证活动。在实际项目中，我们建议采用“文档先行”的策略——在编写第一行代码之前，先定义测试计划和功耗验收指标，这样后续开发才有明确的目标。

1.3 Nordic nRF系列在TinyML中的定位

Nordic Semiconductor的nRF52系列（特别是nRF52840）和nRF53系列（nRF5340）在TinyML领域具有独特的生态位。与高性能的MCU（如STM32H7）或应用处理器（如树莓派）不同，nRF系列的核心优势在于超低功耗与无线连接的深度融合。这使得它成为可穿戴设备、医疗传感器、工业监测节点等电池供电边缘设备的理想选择。

从硬件规格来看，nRF52840搭载Arm Cortex-M4F内核，主频64MHz，内置1MB Flash和256KB RAM，支持BLE 5.0、NFC和USB。而nRF5340则采用双核架构（Cortex-M33应用核 + Cortex-M33网络核），主频高达128MHz，拥有更丰富的安全特性和更大的存储空间。对于TinyML应用，这些资源足以运行经过量化的MobileNetV1、LSTM或异常检测自编码器。

在软件生态方面，nRF Connect SDK（NCS）基于Zephyr RTOS，提供了对TensorFlow Lite Micro的官方支持。这意味着开发者可以直接在Zephyr环境中调用TFLM的C++ API，而无需自行移植。此外，Nordic的Power Profiler Kit 2（PPK2）是业界公认的高精度功耗测量工具，能够以高达75kHz的采样率捕捉微安级别的电流变化，为功耗报告提供可靠的数据基础。

1.4 案例拆解：一个智能穿戴设备的交付物规划

为了让你更直观地理解四类交付物如何在实际项目中落地，我们来看一个具体的案例。假设我们要为一款智能手环开发“跌倒检测”功能，使用nRF52840作为主控，加速度计数据通过TFLM模型进行实时推理。

项目背景与约束：手环电池容量为100mAh，目标续航至少7天；跌倒检测的响应时间要求小于200ms；模型必须在设备端运行，不能依赖云端。初始阶段，团队只有一名嵌入式工程师和一名数据科学家，开发周期为6周。

交付物规划：

1. 源码交付：包含三个层级——模型层（.tflite文件 + 量化脚本）、应用层（传感器读取、特征提取、推理调用、报警逻辑）、集成层（Zephyr设备树配置、TFLM运行时集成）。每个层级都有独立的README说明构建方法和依赖。
2. 固件交付：提供两个版本的hex文件——开发版（启用日志输出）和发布版（关闭日志、优化编译选项）。每个固件都通过Nordic的nrfutil工具签名，并在固件头部写入版本号0x0100。
3. 功耗报告：使用PPK2测量三种场景——待机（BLE广播关闭）、监听（BLE连接但无数据）、推理（每100ms一次推理）。报告显示：待机电流2.1µA，监听电流45µA，推理期间平均电流3.2mA（持续15ms）。计算得出平均功耗约0.5mW，预计电池寿命约8.2天，满足7天目标。
4. 测试文档：包含30个功能测试用例（如不同跌倒姿态、误触发场景）、10个性能测试用例（推理延迟、内存峰值）和5个功耗测试用例。测试记录显示，在200次模拟跌倒中，检出率98.5%，误报率0.5次/天。

这个案例的关键在于：功耗报告不是事后测量，而是驱动设计决策的工具。在开发过程中，我们发现推理频率从50ms改为100ms后，功耗降低了40%，而检出率仅下降0.3%。这一发现直接改变了固件的调度策略，并最终写入了测试文档的“优化建议”章节。

1.5 常见误区与总结复盘

在多年TinyML项目交付中，我们总结了以下高频误区，希望你在学习本课程时引以为戒：

• 误区一：只交付源码，不交付固件。很多开发者认为“源码给你了，你自己编译就行”。但客户往往不具备构建环境，或者构建工具链版本不一致导致失败。专业交付必须包含预编译固件。
• 误区二：功耗报告只给一个数字。“平均电流5mA”这样的报告毫无价值。必须说明测试条件（供电电压、环境温度、采样率）、测量设备、统计方法（样本数、标准差），并区分不同工作状态。
• 误区三：测试文档只记录“通过”。一份可信的测试文档必须包含失败的用例、缺陷分析和修复记录。如果所有测试都一次通过，反而让人怀疑测试的有效性。
• 误区四：忽略版本对应关系。源码、固件、功耗报告和测试文档必须指向同一个版本。建议使用Git标签（如v1.0.0）将四者关联起来，并在每个文档中标注对应的commit哈希。