拿到STM32N6570-DK这块板子之后，我第一个想做的项目不是跑个串口点灯，也不是刷一个TouchGFX官方的示例Demo，而是让摄像头画面真正“跑”进屏幕上，并且在画面外面套一层自定义的GUI——比如叠加传感器数据、加减框、做交互按钮。这个需求看起来和手机摄像头预览差不多，但放在STM32的单片机体系里面，牵涉的东西就完全不是一个量级了：一面是TouchGFX图形栈，一面是摄像头采集中间件，中间还隔着DMA2D、LTDC、内存带宽和Cache一致性这些容易出问题的环节。
如果你也正在STM32N6570-DK上做类似的TouchGFX和摄像头中间件集成，这篇文章应该能帮你省下不少查手册和翻示例代码的时间。我会从硬件资源盘点讲起，然后逐步拆解CubeMX配置、帧缓冲传递、格式转换、性能优化和排错方法。内容不追求抽象的原理堆砌，全部按我实际跑通这条链路的经验来写。
1. 先把硬件端清楚：这块板的图形链路和摄像头链路分别怎么走
1.1 开发板资源盘点：不只是“多了个摄像头接口”
STM32N6570-DK是围绕STM32N6570这颗芯片做的评估板。和普通的F系列、H系列开发板相比，STM32N6最大的差异化在于它内置了Neural-ART NPU加速器，核心是Arm Cortex-M55。这颗芯片的计算能力放在几年前几乎是不可想象的：它不仅要跑传统意义上的控制逻辑，完全可以承担图像预处理、简单的AI推理和图形渲染这三种负载。
板上资源里，和摄像头集成强相关的有这么几块：
- 显示侧：板载的LCD屏幕通过RGB并行接口连接，由芯片内部的LTDC（LCD-TFT控制器）驱动。
- 触摸侧：屏幕带有触摸面板，一般通过I2C接一个触摸控制芯片，比如FT3267之类。
- 摄像头侧：开发板留有FPC摄像头接口，可以接ST的柔性摄像头模块。
- 内存：板上有较大容量的外部RAM，加上芯片内部的SRAM，摄像头帧缓冲、TouchGFX帧缓冲、UI资源才能同时放得下。
- 调试：板载ST-LINK，可以直接用STM32CubeProgrammer烧录和调试。
也就是说，做摄像头和TouchGFX集成，不需要你自己去拼一个显示模块和一个摄像头模块，板卡已经把这些接口都引出来了。你要做的核心工作，是让芯片内部的各个外设和中间件之间，把数据和同步关系理顺。
1.2 图形链路：LTDC、RGB TFT和触摸控制器
先看显示链路，因为这块的故障表现最直观——屏幕上没东西，后面什么摄像头也别提。
LTDC在STM32里是一个相当成熟的显示控制器。它支持多层叠加，每一层都可以设置像素格式、透明度、颜色查找表等，芯片会把各个Layer完成混合，然后把最终的像素数据通过RGB引脚送给屏幕。在STM32N6570-DK上，LTDC的输出直接接到了LCD的接口上。
在TouchGFX的场景里，默认的渲染流程是：TouchGFX在需要刷新时，把要显示的内容绘制到一块帧缓冲（Framebuffer）里，然后LTDC这块帧缓冲的内容不断送到屏幕。如果启用双缓冲，TouchGFX会一边让LTDC读取当前的Frame Buffer，一边把下一帧画面绘制到另一块Buffer上，绘制完成后再切换。
触摸控制器走的是I2C。我看到有不少人的TouchGFX工程是从“显示正常但触摸没反应”开始的。这里有个很实际的问题：如果你在同一个I2C总线上挂了触摸芯片和摄像头sensor，要格外注意地址冲突和总线时钟速率。最好让触摸芯片单独走一条I2C，或者至少保证两者的工作模式不会在初始化时互相干扰。
1.3 摄像头链路：DCMI/CSI、I2C、MCLK和电源
摄像头sensor不是插上就能用的。和显示链路相比，摄像头链路复杂得多，因为它在物理上至少涉及四类信号：
- 数据信号：像素数据有D0到D7这样一组并行数据线，或者走MIPI CSI-2差分串行信号。STM32N6570同时带有DCMI和CSI相关能力，具体用哪个取决于你选择的摄像头模块。
- 像素时钟（PCLK）：sensor输出像素时钟，DCMI要基于这个时钟去采数据。
- 同步信号：垂直同步（VSYNC）和水平同步（HSYNC），或者内嵌同步模式。
- 控制信号：I2C引脚用于配置sensor内部寄存器，MCLK用于给sensor提供主时钟，PWDN、RESET等引脚控制sensor的电源和复位。
我在这个项目里用的是标准并行DCMI接口的摄像头模块，好处是引脚数量少、调试直观，而且DCMI的配置相对简单。如果你用的是MIPI CSI-2模块，就要额外配置MIPI物理层、协议层和DPHY的PLL，复杂度会高不少。
摄像头中间件在硬件层面的作用，就是把上面这些信号统一封装成“初始化摄像头、启动预览、拿到帧数据”这么几个简单的API。但底层的时序和电气连接，仍然是你必须自己确认的部分。
1.4 内存：为什么摄像头帧和UI帧要分开规划
STM32N6570的内部存储资源比传统MCU宽裕，但这不代表你可以随便分配。摄像头帧缓冲、TouchGFX帧缓冲、UI资源图片、摄像头中间件数据结构和AI推理缓冲区，这几类数据对内存带宽、缓存策略、访问延迟的需求完全不一样。
更关键的一点：摄像头sensor通过DMA直接往内存里写数据。如果这块内存是带Cache的，那么CPU在读取摄像头数据时，可能读到Cache里的旧数据，导致画面花屏或者内容迟迟不更新。反过来，TouchGFX帧缓冲是LTDC在持续读取的，如果摄像头DMA写入的地址恰好和LTDC正在扫描的地址重叠，就会看到撕裂画面。
所以，内存规划的核心原则是：
- 摄像头帧缓冲：优先放在非Cacheable区域，或者放到易失性较弱的外部RAM里，但必须保证DMA引擎访问路径正确。
- TouchGFX的Frame Buffer：可以放在LTDC访问效率高的内存区域，通常与SDRAM或内部SRAM能高效匹配。
- UI图片精灵动画之类的资源：尽量放在Flash或速度较慢的内存，不用频繁访问。
我在一开始踩过的坑就是直接把摄像头帧缓冲指向了一块默认的RAM数组，结果TouchGFX永远显示不出实时画面。后来把这块内存重新规划成Non-cacheable属性，问题立刻消失了。这一点在后面第五章会展开说。
2. 摄像头中间件到底解决了什么，和TouchGFX又是什么关系
2.1 ST摄像头中间件的分层逻辑
如果你第一次接触STM32的摄像头相关中间件，可能会被它和底层驱动之间的关系搞混。简单讲，摄像头中间件不是取代HAL和BSP，而是在上面建了一个“sensor无关层”。
底层部分仍然是ST标准外设库和高层BSP驱动：DCMI的寄存器配置、DMA通道配置、GPIO和I2C的init，这些工作由CubeMX生成的代码和HAL驱动完成。
中间件部分，比如常见的X-CUBE-CAMERA，它做的是更上层的抽象：它知道某个具体的sensor型号有哪些寄存器，怎么设置分辨率、帧率、曝光时间、白平衡，也负责把sensor的预览模式统一抽象成“StartPreview”这样的API。使用者在应用层调用中间件API，不需要关心sensor到底是OV某型号还是其他厂商型号。
这个分层在实际工程里非常重要。你写的TouchGFX显示逻辑、帧同步逻辑，不应该依赖于某个具体sensor的寄存器地址。否则将来换一颗sensor，整个应用层代码都要推翻重来。
2.2 帧从传感器到显示器的完整数据流
下面是我在这个项目中整理出来的完整数据流，你可以在心里建立一个“管道”模型：
- sensor通过MCLK获得主时钟，内部PLL开始工作，输出PCLK和VSYNC/HSYNC同步信号。
- DCMI外设接收像素数据，按照设定的极性采样，将数据填入FIFO。
- DMA根据配置，把FIFO里的数据搬运到指定的内存地址，也就是摄像头帧缓冲。
- 当一帧数据搬运完成，DMA传输完成中断触发，摄像头中间件调用应用层注册的回调函数。
- 应用层拿到新帧的指针，根据需求做格式转换或尺寸缩放。
- 转换好的图像数据被送到TouchGFX侧的自定义控件，或者写入动态位图。
- LTDC在下一个VSync周期把新的帧缓冲内容送给屏幕。
这个流程里，摄像头产生的帧是异步的，TouchGFX的显示刷新也是异步的，中间层必须有一个同步机制。很多集成项目的Bug并不是单个环节坏了，而是两个异步流程之间的竞争关系没有处理好。
2.3 和TouchGFX Video控件的边界：别用错方案
TouchGFX里有一个Video控件，它确实可以播放视频。但这个控件和“实时摄像头预览”是两回事。
Video控件在STM32平台上，通常是对预编码的视频文件进行解码播放，比如MJPEG编码的视频流。它内部有专门的处理管线，需要你把视频数据打包成控件支持的格式，然后由视频解码器逐帧解码并渲染。而我们的摄像头中间件拿到的是sensor直接输出的裸数据流，没有经过任何编解码，是“活”的实时视频。
如果你试图把sensor的原始帧塞给TouchGFX的Video控件，大概率会遇到格式不识别、画面无法刷新的问题。正确做法是绕开Video控件，用自定义绘制或动态位图的方式，把摄像头帧交给TouchGFX。
简而言之：TouchGFX的Video适合播放“预先存在”的视频素材，摄像头中间件适合处理“实时生成”的帧数据。两者可以共存，但不能混为一谈。
3. CubeMX工程配置：最花时间的不是代码，是时钟和引脚分配
集成这类项目时，真正的体力活不是调用摄像头预览API，而是在STM32CubeMX里把外设配置到“能一起工作”的状态。
3.1 引脚冲突排查与复用的教训
LCD的RGB接口占了大量GPIO引脚，摄像头DCMI还可能使用另外一组GPIO，加上I2C、UART、SDIO、以太网，STM32N6570-DK的引脚资源在一个复杂项目里会非常紧张。我用的办法是，在CubeMX里先只启用LTDC和触摸I2C，确认图形显示正常，然后把DCMI、摄像头电源和复位GPIO逐个添加。
在这个过程中发现的两个实际问题：
- DCMI的某些数据引脚会和板载以太网或UART功能引脚重叠，需要仔细看板卡原理图，而不是只看芯片引脚定义。
- 有些摄像头模块需要额外的一个GPIO来控制电源使能，这个GPIO如果没配置正确，sensor上电后连I2C地址都扫描不到。
建议在CubeMX里使用“Pinout view”逐个核对，并且每一次修改引脚分配后，都做一次重新生成代码和编译，不要一次把几十个引脚全部改完再编译。
3.2 时钟树上让摄像头、LTDC和DCMI都满意的比例
这是摄像头集成中最隐蔽的坑。
DCMI采集数据依赖sensor输出的PCLK，和芯片的内部HCLK之间没有严格倍频关系。但DCMI的DMA传输和FIFO读取依赖系统时钟，如果系统时钟频率不足，或者DCMI的接口时钟分频不合理，会导致图像数据溢出。
LTDC需要像素时钟才能驱动LCD屏幕。常见的4.3寸RGB屏，像素时钟可能在9MHz到20MHz区间，具体要看屏幕的时序参数。LTDC的像素时钟往往不是整数倍关系生成的，而是通过PLL分频得到的。
摄像头sensor的主时钟MCLK通常有明确范围，比如8MHz到27MHz，很多sensor固定工作在24MHz或12MHz。如果MCLK偏差太大，sensor输出的图像会变得怪异，甚至完全不输出。
我的做法是先把芯片主频和所需外设时钟在Clock Configuration界面里列出来，逐一确认：
- 系统主频：比如600MHz
- HCLK：与外设总线对齐
- LTDC像素时钟：按屏幕规格书设置
- I2C时钟频率：400kHz
- MCLK：给摄像头sensor提供的主时钟频率
检查这些配置的关键是看CubeMX右边生成的时钟树是否全绿。如果一个时钟源被多个外设共享，还要格外注意分频系数会不会把某个外设的频率推到上限之外。
3.3 内存区划分：Cacheable和Non-cacheable的分区要点
STM32N6570的Cortex-M55内置了DCache。当DMA往内存写数据时，DCache默认是感知不到这个过程的，因为DMA是直接访问内存，不会写Cache。如果你在CPU里读取这个地址，发现Cache命中，返回的是Cache里的旧值，这就出现了“数据明明在内存里更新了，但CPU读到的还是旧值”的情况。
处理方式有两种：
方法一是为摄像头帧缓冲建立一段Non-cacheable的内存区域。CPU读这段内存时不做缓存，每次都直接问内存要数据。虽然性能稍低，但对于摄像头预览的场景完全够用。
方法二是在每次DMA完成后做Cache的Invalidate操作。比如调用SCB_InvalidateDCache_by_Addr来使指定地址段的Cache作废。这个方式更灵活，但如果你在中断里频繁调用，可能会带来不可忽视的开销。
我在工程里混合使用了两种方式：摄像头帧缓冲直接放在Non-cacheable属性区域，降低同步复杂度；TouchGFX的帧缓冲保留Cacheable属性，让图形渲染能享受Cache带来的加速。
3.4 中间件堆栈参数：摄像头和TouchGFX的RAM开销
启动一个TouchGFX工程，RAM开销通常包含以下几部分：
- TouchGFX本身的帧缓冲：至少一帧，典型RGB565格式下，800x480分辨率的帧缓冲是800x480x2字节，约768KB。如果双缓冲就是1.5MB。
- UI资源缓存：图片纹理、字体、控件对象。
- 摄像头中间件的DMA描述符和上下文结构体。
- 摄像头帧缓冲：YUV422格式下，640x480一帧约614KB。
把这些加起来，你会发现STM32N6570-DK虽然内存大，但如果没有规划，很快就捉襟见肘。建议在工程早期就建立一个内存分配表，把每块Buffer的地址和大小列清楚。
4. 集成代码：把摄像头帧“送”到TouchGFX控件上
4.1 底层摄像头中间件调用与回调程序设计
假设你已经通过CubeMX把中间件和外设都初始化好了，下面是一个典型的摄像头预览启动代码框架：
/* 打开摄像头 */ Camera_MW_Init(); /* 设置输出图像格式为 RGB565，分辨率 CVGA_480x640 */ Camera_MW_SetFormat(CAMERA_RGB565, 480, 640); /* 注册回调函数 */ Camera_MW_RegisterFrameCallback(MyFrameCallback); /* 启动预览 */ Camera_MW_StartPreview();上面的API会根据具体的中间件包名称略有差异，但整体思路一致。启动后，每次DCMI完成一帧采集，中断会触发中间件的内部处理函数，然后回调你注册的MyFrameCallback。
回调函数里一般是这么写的：
static void MyFrameCallback(uint32_t frameBufferAddr) { /* 先判断帧缓冲是否准备好 */ if (frameBufferReady == 0) { currentFrame = (volatile uint16_t *)frameBufferAddr; frameBufferReady = 1; /* 通知TouchGFX侧去处理 */ } }这里不要把大量的图像处理放在回调里，因为摄像头中断的优先级如果太高，会影响图形渲染和系统调度。回调里最合理的操作就是“转移所有权”，而不是“处理”。
4.2 帧缓冲传递机制：指针共享与回调
在TouchGFX里刷新画面，核心机制是“让TouchGFX知道图像数据已经更新了”。TouchGFX本身不会主动去轮询摄像头帧缓冲，必须由外部调用某个机制来触发它。
我的做法是建立了一层“桥接层”。
// 桥接文件，同时包含摄像头中间件头文件和TouchGFX头文件 void NotifyCameraFrameReady(uint32_t addr) { // 更新全局帧指针 cameraFrameBuffer = (uint8_t *)addr; // 调用TouchGFX的更新机制 cameraWidget->invalidate(); }invalidate()会让TouchGFX在下一帧渲染时重绘CameraWidget。
这里要注意：TouchGFX的渲染和屏幕刷新是同步的，invalidate()通知完成后，TouchGFX在该帧渲染里会调用draw()函数，我们需要在draw()里把摄像头帧数据画到目标区域。
4.3 帧格式转换：YUV/RGB之间怎么平滑处理
sensor输出的原始数据格式大多是YUV422、NV12或者RAW Bayer，而TouchGFX支持的图像格式一般是RGB565或RGBA8888。如果你不转换就想直接用，画面花屏几乎是必然的。
最省事的方式是让摄像头中间件直接输出RGB565。但很多sensor的ISP并不直接输出RGB565，它输出的是YUV422或RGB888。这时就需要在MCU侧做转换。
我对YUV422到RGB565做过手写转换，如果逐像素用浮点公式算，速度非常慢。实际工程里有两个更好的方案。
方案一是查表法。把Y、U、V拆成高位索引，在Flash里放一个转换表，把常用的YUV组合提前算好存起来。这个方法速度快，但会消耗不少Flash空间。
方案二是利用DMA2D的像素格式转换能力。我在这一章前面提到过DMA2D不仅能搬运，还支持格式转换。你可以直接把DMA2D的输入地址指向YUV帧缓冲，输出地址指向RGB565的目标缓冲，然后在配置里指定输入格式和输出格式，DMA2D硬件会完成转换。
用DMA2D做转换的代码大致是这样的框架：
/* 配置DMA2D */ hdma2d.Init.Mode = DMA2D_M2M_PFC; hdma2d.Init.ColorMode = DMA2D_OUTPUT_RGB565; hdma2d.Init.InputColorMode = DMA2D_INPUT_YUV422; ... HAL_DMA2D_Start(&hdma2d, (uint32_t)yuvBuffer, (uint32_t)rgbBuffer, width, height);这样做之后，CPU的负载会明显降低，帧率也有保证。
4.4 画面撕裂问题的第一道防线：等待VSync和DMA2D
撕裂是什么？就是屏幕的上半部分显示的是新的一帧，下半部分还是旧的一帧，看起来像画面被撕开了。原因是LCD的扫描时序和帧缓冲的更新时机发生了冲突。
在TouchGFX内部，正常情况下它会等待LTDC的垂直同步信号，在扫描空隙时才切换帧缓冲地址，从而避免撕裂。但摄像头数据是独立于TouchGFX的，如果我们把摄像头数据直接写进TouchGFX正在渲染的Frame Buffer区域，撕裂就控制不住了。
最常用的解决办法是引入“中间缓冲”和DMA2D拷贝：
- 摄像头中间件把新帧写入摄像头自己的帧缓冲A。
- 处理逻辑把A里的内容通过DMA2D复制到TouchGFX的Frame Buffer中的对应区域。
- 复制动作要放在TouchGFX的Frame Buffer已经完成本帧渲染，并且LTDC还没有开始扫描下一帧的时候。
在实际代码里，监听垂直同步的常用手段是注册LTDC的Line Interrupt回调，或者通过TouchGFX的HAL机制等待VSync信号。复制操作放在VSync结束后的一小段时间窗口里，可以非常有效地减少撕裂。
如果你实在无法精准把握VSync时机，也可以考虑用双缓冲：TouchGFX在渲染下一帧时，摄像头数据写入另一个缓冲区，两个缓冲区交替使用。这个方案对内存开销更大，但稳定性更好。
5. 性能调优：从“能显示”到“流畅显示”
5.1 瓶颈观察：CPU搬运、DMA2D搬运与Cache一致性
画面上已经能看到实时摄像头预览后，性能问题就开始浮现了。最常见的现象是：摄像头帧率上不去，或者界面按钮点击后响应变慢。
我建议先做一次“搬移统计”：摄像头一帧图像在芯片内部被搬运了几次。
举个例子：sensor输出YUV422到帧缓冲，CPU把它读出来转成RGB565，然后又由CPU把RGB565写入TouchGFX的Frame Buffer。这一帧其实被CPU搬了两次，中间还涉及Cache读写。在640x480的分辨率下，一帧大约60万个像素，每个像素至少两次读写，总的数据量非常可观。
优化路径很清晰：
- 能用DMA2D的地方，不使用CPU搬运。
- 能一次转换完成的，不分成两步。
- 能被DMA2D直接转换地址的，不先落到中间Buffer。
5.2 用双缓冲/三缓冲控制帧写入时机
摄像头的DMA持续写入，TouchGFX持续渲染，如果只有一个摄像头帧缓冲，那么会发生以下问题：当CPU还在读取上一帧数据时，DMA已经把下一帧覆盖进来了，读取出来的图像是“上半帧新、下半帧旧”的混合体。
解决方法是至少使用两个摄像头帧缓冲。DMA往缓冲0写第一帧，CPU处理缓冲0里的内容；同时DMA往缓冲1写第二帧。等一帧写完后，两个缓冲角色互换。这样当前被处理的帧就不会被DMA破坏。
ST的摄像头中间件一般支持这种连续的DMA双缓冲模式。你可以在启动预览时传入两个地址，或者在DCMI的DMA回调里动态切换目标地址。
使用三缓冲则更进一步：一个缓冲被DMA写入，一个缓冲被CPU/DMA2D处理，另一个缓冲被TouchGFX渲染。三者互不阻塞，代价是内存占用更高。
5.3 帧率与分辨率的取舍策略
如果摄像头sensor支持输出不同分辨率，比如640x480、800x600、1280x720，那么你需要想清楚一个问题：最终呈现在TouchGFX里的预览面积有多大。
如果你的预览窗口只占屏幕的1/4，比如400x240这样的区域，那么摄像头完全没必要跑到800x600再缩小。sensor直接输出低分辨率，可以减少DCMI的DMA传输时间，减少DMA2D转换耗时，也降低帧缓冲大小。
在实际项目里，我通常会让sensor直接输出预览窗口需要的近邻分辨率，宁可让sensor输出的画面和窗口比例不完全一致，后期做一个小范围的裁剪或拉伸，也不要让数据量无谓地跑大。
6. 排错记录：我遇到的黑屏、花屏和卡顿
6.1 黑屏：摄像头ID读不通，先查上电和复位
做摄像头集成时，第一个项目周期里最常见的现象是：程序跑起来了，LCD上已经有TouchGFX的界面，但摄像头预览区域是黑的。
排查思路不是急着查DCMI寄存器，而是先确认sensor是否有响应。
我的排错顺序是：
- 用I2C读sensor的ID寄存器。如果读出来的值和sensor手册不一致，说明I2C链路或sensor电源有问题。
- 如果I2C地址扫描不到，优先检查sensor的供电引脚是否通过GPIO控制，这个控制脚有没有被正确拉高。
- 再检查MCLK是否正常输出。用逻辑分析仪或者示波器量MCLK引脚，没有波形就是时钟配置不对。
- 检查RESET引脚的电平时序。很多sensor要求上电后延迟几十毫秒再拉高复位，过早过晚都可能导致初始化失败。
- 最后才看DCMI的同步极性设置。VSYNC和HSYNC的极性接反，图像也会不出，但这种情况下你至少能读取到sensor ID。
黑屏问题里，绝大多数是我前几步的问题，真正因为DCMI同步极性设置错误导致的黑屏反而少。
6.2 花屏：格式不匹配与行缓冲错位分析
花屏比黑屏好一点，因为至少说明摄像头已经出数据了。花屏的表现有很多种，下面是我遇到过的三种：
- 图像颜色明显怪异，比如画面整体发绿、发红。这通常是YUV和RGB的转换参数不对，或者sensor输出的是RAW Bayer，而你的中间件没有做像素处理。
- 图像上下两部分严重偏移，或者出现“斜向条纹”。这种情况通常是DMA的行长配置和实际图像宽度不一致，导致每行像素没有正确对齐。
- 画面扭曲、有条纹但颜色正常。这种情况往往是DCMI采集到的像素时钟和sensor期望的采样相位不对，或者摄像头数据线的信号质量问题。
花屏问题的排查工具，最好用逻辑分析仪或者屏幕截图。不要凭眼睛猜，因为花屏的模式差异很大。如果DCMI时序配置正确、DMA行长正确，那么能显示的画面基本不会出现错位。
6.3 卡顿和丢帧：中断优先级、DMA和调度问题
集成完成后，最让人困扰的性能问题是：摄像头预览帧率降到只有10帧左右，或者TouchGFX的触摸响应明显迟滞。
我遇到过两个典型场景。
第一个场景是摄像头中断处理耗时过长。我在回调函数里直接做了YUV到RGB的软件转换，导致中断服务函数占用了大量时间。把转换逻辑挪到主循环的一个任务里，并且用DMA2D替换CPU转换后，帧率立刻提升了。
第二个场景是TouchGFX的渲染和摄像头DMA传输在总线仲裁上互相占用带宽。STM32N6570内核虽然快，但内部总线的带宽是有限的。DCMI的DMA传输在高速率下会占用较多的总线周期，而LTDC扫描显示也需要总线带宽，TouchGFX渲染同样如此。这三者同时访问总线的概率很大，一旦冲突，彼此都需要等待。
优化方法是把摄像头帧缓冲放到一个与LTDC读取带宽隔离的内存区域中，同时调整DMA传输的优先级。另一个实用做法是降低摄像头DMA的突发长度，减少单次占用总线的时间片，虽然可能略微降低传输效率，但能让整个系统的调度更平滑。
7. 一点实际项目的建议与扩展思路
如果这个项目要继续往下做，我个人会考虑三件事。
第一，摄像头中间件和TouchGFX的集成，一定要先做最小系统验证。也就是说，先用屏幕显示纯色背景，再单独启动摄像头预览，最后才将两者合在一起。不要一开始就试图把触摸按钮、动态图表、摄像头画面全部塞进同一帧，否则出了Bug你根本分不清是图形栈的问题还是摄像头链路的问题。
第二，STM32N6570-DK上的NPU能力，值得好好利用。摄像头中间件输出的帧，除了送TouchGFX显示，还可以同时传给NPU做推理。比如物体检测或者人脸识别，然后把推理结果作为UI控件叠加在摄像头画面上。这种“实时视频+AI标注”的交互方式，是这个平台最强的使用场景，也是很多实际产品形态的雏形。
第三，如果未来要把代码从这块开发板迁移到自己的产品板，请务必在编码阶段保持“硬件隔离”。摄像头中间件的调用、TouchGFX控件的实现、内存地址的分配，尽量用宏定义和配置头文件隔离，不要把硬编码的地址或寄存器位散落在业务代码里。我见过太多项目因为把所有功能都在评估板上跑通，结果一换板子，光是重新适配摄像头引脚和LCD时序就花了几个星期的时间，这个成本远大于一开始的架构设计成本。
最后分享一个我在实际调试中的小技巧：在代码里保留一个“调试开关”，可以把摄像头帧缓冲的地址直接映射到LTDC的Layer1，绕过TouchGFX直接显示。这不是最终交付的方式，但在定位问题时非常有效。它能帮你快速区分画面异常到底出现在摄像头采集链路，还是出现在TouchGFX渲染链路。等你确认摄像头采集正常，再切换回TouchGFX自定义控件模式，问题往往就能快速定位到具体环节。
