STM32串口传图：RGB565图片显示与DMA帧协议优化

简介这份资料围绕“STM32串口发彩色图片”展开面向有C语言与单片机基础的嵌入式学习者及图像采集传输实验开发者。它将正点原子miniSTM32驱动OV7725、DMA读取像素、BMP格式打包、UART串口发送以及PC端上位机接收解码并显示图片的链路整理成完整工程可用于课程设计、毕业设计前期验证和串口图像传输方案参考。压缩包共499个文件约10.92MB主体为45个h头文件、43个c源文件配套Keil工程uvprojx/uvoptx与Visual Studio解决方案sln/csproj/resx并含o、d、crf、axf、hex、map等编译产物、bmp示例和批处理脚本固件与上位机结构较完整。已有5808人学习下载。读者可获得STM32端图像采集与串口发送的工程骨架、上位机接收与BMP重构的参考实现以及文件头组织、字节序处理、传输速率配置等排错线索便于对照代码搭建实验环境并按需裁剪复用。1. 一张 240×320 彩色图走串口要多久先把带宽这笔账算清把一张 240×320 的彩色图从 PC 塞进 STM32再让它在小屏上完整显示听着像课堂作业真动手才会发现卡点不在显示而在串口。STM32 上位机 发送图片这条链路最典型的翻车方式是图能发出去屏上是雪花颜色对了位置错半屏单张能显示连发三张就死机。这套资源围绕「彩色图片 → 串口字节流 → 屏幕像素」这条主线把上位机取模、帧协议、DMA 接收、LCD 写窗口四段拆开适合手里已经有块带屏开发板、想把这套链路跑通并调快的嵌入式开发者。一张 240×320 的 RGB565 图是 153 600 字节115200 波特率下 8N1 每秒实际能搬 11 520 字节光传完就要 13 秒出头换成 921600压到 1.7 秒左右。这个数字决定了后面所有设计要么提波特率要么减数据量要么两边一起动。2. 上位机把 BMP 打成 RGB565 字节流取模脚本与两种产物2.1 为什么先定 RGB565而不是 RGB888串口传图的第一道选择题是像素格式。RGB888 每像素 3 字节一张 240×320 图就是 230 400 字节比 RGB565 多出 50% 的流量而大多数 240×320 的小屏驱动 IC 内部显存本来就是 16 位色收 24 位还得在 MCU 侧裁位白白多一次运算。RGB565 每像素 2 字节红色占高 5 位、绿色占中间 6 位、蓝色占低 5 位人眼对绿色更敏感这个位分配不是随便定的。常见做法是在 PC 端一次转到位STM32 收到什么就写什么中间不做任何格式转换这样接收侧只需要关心「这串字节该写到屏幕哪一行」逻辑最薄也最容易排查。另一个容易被忽略的点是端序。RGB565 是一个 16 位整数PC 是小端机器屏幕驱动大多按高字节先收。如果你在 Python 里用struct.pack(H, v)打包发过去屏幕上的颜色会整体偏、红蓝互换这类问题在后面的避坑章节还会展开。我在脚本里一般把端序做成显式参数默认大端出问题时改一个开关就能验证不用回头重写整段代码。2.2 读图、缩放与像素格式转换上位机用 Python 写最省事Pillow 负责解码和缩放剩下的位运算手写。下面这段是核心转换函数输入任意格式图片输出按行排列的 RGB565 字节流# img2rgb565.py from PIL import Image import struct def to_rgb565(img_path, w, h, big_endianTrue): # 统一转 RGB避免调色板图或灰度图拿到意外的通道数 im Image.open(img_path).convert(RGB).resize((w, h), Image.LANCZOS) out bytearray(w * h * 2) i 0 for y in range(h): for x in range(w): r, g, b im.getpixel((x, y)) # R 取高 5 位放 bit15-11G 取高 6 位放 bit10-5B 取高 5 位放 bit4-0 v ((r 0xF8) 8) | ((g 0xFC) 3) | (b 3) if big_endian: out[i] (v 8) 0xFF # 高字节先发多数 SPI 屏要这个顺序 out[i 1] v 0xFF else: out[i] v 0xFF out[i 1] (v 8) 0xFF i 2 return bytes(out)逐像素循环在 240×320 下要跑 76 800 次纯 Python 大概几百毫秒能接受但不舒服。图多的时候我会换成 numpy 版本把三重循环压成三次数组运算import numpy as np from PIL import Image def to_rgb565_np(img_path, w, h): im Image.open(img_path).convert(RGB).resize((w, h), Image.LANCZOS) a np.asarray(im, dtypenp.uint16) r (a[:, :, 0] 0xF8) 8 g (a[:, :, 1] 0xFC) 3 b a[:, :, 2] 3 v (r | g | b).astype(u2) # u2 直接产出大端 16 位 return v.tobytes()astype(u2)这一行值得单独说它把整个数组按大端 16 位重新解释等价于逐元素struct.pack(H, v)但省掉了 Python 层的循环。参数w、h必须和屏幕分辨率一致缩放比例不要交给屏幕驱动去做否则你会在调试时同时怀疑两个地方。LANCZOS 比默认的双线性慢一点但边缘更干净传照片类素材时差别肉眼可见。2.3 bin 与 C 数组两种产物的取舍转换结果有两种落盘方式用途完全不同。第一种是.bin文件裸字节流不带任何头尾。它适合「运行时通过串口发」的场景上位机读 bin、切行、加协议头、逐帧发STM32 不需要知道文件系统。153 600 字节的 bin 在磁盘上很轻改图重新生成也快。第二种是 C 数组形如const unsigned char image_rgb565[153600] {0x12, 0x34, ...};。它适合「烧进 Flash 直接显示」的固定开机画面省掉串口传输。生成函数不复杂def dump_c_array(data, nameimage_rgb565, per_line16): lines [fconst unsigned char {name}[{len(data)}] {{] for i in range(0, len(data), per_line): chunk , .join(f0x{b:02X} for b in data[i:i per_line]) lines.append( chunk ,) lines.append(};) return \n.join(lines)这里有个必须提前算的账153 600 字节的数组会占掉 150 KB 的 Flash。很多入门型号的 Flash 只有 64 KB 或 128 KB直接把数组编进去会链接失败报错还不是「空间不够」而是「region FLASH overflowed」第一次见容易懵。我的习惯是开机 Logo 这类不超过 20 KB 的小图走 C 数组照片和动态内容一律走 bin 串口别让一张图把固件撑爆。2.4 发送前自检把字节流重新画回一张图字节流一旦生成别急着接开发板。先在上位机侧做一次反向验证把 RGB565 字节流按同样的端序解析回像素存成 PNG和原图并排看。颜色、比例、上下有没有翻转这一步就能抓出八成问题。def rgb565_to_png(data, w, h, out_path, big_endianTrue): im Image.new(RGB, (w, h)) px im.load() for y in range(h): for x in range(w): i (y * w x) * 2 if big_endian: v (data[i] 8) | data[i 1] else: v data[i] | (data[i 1] 8) r ((v 11) 0x1F) * 255 // 31 g ((v 5) 0x3F) * 255 // 63 b ( v 0x1F) * 255 // 31 px[x, y] (r, g, b) im.save(out_path)反向解析里的三个位移量和正向严格对称右移 11 拿红、右移 5 拿绿、低 5 位拿蓝再各自按 5/6/5 位满量程放大回 0–255。这一步跑通说明取模脚本本身没问题后面屏幕上再出问题范围就缩小到串口协议和写屏逻辑不用三头怀疑。我吃过一次亏图片在 PC 上看着正常上屏后整体偏绿查了半天协议最后发现是转换脚本里绿色的掩码写成了0xF8丢了最低一位肉眼在 PC 预览里几乎看不出来。3. STM32 接收流水线DMA、空闲中断与逐行写屏3.1 串口参数与 DMA 接收的启动时机接收侧的第一件事是把串口参数和上位机对齐波特率、8 数据位、无校验、1 停止位硬件流控关掉。参数不一致的表现是收到一堆0x00或者帧头永远对不上而不是报错所以初始化之后先让上位机连发0xAA 0x55两个字节用调试器看接收缓冲里是不是这两个值是最快的握手验证。DMA 的启动时机比配置本身更容易出错。常见写法是在main里初始化完串口就调一次HAL_UART_Receive_DMA然后进主循环。问题在于DMA 是一次性把指定长度的数据搬进缓冲搬满就停不会自己重来。如果你的帧长不固定或者中途出现半包DMA 停下来之后再也没有人把它拉起来表现就是「传了第一帧后面全静默」。我的做法是把「重启 DMA」封成一个函数每次处理完一批数据立刻调用形成闭环#define MAX_FRAME 512 /* 一帧最大字节数含头尾 */ static uint8_t rxbuf[MAX_FRAME]; static uint16_t rxlen 0; /* 缓冲里已有的有效字节数 */ void uart_rx_restart(void) { /* 从已有数据的尾部接着收剩余空间 总长 - 已有长度 */ HAL_UART_Receive_DMA(huart1, rxbuf rxlen, MAX_FRAME - rxlen); }rxbuf rxlen这个偏移是关键缓冲区头部可能还留着上一次没解析完的半包新数据必须接在它后面不能从 0 开始覆盖。MAX_FRAME - rxlen则是本次 DMA 还能收多少如果rxlen已经等于MAX_FRAME说明缓冲满了还没解析出完整帧这时候要么丢数据要么扩缓冲得在解析函数里处理。3.2 空闲中断拿实际长度半包 memmove 回填DMA 只知道「收够了没有」不知道「对方说到哪了」。串口空闲中断补的就是这个信息总线连续一个字节时间没有新数据硬件置 IDLE 标志此时用 DMA 剩余计数反推实际收了多少字节void USART1_IRQHandler(void) { if (__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); HAL_UART_DMAStop(huart1); /* 先停防止边算边收 */ uint16_t got (MAX_FRAME - rxlen) - __HAL_DMA_GET_COUNTER(huart1.hdmarx); rxlen got; uint16_t used frame_parse(rxbuf, rxlen); /* 返回消耗掉的字节数 */ if (used 0) { memmove(rxbuf, rxbuf used, rxlen - used);/* 半包前移 */ rxlen - used; } uart_rx_restart(); /* 重新挂 DMA */ } HAL_UART_IRQHandler(huart1); }这段代码里有三个容易写错的点。HAL_UART_DMAStop必须在读计数之前调用否则计数器还在往下走算出来的长度是错的。memmove不能用memcpy替代源和目的区域重叠时memcpy行为未定义。frame_parse的返回值语义要统一返回「已完整处理并可以丢弃的字节数」0 表示数据不够、原样保留等下次这样memmove的偏移量永远是对的。还有一点藏在 HAL 里HAL_UART_IRQHandler会检查并清除溢出标志 ORE。如果你自己写了USART1_IRQHandler却忘了在末尾调它一次溢出之后接收就彻底停摆现象是「偶尔能收出了错就再也不动」。这个坑我在早期项目里踩过后来养成习惯自定义中断服务函数第一行先写HAL_UART_IRQHandler(huart1);再写自己的逻辑。3.3 帧解析与一帧一行的设计帧解析的策略直接决定了 RAM 占用和写屏复杂度。一种思路是「收完整图再显示」需要 153 KB 缓冲绝大多数型号扛不住另一种是「收一帧显示一帧」把图片按行切开每帧正好是一行像素seq 字段就是行号。我选后者理由很实在一行 240 像素是 480 字节加头尾不到 500 字节任何型号都能腾出这点 RAM写屏和收包能流水线并行丢帧时能精确定位到某一行排查有抓手。解析函数按「找头 → 验长 → 验 CRC → 回调」四步走非法数据跳一个字节重新同步而不是整段丢弃这样即使前面混进了噪声也能自己爬回来/* 返回本次可丢弃的字节数0 表示半包等下一次数据 */ uint16_t frame_parse(uint8_t *buf, uint16_t len) { if (len 9) return 0; /* 最短帧头2type1seq2len2crc2 */ if (buf[0] ! 0xAA || buf[1] ! 0x55) { /* 不同步滑动找帧头 */ for (uint16_t i 1; i 1 len; i) { if (buf[i] 0xAA buf[i 1] 0x55) return i; } return len; /* 整段没有头全丢 */ } uint8_t type buf[2]; uint16_t seq buf[3] | (buf[4] 8); uint16_t plen buf[5] | (buf[6] 8); if (plen 480) return 1; /* 超长跳一字节重新同步 */ uint16_t total 9 plen; if (len total) return 0; /* 半包保留 */ uint16_t rx_crc buf[7 plen] | (buf[8 plen] 8); if (crc16(buf 2, 5 plen) ! rx_crc) { proto_send_nack(seq); /* 校验失败通知重发 */ return 1; } if (type 0x01) { /* 数据帧 */ lcd_blit_line(seq, buf 7, plen); proto_send_ack(seq); } return total; }几个参数要有明确边界plen 480是硬上限超过就认为帧头是误同步的巧合跳一个字节继续找len 9的判断对应最短合法帧无 payload 的 ACKCRC 覆盖范围是buf 2开始的5 plen字节也就是从 type 到 payload 末尾不含帧头和 CRC 自身。这些边界一旦写错表现是「大部分帧能过、偶尔丢一帧」很难复现所以宁可一开始就写死。3.4 写屏不做整图缓存set window 后连续灌像素写屏这一步的关键认知是带显存的屏幕驱动 IC 本身就能记住像素MCU 不需要在内存里拼完整张图。流程是「设窗口 → 连续写像素 → 关窗口」一行数据对应一个 1 像素高的窗口#define IMG_W 240 #define IMG_H 320 static void lcd_blit_line(uint16_t y, const uint8_t *data, uint16_t len) { if (y IMG_H) return; lcd_set_window(0, y, IMG_W - 1, y); /* 只开一行高的窗口 */ lcd_write_pixels(data, len); /* 直接灌不做缓冲 */ lcd_close_window(); /* 部分 IC 需要显式收尾 */ }lcd_set_window内部一般发三条命令列起始/结束、行起始/结束然后发「写显存」命令之后的总线写操作都会被 IC 自动推进到下一个像素位置。这里的顺序不能反先设窗口再发数据如果先发数据再设窗口数据会落到上一次窗口的残留位置现象就是「图片整体错位几十行」。lcd_close_window不是所有驱动都需要但加上没坏处某些 IC 在窗口未关闭时切换命令会丢第一批像素。还有一个隐性成本写 480 字节走 SPI在 18 MHz 下大约 0.2 ms看起来不多但 320 行加起来是 70 ms 左右占整图传输时间的 4%。如果屏幕走 FSMC 并口这个开销可以忽略如果是软件模拟 SPI写屏时间可能反超串口传输时间那时候该优化的就不是波特率而是写屏方式了。4. 自定义帧协议帧头、CRC16 与停等重传4.1 裸发字节流为什么会翻车最省事的做法是把 RGB565 字节流直接往串口灌STM32 收到多少写多少。短距离、低波特率、线材良好的情况下它确实能跑但只要出现一次干扰或一次缓冲区溢出接收侧就永久错位它不知道当前这个字节是某行的第 137 个像素还是下一行的第 3 个像素。图片数据没有自同步能力错一个字节后面全花。加协议的本质是给数据流加「可恢复的边界」。帧头负责重新同步长度负责知道这一帧到哪结束CRC 负责判断这帧可不可信seq 负责让发送方知道哪一帧需要重发。这四样东西加起来只增加不到 2% 的流量换来的是出错可检测、可重传。我一般会跟人说调试阶段千万别省协议省下来的那点带宽最后都会以「屏幕偶尔花一下」的形式还回来。4.2 帧结构字段与长度计算协议设计得越简单越好维护我用的字段布局如下字段长度字节说明帧头2固定0xAA 0x55用于重新同步type10x01数据0x02ACK0x03NACK0x04结束seq2小端数据帧填行号 0–319ACK/NACK 填被确认的行号len2小端payload 字节数数据帧固定 480控制帧为 0payloadlenRGB565 像素字节按行排列crc162小端对 type 到 payload 末尾计算一帧数据帧的总长是2 1 2 2 480 2 489字节。320 行共 156 480 字节比裸流的 153 600 多出 2 880 字节开销 1.9%。这个比例可以接受但如果你的分辨率更高、每帧 payload 更小开销会涨得很快所以 payload 不要切得太碎一行一帧是个平衡点。type字段是后加的一开始我用 seq 的特殊值区分 ACK结果 seq 回绕时撞上了保留值调试了半天。独立一个字节的类型字段语义清楚扩展也方便比如后来加「请求重传指定行」就只是多一个 type 值。4.3 CRC16 的实现与端序约定校验用 CRC-16/CCITT-FALSE多项式0x1021初值0xFFFF不反射不异或输出。选它是因为实现短、查错能力够用而且很多现成工具能对拍。C 侧实现uint16_t crc16(const uint8_t *data, uint16_t len) { uint16_t crc 0xFFFF; while (len--) { crc ^ (uint16_t)(*data) 8; for (uint8_t i 0; i 8; i) { crc (crc 0x8000) ? ((crc 1) ^ 0x1021) : (crc 1); } } return crc; }Python 侧必须用完全相同的参数否则两边永远对不上而且症状是「每一帧都 NACK」反而好排查。麻烦的是「偶尔对不上」那通常是端序问题CRC 值本身是个 16 位整数发的时候按小端拆成两个字节收的时候也按小端拼回去两边约定必须写进注释。我见过有人发送端用struct.pack(H, crc)、接收端用buf[i] 8 | buf[i1]单字节数据下碰巧能过多字节就挂属于典型的玄学故障。4.4 上位机的发送节奏与超时重传发送侧用停等协议就够发一行等 ACK收到再发下一行超时 200 ms 重发连续 3 次失败就中止并报出行号。115200 下一行要 42 ms200 ms 的超时留了足够余量921600 下一行 5 ms超时可以压到 50 ms。停等的代价是每行多一个 RTT但只要 RTT 远小于传输时间吞吐损失可以忽略。import serial, struct, time def send_line(ser, seq, payload, retry3, timeout0.2): frame_body struct.pack(BHH, 0x01, seq, len(payload)) payload frame b\xAA\x55 frame_body struct.pack(H, crc16(frame_body)) for attempt in range(retry): ser.reset_input_buffer() ser.write(frame) deadline time.time() timeout while time.time() deadline: if ser.in_waiting 9: resp ser.read(9) if resp[0:2] b\xAA\x55 and resp[2] 0x02: ack_seq resp[3] | (resp[4] 8) if ack_seq seq: return True time.sleep(0.001) return Falseser.reset_input_buffer()每次发包前清一次接收缓冲避免上一轮的迟到 ACK 被当成本轮的确认。这个细节在低速链路上不明显波特率提上去之后如果不加会出现「明明这行没发成功却收到了 ACK」的假成功。timeout和retry两个参数按实际链路调线材长、干扰大就加大短接杜邦线可以收紧到 50 ms。如果追求更高吞吐可以把停等换成「发 N 行等一个累积 ACK」N 取 8 或 16。代价是丢一行要重传一整批实现复杂度上一个台阶。我的建议是先跑通停等把花屏和卡死的问题排干净再考虑批量确认不然两个变量一起动出了问题根本分不清是协议还是时序。5. 串口传图的五类翻车现场从花屏到卡死怎么排5.1 现象整屏偏蓝红蓝通道像是换了位置原因基本锁定在 RGB565 的端序或位序。发送端按小端打包、屏幕按大端接收红和蓝会互换发送端红色掩码写成0xF8但移位写成 7红色会整体压暗并串到绿色位。解决方法是先用纯色测试图全红0xF800、全绿0x07E0、全蓝0x001F各发一屏看屏幕显示什么颜色就能反推出错在哪一位。我一般还会在转换脚本里加一个--swap开关一键切换大小端比改代码快。5.2 现象传几十行后停住复位才能继续最常见的原因是 DMA 没有重启或者串口溢出标志没清。前者表现为「固定停在某一行」因为你只调了一次HAL_UART_Receive_DMA后者表现为「随机停复位就好」。排查时先在空闲中断里翻转一个 GPIO用示波器看还有没有中断进来有中断说明数据在进但解析卡住没中断说明 DMA 已经停了。解决就是 3.2 节那套闭环每次解析完立刻memmove回填并重启 DMA同时在中断末尾保留HAL_UART_IRQHandler调用。5.3 现象波特率从 115200 提到 921600反而更慢或大量重传这里有两个独立问题。一是 USB 转串口芯片的 FIFO 和驱动延迟某些模块在高速下每包之间会插入毫秒级间隙导致帧被拆成两段接收侧频繁半包。二是写屏阻塞如果lcd_write_pixels是阻塞式且没有 DMA高波特率下串口数据到了但 CPU 还在写屏DMA 缓冲很快溢出。解决方向是给写屏也上 DMA或者把接收缓冲加大到能扛住一次写屏的时间。判断方法很简单在写屏函数前后各翻转一个 GPIO用逻辑分析仪看写屏占空比超过 50% 就说明瓶颈在屏不在串口。5.4 现象第一张图正常第二张开始整体错位十几行多数是 LCD 窗口没有正确关闭或者 seq 从 0 重新开始但屏幕没有清。窗口未关闭时IC 内部的行列指针停在上次的位置新一帧的「设窗口」命令如果被优化掉有些驱动会判断窗口没变就跳过像素就写到旧位置。解决办法是每帧都无条件重设窗口不要做「窗口相同则跳过」的优化。另一个来源是上位机重发时 seq 没有重置第二张图从 320 开始编号lcd_blit_line里y IMG_H直接 return屏幕看起来就是「下半张没更新」。5.5 排查工具链回环、逻辑分析仪与屏幕三色条排这类问题工具比经验管用。第一步做串口回环把 TX 和 RX 短接上位机发什么就该收到什么这一步能排除 USB 转串口和驱动问题。第二步用逻辑分析仪抓 TX 线看帧头和帧间隔是否符合预期重点看两帧之间有没有异常长的空隙。第三步在 STM32 里加一个「三色条」自检函数不经过串口直接往屏幕写红绿蓝三条确认写屏链路本身没问题。这三步做完问题一定落在「串口收」或「协议解析」其中一段范围就很小了。我习惯把这三步写成一个selftest()函数留在工程里下次换板子直接调用比重新搭环境快得多。6. 把刷新时间再压一半RLE 与局部刷新的取舍6.1 行内 RLE 的编码规则与解码一行 480 字节纯色背景或渐变区域重复度很高行内做游程编码能压掉不少。规则定得简单些连续 3 个及以上相同字节编码成0x00, count, value三字节不足 3 个的原样输出原样里的0x00转义成0x00, 0x01, 0x00。编码侧def rle_encode(data): out, i, n bytearray(), 0, len(data) while i n: run 1 while i run n and data[i run] data[i] and run 255: run 1 if run 3: out bytes([0x00, run, data[i]]) else: for k in range(run): b data[i k] out bytes([0x00, 0x01, 0x00]) if b 0x00 else bytes([b]) i run return bytes(out)解码在 STM32 侧做遇到0x00读下一个字节等于 1 表示转义出一个0x00大于等于 3 表示重复后一个字节 count 次。注意len字段这时要填编码后的长度接收缓冲的上限也得按最坏情况留余量。压缩率取决于图片内容照片类大概 10%–20%图标和 UI 能到 60% 以上所以要不要上 RLE先拿自己的素材跑一遍统计再决定。6.2 只传变化行比压缩更有效的是少传。上位机保留上一帧的 RGB565 字节发送前逐行比对只把变化的行号发出去STM32 侧照常按 seq 写对应行没收到的行保持原样。做 UI 刷新时一屏 320 行里通常只有十几行在变流量直接降一个数量级。代价是两边都要维护一份上一帧的状态内存换带宽在 RAM 紧张的型号上要算清楚上位机侧 153 KB 不算事STM32 侧不需要存整图只存行号位图320 位即 40 字节很划算。6.3 用 CRC 对拍验证整条链路改完压缩和局部刷新最容易出的问题是「看起来正常个别行是旧的」。验证方法是在协议里加一个整图 CRC上位机把整帧 RGB565 算一个 CRC16 随结束帧发下去STM32 在本地按收到的数据同步累加最后比对。不一致就整屏重传一次一致才算这一帧完成。这个机制平时不触发一旦触发就是明确的信号比盯着屏幕找哪一行没更新可靠得多。从那以后我每次改完传输逻辑都会先跑一遍「纯色三屏 整图 CRC 对拍」两个都过才接真实图片。这套习惯帮我省掉的返工时间比优化本身多得多。希望帮到你。本文还有配套的精品资源点击获取