做嵌入式这几年，凡是碰到“摄像头采集”需求的项目，十个有八个最后都会绕到OV5640这颗 sensor 上。原因很简单：便宜、好买、资料多、输出格式全，从720p到1080p、从RAW到YUV再到JPEG，一颗芯片全包了。但正因为用的人多，踩坑的人也多，尤其是在“STM32 + OV5640 + MIPI”这个组合上，我见过太多人卡在同一个地方出不来。
这篇东西不是官方手册的翻译，也不是照搬某家开发板的教程，而是我把实际项目中用 HAL 库调 OV5640 的完整过程、踩过的坑、以及最后验证可行的方案整理出来的总结。如果你正准备用 STM32 做图像采集，或者已经被 OV5640 折腾得怀疑人生，这篇应该能帮你省下好几个星期的调试验证时间。
1. 先说结论：STM32到底能不能直连MIPI接口的OV5640
这个问题几乎每隔几天就会在技术群里出现一次。直接给答案：绝大多数STM32不能直连MIPI接口的OV5640，因为STM32芯片内部根本没有MIPI CSI-2接收控制器。
1.1 为什么总有人把OV5640和MIPI绑定在一起
OV5640这颗sensor在设计上很“狡猾”，它同时支持两种输出接口：传统的DVP并口和MIPI CSI-2串口。很多开发板、核心板、模组厂商为了让自己的板子看起来“高端”，会在标题里重点标注“MIPI接口OV5640摄像头模组”。于是很多初学者买回来一看——MIPI接口，赶紧去查STM32有没有MIPI外设，一查没有，然后就懵了。
其实OV5640模组上那个MIPI接口，只是把sensor的MIPI输出引脚引出来了。它内部还有一个DVP模式，同样通过另外一组引脚输出并口数据。关键问题是：你手上的模组是否把DVP引脚也引出来了。有些模组为了省PCB面积，直接砍掉了DVP引脚，只留MIPI，这种模组在STM32上基本就是废的。
1.2 真正的坑：DVP和MIPI是两条完全不同的路
我见过很多人把DVP和MIPI混为一谈，觉得不就是接口不一样吗，加个转接不就行了？这里面的水比想象中深：
- DVP（Digital Video Port）：并行接口，用8/10/12位数据线 + PCLK + VSYNC + HREF同步信号传输，一根根引脚数很多，但协议简单，MCU侧只要有DCMI外设就能接，或者纯GPIO模拟也行（就是慢）。
- MIPI CSI-2：串行接口，用差分信号对（lane）传输，协议层复杂，有包结构、ECC校验、CRC校验、帧格式定义等等。接收端必须有专门的CSI-2控制器和PHY物理层，不是随便拿几个GPIO就能解出数据的。
所以“STM32 + MIPI摄像头”这个命题，在硬件层面就已经不成立了。不是写写代码就能解决的问题，是芯片本身缺了这个外设。
注意：如果你用的是STM32MP1系列或者部分STM32H7的特定型号，情况会稍微复杂一些，需要查具体型号的参考手册确认是否有CSI外设，但主流的F1/F2/F4/F7/H7系列基本都是没有的。
2. 方案选型：想要STM32接OV5640，实际有三条路可走
既然直接接MIPI这条路被堵死了，那实际项目里大家是怎么做的？我把可行的方案整理成表格，先直观对比一下：
| 方案 | 硬件平台 | 图像格式 | 帧率/分辨率 | 开发难度 | 适用场景 |
|---|---|---|---|---|---|
| 方案一 | STM32F4/F7/H7 + DVP接口OV5640 | RGB565/YUV/JPEG | 30fps@720p以内 | 中 | 低成本、低功耗嵌入式视觉 |
| 方案二 | 带MIPI CSI的MPU（i.MX8M、RK等）+ OV5640 | RAW/YUV/JPEG | 60fps@1080p | 较高 | 需要高分辨率、Linux系统平台 |
| 方案三 | FPGA + OV5640（MIPI或DVP） | 任意 | 取决于FPGA逻辑 | 高 | 高速图像处理预处理 |
2.1 方案一：STM32 DCMI + DVP接口的OV5640
这是STM32平台上最稳妥的方案。STM32的DCMI（Digital Camera Interface）外设专门干这个事的，支持8/10/12/14位并行数据输入，内置FIFO，配合DMA使用可以做到不占CPU的情况下持续接收图像数据。
需要注意的是，DCMI虽然叫“Camera Interface”，但它只负责接收并口数据，不负责MIPI解码。这个外设从F1系列到H7系列都有，区别在于F1的DCMI在主频较低时处理高分辨率图像比较吃力，F4/H7则更从容。我实测过F407 + DVP接口OV5640跑720p RGB565，30fps完全没有问题，CPU占用率还不到30%。
选这个方案时，模组购买要格外谨慎：一定要买“DVP接口”的OV5640模组，或者买那种两种接口都引出来的全引脚模组。某宝上很多卖家标注“OV5640摄像头模块”，详情页里小字写着“MIPI接口”，买回来才发现STM32用不了，我现在习惯下单前直接问清楚卖家引脚定义。
2.2 方案二：换带MIPI CSI-2控制器的MPU平台
如果项目确实需要MIPI接口（比如sensor模组已经定死了、或者后续要接高分辨率sensor），那就要换平台了。带MIPI CSI-2控制器的MCU/MPU其实不少，比如：
- NXP i.MX8M系列：原生支持MIPI CSI-2，跑Linux，驱动模型成熟，接OV5640有官方参考代码。
- Rockchip RK3568/RK3588等：自带MIPI CSI-2，SDK里OV5640驱动很完善，基本是设备树里配置好就能跑。
- 全志V系列：也有MIPI CSI-2，常用于智能摄像头产品。
这种方案的好处是后续扩展性强——今天接OV5640，明天换OV13850，驱动层改改配置就行。坏处是开发门槛高，需要懂Linux驱动模型，编译内核、改设备树、调试ISP，整个链路比单片机复杂得多。
2.3 方案三：FPGA做MIPI接收桥接
还有一种“曲线救国”思路：用FPGA的LVDS/差分IO接收MIPI信号，解码后再转成DVP并口喂给STM32。这个方案从纸面上看起来很美，实际上非常折磨人：
- MIPI的时序要求很严格，FPGA里写CSI-2接收逻辑需要用到高速serdes资源，入门级FPGA不一定有。
- MIPI协议解析里的包头、ECC/CRC校验、virtual channel处理逻辑量不小，虽然网上有开源IP，但调试起来一场硬仗。
- 成本上也没有优势——一块入门级FPGA比换一颗带MIPI的MPU贵多了，除了某些极其特殊的场景（比如产品里本来就有FPGA做其他事），我不推荐这么干。
3. HAL库工程搭建：从CubeMX配置到DMA搬运图像
既然选定了STM32 + DVP这个路线，接下来就是实际把工程搭起来。以下内容基于STM32F407 + HAL库 + OV5640 DVP模组，亲测可跑。
3.1 引脚规划与CubeMX配置要点
OV5640 DVP接口需要以下信号连接：
| 功能 | OV5640引脚 | STM32引脚分配 | 说明 |
|---|---|---|---|
| SCCB时钟 | SIOC | PB6 (I2C1_SCL) | 兼容I2C通信 |
| SCCB数据 | SIOD | PB7 (I2C1_SDA) | 兼容I2C通信 |
| 像素时钟 | PCLK | PC6 (DCMI_PIXCK) | sensor输出，作为同步时钟 |
| 行同步 | HREF | PC4 (DCMI_HSYNC) | 每行数据有效标志 |
| 帧同步 | VSYNC | PC5 (DCMI_VSYNC) | 每帧数据有效标志 |
| 主时钟 | XVCLK | PA8 (TIM1_CH1) | 由STM32定时器产生，24MHz |
| 数据线 | D0~D7 | PC6~PC11、PB8~PB9等 | 根据具体引脚映射分配 |
| 复位 | RESET | 任意GPIO | 低电平复位 |
| 掉电 | PWDN | 任意GPIO | 高电平掉电 |
CubeMX配置时，DCMI外设选择对应引脚后，重点要设置这几个参数：
- 像素时钟极性（Pixel Clock Polarity）：OV5640在PCLK上升沿输出数据，所以DCMI应该配置为在上升沿采样（Rising Edge）。
- 同步信号极性（VSYNC/HSYNC Polarity）：OV5640输出的是低电平有效的VSYNC，高电平有效的HREF，配置时要和sensor寄存器里的输出极性保持一致，不然图像会错位。
- 数据宽度：选择8位，OV5640在DVP模式下的RGB565/YUV422都是8位并口输出。
DCMI时钟来源是AHB总线时钟（HCLK），在F407上通常配置为168MHz。像素时钟PCLK最高由sensor决定，OV5640在720p RGB565下大约42MHz，DCMI外设完全可以跟上。
3.2 读OV5640的ID：先确认SCCB能通
时序配置完别急着去接图像，第一步永远是确认I2C通信正常。OV5640的SCCB协议和I2C高度兼容，但有一个细微差别：SCCB在连续读时必须发送一个Stop信号再重新Start，而标准I2C的重复Start在某些实现下sensor不认。
uint8_t ov5640_read_reg(uint16_t reg, uint8_t *data) { HAL_StatusTypeDef status; uint8_t addr_high = (reg >> 8) & 0xFF; uint8_t addr_low = reg & 0xFF; // 写入寄存器地址 status = HAL_I2C_Master_Transmit(&hi2c1, OV5640_ADDR, &addr_high, 1, 100); if (status != HAL_OK) return 1; // SCCB要求重新发送Start信号，这里用Master_Receive会自动生成新的Start status = HAL_I2C_Master_Receive(&hi2c1, OV5640_ADDR, data, 1, 100); if (status != HAL_OK) return 1; return 0; }这里的OV5640_ADDR要注意：OV5640的7位I2C地址是0x21，但HAL库的I2C地址参数需要的是8位地址（左移一位），所以应该是0x42。很多人第一次读ID时返回0xFF，八成就是这里地址写错了。
读寄存器0x300A和0x300B，OV5640的ID固定是0x5640：
uint8_t id_high, id_low; ov5640_read_reg(0x300A, &id_high); ov5640_read_reg(0x300B, &id_low); // id_high 应为 0x56，id_low 应为 0x40如果ID读出来不对，优先检查：接线是否错了、I2C速率是否过快（建议先降到100kHz）、sensor的PWDN引脚是否处于非掉电状态。
3.3 初始化序列：把OV5640切到RGB565模式
OV5640寄存器初始化是很多人最头疼的部分，因为官方提供的初始化序列动辄几百行，完全看不懂是干什么的。这里不推荐把整套配置死记硬背，而是要理解关键寄存器分组的逻辑：
- 0x3100~0x300D：系统时钟、PLL配置、sensor复位控制。OV5640内部需要通过PLL倍频出sensor工作所需时钟，XVCLK输入24MHz时，PLL倍频系数决定像素时钟。
- 0x3018~0x301D：IO配置、MIPI/DVP模式选择。默认情况下OV5640上电后输出的是DVP模式还是MIPI模式，取决于模组外围电路对相关引脚的上拉/下拉设置。
- 0x4300：数据格式控制。RGB565、YUV422、JPEG都在这里切换。
- 0x3800~0x3831：窗口裁剪、缩放、输出分辨率配置。OV5640内部有完整的ISP流水线和scaler，从sensor原始分辨率到最终输出分辨率的每一级缩放都通过这一组寄存器设置。
- 0x4740~0x474C：VSYNC/HREF/PCLK极性设置。
网上流传的初始化序列很多是针对Linux下OV5640驱动的，直接搬到STM32上跑通常也能正常工作，但需要注意：Linux驱动的初始化序列里包含了很多针对MIPI接口的配置项，DVP模式下需要改掉几处寄存器（特别是IO方向控制和接口模式选择），否则会出现输出数据错乱。
我整理的RGB565 720p初始化序列关键片段参考如下：
uint16_t ov5640_init_regs[][2] = { {0x3103, 0x11}, // system clock from pad {0x3008, 0x82}, // soft reset {0x3017, 0x00}, // frex, rst gpio {0x3018, 0x00}, // MIPI/DVP 模式选择，DVP {0x3034, 0x1A}, // PLL配置 {0x3035, 0x21}, {0x3036, 0x46}, {0x3037, 0x2F}, {0x4300, 0x61}, // RGB565 {0x3800, 0x00}, // 窗口裁剪起点 {0x3801, 0x00}, {0x3802, 0x00}, {0x3803, 0x04}, // 裁剪窗口高度起点 {0x3804, 0x0A}, // 输出宽度 1280 {0x3805, 0x3F}, {0x3806, 0x07}, // 输出高度 720 {0x3807, 0x9F}, {0x3808, 0x05), // 实际输出 1280 {0x3809, 0x00}, {0x380A, 0x02}, // 实际输出 720 {0x380B, 0xD0}, {0x380C, 0x07), // 行时间 HTS {0x380D, 0x1F}, {0x380E, 0x02}, // 帧时间 VTS {0x380F, 0xAF}, {0x3810, 0x00}, // ISP 裁剪 {0x3811, 0x08}, {0x3812, 0x00}, {0x3813, 0x04}, {0x3814, 0x31}, {0x3815, 0x31}, {0x5000, 0xA7}, // ISP 功能使能 ... };这段配置里最关键的就是0x3800~0x380F这几组寄存器。我用了一个很笨但很有效的办法调窗口参数：先输出VGA分辨率，用示波器看PCLK/VSYNC波形确认输出格式正确，再逐步把分辨率拉上去。一次改几百个寄存器出了问题根本没法定位，分段调试反而快。
3.4 DCMI+DMA的双缓冲采集
DCMI配置好之后，图像数据流是：OV5640输出8位并行数据 → DCMI外设按照同步信号组装成帧 → DMA搬运到内存。这里DCMI和普通外设最大的不同是：它不是由CPU主动发起请求，而是被动的数据“洪流”，PCLK一来数据就来了，MCU根本没时间逐像素处理。所以DMA几乎是必须的。
双缓冲是图像采集中防止画面撕裂的标准做法：两个图像缓冲区，DMA正在往A缓冲写当前帧时，CPU在处理B缓冲的上一帧，写完A后立刻切到B，如此交替。HAL库的DCMI驱动里已经封装了这套机制：
#define IMAGE_WIDTH 1280 #define IMAGE_HEIGHT 720 #define IMAGE_SIZE (IMAGE_WIDTH * IMAGE_HEIGHT * 2) // RGB565，每像素2字节 static uint8_t frame_buffer[2][IMAGE_SIZE] __attribute__((aligned(32))); static volatile uint8_t current_buffer = 0; // 启动DCMI采集，使用DMA双缓冲模式 HAL_DCMI_Start_DMA(&hdcmi, DCMI_MODE_CONTINUOUS, (uint32_t)frame_buffer[0], (uint32_t)frame_buffer[1], IMAGE_SIZE / 2);注意这里IMAGE_SIZE / 2这个参数。HAL库的DCMI_DMA传输长度单位是32位字（Word），不是字节。RGB565每像素2字节，每个32位字包含2个像素，所以1280×720的图像总共需要的字数是1280*720*2/4 = 460800。如果这里写错了，DMA会提前停止或者越界访问。
两个FrameEvent回调分别对应帧完成事件：
void HAL_DCMI_FrameEventCallback(DCMI_HandleTypeDef *hdcmi) { // 当前帧采集完成，GPU/CPU可以开始处理 current_buffer 指向的缓冲区 current_buffer = (current_buffer == 0) ? 1 : 0; // 这里添加图像处理任务，比如颜色转换、存储、显示 }每帧图像数据量大，中断回调里千万别做重活。我习惯在回调里只置一个标志位，在主循环里根据标志位处理图像帧，因为F407主频168MHz，处理一帧720p RGB565需要做像素级运算时，如果把处理逻辑直接放在中断里，会严重影响实时性，甚至在PCLK持续输入时触发DCMI溢出错误。
4. 图像数据出来之后：RGB565转BMP显示与帧率带宽核算
DMA把数据搬到内存后，你拿到的数据是raw RGB565格式。这时候很多人会问：我电脑上打开怎么看不到画面？因为电脑上普通的图片浏览器根本不认原始RGB565数据，需要先转成BMP或者通过串口/以太网发到上位机显示。
4.1 RGB565如何转成标准图像格式
RGB565的含义是每个像素16位，高5位为红色、中间6位为绿色、低5位为蓝色。如果要转成24位BMP，核心就是做一个颜色格式转换：
void rgb565_to_bgr24(uint16_t *src, uint8_t *dst, uint32_t pixel_count) { for (uint32_t i = 0; i < pixel_count; i++) { uint16_t pixel = src[i]; uint8_t r = (pixel >> 11) & 0x1F; uint8_t g = (pixel >> 5) & 0x3F; uint8_t b = (pixel) & 0x1F; // 5位/6位扩展到8位，左移保留高位，低位补0 *(dst++) = (b << 3) | (b >> 2); // B *(dst++) = (g << 2) | (g >> 4); // G *(dst++) = (r << 3) | (r >> 2); // R } }BMP文件结构要注意：BMP的像素行是从下往上存储的（Bottom-up），而且每行字节数必须是4的倍数，1280×720×3 = 2764800字节正好是4的倍数，所以不用额外填充。如果输出分辨率让BGR24每行字节数不是4的倍数，要记得补零字节，否则文件打不开或者图像斜着错开。
另一种更省事的方式是找到带屏幕的板子（比如接一块SPI屏或者RGB屏），DMA把图像数据直接刷到屏幕DMA。不过这个方案调试起来要考虑DCMI和LCD两个DMA的带宽冲突，H7系列LTDCC和DCMI同时跑的时候，要关注AHB总线仲裁是否会出现带宽不足。
4.2 帧率和带框计算：为什么我的帧率只有10fps
帧率和有效数据量的关系做一个简单计算就清楚了：
- 720p RGB565：1280×720×2字节 = 1,843,200字节 ≈ 1.76 MB/帧
- 30fps所需的带宽：1.76 × 30 = 52.8 MB/s
- STM32F407的AHB总线带宽理论值：168MHz × 4字节 = 672 MB/s，但实际DCMI的数据走DMA，要竞争AHB总线访问权，加上其他外设（比如ETH、SDIO、LCD）同时工作，实际可用的总线带宽大概是理论值的30%~50%。
这个计算说明F407跑720p@30fps在理论带宽上是够的，但如果同时开着以太网大数据传输，或者LCD同时刷新高清画面，就可能出现DCMI FIFO溢出的情况。解决思路：
- 适当降低帧率，不需要30fps的场景可以降到15fps甚至10fps
- 用JPEG输出模式替代RGB565，图像数据量可以压缩到原来的1/10以下，这是高分辨率下最有效的办法
- 换用H7系列（带更大的DCMI FIFO和更强的AXI总线），或者用DMA2D等专用图形搬运单元
但这里要注意一个反直觉的坑：OV5640在JPEG模式下输出是变长码流，一帧数据量不固定，DCMI+DMA连续模式下无法预知DMA传输长度，实现起来比RGB565麻烦不少。所以如果你只是做简单的图像采集显示，RGB565仍然是STM32上最省心的选择。
5. 常见问题与排查技巧实录：我踩过的坑全在这里
写代码部分其实很快，真正折磨人的是硬件调试阶段。下面这些问题是过去一年里我和身边朋友做OV5640项目时反复遇到的，每条都对应确实发生过的血泪教训。
5.1 花屏/条纹/雪花：有人以为是代码问题，其实九成是信号完整性问题
现象：DCMI采出来的图像完全是一团乱麻，看不出任何物体轮廓。
排查顺序：
- 先把分辨率降到最小（比如VGA或者QVGA），排除sensor内部scaler配置错误的可能。
- 用示波器量PCLK波形：正常应该是一路干净的方波。如果PCLK上升沿有明显振铃或者毛刺，数据线上的数据肯定也会被污染，问题多半出在模组排线。
- OV5640的数据线换到D0~D7并口时，和PCLK、HREF、VSYNC之间的长度差是有要求的。如果飞线过长或者没有等长处理，高速翻转时采样窗口会偏移。我遇到过一次用20cm杜邦线连接，PCLK边缘毛刺大到无法正确采样，改成短排线后一切正常。
5.2 图像左移或右移、出现斜纹
现象：图像内容能辨认出来，但整体带斜向错位，或者顶部有半行残留。
这个问题的根源几乎都是HREF（行同步）和PCLK的时序关系没对齐。OV5640输出RGB565时，每一行的有效像素不是从PCLK第一个沿就开始有效，HREF高电平期间PCLK的边沿会先传送几个dummy数据，真正的有效数据从HREF有效后的某个偏移才开始。
排查方法：看OV5640的寄存器0x3820和0x3821，这两项控制每行输出的时序偏移。Linux下的初始化序列为了兼容各种sensor配置，会给一个默认的偏移量，但不同模组因为PCB布局不同会导致微小差异，手动微调这两个寄存器就能解决。
5.3 DMA中断频繁导致程序卡死
现象：代码一跑就进HardFault，或者主循环根本执行不到。
这个问题有几个层面：第一，确认DCMI中断和DMA中断是否都在NVIC里正确使能，优先级是否合理。第二，如果开了全局中断但DCMI_IT配置不对，帧中断丢失会导致DMA没有及时切换缓冲，下一帧数据覆写正在处理的缓冲区，出现硬件错误。第三，HAL库在HAL_DCMI_ErrorCallback里会报告DCMI溢出错误（Overrun），如果你在中断回调里处理时间太长，DCMI FIFO灌满后DMA来不及搬运，就会触发Overrun。我的做法是：
void HAL_DCMI_ErrorCallback(DCMI_HandleTypeDef *hdcmi) { // 发生错误后必须停止并重新启动DCMI，否则后续帧永远进不来 HAL_DCMI_Stop(&hdcmi); // 清理错误标志 __HAL_DCMI_CLEAR_FLAG(&hdcmi, DCMI_FLAG_OVR | DCMI_FLAG_ERR); // 重新启动 HAL_DCMI_Start_DMA(&hdcmi, DCMI_MODE_CONTINUOUS, (uint32_t)frame_buffer[0], (uint32_t)frame_buffer[1], IMAGE_SIZE / 2); }5.4 颜色偏绿偏紫完全不对
现象：图像轮廓清晰，但颜色完全不对，比如草地变成了紫色，人脸变成了绿色。
RGB565模式下颜色不对，大概率是字节序问题。DCMI外设接收数据进入内存时，是高位先还是低位先，由寄存器DCMI_CR的BYTE_SELECT位和HALF_BYTE_SELECT位控制。OV5640输出的RGB565在每个字节内部的排列顺序与ARM小端存储方式交互后，经常出现高低字节反过来的情况。
解决方式不复杂，两种路径任选：
- 修改DCMI_CR的字节选择位，让数据进来的字节序和前面的处理代码一致。
- 在软件层转RGB565为RGB888时，把高字节和低字节交换，即
pixel = (pixel >> 8) | (pixel << 8)。
顺便说一下，如果用的是YUV422格式，颜色不对就不是字节序问题，而是YUV转RGB的系数矩阵不对。OV5640输出YUV时大部分情况下是按照BT.601标准，直接用标准的转换公式就行。
5.5 sensor初始化后无输出图像
如果你是严格按照上面的流程操作，DCMI也配置正确，但始终没有数据到来，大概率是OV5640压根没有输出。这时候用示波器量OV5640的PCLK引脚，如果没有波形，说明sensor内部没跑起来。常见原因：
- XVCLK主时钟没有输出。很多人在CubeMX里用TIM1输出24MHz，但忘了使能定时器或者在GPIO配置时选了复用功能不对。用示波器测PA8引脚是否真的输出24MHz时钟。
- PLL没锁定。OV5640的PLL配置寄存器如果倍频系数超出了范围，sensor内部会锁不住，直接表现为PCLK无输出。尝试把分辨率降到最低（改0x3808和0x380A为VGA尺寸），用OV5640默认的PLL配置，先确认基本通路能否产生数据。
- sensor复位时序不对。OV5640上电后需要RESET引脚一个至少低电平保持几十毫秒的复位脉冲，然后释放，如果复位引脚被外部电容拉住一直处于复位状态，读ID都会失败。
6. 关于OV5640在HAL库工程里的几个补充建议
最后再说几条项目落地时值得注意的经验，都是我实际编程时容易漏掉的地方。
关于内存对齐，建议为DMA缓冲区加上32字节对齐属性。STM32的DMA在访问未对齐内存时，某些配置下会降低效率甚至产生总线错误。在MDK或GCC下使用__attribute__((aligned(32)))是最简单的保障。
调试时开DCMI的嵌入式同步码（Embedded Synchronization）功能。OV5640除了默认的硬件同步信号模式外，还支持在数据流里插入帧头/行头同步码的方式。用嵌入式同步码时，DCMI配置里要选对同步模式，数据解析逻辑也要相应调整。两种模式混用是新手最容易搞混的地方，但这个特性在某些DMA配置下能大幅提高稳定性，值得花时间研究。
HAL库版本之间行为有差异，建议固定一个版本。我用的是STM32Cube_FW_F4_V1.26.0，后面的版本DCMI实现基本没变，但如果是老项目升级HAL库，DCMI驱动代码有改动，记得对比一下stm32f4xx_hal_dcmi.c的更新内容。
能用Visual Studio或VS Code看图像就别在串口上折腾了。很多帖子教人用串口发送图像到PC端显示，9600波特率下一帧720p图片要传半个多小时。我后来是用SD卡把原始数据写到文件里，拔卡在电脑上解析，调试效率至少快十倍。如果你有以太网口，用UDP把图像数据包发到PC端上位机，帧率能达到很流畅的程度，这个方案生产环境里也在用。
做STM32图像采集这件事，说难不难，说简单也不简单。难在sensor初始化序列上千个寄存器让人望而生畏，简单在一旦把DVP/DCMI这条链路跑通，后续所有的调试都变成了熟能生巧。核心还是要把硬件信号链路搞清楚——哪些信号由sensor产生、哪些由MCU产生、各个信号的时序约束是多少，理清这些，比抄多少行代码都有用。如果这篇能帮你少走一段弯路，我就觉得非常值了。
