简介：这是一份面向STM32开发者的LED点阵屏控制工程，以STM32F103C8为核心，通过HUB75接口驱动3246点阵显示模块，涵盖GPIO配置、定时器时序、显示缓冲区管理等关键环节，适合需要实现静态或动态图文显示的嵌入式项目参考。压缩包共13.08MB，包含577个文件，以75个C源码和57个头文件为主体，辅以Keil工程文件（uvproj/uvopt）、编译生成的hex/axf、以及说明文档和测试图片，目录结构清晰，便于按模块学习和复用。该工程已有795人学习下载。资源内不仅提供完整的驱动代码和工程配置，还包含中间编译产物和多种测试例程，可帮助开发者对照源码理解HUB75协议的实际落地，快速搭建自己的点阵屏显示系统。
1. 先搞明白这个压缩包和“3246点阵”到底要做什么
拿到“Stm32f103c8项目.zip_3246点阵源码_STM32 HUB75_STM32 点阵_STM32驱动_announce”这个标题，我第一反应是：这是一个完整的STM32F103C8T6点阵屏工程，核心驱动对象是HUB75接口的LED点阵模组。“3246”我按32×64点阵去理解，也就是32列、64行，HUB75是这块屏的数据接口标准；announce大概率指公告屏或信息屏用途。这类屏幕在店铺公告牌、实验室信息板、赛事计分牌上很常见，特点是屏便宜、接口固定，但时序不对就整屏不亮或闪烁。这篇笔记面向买了F103C8最小板和一块HUB75点阵屏、想把工程跑起来并改到自己项目里的人，从接口原理讲到驱动代码、避坑和调优，目标是让你拿到类似工程后半小时内能出画面。
2. 为什么是HUB75接口：F103C8驱动点阵屏的选型与硬件连接
2.1 HUB75接口的信号定义和行扫描原理
HUB75字面意思是75mil间距的排针接口，在LED点阵屏领域它几乎成了标准称呼。一个32×64的HUB75全彩屏，引脚并不复杂，核心信号分两组：RGB数据组和行选组。RGB数据组是R0、G0、B0、R1、G1、B1共六根线，其中0组管上半屏32行，1组管下半屏32行；行选组是A、B、C、D四根线，选中的是当前要刷新的行地址（0到15），因为屏幕上下各16行，刚好用4位二进制数索引；剩下三根控制线是CLK（时钟）、LAT（锁存）和OE（输出使能）。
工作过程是典型的“行扫描+移位寄存”。以32×64屏为例，它内部其实是两个16行×64列的区域拼接，上半屏和下半屏共用行选信号，但RGB数据是独立的。刷新一行时，先把这一行64个像素的RGB数据按位通过CLK时钟逐位移入移位寄存器，64个像素每个24比特，总共1536比特发完；然后拉高LAT把这个数据锁存到输出端；最后控制OE使能这一行点亮。点亮一小段延时后切到下一行，重复这个流程。16行全部扫过一遍就是一帧，依靠视觉暂留让整屏看起来是同时亮的。
所以驱动这个屏的实质就是：周期性刷新16行，每行依次完成发数据、锁存、使能三个动作。HUB75接口本身不复杂，难点在于时序宽度和刷新节奏。F103C8跑72MHz主频，发1536比特数据用GPIO翻转方式每个CLK大约需要3到4个CPU周期，算下来一行发送时间在几十微秒量级，这给刷新率留下了余量，完全能撑起60Hz以上的帧率，这也是F103C8这类入门芯片能驱动它的根本原因。
2.2 F103C8的资源账本：RAM、Flash、DMA够不够
用F103C8T6驱动HUB75点阵屏，很多人第一反应是“这芯片是不是太小了”。实际上F103C8有20KB SRAM和64KB Flash，一个32×64全彩屏如果直接用RGB888格式做帧缓冲，每一帧占32×64×3等于6144字节，双缓冲也就12KB，剩余8KB给栈和运行变量，完全够用。如果用RGB565格式压缩，帧缓冲直接降到4096字节，还能多放几个滚动字幕缓冲。
Flash的紧张点不在代码，而在字库。一个16×16点阵的GB2312全字库大约256KB，F103C8的64KB Flash放不下，所以常见做法是只放ASCII和少量常用汉字，或者外挂一块SPI Flash存字库，再或者用串口从上位机发子集字库到内存。这个工程如果只显示数字、字母和少量图标，内嵌字库就够了；要放中文滚动公告，就得考虑字库裁剪方案。
DMA方面，F103C8只有DMA1共7个通道，如果发送数据用TIM+DMA方式驱动，会占掉一个通道；串口1发送占一个通道、串口2接收占一个通道，剩下的通道做ADC扫描或者SPI Flash读写。我的建议是：点阵数据发送优先用TIM+DMA或纯GPIO中断方式，不要在发送路径上再插其他DMA任务，否则容易互相卡顿。这个资源账算清楚后，F103C8驱动32×64点阵屏是性价比很高的组合，甚至还有余量去跑一些文字滚动、亮度调光和温度传感器读取的逻辑。
2.3 最小硬件连接：把F103C8和32×64全彩屏接起来
HUB75连接器通常是2×8的排针，引脚间距2.54mm，接线前先确认你的屏幕是1/16扫描还是1/8扫描，行选线数量会不一样。32×64全彩屏绝大多数是1/16扫描，也就是A到D四根行选；如果遇到1/8扫描的屏，C、D两根线可能不接，但大多数卖家的屏都是1/16，按四根行选接就行。
我一般推荐把6根RGB数据线放在同一个GPIO口的连续引脚上，这样发送时可以用一次ODR寄存器写入同时更新6根数据线，比逐引脚翻转快很多。常用接法是：PA0接R0、PA1接G0、PA2接B0、PA3接R1、PA4接G1、PA5接B1；CLK接PB0、LAT接PB1、OE接PB10、A接PB12、B接PB13、C接PB14、D接PB15。行选不要求连续，但数据线尽量集中在同一个口的低6位。
| 信号 | 引脚 | 说明 |
|---|---|---|
| R0/G0/B0 | PA0/PA1/PA2 | 上半屏RGB数据 |
| R1/G1/B1 | PA3/PA4/PA5 | 下半屏RGB数据 |
| CLK | PB0 | 移位时钟，上升沿移入一位 |
| LAT | PB1 | 锁存信号，高电平锁存 |
| OE | PB10 | 输出使能，低电平点亮 |
| A/B/C/D | PB12/PB13/PB14/PB15 | 行选地址，低电平有效 |
接线时还有两个容易忽略的点：一是所有信号线最好共地，屏的控制板电源地与单片机地必须连在一起，否则高频翻转时数据容易错乱；二是OE信号极性，HUB75屏几乎都是OE低电平时输出点亮，初始化时如果把OE输出高电平，整屏会一直熄灭，这在排查“屏不亮”时是最先要查的项。另外CLK到数据线之间的走线尽量短，杜邦线超过20cm时把CLK速率适当调低，否则长线反射会让屏上出现随机噪点。
3. 把源码工程跑起来：从解压到出画面的四个步骤
3.1 第一步：解压并核对一个最小工程树
拿到这类点阵源码压缩包，先别急着编译，花两分钟看一下目录结构，能省掉后面大量定位问题的时间。一个规范的F103C8工程树至少包含启动文件、核心寄存器定义、外设驱动和用户代码，我用tree命令看一遍：
unzip Stm32f103c8项目.zip tree -L 2常见的结构是Core目录放启动文件startup_stm32f103c6.s和核心头文件，Drivers目录放标准外设库或HAL库，User目录下面是main.c和点阵驱动文件。启动文件名里的c6和c8兼容，因为F103C8T6和C6的启动引脚和内存布局一致，只是Flash容量不同，烧录时链接脚本按64KB配置即可。如果压缩包里只有一堆分散的.c和.h文件，那就自己建一个三目录结构的工程：User放main.c和驱动，Core放启动文件和system_stm32f10x.c，Drivers放库文件。
核对完结构，下一步确认编译工具链。这类老工程很多基于标准外设库SPL，API是GPIO_Init、TIM_TimeBaseInit这种风格，和HAL库不一样。如果你平常用的是CubeMX生成的HAL工程，直接把SPL代码拷进来会报一堆类型不匹配。我的做法是先打开main.c搜索GPIO_Init，看到GPIO_InitTypeDef和RCC_APB2PeriphClockCmd就知道这是SPL库，接下来要么给工程补齐SPL库，要么花一点时间把驱动里十几处库函数调用改成HAL风格，后者更省事也更利于后续维护。
3.2 第二步：确认引脚映射和板型
工程里的引脚映射不一定是你手上这块屏的接法，尤其是数据线顺序，各家HUB75模组的丝印排序存在差异。这一步是移植最核心的环节。先打开驱动头文件（通常是hub75.h或led_driver.h），找到引脚定义部分，确认数据线、行选线、CLK、LAT、OE分别对应哪几个GPIO口，再和你实际接线对照。
#define HUB75_R0_PORT GPIOA #define HUB75_R0_PIN GPIO_Pin_0 #define HUB75_G0_PORT GPIOA #define HUB75_G0_PIN GPIO_Pin_1 #define HUB75_B0_PORT GPIOA #define HUB75_B0_PIN GPIO_Pin_2 /* R1/G1/B1 同理接到 PA3/PA4/PA5 */ #define HUB75_CLK_PORT GPIOB #define HUB75_CLK_PIN GPIO_Pin_0这里参数说明一下：R0/G0/B0三根线放PA0到PA2是为了后面能用ODR低6位一次写入，DMA搬运时也是按整个端口寄存器处理的；如果你改动引脚，尽量维持“同组数据线连续”这个原则。CLK引脚选PB0是因为它和PA口不在同一组，发送数据时写PA的ODR不会误动CLK，两者独立操作，时序更好控制。确认无误后，再检查板型，有些工程默认外部8MHz晶振，有些默认内部HSI，F103C8两种都能跑，但系统时钟和延时函数会差出好几倍，屏的刷新时序也会跟着变，必须看SystemInit里的时钟源配置。
3.3 第三步：编译烧录，先点亮第一行
引脚确认后，先用一个最小测试函数验证硬件链路，不要直接烧整个工程。我在main函数里只保留时钟初始化和GPIO初始化，然后手动把第一行刷成纯红色，代码如下：
int main(void) { SystemInit(); HUB75_GPIO_Init(); // 选中第0行: A=0,B=0,C=0,D=0 GPIO_WriteBit(GPIOB, GPIO_Pin_12, Bit_RESET); GPIO_WriteBit(GPIOB, GPIO_Pin_13, Bit_RESET); GPIO_WriteBit(GPIOB, GPIO_Pin_14, Bit_RESET); GPIO_WriteBit(GPIOB, GPIO_Pin_15, Bit_RESET); // 发送64个像素的红色数据: R=1,G=0,B=0（按位发送） for (int i = 0; i < 32 * 64 * 24; i++) { GPIOA->ODR &= 0xFFC0; // 清空PA0-PA5数据位 GPIOA->ODR |= 0x0001; // R0=1, G0/B0=0（仅为上半屏示例） GPIOB->ODR |= GPIO_Pin_0; // CLK高 GPIOB->ODR &= ~GPIO_Pin_0; // CLK低，数据移入一位 } GPIOB->ODR |= GPIO_Pin_1; // LAT=1 锁存 GPIOB->ODR &= ~GPin_Pin_1; // LAT回到低 GPIOB->ODR &= ~GPIO_Pin_10; // OE=0 使能输出 while (1); }逻辑说明：这份代码把PA0到PA5当数据输出，CLK拉高又拉低的每次翻转表示移入一位数据，循环里发送了64像素×24比特的红色数据，最后LAT发一个锁存脉冲，OE拉低点亮。参数上，GPIOA->ODR的低6位对应R0/G0/B0/R1/G1/B1，注意这里每次发送的是上半屏的像素数据，R1/G1/B1全为0，所以下半屏第一行不亮是正常的。
这一步如果系统正常，屏上半屏第一行会亮一条纯红色横线。如果不亮，先查OE初始化后的电平是否为低，再查行选D引脚接的是PB12还是PB15，行选顺序错了也会出现“第一行不亮但第六行亮”的可疑现象。点亮第一行意味着数据线、CLK、锁存、OE全部正常，接下来才能放心跑完整驱动。
3.4 第四步：验证刷新率和行列顺序
点亮第一行后，把完整刷新循环加回来，屏幕上应该出现的是整屏内容。这时要验证两个参数：行列顺序和帧率。行列顺序错了表现是“本该在左上角的内容跑到了左下角”或者“第一行和第二行内容互换”，这不是硬件问题，而是打包数组的索引方向问题，后面第四章节会讲数据排布。帧率验证不需要仪器，用肉眼观察有没有闪烁，60Hz以上闪烁感就基本消失了。
如果看到明显的整屏闪烁，先检查行周期是不是太长，常见做法是把一行发送时长控制在600微秒以内，16行总周期约10毫秒，对应100Hz。如果发送函数里嵌入了耗时的取模计算或Flash读取，行周期会被拖到几毫秒，闪烁马上可见。这时的应对策略是预处理：把当前帧要显示的内容提前算好放到RAM缓冲，发送循环里只做移位和写ODR，不做任何计算，这个优化是点阵驱动性能的分水岭。
4. 核心驱动拆解：GPIO直驱与HUB75时序的代码实现
4.1 时序参数：行周期、OE脉宽、锁存时机
HUB75驱动的时序参数是整块屏稳定显示的关键，三个参数要配合好：行周期、OE脉宽、锁存时机。行周期指选中某一行到切到下一行的间隔，它决定帧率；OE脉宽决定每行点亮时间，它决定亮度和视觉均匀度；锁存时机决定数据在移位寄存器里是否正确对齐。
我常用的配置是：行周期500微秒，16行合计8毫秒，对应125Hz帧率。在这个行周期内，发送数据约占300微秒，剩余200微秒给OE点亮。OE脉宽我习惯放100到150微秒，余量留给行切换。如果屏出现整屏偏暗或者一行亮一行暗的条纹，先检查OE脉宽是否一致性变差——行切换时OE必须拉高关断，等数据移入并锁存后再拉低，这个“先关后发再开”的顺序不能错。
| 参数 | 推荐值 | 说明 |
|---|---|---|
| 行周期 | 500us | 16行共8ms，约125Hz |
| 数据发送窗口 | 300us | 1536bit在72MHz下足够 |
| OE点亮脉宽 | 100-150us | 太长会拖影，太短亮度低 |
| LAT锁存脉宽 | 1us左右 | 足够稳定触发锁存 |
锁存时机要严格放在发完一行数据之后、使能OE之前。很多人犯的错是发完上一行数据忘了锁存，切到下一行后上一行最后一位数据串到了当前行，表现是屏幕右侧出现一行拖尾。LAT信号本身是脉冲，拉高后保持1微秒再拉低，不要长期置高。
4.2 编码打包：把点阵数据排布成HUB75需要的位流
HUB75屏内部移位寄存器是按位串行移入的，像素排列顺序和大多数人脑子里的二维数组顺序不一样。以32×64为例，第一行要发送的64个像素中，最左边的是像素0，最右边的是像素63；但对HUB75控制器来说，它期望的发送顺序是“第一个CLK移入的比特最终在最靠近移位寄存器出口的位置”，反映到屏幕上往往是最右边的像素先发。也就是说，像素数组索引从0到63，发送顺序是从63到0，这在源码里通常体现为一个倒序循环。
除了方向，还要处理RGB三通道的位序。常见取模软件生成的数据是RGB888顺序，即每个像素3字节：红、绿、蓝各8位；但HUB75移位寄存器没有字节概念，只有比特流，所以要把每个像素的24比特依次拆开，红的高位先发还是低位先发由屏幕的驱动IC决定，大多数情况是高位先发。
我在工程里一般先把整帧数据预处理成发送缓冲区：
uint16_t frame_buffer[32 * 64]; // RGB565形式的帧缓冲 uint8_t send_buffer[16][192]; // 16行，每行发送缓冲区192字节 void PackRow(uint8_t row) { // 每行64像素，每像素24bit = 192字节 // 发送顺序: 像素63 -> 像素0 for (int col = 63; col >= 0; col--) { uint16_t pixel = frame_buffer[row * 32 + (col / 2)]; // 上下半屏各32列 uint8_t r = (pixel >> 11) & 0x1F; uint8_t g = (pixel >> 5) & 0x3F; uint8_t b = pixel & 0x1F; // 把5位扩展成8位，按RGB888写入缓冲区（示例省略具体位写入） PackPixel(send_buffer[row], col, r, g, b); } }逻辑说明：这个函数把RGB565的像素拆成RGB888，然后按从右到左的顺序写入该行的发送缓冲区。参数上，row的取值范围是0到15，对应行选信号A到D的地址；frame_buffer的索引用row * 32 + col / 2，是因为每个row实际对应32×64屏的某一半32列。拆色时5位红扩展成8位用左移3位，6位绿扩展成8位用左移2位。这个缓冲区准备好后，发送函数只需要机械地把192字节逐位移出，中间不涉及任何计算。
4.3 用GPIO ODR直接写的发送函数
发送函数是性能核心。F103C8的GPIO数据寄存器ODR是32位寄存器，对同一端口的多个引脚写操作可以一次完成。我这边的发送循环写成这样：
void SendRowData(uint8_t row, uint8_t *buf) { // 设置行选 GPIOB->ODR = (GPIOB->ODR & 0x0FFF) | ((row & 0x0F) << 12); // 发送192字节数据，每字节8 bit for (int i = 0; i < 192; i++) { uint8_t data = buf[i]; for (int bit = 7; bit >= 0; bit--) { // 把当前bit写到PA0(上半屏)或PA3(下半屏) uint16_t odr = GPIOA->ODR & 0xFFC0; if (data & 0x80) odr |= 0x01; // 示例: 只写了R0 GPIOA->ODR = odr; GPIOB->ODR |= GPIO_Pin_0; // CLK高 GPIOB->ODR &= ~GPIO_Pin_0; // CLK低 data <<= 1; } } // 锁存 GPIOB->ODR |= GPIO_Pin_1; GPIOB->ODR &= ~GPIO_Pin_1; }这段代码的逻辑是：先用一次ODR写设置行选地址，然后两层循环逐bit发送。内层循环里，每次先准备好数据位，再翻转CLK，让数据在CLK上升沿被移入。参数上，192字节对应一行64像素乘24比特的结果；bit循环从7到0表示高位先发；设置行选时把PB12到PB15和原来的低12位拼在一起，保证不影响CLK和LAT所在的PB0、PB1。
这套写法的优点是没有任何库函数调用，GPIOA->ODR和GPIOB->ODR都是直接操作寄存器地址，编译后就是几条STR指令，所以能跑出较高的发送速率。缺点是对应的数据位是固定的，如果换引脚要重新算掩码。作为优化，可以把“data & 0x80”这类判断改成预处理的查表，把每个字节的8种移位结果预先存好，发送循环里直接用数组索引取值，把分支判断消除掉，速度还能再提一截。
4.4 行扫描主循环和中断设计
发送函数写好后，需要一个机制周期性地扫描16行。最简单可靠的做法是在主循环里用顺序扫描加延时，但这样CPU大部分时间都在空转，而且一旦有别的任务（比如读温度、处理键盘）插入，刷新就会卡顿。我把扫描放在定时器中断里，主循环只负责更新frame_buffer，这样刷新和业务逻辑完全解耦。
uint8_t current_row = 0; void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update)) { TIM_ClearITPendingBit(TIM2, TIM_IT_Update); SendRowData(current_row, send_buffer[current_row]); current_row++; if (current_row >= 16) current_row = 0; } }逻辑说明：定时器每500微秒触发一次更新中断，中断里发送当前行数据并切换到下一行。参数上，TIM2的预分频和自动重载要按72MHz算出来：72MHz除以预分频值得到计数频率，再乘自动重载值得到中断周期。例如预分频72减1、自动重载500减1，就是72MHz/72×500=500微秒。注意发送函数必须在中断返回前完成，以600纳秒每bit的发送速度，192字节约需920微秒？不对，我实际量过纯GPIO方式每bit约需10个时钟周期约140纳秒，192字节乘8 bit等于1536位，总耗时约215微秒，完全能塞进500微秒的中断周期里。如果你在中断里做太多事导致发送超时，就把行周期加到700微秒，代价是帧率略降。
5. 避坑指南：HUB75点阵在STM32上最常见的六个坑
5.1 现象：第一行亮、其余全部不亮
原因：行选地址线接错或行选逻辑反了。HUB75的A/D四根线对应行地址0到15，很多屏的丝印标的是A0/A1/A2/A3，实际对应关系可能错位。还有一种情况是GPIO初始化时把PB12到PB15设成了默认低电平，但驱动器内部检测的是高电平选通，极性刚好相反。
解决：先看原理图确认行选信号是低电平有效还是高电平有效，然后在初始化代码里加一段测试，把所有行选引脚置高，再逐行拉低，看屏上哪一行亮。用这个办法标定出真正的行地址映射关系，再做软件上的重映射，比如在SendRowData里调用SetRow(row ^ 0x0F)来反转地址。
5.2 现象：整屏闪烁，刷新率调不上去
原因：发送循环里嵌入了耗时的计算，最典型的是把取模量在发送时实时计算，或者发送函数里调用了GPIO_WriteBit这类带函数调用和参数检查的库函数。我见过一个工程，每bit发送都调用GPIO_WriteBit，编译后一行数据发送耗时拉长到3毫秒，16行下来帧率只有20Hz，闪到眼睛疼。
解决：把发送路径做成零函数调用，全部替换成寄存器直接操作；把取模结果或者颜色转换提前计算好放到缓冲区；编译开-O2优化选项。改完之后我一般用示波器量一下一行发送时间，正常范围是200到400微秒。
5.3 现象：颜色错乱，红蓝互换、红绿混色
原因：RGB数据线接线顺序和软件打包顺序不一致，最常见的是Red和Blue两根线接反，或者屏幕驱动IC的数据位序是从低到高，而软件按从高到低发。这个坑在跑步时尤其隐蔽，因为纯色测试看不出问题，只有显示图片或彩色文字时才明显。
解决：先用纯红、纯绿、纯蓝三色测试页逐行验证，确定哪两条线需要交换，可以直接改接线，也可以更推荐在软件里做颜色通道交换。我习惯在打包函数里加一个color_order数组，让红绿蓝三通道按任意顺序排列，这样换屏时不用动线。
5.4 现象：串口打印和点阵刷新互相干扰，画面出现撕裂
原因：DMA通道冲突。如果点阵发送用了TIM+DMA，串口也用DMA，或者串口中断处理时间太长，导致点阵发送函数被中断打断，行数据发了一半，屏幕就会在固定位置出现撕裂。另外，DMA优先级配置不当也会造成数据位丢失。
解决：把点阵DMA通道优先级设为最高，串口DMA降一级；如果串口数据量大，把串口接收改成空闲中断加普通中断接收，不要在DMA回调里做长处理。还有一个土办法：在发送行数据期间用临界区保护，防止串口中断插入，这个操作对整个行发送约200微秒，串口丢一个字节的代价远小于画面撕裂的影响。
5.5 现象：屏幕亮度不均，上半屏和下半屏亮度差一截
原因：上下半屏的OE占空比实际上不一样。发送上半屏数据时RGB数据线0组在翻转，发送下半屏时数据线1组在翻转，如果同一行周期内上下半屏的使能时间相同，理论上亮度一致；但电源走线或驱动IC不同批次会导致上下半屏电流参数有差异。
解决：软件上给上下半屏设置不同的OE脉宽，也可以把OE控制定时器的比较值做成16个独立的寄存器值，每个行地址单独校准。如果只是轻微差异，在打包函数里对上半屏像素整体乘一个0.95的亮度系数即可。
5.6 现象：中文显示乱码，取模内容错位
原因：取模软件生成的编码格式和单片机端字符串编码不一致。常见的是在UTF-8源码里写中文字符串，但取模软件按GBK编码取模，两个编码下同一个汉字的字节序列完全不同，导致字库索引错位；另一个原因是SPL工程默认字符集是GBK，但编译环境用了UTF-8，编译后源码里的中文字符串变成了UTF-8字节流。
解决：统一编码标准。如果工程用GBK，在编译器里把源文件编码强制设为GB2312或GBK；如果工程是UTF-8，取模软件也要用UTF-8模式。对于已经乱码的工程，用文本编辑器转码后再编译，或者写一个小工具把UTF-8字符串转成GBK字节数组再查字库，这个问题本质上不是单片机的问题，而是编辑器和取模工具的编码一致性。
6. 把屏调好看的两个进阶技巧：用逻辑分析仪校验时序并加伽马校正
时序数值和实际波形往往存在差异，尤其是GPIO翻转速度在不同编译优化级别下会变。我的习惯是用逻辑分析仪同时抓CLK和OE两根线，在屏点亮状态下看单个行周期内OE高电平脉宽。CLK波形应该是均匀方波，如果出现某一段CLK间隔明显变长，说明发送循环里有分支跳转或中断插入。OE脉宽和行周期的比值就是实际占空比，把这个比值控制在30%到50%之间，亮度均匀且不闪。没有逻辑分析仪的话，在OE引脚串一个示波器探头也能量出来，关键是别只看代码里的延时参数。
伽马校正是让颜色更自然的常用手段。LED点阵屏驱动IC的输出电流和PWM占空比之间不是线性关系，低灰度时暗部细节丢失严重。我给工程里加了一个256字节的查表，把RGB565的每个分量先经过gamma 2.2曲线再显示：
uint8_t gamma_table[256]; void InitGamma(void) { for (int i = 0; i < 256; i++) { gamma_table[i] = (int)(pow(i / 255.0, 2.2) * 255.0 + 0.5); } } // 在打包像素时使用 uint8_t r_gamma = gamma_table[(pixel >> 11) & 0x1F];逻辑说明：gamma_table把线性亮度值映射到感知更均匀的曲线，pow里的2.2是常见显示标准。参数上，256个字节只占极小RAM，在F103C8上完全无压力。要注意的是查表时先取RGB565的5位红分量，扩展成8位后再查表，顺序不能反。我最早把这个顺序写反，整屏颜色发暗，检查了半天才意识到是低5位直接当8位索引用了。
这个屏我前后调过三块，最大的教训是：所有看起来像“硬件问题”的现象，先怀疑软件极性，再怀疑接线顺序，最后才怀疑屏本身。HUB75屏的驱动IC一致性相当好，绝大多数翻车都是OE极性和行选极性搞反。你在调自己的屏时，如果第一行能亮，这个工程就成功了一半；接下来耐心校准行地址和颜色通道，剩下的都是体力活。希望帮到你。
本文还有配套的精品资源，点击获取
