引言

高性能STM32微控制器以及软件架构上的释放限制，为更高级的软件解决方案打开了大门。高级软件应用程序需要独立组件同时运行。STM32H745/755和STM32H747/757系列的微控制器具有非对称双核架构;因此，通过两个CPU并行处理，确保可以运行不同的负载。然而，往往存在需要相互通信以共享信息并确保正确处理的任务。 由于这些原因，需要使用处理器间通信(IPC)层来链接数据依赖任务。 ****为了简化核心间交互并缩短上市时间，STM32CubeH7提出了一套标准中间件，用于实现Arm®Cortexe-M7与Arm®Cortex®-M4之间的处理器间通信通道(IPCC)。本应用笔记提供了双核通信技术的概述，并介绍了OpenAMP、RPMSg、FreeRTOS等处理器间通信通道。"此外还包括消息缓冲区和自定义通信机制。它还提供了一个详细的流程图以及代码片段示例，以说明如何使用OpenAMP和FreeRTOS。"以创建核心之间的通信通道。

基本信息

2 双核通信

在针对 STM32H745/755 和 STM32H747/757 器件的双核架构进行开发，以设计需要并行执行的应用时，必须采用一种通信和同步机制，来确保两个内核之间的交互不会出现意外行为。本节重点介绍处理器间通信技术，并给出一些用例示例。 **注意**：有关这些器件双核架构的更多详细信息，请参阅应用笔记《STM32H745/755 和 STM32H747/757 系列双核架构》（AN5557），可从 www.st.com 获取。

2.1 需使用 IPCC 的典型用例

在许多应用示例中都需要通信通道。本节列出了****非详尽的**处理器间通信通道示例，包括：事件通知、请求远程服务以及有效载荷处理。 （注：IPCC 通常指“Inter-Processor Communication Controller，处理器间通信控制器”）**

2.1.1 事件通知

事件通知可用于同步两个内核上任务的执行，尤其是在需要数据处理流水线的场景中。下图展示了一个典型用例：一个内核可运行事件监控进程，并发送通知以唤醒第二个内核，从而启动所需的处理。这种情况的一个实际示例是，通过 CPU2 的用户界面进行语音激活模式检测，并使用 CPU1 执行相应命令。 该通知机制还可控制 CPU1 上的应用程序生命周期。例如，当没有更多数据可供处理时，可使用 IPCC（处理器间通信控制器）发送相应事件，从而将 CPU1 切换到低功耗模式。为了在执行复位前保证系统处于安全状态（如关闭已打开的文件、清空日志/缓冲区），当 CPU2 接收到复位命令时，可向 CPU1 发送通知。

2.1.2 请求远程服务

为了在使用外设时减少并发情况以及驱动代码重复（包括栈），部分服务可在其中一个 CPU 上实现。这种做法有助于减小代码体积，并解决与资源共享相关的其他问题。一旦某个任务需要该服务，它可通过处理器间通信通道发起请求。此类服务的示例包括文件系统管理和串行通信接口。

2.1.3 有效载荷处理

通过功能划分，可将 CPU1 设为执行计算密集型任务，而实时任务（如传感器采集和控制）则由第二个内核承担。这种做法能够满足应用在**性能和功耗**方面的需求。 在 CPU2 预处理数据（数据采集、处理连接性）期间，将 CPU1 置于**低功耗模式**，之后再唤醒 CPU1 以运行密集数据计算算法，这样可以降低整体功耗。 此外，可通过通信通道将**处理指令**（如数据大小、数据类型或处理类型）从 CPU2 传递到 CPU1。**

2.2 技术实现

实现两个 CPU 之间通信所需的基本环境是一块共享内存区域。如下一个图所示，该技术用于交换数据和通知，从而同步对共享区域的访问。

2.2.1 共享内存

实现共享内存区域的第一步是选择一块两个内核都能使用且可访问的内存区域。STM32H745/755 和 STM32H747/757 器件在两个内核之间实现了对称的内存映射。如下表所示，这种架构使得约 82% 的 SRAM 可被两个 CPU 直接访问，并能用于数据交换。

一些实践做法是将交换缓冲区映射到****公共电源域**（始终对 CPU 可用），以便在其中一个 CPU 处于低功耗模式时，另一个 CPU 仍能访问共享内存。**

D3 域配备了 64 KB 的 SRAM 和 4 KB 的备份 SRAM（BKSRAM）。SRAM4 和 BKSRAM 能被 Cortex®-M7 和 Cortex®-M4 访问，而且当 D1 或 D2 域处于低功耗模式时，它们依然可用。D3 RAM 可作为消息交换的共享内存。 D1 和 D2 的 RAM（TCM 除外）仍可用于实现交换缓冲区。

由于当其中一个 CPU 处于 CSleep 或 CStop 模式时，SRAM 需要分配给两个 CPU，才能保持可读写数据的状态，这会对应用的功耗效率产生影响。

注意：** 有关双核电源管理的更多详细信息，请参考应用笔记《STM32H747/757 高级电源管理》（AN5215），该文档可在 www.st.com 获取。 在处理内存中的共享数据时，缓存与数据一致性是需要重点考虑的问题。开发者必须为应用制定恰当的策略。以下是几种可预见的实现场景： - 通过 CMSIS 函数以软件方式执行运行时缓存维护。在向 CPU2 发送通知以及使用来自 CPU2 的数据前，需执行数据缓存清理操作。**

使用内存保护单元（MPU）将共享内存区域设置为不可缓存，以确保数据的一致性与连贯性。

注意**： 有关数据一致性的更多详细信息，请参考应用笔记《STM32F7 系列和 STM32H7 系列的一级缓存》（AN4839），可在 www.st.com 获取。 **

****注意**： 有关内存保护单元（MPU）的更多详细信息，请参考应用笔记《STM32 微控制器中内存保护单元的管理》（AN4838），可在 www.st.com 获取。**

2.2.2 通知机制

通过一个内核向另一个内核发送****通知或中断请求**，有助于保障数据一致性，同时减少轮询新消息的耗时。 STM32H745/755 和 STM32H747/757 这类双核器件，提供了丰富的方案来实现通知机制。若要在其中一个内核侧生成中断，软件可采用以下方式：硬件信号量释放中断（HSEM）、外部中断/事件控制器（EXTI）的软件中断与事件寄存器，或者 CPU 的发送事件指令（SEV）。此外，HSEM、EXTI 和 SEV 还能将 CPU 及其对应的电源域从低功耗模式唤醒，从而处理传入的消息。**

3 STM32 处理器间通信通道

本节介绍 STM32CubeH7 固件中提供的处理器间通信库的基本信息，包括 OpenAMP 和 RPmsg API，以及 FreeRTOS™ 的消息缓冲区和流缓冲区 API。此外，还介绍了一些利用 STM32H745/755 和 STM32H747/757 硬件资源实现的基础处理器间通信控制器（IPCC）相关内容。

3.1 OpenAMP 和 RPMsg

本节介绍 OpenAMP（开放式异构多处理）与 RPMsg（远程处理器消息传递）库的相关信息。 OpenAMP 是一套框架，提供了开发****异构多处理（AMP）系统**应用所需的软件组件。它通过 remoteproc、RPMsg 等开源组件，对异构嵌入式系统中不同操作环境之间的交互进行了标准化。 RPMsg 是 OpenAMP 框架的组件，支持运行在不同 CPU 上的应用开展**处理器间通信**。它是基于虚拟 I/O 的消息传递库，能让主处理器上的 RTOS（实时操作系统）或裸机应用与远程 CPU 固件交互，并通过标准 API 通信。在 OpenAMP 框架中，定义了“主（Master）”和“从（Slave）”的术语表述。 虚拟 I/O 实现了**共享内存管理**的标准。OpenAMP 借助远程处理器固件资源表发布的信息，分配系统资源并创建虚拟 I/O 设备。下图表展示了在 RTOS 或裸机环境中 RPMsg 的实现示例。**

从 CPU1 向 CPU2 发送消息的流程如下： 作为主核心的 CPU1 在发送数据时，会从用于传输的共享内存中分配缓冲区，向其中写入 RPMsg 头部和数据有效载荷。最后，它会把这些缓冲区放入环形缓冲区的队列中，让 CPU2 可以获取到。下面会展示这个流程：

3.2 reeRTOS 消息缓冲区与流缓冲区

从 10.0.0 版本起，FreeRTOS™ 实现了处理器间通信的 API。以下章节将介绍消息缓冲区和流缓冲区的 API。

3.2.1 消息缓冲区

消息缓冲区支持将****可变长度的离散消息**从中断服务程序传递到任务，或是在任务之间传递。比如，长度为10字节、20字节、123字节的消息，都能写入同一个消息缓冲区，也能从该缓冲区读取。一条10字节的消息只能以“10字节的完整消息”被读取，而非拆成单个字节读取。消息缓冲区是基于流缓冲区的实现搭建的。 消息缓冲区需要一个字（word）来存储有效载荷的数据长度。在32位架构中，这个长度通常存放在一个4字节的变量里。因此，向消息缓冲区写入一条10字节的消息时，会占用14字节的缓冲区空间；同理，写入一条100字节的消息会占用104字节的缓冲区空间。**

3.2.2 流缓冲区

流缓冲区允许字节流从中断服务程序传递到任务，或者从一个任务传递到另一个任务（如下图所示）。字节流可具有任意长度，且不一定有起始或结束标识。可一次性写入任意数量的字节，也可一次性读取任意数量的字节。 流缓冲区的实现采用了针对****速度和内存占用**优化的通知机制。因此，调用会使调用任务进入阻塞状态的流缓冲区 API 时，可能会改变调用任务的通知状态和值。 与 FreeRTOS™ 的大多数其他通信原语不同，流缓冲区针对**单读取者、单写入者**场景进行了优化。存在多个写入者或读取者的情况下，操作是不安全的。 在双核微控制器上从一个 CPU 向另一个 CPU 传递数据时，数据通过**复制**的方式传递：发送方将数据复制到缓冲区中，读取方再从缓冲区中复制出数据。**

3.3 使用 STM32H745/755 和 STM32H747/757 的硬件资源

可利用 STM32H745/755 或 STM32H747/757 器件内置的可用外设，实现轻量级的处理器间通信通道。例如，中断线可用于发送事件信号或传递“数据可用”的信息；像 DMA 通道这类其他外设，可用于传输数据，并从一方到另一方生成传输完成的通知。这种方案属于定制化方案，不像 OpenAMP 或 FreeRTOS™ 的远程消息传递实现那样具有通用性。

3.3.1 硬件信号量

STM32 微控制器上的硬件信号量外设，支持在两个 CPU 之间实现通知与事件交互（见下图）。

HSEM（硬件信号量）外设为 CPU1 和 CPU2 的中断控制器提供了两条中断线，其通知功能能让开发者实现内核间的事件交互。 在 STM32H7 系列产品中，HSEM 外设还与 EXTI（外部中断/事件控制器）相连；借助这种连接，即便 CPUy 处于低功耗模式，也能管理从 CPUx 到 CPUy 的通知。

HSEM 可用于在 CPU 之间传递简单的通知事件，也能被固件开发者用来向运行在另一个 CPU 上的任务“提示”：共享内存结构中已有新数据可用。

3.3.2 EXTI 控制器与发送事件指令

STM32H745/755 和 STM32H747/757 系列器件的架构及内部连接，支持开发者实现通知机制。CPU1 的事件输出信号（TXEV）与 EXTI 控制器相连，这能触发 CPU2 上的中断或事件；且这种连接是双向的（从 CPU1 到 CPU2、从 CPU2 到 CPU1，如下图所示）。在固件中只需执行 SEV（发送事件指令），就能触发事件输出信号。此外，EXTI 可根据应用需求，对 TXEV 信号产生的事件和中断进行屏蔽或取消屏蔽操作。

注意**：CPU1 发出的 TXEV 脉冲持续时间为 512 个 AHB 周期，CPU2 上运行的固件需要考虑这一持续时间。512 个 AHB 周期的脉冲持续时间，可使 CPU2 无论两个 CPU 之间的时钟比例如何，都能正确锁存该事件。**

3.3.3 DMA 和 MDMA

除硬件信号量外设与事件输出互连外，DMA（直接内存访问）或 MDMA（多通道直接内存访问）有助于实现 CPU1 上运行的任务与 CPU2 上运行的任务之间的通信。DMA 的“内存到内存”模式可作为传输通道，将数据从某一 CPU 的 SRAM 缓冲区复制到共享缓冲区（供 CPU2 使用）；而“传输完成”中断可用于通知 CPU2：已有新数据写入该共享缓冲区。

这种方法中使用 DMA 的优势在于，数据复制由 DMA 执行，从而减轻了 CPU 的负担。由于产品中配备了两个以上的 DMA 控制器，在应用资源划分期间，可定义专用通道来执行处理器间通信。