2. STM32N6硬件架构与图形HMI开发资源
STM32N6 是 ST 面向边缘 AI 与图形 HMI 场景推出的高性能 MCU 系列，其核心思路不是简单提高主频，而是把“通用控制、图形渲染、AI 推理、大容量数据搬运”拆成多个可并行工作的硬件单元。理解这些单元各自负责什么、通过什么总线连接、数据从哪里来又到哪里去，是后续做界面流畅度优化、内存规划和外设选型的前提。
一、从整体看：四类资源支撑图形 HMI
STM32N6 的图形 HMI 能力可以归纳为四条并行的资源线：
- Cortex-M55 内核：运行 RTOS、LVGL/TouchGFX 等 GUI 框架、业务逻辑与显示驱动，负责“决定画什么、什么时候画”。
- NeoChrom GPU：承担 2D 图形加速，包括图层混合、Alpha 混合、缩放、旋转、颜色格式转换等，把 CPU 从逐像素运算中解放出来。
- Neural-ART NPU：执行量化后的神经网络推理，用于手势识别、人脸检测、语音唤醒等智能交互，与图形渲染并行。
- Chrom-ART (DMA2D) 加速器：负责矩形填充、图像拷贝、格式转换和图层合成，是帧缓冲刷新和背景绘制的高效通道。
这四者并不是互相替代关系，而是分工协作：CPU 组织命令与数据，GPU 与 DMA2D 处理像素，NPU 处理模型，SRAM 与外部存储提供带宽和容量。下图给出它们在数据通路上的相对位置。
二、Cortex-M55：控制与调度的中枢
Cortex-M55 是 Armv8.1-M 架构内核，支持 Helium（MVE）向量扩展，在 STM32N6 中主频可达 800 MHz 级别（具体以型号数据手册为准）。对图形 HMI 而言，它的价值不只是跑得快，而是能高效处理“非像素类”工作：
- 运行 FreeRTOS 或裸机调度，管理 GUI 任务、触摸事件、通信任务；
- 调用 GPU 和 DMA2D 的驱动接口，组织绘制命令队列；
- 用 Helium 指令处理音频前处理、传感器融合、简单滤波等；
- 通过 Cache 与 MPU 配置，保证帧缓冲和 DMA 区域的一致性。
实际开发中，CPU 不应直接做逐像素填充或大块 memcpy，而应把这类操作交给 DMA2D 或 GPU。一个常见的判断标准是：如果一段代码在循环里对每个像素做运算，就应该考虑是否有硬件加速通道可以替代。
三、NeoChrom GPU 与 Chrom-ART 的分工
NeoChrom GPU 是 2D 图形加速器，擅长图层混合、Alpha 混合、缩放、旋转、颜色空间转换等。它通常以“命令 + 源/目标缓冲区”的方式工作，适合处理 LVGL 中的图像变换、半透明叠加、圆角抗锯齿等场景。
Chrom-ART（DMA2D）则更偏向“规则搬运”：矩形填充、图像拷贝、格式转换、两层或三层合成。它的优势是确定性高、开销低，适合背景刷新、图标拷贝、帧缓冲切换等重复性操作。
两者配合的典型模式是：DMA2D 负责把背景和静态图层快速铺好，GPU 负责动态图层的混合与变换，CPU 只做命令下发和状态管理。这样可以在 800×480 或 1024×600 等常见分辨率下，把界面刷新稳定在较高帧率。
四、NPU：让 HMI 具备智能交互能力
Neural-ART NPU 是 STM32N6 区别于普通 MCU 的关键资源。它支持量化神经网络推理，典型应用包括：
- 手势识别：摄像头采集 → 预处理 → NPU 推理 → 返回类别与置信度；
- 人脸检测：用于唤醒、注意力判断或安全提示；
- 语音关键词识别：本地唤醒词检测，减少云端依赖。
NPU 与图形渲染是并行关系：CPU 可以在等待 NPU 推理结果的同时，继续驱动 GPU 刷新界面。实际项目中需要注意模型量化格式、输入张量布局、内存对齐和 Cache 维护，否则容易出现推理结果异常或性能下降。
五、SRAM 与外部存储：容量与带宽的平衡
STM32N6 内部集成了大容量 SRAM，通常划分为多个可独立访问的块，支持不同主控同时访问，这对图形 HMI 非常关键。帧缓冲、图层缓冲、NPU 输入输出张量、GUI 堆栈都需要占用 SRAM，因此内存规划必须提前做。
以 800×480、RGB565 单帧缓冲为例，一帧约 800×480×2 = 768 KB。若采用双缓冲，则约 1.5 MB。再加上图层、图标缓存和 NPU 张量，内部 SRAM 会很快被占满。此时外部存储接口（XSPI/OSPI、SDMMC 等）就承担起存放图片资源、字体、模型文件和日志的角色。
外部存储的访问速度远低于内部 SRAM，因此不能直接把帧缓冲放在外部 Flash 中逐像素读取。合理做法是：启动或切换界面时，把需要的资源块预取到 SRAM；运行期间只从 SRAM 读取。对于大尺寸图片，可以配合 DMA2D 从外部存储搬运到内部缓冲，再参与合成。
六、面向图形 HMI 的资源分配示例
下面给出一个教学示例性的资源分配思路，用于说明各单元如何协同。参数为合理假设，实际项目需根据具体型号和屏幕规格调整。
| 资源 | 典型用途 | 示例占用 | 注意事项 |
|---|---|---|---|
| 内部 SRAM | 帧缓冲、图层、NPU 张量 | 双缓冲 1.5 MB + 图层 512 KB | 注意 Cache 一致性与 DMA 对齐 |
| 外部 XSPI Flash | 图片、字体、模型文件 | 16 MB ~ 64 MB | 预取到 SRAM 后再参与渲染 |
| NeoChrom GPU | 动态图层混合、缩放 | 每帧若干次混合操作 | 命令队列不宜过长 |
| DMA2D | 背景填充、图标拷贝 | 每帧 1~2 次全屏操作 | 避免与 GPU 争抢同一缓冲 |
| NPU | 手势/人脸推理 | 每 100 ms 一次推理 | 与渲染任务错峰调度 |
七、开发时值得优先确认的几件事
- 确认所选 STM32N6 型号的 SRAM 容量和分区方式，明确哪些块可被 DMA2D/GPU/NPU 访问。
- 确认显示接口类型（LTDC RGB 并口或 MIPI DSI）以及对应引脚和时钟配置。
- 确认外部存储接口的吞吐能力，估算资源预取时间是否满足界面切换要求。
- 确认 NPU 支持的量化格式和算子集，避免模型转换后无法部署。
- 确认 Cache 与 MPU 配置策略，保证 CPU、DMA2D、GPU、NPU 看到的数据一致。
把上述资源关系理清后，后续的 GUI 框架移植、显示驱动编写、内存优化和 AI 功能集成就有了明确的硬件依据。STM32N6 的图形 HMI 开发，本质上是在 CPU、GPU、DMA2D、NPU 和存储之间做合理的任务划分与数据流设计。