从BMP到C数组：LCD Image Converter操作指南-编程阁

从BMP到C数组：嵌入式图像资源转换实战全解

在做嵌入式开发时，你有没有遇到过这样的场景？

产品经理递来一张精美的Logo图：“这个要显示在开机画面上。”
设计师甩出一个PSD文件：“图标都做好了，直接用就行。”
而你打开代码编辑器，面对的却是——如何把这张图变成能烧进MCU的C语言数据？

别急。这并不是你需要手动一个像素一个像素敲出来的任务。今天我们就来彻底讲清楚：如何用LCD Image Converter这个“神器”，把一张普通的BMP图片，一键转成可以直接调用的C数组。

更重要的是，我会带你理解背后的技术逻辑，让你不仅“会用”，还能“知其所以然”。

为什么不能直接加载BMP？

我们先从最根本的问题说起：既然BMP是标准格式，能不能让单片机自己解析它？

答案很现实：理论上可以，实际上不推荐。

原因有三：

无压缩、体积大
一张 240×320 的24位BMP，光像素数据就要 $240 \times 320 \times 3 = 230,!400$ 字节（约225KB），这对很多只有几十KB Flash和SRAM的MCU来说简直是灾难。
结构复杂、解析成本高
BMP文件头、信息头、调色板、行对齐补白……这些都需要额外代码去处理。为了读一张图，你要引入一整套图像解析逻辑，得不偿失。
运行时开销不可接受
每次显示都要现场解码？那CPU就得停下来干这事，界面卡顿几乎是必然结果。

所以更聪明的做法是：在编译前就把图像预处理成目标格式的C数组，固化进Flash，运行时零解码直接送显。

而这，正是LCD Image Converter存在的意义。

LCD Image Converter 是什么？

简单说，它是一个专为嵌入式GUI设计服务的小工具，功能就一句话：

把.bmp文件转换成const uint16_t image_data[]这样的C语言常量数组。

但它远不止“导出数组”这么简单。它的真正价值在于：

支持多种颜色格式输出（RGB565、灰度、单色等）
可自定义变量名、宏定义、字节序
提供可视化预览，避免“导出来才发现颜色反了”
输出.c/.h配套文件，便于工程管理

常见使用场景包括：
- 显示启动Logo
- 绘制固定图标（如Wi-Fi信号、电池电量）
- 构建菜单背景或按钮贴图

支持平台覆盖 STM32、ESP32、NXP、GD32 等主流MCU，配合 ST7789、SSD1306、ILI9341 等驱动芯片都能无缝对接。

BMP文件结构：搞懂才能不出错

要想用好这个工具，必须先了解输入源——BMP文件的基本结构。

BMP由哪几部分组成？

块名称	大小	说明
BITMAPFILEHEADER	14字节	固定头部，“BM”开头，包含文件总大小、数据偏移等
BITMAPINFOHEADER	40+字节	图像宽高、位深度、压缩方式等关键信息
Color Table（可选）	变长	索引色模式下使用，比如1/4/8位图
Pixel Data	主体数据	实际像素值，按行存储

对于最常见的24位真彩色BMP（即RGB888）：
- 没有调色板
- 每个像素占3字节：R-G-B顺序
- 每行字节数必须是4的倍数 → 不足则补0

举个例子：宽度为100像素的图像，每行原始数据是 $100 \times 3 = 300$ 字节，已经是4的倍数，无需填充；但如果宽度是101，则需补1字节对齐。

这也是为什么有些工具导出后图像出现“竖条纹”——就是因为没正确处理行对齐！

转换流程详解：从导入到集成

下面我们以一个典型项目为例，手把手演示完整操作流程。

假设我们要在一个基于STM32的TFT屏上显示公司Logo，尺寸为 100×50 像素。

第一步：准备图像源文件

使用 Photoshop/GIMP/Paint.NET 创建图像
导出为logo_100x50.bmp
设置为 24位真彩色（RGB888）
注意：BMP不支持透明通道，如有透明区域，请预先设定为白色或黑色

✅ 小贴士：建议保留一份PNG源文件用于版本管理，每次修改后再导出BMP用于转换。

第二步：配置 LCD Image Converter

打开工具（以常用版本为例），执行以下操作：

导入图像
点击“Open”选择logo_100x50.bmp
设置输出参数
-Color Format:RGB565（适用于大多数TFT屏幕）
-Variable Name:g_img_logo_100x50
-Output Type:C Array (.c/.h)
-Byte Order:Little Endian（ARM Cortex-M默认）
-Swap R/B Bytes: ✔️（某些屏幕要求BGR顺序）
启用预览功能
勾选“Generate Preview”，实时查看转换效果
检查资源占用
工具底部会显示：
Size: 100 x 50 Data Size: 10,000 bytes (100 * 50 * 2)

对比原始BMP的 $100×50×3=15,!000$ 字节，已经节省了1/3空间。

第三步：生成代码并查看内容

点击“Generate”，得到两个文件：

`image_logo.h`

#ifndef IMAGE_LOGO_H #define IMAGE_LOGO_H #include <stdint.h> extern const uint16_t g_img_logo_100x50[5000]; // 100*50 = 5000 pixels #define IMAGE_LOGO_WIDTH 100 #define IMAGE_LOGO_HEIGHT 50 #endif

`image_logo.c`

#include "image_logo.h" const uint16_t g_img_logo_100x50[5000] = { 0xF800, 0xF800, 0xF800, ... // RGB565 数据流 };

可以看到：
- 数组类型为uint16_t，对应RGB565每像素2字节
- 数据以十六进制表示，高位代表红色（5位），中间绿色（6位），低位蓝色（5位）
- 变量声明为const和extern，符合嵌入式只读资源的最佳实践

第四步：集成到工程中

将这两个文件加入你的Keil/IAR/VS Code + PlatformIO 工程，并确保.c文件被编译。

然后在主程序中调用：

#include "lcd_driver.h" #include "image_logo.h" int main(void) { lcd_init(); // 设置显示窗口（起点x,y 和 宽高） lcd_set_window(60, 100, 159, 149); // 区域大小正好100x50 // 发送图像数据到LCD lcd_draw_bitmap((uint8_t*)g_img_logo_100x50, IMAGE_LOGO_WIDTH * 2 * IMAGE_LOGO_HEIGHT); while (1); }

其中lcd_draw_bitmap函数内部通过SPI发送数据，具体实现取决于你的驱动架构。

常见坑点与调试秘籍

别以为点了“Generate”就万事大吉。实际开发中，以下几个问题极为常见：

❌ 问题1：图像颜色发红 or 偏蓝

现象：本来是白色的Logo变成了粉红色，或者整个画面偏紫。

根源：R和B通道颠倒了！

虽然你选择了RGB565，但不同LCD控制器对字节顺序的要求可能不同：
- ST7789：通常支持RGB或BGR切换（可通过命令控制）
- SSD1331：固定为BGR
- 某些旧款屏：只认特定顺序

解决方案：
1. 在LCD Image Converter中勾选 “Swap Red and Blue”
2. 或者在驱动层统一翻转：
c uint16_t rgb565_swap_rb(uint16_t color) { return ((color & 0x1F) << 11) | (color & 0x07E0) | ((color & 0xF800) >> 11); }
3. 最佳做法：在LCD初始化时发送命令设置为BGR模式（查阅数据手册）

❌ 问题2：图像上下颠倒 or 显示乱码

原因：BMP的像素存储顺序是从下往上的！

也就是说，第一行数据其实是图像的最底行。如果你不做处理，就会导致图像倒置。

解决方法：
- 方法一：在图像编辑软件中“垂直翻转”后再导出BMP
- 方法二：在转换工具中启用“Flip Vertically”选项（部分高级版支持）
- 方法三：在驱动层接收时逆序写入DMA缓冲区

🔍 推荐做法：统一规范所有素材导出前已正向排列，避免后期混乱。

❌ 问题3：内存爆了！

前面算过，一张 240×320 的RGB565图要占用约150KB。如果你的MCU只有64KB SRAM，还跑FreeRTOS，那肯定扛不住。

怎么办？

✅ 应对策略清单：

场景	优化方案
小图标（<1KB）	直接固化在Flash，零成本
中等图像（1~10KB）	使用1位单色（Monochrome）模式，压缩至原大小1/16
大图（>10KB）	存于外部QSPI Flash，按需加载
动态资源多	引入LVGL等GUI框架，支持运行时解压

例如，在LCD Image Converter中选择1-bit Monochrome输出：

const uint8_t icon_wifi_20x20[40] = { ... }; // 仅40字节！

配合简单的位操作绘制函数即可高效显示。

工程最佳实践建议

别让工具成了“一次性用品”。真正高效的团队，应该把它纳入标准化流程。

1. 统一命名规范

建议采用如下格式：

g_img_[功能]_[宽]x[高]_[格式]

示例：
-g_img_logo_100x50_rgb565
-g_img_icon_wifi_20x20_mono
-g_img_bg_menu_240x320_rgb565

这样一看就知道用途、尺寸和格式，协作无障碍。

2. 源文件与生成文件一起纳入Git

结构建议如下：

/assets/ /source_bmp/ logo_100x50.bmp icon_wifi_20x20.bmp /generated_c/ image_logo.c image_logo.h image_icon_wifi.c image_icon_wifi.h

好处：
- 修改源头可追溯
- 团队成员拉代码后无需重新安装工具也能编译
- CI/CD流水线可自动检测BMP变更并触发重建

3. 自动化构建集成（进阶）

对于大型项目，手动点击“Generate”太低效。可以用批处理脚本或Makefile自动化：

ASSETS := $(wildcard assets/source_bmp/*.bmp) GEN_C := $(ASSETS:.bmp=.c) GEN_H := $(ASSETS:.bmp=.h) %.c %\.h: %.bmp @echo "Converting $< ..." @lcd_image_converter -i $< -f rgb565 -o $(dir $<) --swap-rb all: $(GEN_C) $(GEN_H)

再结合 GitHub Actions 或 Jenkins，实现“提交BMP → 自动生成C数组 → 编译固件”的全自动流程。

总结与延伸思考

当你下次再接到“把这个图显示出来”的任务时，希望你能从容地说一句：

“没问题，我五分钟搞定。”

而这五分钟的背后，是你对整个图像资源链路的理解：

输入端：知道BMP的结构特性，能正确导出
转换层：熟练使用LCD Image Converter，规避常见陷阱
输出端：合理组织C数组，适配驱动接口
系统级：考虑内存、性能、可维护性，做出权衡决策

这才是一个成熟嵌入式工程师应有的能力模型。

当然，随着LVGL、TouchGFX等现代GUI框架的普及，图像资源管理也变得更加智能。它们支持动态加载压缩纹理、字体子集化、动画合成等功能，但底层思想不变：

视觉资产最终还是要变成MCU能理解和传输的数据流。

而LCD Image Converter正是这条链路上最早、也最关键的环节之一。

哪怕未来我们用上了AI辅助设计、自动切图、实时渲染，我相信这种“把图像变成代码”的思维模式，依然值得每一位开发者掌握。

如果你正在做一个带屏的项目，不妨现在就试试这个工具。也许你会发现，原来让人头疼的“贴图问题”，其实可以如此轻松地解决。

欢迎在评论区分享你的使用经验或踩过的坑，我们一起交流进步。

从BMP到C数组：LCD Image Converter操作指南