1. 实验目标与系统架构概览

OV7725摄像头拍照实验的核心目标，是构建一个具备图像捕获、格式转换与持久化存储能力的嵌入式视觉子系统。该系统运行于STM32平台（以正点原子战舰/指南者开发板为典型载体），其功能边界明确：不依赖PC端上位机，不进行实时视频流传输，而是通过本地按键触发，将当前液晶屏（LCD）所显示的帧缓冲区内容，以标准BMP格式完整写入SD卡。这一过程本质上是一次“屏幕快照”（Screenshot），而非传统意义上的传感器原始数据直存，但其工程价值在于完整串联了图像采集、内存管理、文件系统操作与二进制协议编码四大关键技术栈。

整个系统并非孤立模块的简单叠加，而是一个具有清晰数据流向与职责划分的分层架构。底层是硬件抽象层（HAL），负责GPIO、USART、SPI、DMA等外设的初始化与寄存器级控制；中间层是外设驱动与中间件，包括OV7725的I2C配置、LCD的FSMC或SPI驱动、SDIO/SPI接口的SD卡驱动，以及FATFS文件系统；顶层是应用逻辑层，由 main() 函数调度，包含图像采集循环、按键中断服务程序（ISR）、截图触发逻辑与BMP文件生成引擎。其中， BSP_BMP.c 文件是本实验的技术核心，它屏蔽了BMP文件格式的复杂性，向上提供 LCD_Screenshot() 这一简洁接口，向下则精确构造符合Windows与Linux通用解析规范的二进制文件头与像素数据区。

值得注意的是，该实验对硬件环境有刚性约束：SD卡为必需外设，不可省略。其原因在于，STM32片上Flash容量有限（通常为数百KB），无法容纳一幅320×240分辨率、RGB565格式的原始图像（约153.6KB），更遑论多张图片的连续存储。而SD卡提供了廉价、大容量、可热插拔的非易失性存储方案。因此，在实验前，必须确保SD卡已正确插入开发板卡槽，并使用Windows磁盘管理工具或Linux mkfs.fat 命令将其格式化为FAT32文件系统。任何尝试在未格式化或格式化为exFAT/NTFS的SD卡上运行此程序的行为，都将导致FATFS初始化失败， f_mount() 返回 FR_NO_FILESYSTEM 错误，后续所有文件操作均无法执行。

2. 硬件连接与关键外设配置

2.1 OV7725与LCD的物理链路

OV7725作为一款并行输出的CMOS图像传感器，其与STM32的连接遵循严格的时序与电气规范。在战舰/指南者板上，OV7725的8位数据总线（D0-D7）直接挂载于STM32的FSMC_NADV或特定GPIO端口（具体取决于板载设计），用于传输YUV422或RGB565格式的原始像素数据。其关键控制信号包括：
- PCLK（Pixel Clock） ：由STM32的TIM定时器（如TIM3）通过PWM模式产生，频率需严格匹配OV7725的输出帧率（例如，QVGA@30fps下约为12MHz）。该时钟决定了像素数据的采样节奏，任何偏差都将导致图像撕裂或色彩错乱。
- VSYNC（Vertical Sync） ：垂直同步信号，低电平有效，标识一帧图像的开始。STM32需配置为外部中断输入（EXTI），上升沿或下降沿触发，用于精确捕获帧起始时刻。
- HSYNC（Horizontal Sync） ：水平同步信号，低电平有效，标识一行像素的开始。在本实验中，由于采用DMA自动搬运整帧数据，HSYNC常被用作行计数的辅助参考，但非必需中断源。
- RST与PWDN ：复位与掉电引脚，由GPIO控制，用于传感器的上电初始化与低功耗管理。

LCD模块（通常为3.2英寸TFT，分辨率为320×240）的驱动方式决定了图像显示的性能瓶颈。在资源受限的STM32F103系列上，普遍采用SPI接口（如SPI1）配合DMA进行数据传输，以避免CPU在逐像素写入时陷入阻塞。其关键配置点在于SPI的波特率设置：需在保证通信稳定的前提下尽可能提高，例如配置为 SPI_BAUDRATEPRESCALER_2 （主频72MHz下理论速率达36Mbps），这直接决定了LCD刷新一帧所需的时间，进而影响到按键响应的实时性。

2.2 SD卡接口与FATFS初始化

SD卡在本系统中承担着唯一的持久化存储角色，其接口方式有两种主流实现：SDIO与SPI。战舰/指南者板多采用SPI模式，因其硬件资源占用少、布线简单，且对STM32F103的兼容性更好。SPI接口下，SD卡的四根信号线为：
- CS（Chip Select） ：片选信号，由GPIO控制，低电平有效。
- SCK（Serial Clock） ：SPI时钟，由SPI外设产生。
- MOSI（Master Out Slave In） ：主机输出，向SD卡发送命令与数据。
- MISO（Master In Slave Out） ：主机输入，从SD卡读取响应与数据。

FATFS的初始化是整个存储流程的基石。其核心函数 f_mount() 的调用必须在SD卡物理初始化成功之后。物理初始化流程包含：发送 CMD0 使SD卡进入IDLE状态；发送 CMD8 查询SD卡版本与电压支持；发送 ACMD41 进行初始化并等待就绪；最后发送 CMD58 读取OCR寄存器确认初始化完成。只有当 disk_initialize() 返回 RES_OK ，且 f_mount() 返回 FR_OK 时，才能认为FATFS子系统已准备就绪。若在此阶段失败，最常见原因是SD卡接触不良、供电不稳或文件系统损坏，此时应检查硬件连接，并使用PC端工具重新格式化SD卡。

3. BMP文件格式深度解析与结构建模

BMP（Bitmap）文件格式是Windows操作系统原生支持的位图标准，其设计哲学是“简单即可靠”，不采用任何压缩算法，所有像素数据以明文形式线性排列。这种特性使其成为嵌入式系统图像存储的理想选择——无需复杂的解码逻辑，仅需按固定偏移写入二进制数据即可。理解BMP的二进制布局，是实现 LCD_Screenshot() 函数的前提。

一个标准的BMP文件由三大部分构成，其字节顺序严格遵循小端（Little-Endian）规则，即低位字节在前，高位字节在后。这与x86架构及大多数PC保持一致，但与某些嵌入式处理器（如部分ARM Cortex-M内核的默认模式）存在差异，需在代码中显式处理。

3.1 BITMAPFILEHEADER：文件头（14字节）

这是BMP文件的“身份证”，位于文件最前端，长度固定为14字节。其结构体定义如下：

typedef struct __attribute__((packed)) {
    uint16_t bfType;      // 文件类型标识，必须为0x4D42，即ASCII字符"BM"
    uint32_t bfSize;      // 整个文件大小（字节）
    uint16_t bfReserved1; // 保留字段，必须为0
    uint16_t bfReserved2; // 保留字段，必须为0
    uint32_t bfOffBits;   // 像素数据起始位置相对于文件开头的偏移量（字节）
} BITMAPFILEHEADER;

• bfType ：值为 0x4D42 （’M’+’B’），是BMP文件的唯一签名。任何BMP解析器首先会校验此字段，若不为 0x4D42 ，则直接判定为非法文件。
• bfSize ：这是一个动态计算值，等于 sizeof(BITMAPFILEHEADER) + sizeof(BITMAPINFOHEADER) + 像素数据总字节数 。在截图函数中，它必须在写入文件头时预先计算完毕，因为后续的 bfOffBits 也依赖于此。
• bfOffBits ：指明了从文件开头到实际像素数据块的字节偏移。对于标准24位BMP，其值恒为 14 + 40 = 54 字节，即文件头（14字节）加信息头（40字节）的长度之和。

3.2 BITMAPINFOHEADER：信息头（40字节）

紧随文件头之后，信息头描述了图像的几何与色彩属性，是BMP格式的核心元数据。其结构体定义如下：

typedef struct __attribute__((packed)) {
    uint32_t biSize;          // 本结构体大小，必须为40
    int32_t  biWidth;         // 图像宽度（像素），可为负值表示倒置
    int32_t  biHeight;        // 图像高度（像素），可为负值表示倒置
    uint16_t biPlanes;         // 平面数，必须为1
    uint16_t biBitCount;       // 每像素位数，本实验为24（RGB888）
    uint32_t biCompression;    // 压缩方式，0表示BI_RGB（无压缩）
    uint32_t biSizeImage;      // 像素数据大小（字节），可为0（由biWidth*biHeight推算）
    int32_t  biXPelsPerMeter;  // 水平分辨率（像素/米），可为0
    int32_t  biYPelsPerMeter;  // 垂直分辨率（像素/米），可为0
    uint32_t biClrUsed;        // 颜色表中实际使用的颜色数，0表示全部
    uint32_t biClrImportant;   // 重要的颜色索引数，0表示全部
} BITMAPINFOHEADER;

• biWidth 与 biHeight ：本实验中，LCD分辨率为320×240，故二者分别赋值为320和240。需特别注意，BMP的坐标系原点在左下角，而LCD的坐标系原点在左上角。因此，若要使最终图像在PC上正向显示， biHeight 应设为 -240 ，这样BMP解析器会将数据行从下往上绘制，从而抵消坐标系差异。
• biBitCount ：必须设为24，表示每个像素由3个字节（R、G、B各8位）组成。这是与LCD的RGB565（16位）格式的根本差异所在，也是截图函数中像素格式转换的核心任务。
• biSizeImage ：对于24位无压缩BMP，其值为 biWidth * biHeight * 3 。由于BMP要求每行字节数必须是4的倍数（DWORD对齐），实际每行字节数为 ((biWidth * 3) + 3) & ~3 ，因此 biSizeImage 应为 ((biWidth * 3) + 3) & ~3) * biHeight 。在320×240下， 320*3=960 ，已是4的倍数，故 biSizeImage = 960 * 240 = 230400 字节。

3.3 像素数据区：RGB888的线性存储

BMP的像素数据区是文件的主体，其组织方式极为规整：数据按行存储，每行从左到右，所有行从上到下（或从下到上，取决于 biHeight 符号）。每一像素由3个连续字节表示，顺序为B、G、R（注意，不是R、G、B！）。这是BMP格式的一个关键约定，源于早期Windows设备的色彩通道映射习惯。

对于LCD的RGB565格式数据，其单个像素的16位编码为： [R:5 bits][G:6 bits][B:5 bits] 。将其转换为BMP所需的BGR888，需执行以下位操作：
1. 提取R5： r5 = (rgb565 >> 11) & 0x1F
2. 提取G6： g6 = (rgb565 >> 5) & 0x3F
3. 提取B5： b5 = rgb565 & 0x1F
4. 扩展为8位： r8 = r5 << 3 | r5 >> 2 （复制最高位填充低三位）
5. 扩展为8位： g8 = g6 << 2 | g6 >> 4 （复制最高位填充低两位）
6. 扩展为8位： b8 = b5 << 3 | b5 >> 2 （复制最高位填充低三位）

最终，按B、G、R顺序将 b8 、 g8 、 r8 三个字节依次写入文件。此过程在 LCD_Screenshot() 函数中通过一个双重嵌套循环实现：外层循环遍历240行，内层循环遍历320列，对帧缓冲区中每个 uint16_t 类型的像素值执行上述转换，并调用 f_write() 逐字节写入。

4. LCD_Screenshot()函数的工程实现

LCD_Screenshot() 是本实验的灵魂函数，它将前述所有理论知识转化为可执行的C代码。其设计必须兼顾功能性、鲁棒性与效率。以下是其核心逻辑的逐层剖析。

4.1 函数接口与前置条件检查

函数原型为 FRESULT LCD_Screenshot(char *filename) ，接收一个字符串指针，用于指定生成的BMP文件名。在函数入口处，首要任务是进行防御性编程：

// 检查FATFS文件系统是否已挂载
if (fatfs_mounted == 0) {
    return FR_NOT_READY;
}
// 检查LCD帧缓冲区地址是否有效
if (lcd_framebuffer == NULL) {
    return FR_INVALID_OBJECT;
}
// 生成唯一文件名，防止覆盖
static uint8_t photo_count = 0;
photo_count++;
sprintf(filename, "PHOTO%03d.BMP", photo_count);

此处的 photo_count 静态变量是实现“自增编号”的关键。每次调用函数， photo_count 递增，并通过 sprintf 格式化为 PHOTO001.BMP 、 PHOTO002.BMP 等形式。这避免了手动管理文件名的复杂性，并确保了在同一程序运行周期内，多次截图不会相互覆盖。该变量被声明为 static ，保证了其生命周期贯穿整个程序运行期，其值在函数调用间得以保持。

4.2 BMP文件头与信息头的构造与写入

构造文件头与信息头是纯内存操作，不涉及任何外设访问，因此速度极快。代码如下：

BITMAPFILEHEADER file_header;
BITMAPINFOHEADER info_header;

// 初始化文件头
file_header.bfType = 0x4D42; // "BM"
file_header.bfReserved1 = 0;
file_header.bfReserved2 = 0;
file_header.bfOffBits = 54; // 14 + 40

// 计算文件总大小
uint32_t pixel_data_size = ((LCD_WIDTH * 3) + 3) & ~3; // 每行字节数（DWORD对齐）
pixel_data_size *= LCD_HEIGHT;
file_header.bfSize = 14 + 40 + pixel_data_size;

// 初始化信息头
info_header.biSize = 40;
info_header.biWidth = LCD_WIDTH;
info_header.biHeight = -LCD_HEIGHT; // 负值，确保正向显示
info_header.biPlanes = 1;
info_header.biBitCount = 24;
info_header.biCompression = 0;
info_header.biSizeImage = pixel_data_size;
info_header.biXPelsPerMeter = 0;
info_header.biYPelsPerMeter = 0;
info_header.biClrUsed = 0;
info_header.biClrImportant = 0;

// 打开文件并写入头部
FIL bmp_file;
FRESULT fr = f_open(&bmp_file, filename, FA_CREATE_ALWAYS | FA_WRITE);
if (fr != FR_OK) {
    return fr;
}
fr = f_write(&bmp_file, &file_header, sizeof(file_header), &bytes_written);
if (fr != FR_OK || bytes_written != sizeof(file_header)) goto error_close;
fr = f_write(&bmp_file, &info_header, sizeof(info_header), &bytes_written);
if (fr != FR_OK || bytes_written != sizeof(info_header)) goto error_close;

这段代码展示了嵌入式开发中典型的“资源获取-使用-释放”模式。 f_open() 以 FA_CREATE_ALWAYS 标志打开文件，这意味着如果文件已存在，则会被清空并重新创建； FA_WRITE 标志赋予写入权限。随后，两次 f_write() 调用将预计算好的 file_header 和 info_header 结构体完整写入文件开头。 goto error_close 语句是一种简洁的错误处理机制，当任一写入操作失败时，程序跳转至错误处理标签，执行 f_close() 并返回错误码，确保文件句柄得到及时释放，避免资源泄漏。

4.3 像素数据的高效转换与写入

像素数据的写入是整个函数的性能瓶颈所在。一幅320×240的图像包含76,800个像素，每个像素需转换为3个字节，总计230,400字节。若采用最朴素的“逐像素、逐字节”写入方式， f_write() 的频繁调用会产生巨大的函数开销。为此， LCD_Screenshot() 采用了“行缓冲”策略：

// 为一行BGR数据分配临时缓冲区
uint8_t *row_buffer = (uint8_t*)malloc(LCD_WIDTH * 3);
if (row_buffer == NULL) {
    fr = FR_NOT_ENOUGH_CORE;
    goto error_close;
}

// 逐行处理
for (int y = 0; y < LCD_HEIGHT; y++) {
    // 将LCD帧缓冲区的一行RGB565数据转换为BGR888
    for (int x = 0; x < LCD_WIDTH; x++) {
        uint16_t rgb565 = lcd_framebuffer[y * LCD_WIDTH + x];
        uint8_t r5 = (rgb565 >> 11) & 0x1F;
        uint8_t g6 = (rgb565 >> 5) & 0x3F;
        uint8_t b5 = rgb565 & 0x1F;
        row_buffer[x * 3 + 0] = (b5 << 3) | (b5 >> 2); // B
        row_buffer[x * 3 + 1] = (g6 << 2) | (g6 >> 4); // G
        row_buffer[x * 3 + 2] = (r5 << 3) | (r5 >> 2); // R
    }
    // 一次性写入整行
    fr = f_write(&bmp_file, row_buffer, LCD_WIDTH * 3, &bytes_written);
    if (fr != FR_OK || bytes_written != (LCD_WIDTH * 3)) {
        goto error_close;
    }
}

free(row_buffer);

该策略的核心思想是：在内存中开辟一块足够容纳一行BGR888数据的缓冲区（ LCD_WIDTH * 3 字节），然后在一个内层循环中，将LCD帧缓冲区对应行的所有RGB565像素值批量转换并填入该缓冲区；最后，调用一次 f_write() ，将整行数据作为一个数据块写入文件。这将 f_write() 的调用次数从230,400次锐减至240次，极大地提升了I/O效率。 malloc() 的使用虽引入了动态内存分配，但在本实验的上下文中是可接受的，因为 row_buffer 的生命周期仅限于函数内部，且其大小固定（960字节），不会造成内存碎片。

5. 按键中断与系统状态机设计

“KEY”按键是用户与系统交互的唯一物理接口，其行为定义了整个拍照实验的用户体验。在硬件层面，KEY按键通常连接至一个GPIO引脚（如GPIOE_Pin4），并配置为上拉输入，按键按下时引脚电平被拉低。软件层面，其实现必须遵循实时嵌入式系统的最佳实践：中断服务程序（ISR）应尽可能简短，只做最必要的工作，将繁重的业务逻辑交由主循环或专用任务处理。

5.1 中断服务程序（ISR）的黄金法则

在 stm32f1xx_it.c 中，KEY按键对应的EXTI中断服务函数 EXTI4_IRQHandler() 的实现应严格遵守以下原则：

void EXTI4_IRQHandler(void) {
    // 1. 清除中断标志位（必须第一步！）
    __HAL_GPIO_EXTI_CLEAR_IT(GPIO_PIN_4);

    // 2. 设置一个全局标志位（volatile）
    volatile static uint8_t key_pressed_flag = 0;
    key_pressed_flag = 1;

    // 3. （可选）触发一个低优先级中断或软件定时器，用于去抖
    // 此处省略，假设硬件已做足够滤波
}

__HAL_GPIO_EXTI_CLEAR_IT() 是清除EXTI线路中断挂起位的关键操作。若遗漏此步，中断将被持续触发，导致系统死锁。 key_pressed_flag 被声明为 volatile ，以防止编译器优化掉对该变量的读写，确保主循环能准确感知其变化。ISR中绝对禁止执行任何耗时操作，如调用 f_open() 、 f_write() 或 LCD_Screenshot() ，因为这些函数可能阻塞，导致其他更高优先级的中断（如VSYNC）被延迟响应，进而破坏图像采集的时序。

5.2 主循环中的状态机与LED反馈

主循环（ while(1) ）扮演着系统协调者的角色，它基于 key_pressed_flag 的状态，驱动一个简单的状态机：

while (1) {
    // 检查按键标志
    if (key_pressed_flag) {
        key_pressed_flag = 0; // 清除标志

        // 进入“拍照中”状态：点亮蓝灯
        HAL_GPIO_WritePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin, GPIO_PIN_SET);

        // 执行截图
        FRESULT fr = LCD_Screenshot(photo_filename);
        if (fr == FR_OK) {
            // 成功：熄灭蓝灯，点亮绿灯
            HAL_GPIO_WritePin(LED_BLUE_GPIO_Port, LED_BLUE_Pin, GPIO_PIN_RESET);
            HAL_GPIO_WritePin(LED_GREEN_GPIO_Port, LED_GREEN_Pin, GPIO_PIN_SET);
            // 通过串口打印成功信息
            printf("Screenshot saved as %s\r\n", photo_filename);
        } else {
            // 失败：闪烁红灯报警
            HAL_GPIO_WritePin(LED_RED_GPIO_Port, LED_RED_Pin, GPIO_PIN_SET);
            HAL_Delay(500);
            HAL_GPIO_WritePin(LED_RED_GPIO_Port, LED_RED_Pin, GPIO_PIN_RESET);
            printf("Screenshot failed: %d\r\n", fr);
        }

        // 保持LED状态一段时间，给予用户视觉反馈
        HAL_Delay(2000);
        HAL_GPIO_WritePin(LED_GREEN_GPIO_Port, LED_GREEN_Pin, GPIO_PIN_RESET);
    }

    // 其他后台任务...
    HAL_Delay(10);
}

该状态机清晰地定义了用户操作的闭环：按键按下 → ISR置位 → 主循环检测 → 执行截图 → 根据结果切换LED → 延时保持 → 返回待机。LED的反馈至关重要：蓝灯亮起表示系统正在忙于写入SD卡，此时用户必须等待，不可再次按键；绿灯亮起表示操作成功，是用户可信赖的成功信号。这种直观的视觉反馈，是嵌入式人机交互设计的基本功。 HAL_Delay(2000) 的延时，既是为了让用户看清LED状态，也是为了给SD卡一个充分的写入完成时间，避免因过早关闭电源而导致文件系统损坏。

6. 实验现象分析与常见问题排错

将编译生成的固件下载至开发板并上电后，预期的实验现象序列如下：
1. 上电初始化 ：系统启动，LCD显示OV7725采集的实时画面（通常为调试用的灰度条纹或环境图像），同时串口助手（如XCOM）会输出初始化日志，包括“FATFS mounted OK”、“OV7725 init OK”等关键信息。
2. 待机状态 ：LED蓝灯熄灭，绿灯熄灭，红灯熄灭（或仅红灯常亮表示待机），系统处于静默监听按键状态。
3. 按键触发 ：按下KEY按键瞬间，LED蓝灯立即点亮，串口输出“Screenshot started…”（若代码中添加了此日志）。
4. 写入过程 ：蓝灯持续点亮约1-3秒（具体时间取决于SD卡速度与图像大小），期间串口无新输出，表明 f_write() 正在阻塞等待SD卡完成物理写入。
5. 完成反馈 ：蓝灯熄灭，绿灯点亮，串口输出“Screenshot saved as PHOTO001.BMP”及“Success!”。此时，可安全断电。
6. PC端验证 ：将SD卡通过读卡器接入PC，在文件管理器中可直接看到 PHOTO001.BMP 等文件，双击即可用系统自带的“照片”应用查看，图像内容与LCD上最后一帧完全一致。

当实验现象与预期不符时，应遵循“由外而内、由简入繁”的排错逻辑：

6.1 SD卡无反应或文件无法创建

• 现象 ：按键后蓝灯不亮，或蓝灯亮起但无绿灯反馈，串口无任何截图日志。
• 排查步骤 ：
  1. 硬件检查 ：用万用表测量SD卡卡槽的 VCC 引脚电压是否为3.3V；检查 CS 引脚在按键前后是否有电平跳变（应为低电平有效）。
  2. FATFS日志 ：在 f_mount() 调用后，添加 printf("f_mount result: %d\r\n", fr) ，若输出 1 （ FR_NO_FILESYSTEM ），则SD卡未格式化或格式化错误；若输出 6 （ FR_DISK_ERR ），则SPI通信异常，需检查 SCK 、 MOSI 、 MISO 接线及 CS 电平。
  3. 文件名检查 ：确认 filename 字符串末尾有 \0 终止符，且长度不超过FATFS的 FF_MAX_LFN （默认为255）。

6.2 图像显示异常（全黑、全白、彩色噪点）

• 现象 ：PC端打开BMP文件，图像内容与LCD不符，表现为大面积黑色、白色或随机彩色块。
• 根本原因 ：BMP文件头或像素数据写入错误。
• 排查步骤 ：
  1. 用WinHex查看文件头 ：打开生成的BMP文件，确认前两个字节为 42 4D （即ASCII ‘B’ ‘M’）。若为 00 00 或其他值，则 f_write() 写入文件头失败，应检查 f_open() 返回值及 file_header 结构体的内存布局（确保 __attribute__((packed)) 生效）。
  2. 检查 biHeight 符号 ：若图像上下颠倒，则 biHeight 应为正值；若图像左右镜像，则问题出在 row_buffer 的索引计算上，应确认 row_buffer[x * 3 + 0] 对应B通道。
  3. 验证像素转换 ：在 row_buffer 写入前，添加 printf("RGB565: %04X -> B:%02X G:%02X R:%02X\r\n", rgb565, b8, g8, r8) ，观察输出是否符合预期（如纯红色像素 0xF800 应转换为 B:00 G:00 R:F8 ）。

6.3 系统卡死或按键无响应

• 现象 ：上电后LCD无显示，或按键后系统无任何反应。
• 排查步骤 ：
  1. 中断优先级冲突 ：检查 HAL_NVIC_SetPriority(EXTI4_IRQn, 2, 0) 的设置。 EXTI4 的抢占优先级（第1个参数）必须低于VSYNC中断（如 TIM3_IRQn ）的优先级，否则VSYNC中断会被阻塞，导致图像采集停滞。
  2. 栈溢出 ： LCD_Screenshot() 中 malloc() 分配的 row_buffer （960字节）可能超出默认栈空间。应在 main() 函数开头，通过 osThreadAttr_t attr; attr.stack_size = 2048; 为 main 线程分配更大栈空间（若使用FreeRTOS），或在裸机环境下，修改 startup_stm32f103xe.s 中的 Stack_Size 为 0x00000800 。

我在实际项目中遇到过一次因 biWidth 和 biHeight 未取负值而导致的图像倒置问题，当时花了整整一个下午用WinHex逐字节比对文件头，最终发现 biHeight 字段的高字节是 00 而非 FF ，这才恍然大悟。嵌入式开发的魅力，往往就藏在这些看似微小的二进制细节之中。