3、硬件平台与开发板：nRF52/nRF53/nRF91系列介绍、开发板选型、外设资源与引脚映射

在部署TinyML模型时，硬件平台的选择直接决定了模型推理的能效比、内存预算以及传感器数据采集的可行性。nRF系列芯片并非为高性能计算设计，而是为超低功耗无线嵌入式场景而生，因此理解其架构差异、外设资源与引脚映射规则，是确保Zephyr工程能够正确编译、烧录并稳定运行的关键前提。本节将系统梳理nRF52、nRF53、nRF91三大系列的核心差异，给出开发板选型的决策路径，并深入解析外设资源与引脚映射的工程方法。

3.1 三大系列芯片架构与TinyML适配性分析

nRF52、nRF53、nRF91虽然同属Nordic产品线，但内部架构差异显著，这直接影响了Zephyr工程中设备树（Devicetree）的配置方式以及TinyML模型的部署策略。nRF52系列基于单核Cortex-M4F，主频64MHz，最高配备256KB RAM和1MB Flash，适合运行参数量在100KB以内的量化模型。nRF53系列采用双核异构设计，应用核为Cortex-M33（128MHz），网络核为Cortex-M4F（64MHz），两者通过IPC（Inter-Processor Communication）通信，这种架构允许将传感器数据采集与模型推理并行处理，显著提升系统吞吐量。nRF91系列则集成了LTE-M/NB-IoT调制解调器，应用核为Cortex-M33，其最大价值在于将TinyML推理结果直接通过蜂窝网络上传，省去外部MCU+通信模块的组合。

从TinyML部署角度看，nRF53的双核架构最具吸引力。M33核运行Zephyr RTOS和TFLite Micro解释器，M4F核专职处理传感器中断和DMA传输，两核共享512KB RAM（nRF5340 QKAA版本）。这种设计使得模型推理与数据采集互不阻塞，在音频关键词识别或振动异常检测场景中，可以稳定维持20ms以内的推理周期。而nRF52系列虽然算力有限，但其PPI（可编程外设互连）和GPIOTE（GPIO任务事件）机制允许外设直接触发CPU中断或DMA传输，无需CPU干预即可完成数据预处理，这对降低整体功耗至关重要。

3.2 开发板选型决策路径与Zephyr工程适配

开发板选型不能只看芯片型号，还需考虑调试器集成、板载传感器、Arduino兼容引脚布局以及Zephyr的board target支持情况。Nordic官方开发板中，nRF52840 DK和nRF5340 DK是最常用的TinyML实验平台。nRF52840 DK板载J-Link OB调试器、4个用户LED、2个按钮，并引出全部GPIO，兼容Arduino Uno Rev3引脚布局，这意味着大量现成的传感器扩展板可以直接插用。nRF5340 DK则额外提供了MIPI调试接口和更丰富的电源测量选项，便于分析模型推理时的动态功耗。

在Zephyr工程中，开发板选型直接对应board target名称。例如nRF52840 DK对应nrf52840dk/nrf52840，nRF5340 DK对应nrf5340dk/nrf5340（CPUAPP）。构建时需在prj.conf中显式配置CONFIG_BOARD_TARGET，并确保设备树文件（.dts）中的chosen节点正确指向外部Flash或传感器节点。对于第三方开发板（如MakerDiary nRF52840 MDK），需要手动添加board definition文件，这通常涉及创建boards/arm/xxx目录并编写board.cmake和Kconfig.board文件。

1. 确认调试接口：优先选择板载J-Link或DAPLink，避免额外购买调试器。
2. 检查Flash/RAM余量：在west build后查看build/zephyr/zephyr.map，确认模型权重和中间变量不超限。
3. 验证外设驱动：在Zephyr的samples/drivers中运行对应外设测试例程，确保SPI/I2C时序满足传感器要求。
4. 评估功耗测量能力：若需优化推理功耗，选择带电流测量引脚的开发板（如nRF5340 DK的P22引脚）。

3.3 外设资源深度解析：从设备树到引脚映射

Zephyr使用设备树描述硬件资源，引脚映射通过pinctrl子系统实现。在nRF系列中，每个GPIO引脚可复用为多种功能，例如P0.03既可作普通GPIO，也可配置为UART_TXD或SPI_SCK。设备树中的&pinctrl节点定义了引脚复用状态，而&gpio0或&gpio1节点则控制引脚方向和电平。TinyML工程中，传感器通常通过SPI或I2C连接，因此需要重点配置spi2或i2c1节点的pinctrl-0属性。

// nRF5340 DK 设备树片段：配置SPI1连接外部加速度计
&spi1 {
    compatible = "nordic,nrf-spim";
    status = "okay";
    pinctrl-0 = &spi1_default;
    pinctrl-names = "default";
    cs-gpios = <&gpio0 29 GPIO_ACTIVE_LOW>;
    
    accel: lis2dh12@0 {
        compatible = "st,lis2dh12";
        reg = <0>;
        spi-max-frequency = <1000000>;
        label = "ACCEL";
    };
};

&pinctrl {
    spi1_default: spi1_default {
        group1 {
            psels = <NRF_PSEL(SPIM_SCK, 0, 28)>,
                    <NRF_PSEL(SPIM_MOSI, 0, 30)>,
                    <NRF_PSEL(SPIM_MISO, 0, 31)>;
        };
    };
};

引脚映射时需注意nRF52系列GPIO端口为P0.00-P0.31和P1.00-P1.31，而nRF53和nRF91系列增加了P2端口。Zephyr的NRF_PSEL宏接受端口号和引脚号，例如NRF_PSEL(SPIM_SCK, 0, 28)表示P0.28作为SPI时钟。在TinyML应用中，建议将传感器中断引脚连接到支持GPIOTE的引脚（如P0.08），以便在数据就绪时通过事件触发CPU唤醒，避免轮询浪费功耗。

3.4 案例拆解：基于nRF5340 DK的振动监测TinyML节点

本案例目标是在nRF5340 DK上部署一个振动异常分类模型，输入为3轴加速度计数据，输出为“正常/异常”二分类结果。硬件连接为：ADXL345加速度计通过SPI1连接至P0.28（SCK）、P0.30（MOSI）、P0.31（MISO），片选接P0.29，中断输出接P0.08（GPIOTE）。Zephyr工程配置了CONFIG_TFLITE_MICRO和CONFIG_SPI_SUPPORT，模型使用TensorFlow训练后转换为C数组。

初始现象：模型推理结果正确，但系统整体功耗高达12mA，远超预期。通过分析power_profiler日志发现，SPI通信期间CPU频繁唤醒，且ADC采样未使用DMA。进一步检查设备树，发现spi1的cs-gpios未指定，导致Zephyr使用软件控制片选，每次传输都触发GPIO中断。优化步骤：1）在设备树中显式添加cs-gpios属性；2）将加速度计数据读取改为SPI DMA模式，配置CONFIG_SPI_DMA=y；3）利用GPIOTE事件触发传感器数据就绪中断，替代轮询。

优化后功耗降至4.5mA，推理周期稳定在15ms。复盘经验：TinyML部署中，外设配置的细节往往比模型优化更能影响整体性能。建议在开发初期就使用Zephyr的sensor驱动框架，而非直接操作SPI寄存器，这样可以利用驱动层内置的DMA和电源管理优化。

3.5 常见误区与总结复盘

在nRF系列上部署TinyML时，开发者常陷入几个误区。第一，盲目追求高主频芯片，忽略外设瓶颈——实际上nRF5340的M33核在128MHz下运行TFLite Micro，其性能瓶颈往往在Flash读取速度和RAM带宽。第二，忽视引脚映射的电气特性，例如将SPI MISO引脚配置为开漏输出，导致通信失败。第三，未利用PPI和GPIOTE硬件加速机制，使得CPU频繁处理中断，增加功耗和延迟。

总结本章核心要点：nRF52适合轻量级单传感器应用，nRF53的双核架构是复杂TinyML场景的首选，nRF91则面向广域物联网。开发板选型需结合Zephyr board target支持、调试便利性和外设扩展性。引脚映射必须通过设备树pinctrl精确配置，并验证电气特性。最后，建议在工程初期就建立功耗基线，使用Nordic的Power Profiler Kit进行测量，确保模型推理的能效比达到预期。