4、双核通信基础：IPC（Inter-Processor Communication）、mbox、共享内存、信号量等机制

nRF5340 作为一款双核 SoC，其应用核（Application Core，Cortex-M33）与网络核（Network Core，Cortex-M33）各自独立运行，拥有独立的时钟、中断控制器和内存映射。要让两个核协同完成 AI 推理任务（例如应用核负责传感器数据采集与结果呈现，网络核负责 BLE 协议栈或模型推理加速），就必须建立一套高效、可靠、低延迟的核间通信机制。本章将深入剖析 nRF5340 双核通信的底层原理与工程实践，重点讲解 IPC（Inter-Processor Communication）框架、mbox（邮箱）硬件机制、共享内存（Shared Memory）以及信号量（Semaphore）在双核协作中的角色与用法。

应用核 (Cortex-M33) AI 推理任务 传感器采集 结果呈现 IPC 框架 mbox 驱动 共享内存管理 信号量同步 事件回调 网络核 (Cortex-M33) BLE 协议栈 模型推理加速 无线通信 IPC 框架 mbox 驱动 共享内存管理 信号量同步 事件回调 共享内存 SRAM 区域 mbox 通道 信号量: 互斥/同步 硬件信号量单元

上图展示了 nRF5340 双核通信的整体架构。两个核心通过硬件 mbox 邮箱传递短小控制消息，通过共享内存交换大数据块，通过硬件信号量单元实现互斥与同步。IPC 框架（如 Zephyr 的 ipc_service）则对底层硬件进行抽象，向上层应用提供统一的 API。理解这些机制的分工与配合，是设计高效双核 AI 应用的关键。

4.1 核心原理：从硬件原语到软件框架

nRF5340 的双核通信建立在三个硬件基础之上：mbox（Mailbox）、共享内存（Shared Memory）和硬件信号量（HW Semaphore）。这三个硬件单元各有分工，互为补充。

  • mbox 邮箱：本质是一组可产生中断的寄存器对。应用核写入 mbox 寄存器，网络核立即收到中断，反之亦然。mbox 适合传递 控制信息（如“数据已就绪”“请开始推理”）和 小数据（如状态码、命令字），传输延迟极低（纳秒级），但不适合传输大量数据。
  • 共享内存：两个核都可以访问的 SRAM 区域。通过配置 sram_shared 节点，在链接脚本中预留一段物理内存，两个核通过各自的地址映射访问同一物理区域。共享内存适合传输 大数据块（如音频帧、图像数据、模型输入输出张量），但需要解决 缓存一致性 和 并发访问 问题。
  • 硬件信号量：nRF5340 内置一组硬件信号量单元（共 16 个），支持原子性的获取（take）和释放（give）操作。硬件信号量用于保护共享资源（如共享内存的读写权限），避免两个核同时写入造成数据损坏。与软件信号量相比，硬件信号量不依赖操作系统调度，在中断上下文和低功耗模式下依然可靠。

在软件层面，Zephyr RTOS 提供了 ipc_service 框架，将上述硬件机制封装为两种主要 API：IPC 实例（IPC instance） 和 IPC 通道（IPC channel）。应用核与网络核各自注册一个 IPC 实例，通过绑定通道 ID 建立逻辑连接。当一端调用 ipc_service_send() 时，框架自动完成 mbox 触发、共享内存写入和信号量保护，另一端通过回调函数接收数据。这种分层设计让开发者无需直接操作寄存器，但理解底层机制对性能调优和问题排查至关重要。

关键认知：mbox 是“信使”，共享内存是“仓库”，信号量是“锁”。信使通知仓库已备货，锁确保同一时间只有一个人进出仓库。三者缺一不可，但各自职责不同，不能互相替代。

4.2 判断方法与操作流程：如何选择通信机制

在实际开发中，工程师需要根据数据特征和实时性要求，选择最合适的通信组合。下表总结了三种机制的适用场景与性能特征：

通信机制 数据量 延迟 典型用途 注意事项
mbox 邮箱 ≤ 4 字节（寄存器宽度） 纳秒级 命令通知、状态同步、事件触发 寄存器数量有限，不可传输大数据
共享内存 KB ~ MB 级 微秒级（受内存访问速度限制） 音频帧、图像、模型权重、推理结果 需处理缓存一致性，需信号量保护
硬件信号量 无数据承载 纳秒级 互斥锁、资源计数、任务同步 数量有限（16 个），需合理分配

选择通信机制的判断流程如下：

  1. 评估数据量：若单次传输小于 4 字节且为控制信息，优先使用 mbox；若数据量超过几十字节，必须使用共享内存。
  2. 评估实时性：若要求端到端延迟小于 10 微秒，mbox 中断路径是最佳选择；共享内存的延迟主要来自缓存刷新和信号量等待，通常可控制在 10-50 微秒。
  3. 评估并发风险：只要存在两个核同时读写同一内存区域的可能，就必须引入信号量保护。即使只有一个写者一个读者，也可能因缓存不一致导致数据错乱。
  4. 考虑功耗约束：在低功耗模式下，mbox 中断可以唤醒核心，而共享内存访问不会产生中断。若网络核处于睡眠状态，应用核需先通过 mbox 唤醒它，再准备共享数据。

经验建议：在 AI 推理任务划分中，推荐采用“mbox 通知 + 共享内存传输 + 信号量保护”的组合模式。例如，应用核将传感器数据写入共享内存，释放信号量，然后通过 mbox 发送“数据就绪”命令；网络核收到中断后，获取信号量，读取数据，执行推理，再将结果写回共享内存，释放信号量，通过 mbox 回复“推理完成”。这种模式既保证了数据吞吐量，又实现了低延迟通知。

4.3 案例拆解：双核 AI 推理任务的数据流水线

下面通过一个具体的工程案例，展示如何在实际项目中运用上述机制。假设我们要设计一个 无线 AI 音频分类器：应用核负责从 PDM 麦克风采集音频数据（16kHz，16bit，每帧 20ms），网络核负责运行轻量级神经网络模型进行关键词识别（如“Hey Nordic”），识别结果通过 BLE 发送到手机。

初始现象与约束：

  • 每帧音频数据量为 20ms × 16kHz × 2 字节 = 640 字节，属于中等数据量，必须使用共享内存。
  • 推理必须在 20ms 内完成，否则下一帧数据到来时会产生覆盖，因此端到端延迟需控制在 15ms 以内。
  • 两个核都需要访问共享内存，且存在生产者-消费者关系，必须使用信号量防止数据竞争。

关键参数设计：

// 共享内存区域定义（链接脚本中预留 4KB）
sram_shared: 0x2007C000, size 0x1000

// 共享数据结构
typedef struct {
    int16_t audio_data[320];  // 20ms @ 16kHz 单声道
    uint32_t frame_id;        // 帧序号，用于检测丢帧
    uint8_t  status;          // 0=空, 1=满, 2=推理中
    uint8_t  result;          // 识别结果
} shared_audio_frame_t;

// 硬件信号量分配
#define SEM_AUDIO_READY  0   // 应用核→网络核：数据就绪
#define SEM_AUDIO_DONE   1   // 网络核→应用核：推理完成
#define SEM_MEM_PROTECT  2   // 共享内存互斥锁

操作流程：

  1. 初始化阶段：应用核与网络核各自调用 ipc_service_init()，绑定 mbox 通道 ID（如通道 0 用于音频数据通知，通道 1 用于结果通知）。共享内存区域清零，信号量 SEM_MEM_PROTECT 初始值为 1（可用）。
  2. 数据采集与发送：应用核的 PDM 驱动每 20ms 产生一次 DMA 完成中断，将音频数据拷贝到共享内存的 audio_data 数组。拷贝完成后，获取 SEM_MEM_PROTECT 信号量，更新 status=1，释放信号量。然后通过 mbox 通道 0 向网络核发送命令字 0x01（数据就绪）。
  3. 网络核推理：网络核收到 mbox 中断后，在中断回调中获取 SEM_AUDIO_READY 信号量（该信号量由应用核在发送 mbox 前释放），然后获取 SEM_MEM_PROTECT 信号量，读取 audio_data 和 frame_id，释放 SEM_MEM_PROTECT。接着执行神经网络推理，将结果写入 result 字段，更新 status=2，释放 SEM_AUDIO_DONE 信号量，并通过 mbox 通道 1 回复应用核。
  4. 结果处理：应用核收到 mbox 通道 1 中断后，获取 SEM_AUDIO_DONE 信号量，读取 result，通过 BLE 发送到手机。同时准备接收下一帧数据。

结果对比与复盘：

实测端到端延迟约为 1.2ms（mbox 中断响应 + 信号量获取 + 内存拷贝 + 推理），远小于 15ms 的预算。但调试过程中发现两个问题：一是当网络核忙于推理时，应用核可能连续发送多帧数据，导致共享内存覆盖。解决方案是增加一个 frame_id 校验，应用核在写入前检查网络核是否已处理完上一帧（通过 status 字段）；二是缓存一致性问题，由于两个核的 Cortex-M33 都带有缓存，需要将共享内存区域配置为 非缓存（non-cacheable） 属性，或在每次访问前后执行 __DSB() 屏障指令。最终在设备树中为 sram_shared 节点添加 zephyr,memory-attr = "non-cacheable" 解决。

风险提示：硬件信号量数量有限（16 个），且不可动态创建。在设计阶段应提前规划信号量分配表，避免多个功能模块争用同一信号量。此外，在低功耗模式下，mbox 中断可以唤醒核心，但共享内存访问不会自动唤醒，需要软件配合电源管理策略。

4.4 常见误区与总结复盘

在双核通信开发中，工程师常犯以下错误，需要特别注意：

  • 误区一：认为 mbox 可以传输大数据。mbox 寄存器宽度有限，强行将大数据拆分为多次 mbox 传输会显著增加延迟和中断负载。正确做法是 mbox 只传指针或索引，数据走共享内存。
  • 误区二：忽略缓存一致性。Cortex-M33 的缓存是 PIPT（物理索引物理标签）的，但两个核的缓存彼此不感知。若共享内存被标记为 cacheable，一个核写入的数据可能只存在于 L1 缓存中，另一个核读取时看到的是旧数据。必须将共享区域配置为 non-cacheable，或使用 arm_nvic 提供的缓存维护函数。
  • 误区三：信号量使用不当。硬件信号量是“非阻塞”的，获取失败会立即返回错误码，需要软件自旋等待。在中断上下文中自旋等待要格外小心，避免死锁。推荐在中断回调中仅做标记，实际的数据处理放到线程上下文。
  • 误区四：忽视 mbox 中断优先级。mbox 中断默认优先级可能较低，在高负载下可能被其他中断延迟。应根据实时性要求，将 mbox 中断设置为较高优先级（如 0 或 1），并确保两个核的中断优先级配置一致。

总结复盘：双核通信的本质是“分工明确、协作有序”。mbox 负责“通知”，共享内存负责“承载”，信号量负责“保护”。在实际项目中，建议遵循以下设计原则：

  1. 先画数据流图，明确每个数据块的产生者、消费者、大小和频率，再决定使用哪种机制。
  2. 共享内存区域使用独立的内存段，并配置为 non-cacheable，避免缓存一致性问题。
  3. 信号量分配表写入设计文档，每个信号量有明确的用途和持有者，避免复用。
  4. 在开发初期就建立双核通信的 压力测试，模拟满负载和低功耗切换场景，验证通信可靠性。
  5. 利用 Zephyr 的 ipc_service 框架时，注意其回调上下文（中断或线程），在回调中只做轻量操作，重操作通过消息队列或工作队列延后处理。

掌握这些基础机制后，开发者就可以在 nRF5340 上灵活设计双核 AI 应用的任务划分，将实时性要求高的任务放在应用核，将协议栈和复杂计算放在网络核，充分发挥双核的并行处理能力。

← 上一章 📖 返回目录 下一章 →