STM32F103 GPIO驱动OV2640摄像头：无DCMI接口的时序采集方案详解

简介：本资源是一套基于GPIO接口方式实现STM32F103驱动OV2640摄像头的完整嵌入式开发工程，面向嵌入式初学者、课程设计学生及STM32F1系列单片机开发者，解决图像传感器底层驱动与实时数据采集的核心难点。压缩包共176个文件，含94个头文件（.h，定义寄存器、结构体与函数声明）、77个源文件（.c，涵盖HAL库初始化、I2C配置OV2640寄存器、DMA图像数据接收、TIM定时触发、UART调试输出等关键模块），以及工程配置文件（.uvprojx/.uvoptx）和可执行镜像（.hex），总大小1.13MB。已有4309人学习下载，说明其在实践教学与项目复现中具备较高参考价值。读者可直接导入Keil MDK编译运行，获得从硬件连接、I2C通信、OV2640初始化到JPEG/YUV格式图像捕获的全流程代码支撑，并通过预览中涉及的HAL_TIM、HAL_I2C、HAL_SPI等标准外设驱动文件，深入理解STM32F1平台多外设协同工作的典型架构与调试逻辑。 最近整理了一个挺有年代感的方案：STM32F103 通过 GPIO 接口方式直接驱动 OV2640 摄像头模块。很多人可能第一反应是“为什么不直接用 DCMI 摄像头数字接口”，但等你看完 STM32F1 系列的参考手册就会明白，F103 根本没有 DCMI 外设。既然手上只有一块 STM32F103 最小系统板，又想跑摄像头，那 GPIO 接口方式就是最现实、最通用的一条路。这个方案不挑具体型号，只要芯片是 STM32F1 系列，几乎都能用。刚好手头积累了一套可用的工程，我把它整理成了 zip 包，今天就把里面的设计思路和调试过程完整讲一遍。

这套东西特别适合三类朋友：一是学校课程设计要搞图像采集、智能小车视觉识别，但手头只有 F103 板子的；二是手里有闲置 OV2640 模块，想用标准库快速跑通摄像头输出，暂时不想换 F4/F7 平台的；三是对 OV2640 的 PCLK、VSYNC、HREF 这些时序信号还比较模糊，想通过 GPIO 逐字节读取来加深理解的。如果只是想拍张照片传电脑，那用串口加 PC 端上位机就能解决，不用急着上屏或者上操作系统。

1. 方案选型：为什么 GPIO 接口方式绕不开

1.1 先搞清楚 STM32F103 和 OV2640 之间的“接口鸿沟”

OV2640 是一颗 200 万像素的 CMOS 图像传感器，它对外输出的图像数据接口本质上是 8 位并行的 DVP 接口。正常工作时，摄像头会给出像素时钟 PCLK、帧同步信号 VSYNC、行同步信号 HREF，以及 D0-D7 这 8 根数据线。MCU 要做的事情，就是在 PCLK 的节拍下，把 D0-D7 上的数据一个字节一个字节地读回来。

问题在于，STM32F103 的数据总线和 GPIO 虽然都能完成这个任务，但芯片内部没有专门的摄像头接口。到了 STM32F4 系列才开始有 DCMI，可以直接接收 DVP 并行信号，还要配合 DMA 才能高效搬运数据。而在 F1 系列上，我们能用的就是纯粹的 GPIO。换句话说，所有同步信号、所有数据字节，都要靠 GPIO 读引脚电平来完成，时序上完全依赖软件控制。

这听起来很“原始”，但它有一个极大的优势：可移植性好。不管你是 F103C8T6、F103ZET6 还是其它 STM32F1 型号，只要把引脚分配理清楚，程序几乎不用改。而且 GPIO 读取方式能让你把整个摄像头时序看得明明白白，后面的调试经验也能直接迁移到 DCMI 方案上。

1.2 GPIO 接口方式的代价与适用场景

当然，代价也很直白。第一是占用的引脚多，OV2640 一旦启用完整 8 位数据接口，加上 PCLK、VSYNC、HREF 和 I2C 配置引脚，最少要十几个 GPIO。第二是 CPU 占用率极高，如果输出的是 RGB565 格式，一帧 320x240 的图像就是 15 万字节，纯靠 GPIO 轮询去读，主频 72MHz 的 F103 也会被拖到喘不过气。第三是帧率上不去，JPEG 模式相对好一点，可以只拍特定分辨率并压缩数据量，但和正经 DCMI 加 DMA 的方案比起来，差距明显。

所以，这个方案更适合“功能验证”和“学习原理”，不太适合做高帧率实时视频流。我在项目里默认把摄像头设置成 JPEG 输出模式，分辨率压到 320x240 甚至更小，这样一帧数据量可以控制在几十 KB 以内，F103 的 64KB SRAM 才勉强扛得住。如果你手头的 F103 只有 20KB SRAM，那建议把分辨率降到 160x120，并且用串口边读边发，不要整帧缓存。

1.3 还有一个隐藏的选型原因：调试方便

用 GPIO 方式还有一个容易被忽略的实用价值，就是调试非常直观。你可以不接摄像头，直接用杜邦线把某个 GPIO 拉高拉低，模拟 PCLK 和 HREF，看看读数据这部分程序是否正常。这在没有逻辑分析仪的场合尤其有用。我实际调试时，就是先让 STM32F103 自行产生一组伪 PCLK 和 D0-D7 数据，验证软件抓取逻辑正确以后，再真正接上 OV2640。

如果用 DCMI 的话，没逻辑分析仪真的很难确认时序，因为那是芯片内部硬件在采集，软件只能看到最后的结果。GPIO 方式等于是把摄像头接口的每一根线摊开在桌面上，出了问题你可以顺着时序一步一步查，这是我很推荐新手先用 GPIO 方式玩一遍 OV2640 的核心原因。

2. OV2640 核心接口与工作原理

2.1 引脚功能与接线要点

先看 OV2640 模块上常见的排针。就算不同厂家的模块丝印略有差异，核心引脚基本一致：VCC、GND、SCL、SDA、VSYNC、HREF、PCLK、XCLK，以及 D0-D7。模块上的 SCCB 接口我用的是 GPIO 模拟方式，SCL 和 SDA 分别接到 F103 的两个普通 GPIO，通过软件协议去读写 OV2640 的内部寄存器。

这里特别提醒一下，很多 OV2640 模块上有两组电源引脚：VCC 和 DOVDD。VCC 是模拟供电，一般接 3.3V，DOVDD 是数字接口供电，也可以接 3.3V，但要看模块上是否有板载稳压和电平转换电路。有些老模块没有电平转换，如果接 5V 单片机会有风险。STM32F103 和 OV2640 都是 3.3V 逻辑，直接连 3.3V 就行，杜邦线尽量短一点。PCLK 在 VGA 分辨率下能跑到几十兆赫兹，杜邦线太长会带来信号完整性问题，我经常为此把帧数据抓花。

一个容易忽略的引脚是 XCLK。OV2640 需要一个外部时钟输入，一般接 24MHz。F103 上面没有专门给摄像头提供时钟的引脚，但可以利用 MCO 引脚，也就是 PA8，通过重映射把 PLL 输出的 24MHz 时钟送到 XCLK。如果没有用 MCO，也可以用 GPIO 翻转模拟一个方波时钟，但那样频率不稳定，不建议。所以引脚分配时一定提前留好 PA8。

2.2 同步信号与时序基础

OV2640 输出的是一帧一帧的图像，每帧由若干行组成。VSYNC 会标定一帧图像的开始和结束，HREF 标定每一行有效像素的区间，PCLK 则提供像素节拍。在一个行有效周期内，每个 PCLK 脉冲对应一个字节或一个像素的数据输出。如果不理会这些同步信号，一股脑地按 PCLK 读数据，出来的画面一定是错乱甚至的雪花点。

在我这个工程里，具体流程是这样：先等 VSYNC 产生一个下降沿，表示新一帧开始；然后等 HREF 变高，进入行有效；之后在 HREF 为高期间，每个 PCLK 上升沿读取一次 D0-D7；HREF 变低以后一行结束，继续等待下一行 HREF。这样一行一行地读完整个有效区域，一帧图像就拼出来了。

有一个细节值得注意，OV2640 的 PCLK 极性可以通过寄存器配置成上升沿有效或下降沿有效，默认是上升沿。我在程序里使用的是“上升沿读数据”的方式，如果后续你想换模块或改配置，一定要先确认 PCLK 的极性设置，否则数据错位是很正常的事。

2.3 输出格式选择：RGB565 还是 JPEG

OV2640 支持多种输出格式，常见的包括 YUV422、RGB565 和 JPEG。对 GPIO 接口方式来说，我强烈建议用 JPEG。原因很简单：JPEG 输出本身就是压缩后的数据，一帧 320x240 的图像往往只有十几到几十 KB，而且没有严格的像素同步要求，你只需要在字节流中搜索 JPEG 起始标志 0xFFD8 和结束标志 0xFFD9，截取中间数据就是完整图。

RGB565 虽然解码简单，但数据量太大，而且要求每一行每个像素的读取时序都必须严格准确，只要一个像素错位，整行颜色就全乱了。用 GPIO 轮询的方式去读 RGB565，通常只能做到低分辨率和极低帧率，体验很糟糕。如果你后续要在 F103 上做简单的图像处理，比如二值化或者找色块，其实也可以先用 JPEG 模式把图像传给电脑，再做离线处理。想实时在线处理的话，F103 的性能会非常吃力。

2.4 SCCB 配置与寄存器初始化

OV2640 的控制接口是 SCCB，本质上兼容 I2C，只是时序要求略有不同。设备地址通常为 0x60 写入、0x61 读取。工程里我用 GPIO 软件模拟 I2C，这样引脚选择更自由，不用死磕硬件 I2C。初始化流程主要包含三块：设置输出格式、设置分辨率、设置 JPEG 压缩质量。

我在这套工程里保存了一组常用的 OV2640 初始化寄存器序列，直接通过 SCCB 依次写入。需要注意，OV2640 的寄存器体系有 bank 切换机制，写寄存器前可能需要先切换 bank，具体值还是要看官方 datasheet 或者参考 Omnivision 的例程。如果你拿到的模块附带测试程序，最好把它的初始化序列抄过来，不同批次模块之间，有些寄存器默认值不一定完全一致，但绝大多数情况下标准序列都能跑起来。

初始化完毕以后，可以通过寄存器 0x12 确认输出格式。JPEG 模式下，0x12 的 bit3 需要设置成 1。如果读出来的图像是一堆乱码，第一件事就是回读这个寄存器，看看格式配置是否真的写进去。SCCB 写失败这种事，在杜邦线接触不良的时候太常见了。

3. STM32F103 侧 GPIO 设计与初始化

3.1 GPIO 八种工作模式到底怎么选

这个项目几乎把 F103 GPIO 的常用模式都用上了。F1 系列 GPIO 一共有八种模式，分别是模拟输入、浮空输入、上拉输入、下拉输入、推挽输出、开漏输出、复用推挽输出、复用开漏输出。很多人初学时记不住这八个模式到底有什么区别，我建议从两个维度去看：输入还是输出，以及引脚内部有没有电阻或输出驱动结构不同。

OV2640 的数据线和同步信号，都是摄像头主动输出的信号，而且输出驱动能力比较强。所以在 STM32F103 这一侧，D0-D7、PCLK、VSYNC、HREF 这 11 个引脚统统配置成浮空输入。选浮空而不是上拉输入或下拉输入，是因为外部信号源本身是推挽输出，它的高电平和低电平都是确定的，不需要 MCU 内部上拉电阻来固定电平。内部上拉电阻一般是 30-50K 欧姆，会对高速信号的边沿产生轻微影响，虽然不至于致命，但没必要引入这个变量。

SCL 和 SDA 这两个引脚有点特殊。因为是软件模拟 I2C，SCL 始终由 MCU 主动驱动，可以配置成推挽输出。SDA 是双向引脚，读的时候要切换成输入，写的时候要切换成推挽输出。我在实际工程里是直接把 SDA 配置成开漏输出，外部加上拉电阻，这样天然就能支持双向通信，不需要反复切换模式，省去不少麻烦。

3.2 引脚分配建议与冲突检查

分配引脚是 GPIO 方式最容易踩坑的一步。我踩过一次很冤枉的坑：把数据线接到了 PC13 引脚，结果那一路怎么读都是错的。后来查手册才发现，PC13、PC14、PC15 这三个引脚在 F103 上属于备份域，内部还有 RTC 相关的电路，当作普通高速 GPIO 使用非常受限。

我的建议是，8 根数据线优先使用同一个 GPIO 端口的连续引脚，比如 PC0-PC7。这样做有个巨大好处：你可以一次读取整个端口的低 8 位，只需要从 IDR 寄存器取一个整型值，再按位与 0xFF，比逐根引脚调用 GPIO_ReadInputDataBit 快得多。GPIO 逐位读取虽然直观，但在高速 PCLK 下会拖慢程序，容易丢数据。

同步信号 PCLK、VSYNC、HREF 可以放在另一个端口，比如 PB0、PB1、PB2。这样数据端口和同步信号端口分开，软件读取时结构清晰，调试也方便。XCLK 用的是 PA8 的 MCO 输出，SCL 和 SDA 放在 PB10 和 PB11 或者 PB6 和 PB7 都行。分配完以后，先打开 STM32CubeMX 或者其他引脚冲突检查工具，把工程里已经占用的引脚标出来，避免和串口、下载器、LED 等资源打架。

3.3 初始化代码示例

这里给出一段标准库环境下的 GPIO 初始化代码。工程里我用的是标准外设库，而不是 HAL 库，因为 F1 系列用标准库的人还是很多，而且代码更直白一点。

void OV2640_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; // 开启 GPIOB、GPIOC、GPIOA 时钟 RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA | RCC_APB2Periph_GPIOB | RCC_APB2Periph_GPIOC, ENABLE); // 同步信号 PCLK/PB0、VSYNC/PB1、HREF/PB2，全部浮空输入 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); // 8 位数据线 PC0-PC7，也配置成浮空输入 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0 | GPIO_Pin_1 | GPIO_Pin_2 | GPIO_Pin_3 | GPIO_Pin_4 | GPIO_Pin_5 | GPIO_Pin_6 | GPIO_Pin_7; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOC, &GPIO_InitStructure); // SDA/PB11 开漏输出，SCL/PB10 推挽输出 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_10; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_11; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_Out_OD; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOB, &GPIO_InitStructure); // 读取 SDA 前，把 SDA 切回输入模式 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_11; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOB, &GPIO_InitStructure); }

如果你用 HAL 库，逻辑也是一样的，只是把函数名从 GPIO_Init 换成 HAL_GPIO_Init。这里有个小细节，GPIO_Speed 对于输入模式其实不起作用，速度配置主要影响输出驱动电路的翻转速率。但我习惯统一设置成 50MHz，这样后面如果某些引脚要临时改成输出，不会因为忘记配置速度而采坑。

3.4 为什么速度配置和内部结构不是小事

GPIO 速度选项有 2MHz、10MHz 和 50MHz，它决定的是输出驱动器在电平翻转时的边沿速率。高速模式翻转更快，但也会带来更大的噪声和功耗。对输入模式而言，速度配置不影响输入采样，但会影响施密特触发器的相关特性。F1 的 GPIO 输入路径里有一个施密特触发器，可以把缓慢变化的模拟信号整形成干净的数字电平。OV2640 数据信号在杜邦线传输后会变差，这时候施密特触发器能帮忙过滤一部分噪声。

我建议在保证信号完整性的前提下，优先用适中的 GPIO 速度。如果你把数据口临时改成输出用来调试，比如主动输出特定数据模拟摄像头信号，那就一定要把速度调到 50MHz，否则数据波形边沿会慢到无法模拟真实时序。别小看这个设置，我曾经一次调试中，所有配置都对，就是速度设置太低，导致模拟时序整体变慢，摄像头端始终不识别。

4. 数据采集：用 GPIO 逐字节抓取一帧图像

4.1 像素字节从哪里来

OV2640 在 JPEG 模式下，D0-D7 上的数据流并不是“每个像素点一个字节”，而是 JPEG 编码器输出的压缩字节流。也就是说，数据线和 PCLK 之间的关系仍然有效，但数据内容在不同时刻可能是图像头、量化表、霍夫曼表或者压缩图像数据。软件层面不需要理解 JPEG 编码细节，只需要把所有字节保存下来，最后按 JPEG 文件格式处理即可。

正因为是字节流，行同步信号 HREF 的意义不再是“图像的每一行边界”，而是“数据块输出的有效区间”。在 JPEG 模式下，HREF 仍然有效，但它对应的行信息没有 RGB565 那么直观。实际操作中，我们可以不关心 HREF 的具体行号，只把它当作判断“当前有没有数据输出”的门控信号。当 HREF 为高时，PCLK 每来一个脉冲，就读一个字节；HREF 为低时，就读不到数据。

4.2 一个最简单的读取循环

下面是我在工程里最初用的核心循环，逻辑很简单，就是把 GPIO 端口上的数据读回来，存进数组，同时寻找 JPEG 起始标志。

uint8_t frame_buf[60000]; uint16_t frame_len = 0; uint8_t last_byte = 0; uint8_t state = 0; while (1) { // 等待 VSYNC 高，表示新帧开始 while (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_1) == 0); while (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_1) == 1); // 等待 HREF 高电平 while (GPIO_ReadInputDataBit(GPIOB, GPIO_Pin_2) == 0); frame_len = 0; state = 0; while (HREF_IS_HIGH()) { if (PCLK_IS_HIGH()) { // 上升沿到，读取 8 位数据 uint8_t data = (uint8_t)(GPIOC->IDR & 0xFF); // 只做 JPEG 头检测 if (state == 0) { if (last_byte == 0xFF && data == 0xD8) { frame_buf[0] = 0xFF; frame_buf[1] = 0xD8; frame_len = 2; state = 1; } } else { if (frame_len < sizeof(frame_buf)) frame_buf[frame_len++] = data; if (last_byte == 0xFF && data == 0xD9) { // 检测到 JPEG 结束标志，一帧图像完成 break; } } last_byte = data; } } // 一帧完成，可以在这里做串口发送或 SD 卡存储 break; }

这段代码里有一个隐患，PCLK 为高电平的持续时间可能很短，轮询判断时会存在漏读风险。如果你的模块 PCLK 配置得比较低，比如把输出分辨率调小以后，PCLK 相对较低，那这段代码能正常工作。但如果你想提高帧率，就得用边沿中断或者定时器捕获，或者干脆先降低 PCLK。

4.3 上升沿判断和电平读取的取舍

很多朋友会纠结，为什么不用 EXTI 外部中断检测 PCLK 上升沿。外部中断确实比轮询更省 CPU，而且边沿触发更精确。但 OV2640 的 PCLK 频率对于 F103 的外部中断来说太快了，中断响应需要保存现场、跳转、读取数据、恢复现场，一秒钟进来几百万次中断，CPU 几乎全是开销，主程序根本没法跑。就算勉强能读，也容易因为中断响应不及时丢字节。

所以我更推荐把 PCLK 频率压下来，配合轮询读取。OV2640 的输出时钟可以通过设置分频寄存器降低。做验证功能时，把 PCLK 控制在 5MHz 以内，轮询读取一帧 JPEG 仍然是可以接受的。这样代码简单，不容易出问题。等真正要提速的时候，可以考虑用 DMA 加外部引脚触发，但那就已经不是 GPIO 轮询方案的范畴了。

4.4 数据缓冲与串口传输策略

GPIO 方式采集到的数据最终要送到电脑或 SD 卡存储。F103 上最常见的做法是通过串口把 JPEG 数据发送到上位机。这里注意，一帧 JPEG 图像可能有几十 KB，如果用串口以 115200 波特率发送，一帧需要好几秒，体验非常痛苦。我建议至少把串口波特率调到 921600 或者 2M，如果上位机支持的话。

另一个办法是直接用 SDIO 或者 SPI 接口写 SD 卡，把 JPEG 文件存成文件。F103 有 SDIO 外设，但 SDIO 的底层驱动稍微复杂一些，很多朋友直接用 SPI 模式访问 SD 卡，速度虽然不够快，但对存几张照片来说完全够用。如果你用的是 STM32F103RET6 这种 64KB SRAM 的型号，可以把一帧 JPEG 完整缓存在 RAM 里，存卡或发串口都方便。如果 RAM 太小，就只能边读边发，或者边读边写 SD 卡，代码复杂度会高不少。

5. 调试过程与常见问题排查

5.1 画面全黑或全白，问题大多不在读取代码

遇到的第一类经典问题，是读取到的 JPEG 数据看起来有内容，但上位机解码后一片黑或一片白。这个时候不要急着抓代码，先检查 OV2640 镜头有没有盖、感光区域有没有对着亮处。很多 OV2640 模块的镜头出厂时带着保护膜，或者排线没插牢，导致感光芯片没工作，输出就是黑帧。

排除物理因素以后，再去检查初始化寄存器。JPEG 模式下如果压缩设置不对，可能导致量化表全零，解码器解出来的就是“没有颜色对比度”的图像，看着像半黑半白的乱码。我一般会先回读 0x12 寄存器确认输出格式位，再回读 JPEG 压缩相关的寄存器，看有没有写成 0。另外，OV2640 的初始化序列必须按先设置分辨率、再设置输出格式、最后启动 JPEG 模式的顺序来，顺序错了容易导致寄存器值冲突。

5.2 数据错位、画面撕裂，先怀疑接线和 PCLK 极性

画面撕裂、有明显偏移或者花屏，最可能的原因是 PCLK 边沿选择不对。OV2640 默认在 PCLK 上升沿输出数据，但有些模块或者某些初始化配置会让数据在上升沿之后才稳定。解决办法是读数据前加一小段延时，或者在下降沿读取。改用下降沿读取也只需要改循环里的判断条件，从等待 PCLK 为高改成等待 PCLK 为低。

杜邦线接触不良也是常见原因。OV2640 的 D0-D7 有 8 根线，如果有一根接触不良，整个数据流的某些位就会丢，画面出现规律性错位。排查时用万用表量通断，或者干脆把所有线重新插一遍。还有一个容易被忽略的问题，地线没接好。摄像头和 MCU 之间如果没有共地，GPIO 读回来的信号到处乱飘，画面完全不能用。接摄像头时第一根线永远先接 GND。

5.3 JPEG 数据长度异常，帧缓冲区溢出

GPIO 方式采集 JPEG 最怕的就是图像太大，缓冲区装不下。OV2640 的 JPEG 输出大小受分辨率和压缩质量影响波动很大，同一个场景下，信息量大的画面可能会突然多出几 KB。所以不设保护长度上限直接往数组里写，就会出现缓冲区溢出，把程序其它变量冲掉，导致各种诡异现象。

工程里我在写入前加了长度检查，frame_len 如果超过数组容量就直接停止采集。触发溢出时，可以在串口打印一条提醒，方便知道是分辨率和 RAM 不匹配。另一个思路是调用 OV2640 的寄存器，把 JPEG 压缩质量调低一点，让每帧数据量更稳定。实测下来，320x240 分辨率、中等压缩质量，一帧 JPEG 通常稳定在 15KB 到 30KB 之间。

5.4 常见问题速查表

5.5 一个让我印象深刻的时序坑

我在这个项目里踩过最大的坑，是 MCO 时钟配置和摄像头 XCLK 不匹配。本来以为只要 PA8 输出 24MHz 就够了，结果发现 F103 的 MCO 默认输出的可能是 HSI 或者 HSE 分频后的频率，如果不改 MCO 预分频寄存器，XCLK 给到 OV2640 的不是 24MHz。OV2640 对 XCLK 的容忍范围有限，频率不对时初始化可能成功，但图像输出会非常弱，甚至没有数据。

后来我查了参考手册才发现，MCO 输出源是可选的，可以是 PLL 的 2 分频输出，也可以是 HSE 或 HSI。我为了让主频 72MHz，PLL 输出 72MHz，2 分频刚好 36MHz。OV2640 的 XCLK 一般支持 24MHz，我必须在 RCC 配置里把 PLL 的 2 分频输出作为 MCO 源，但这样输出是 36MHz，不是 24MHz。最终我改用外部 8MHz 晶振倍频到 72MHz，再通过 MCO 输出 8MHz 给摄像头，因为 OV2640 也支持 8MHz 到 27MHz 的 XCLK，只是图像输出时序和帧率会变。如果想让 XCLK 正好 24MHz，F103 的 MCO 配置确实需要仔细算一下，不能随意。

6. 工程结构、代码组织与后续扩展

6.1 解压后你看到的工程结构

这个项目打包成 zip 后，我按自己常用的方式组织了文件结构。核心代码分成三个部分：OV2640 驱动、GPIO 抓取、应用层。OV2640 驱动部分负责 SCCB 通信和寄存器初始化，GPIO 抓取部分负责时序读取和数据缓存，应用层负责串口发送、存储逻辑和测试主函数。

这样做的好处是，如果你想换到 HAL 库，或者换到另一款 STM32F1 型号，只需要改 GPIO 初始化和少量底层接口。寄存器初始化序列是通用的，摄像头本身的寄存器配置和 MCU 平台基本无关。我把常用初始化序列放在一个独立的数组里，方便直接替换成你手头模块的寄存器配置。

6.2 这套方案后续还能怎么扩展

如果你已经跑通了 GPIO 轮询读取 JPEG，后续扩展有几个方向。第一个方向是加 DMA，把 GPIO 的 IDR 寄存器地址作为 DMA 外设地址，用定时器触发 DMA 搬运数据，这样可以大幅降低 CPU 占用，但 F103 的 DMA 需要配合定时器才能实现外部引脚触发，配置复杂一些。第二个方向是加蓝牙或 Wi-Fi 模块，把 JPEG 数据发送到手机或电脑，做成无线拍照。第三个方向是换用带 DCMI 的 STM32F4，把这套寄存器初始化序列迁移过去，然后直接用硬件 DCMI 加 DMA，效率提升会非常明显。

还有一个容易被忽略的扩展点，就是利用 F103 的片上外设做简单图像判断。虽然 JPEG 数据不能直接像素处理，但可以通过 JPEG 文件大小大致判断画面复杂度，或者通过特定区域的亮度统计做简单逻辑判断。如果要做更复杂的视觉，建议还是把图片传到上位机处理。

6.3 关于 GPIO 模式选择的再补充

最后再聊两句 GPIO 模式。很多朋友纠结“GPIO 的 8 种工作模式”到底怎么背，我觉得从使用角度去理解就不难。摄像头的输入信号用浮空输入，是因为外部信号源本身是强驱动；SDA 这类双向信号用开漏输出，因为有了外接上拉电阻，低电平靠内部 MOS 管拉低，高电平靠上拉电阻实现，天然支持线与逻辑；PCLK、VSYNC、HREF 这种同步信号，其实是快速变化的数字信号，用浮空输入就足够，不需要软件干预电平。如果你哪天想用 GPIO 输出模拟时序，那就把对应引脚改成推挽输出，并注意把复用功能关闭。

这套 GPIO 接口方式驱动 OV2640 的工程，虽然谈不上高效率，但它把摄像头工作时序拆得很透，每一步都能用万用表和示波器验证。实际调试时，我也建议你从最小功能开始：先点亮摄像头的 SCCB 通信，再读几个寄存器确认芯片活着，然后才进入 GPIO 抓像素阶段。一步一步来，别想着一次搞定，这个项目就一定能跑通。

本文还有配套的精品资源，点击获取