1. STM32MP产品架构总览

STM32MP 是意法半导体把“实时控制”与“应用处理”放进同一颗芯片的异构产品线。理解它的第一步，不是记住外设数量，而是先建立一张“谁负责什么、谁访问哪里、谁和谁通信”的架构图。只有把双核 Cortex-A7 与 Cortex-M4 的分工、内存映射和外设归属看清楚，后续的启动链、设备树、驱动开发和实时任务划分才有落脚点。

一、型号谱系与定位

STM32MP 目前主流分为三条线：STM32MP1（如 MP151、MP153、MP157）、STM32MP2（如 MP25x）以及面向安全与边缘 AI 的衍生型号。MP1 系列内部又按“是否带 3D GPU、是否带 DSI 显示接口、M4 是否可用”细分：MP151 为单 A7 + M4 的基础型，MP153 增加显示与 GPU 相关资源，MP157 则是双 A7 + M4 + GPU 的旗舰配置。选型时先问三个问题：需不需要双 A7 跑 Linux 多任务？需不需要 M4 做硬实时？需不需要 GPU/DSI 做图形界面？三个“需要”决定型号档位，而不是先看主频。

二、双核异构架构：A7 与 M4 的分工

Cortex-A7 运行 Linux，负责文件系统、网络协议栈、图形界面、应用逻辑；Cortex-M4 运行裸机或 RTOS（如 FreeRTOS），负责微秒级响应的电机控制、采样闭环、安全联锁。两者不是主从关系，而是对等但职责分离的两个执行域。它们通过芯片内部的 IPCC（处理器间通信控制器）产生中断，配合共享内存传递数据，形成“消息通知 + 数据搬运”的协作模式。

典型数据通路是：M4 采集 ADC 并完成闭环计算，把结果写入共享内存，再通过 IPCC 通道触发 A7 中断；A7 读取后做记录、上传或界面刷新。反向则用于 A7 下发参数或启停命令。这里的关键约束是共享内存必须双方约定同一物理地址与同一结构体布局，否则会出现“数据看似收到但字段错位”的隐蔽问题。

三、内存映射：先分清“谁在哪个地址段”

STM32MP 的地址空间可以按“域”来记。A7 侧 Linux 主要使用 DDR，典型起始映射在 0xC0000000 附近，具体容量由型号和板级 DDR 决定；M4 侧优先使用 MCU SRAM 与 RETRAM，以获得确定性访问延迟。两者之间还有一段被双方共同映射的共享 SRAM，用于 IPCC 消息与数据缓冲。

实际开发中最容易踩的坑是地址视角不一致：M4 看到的是物理地址，Linux 用户态看到的是虚拟地址，内核驱动则可能经过 ioremap。因此共享内存的约定必须写清楚“物理基地址 + 偏移 + 长度 + 结构体对齐方式”。例如约定共享区物理基址 0x10040000，长度 4 KB，前 16 字节放控制头（命令字、序号、状态），其后放 64 个 16 位采样值，则 M4 直接按物理地址写入，Linux 侧通过 /dev/mem 或专用 rpmsg 驱动映射同一段。若结构体未按 4 字节对齐，A7 读到的序号可能整体错位，表现为“数据在跳但对应不上”。

四、外设资源与归属

外设并非平均分给两个核，而是按实时性需求划分。M4 通常独占或优先使用：高级定时器（TIM1/TIM8）做互补 PWM、ADC 做电流采样、DAC 做模拟输出、部分 UART/SPI 做传感器直连。A7 侧则掌握以太网 MAC、USB、SDMMC、显示接口 DSI/LTDC、GPU 以及大容量存储控制器。两边都能看到的 GPIO、I2C 等，需要在设备树或资源分配表中明确“归谁管”，避免双方同时初始化同一引脚导致电平冲突。

五、典型应用场景与选型依据

工业场景中，STM32MP157 常用于“Linux HMI + M4 电机控制”的组合：A7 跑 Qt 界面与 EtherCAT 主站，M4 跑三环控制与故障保护。消费与医疗场景更关注低功耗与显示，MP153 或 MP151 即可满足。边缘 AI 场景则倾向 MP2 系列，借助 NPU 与更强算力在本地完成推理，A7 负责调度与结果上报。

选型时可以按下面这张判断表逐项打勾，避免“先买旗舰再发现用不上”或“省成本却卡在实时性”两类常见失误。

把这张架构图记牢之后，后续的启动流程、设备树编写、rproc 固件加载和 IPCC 中断调试，都会变成对同一张图的逐块展开，而不是零散知识点的堆叠。