做嵌入式的谁没跟液晶屏打过交道。无论是手头一块单色点阵屏还是TFT彩屏到了要显示字符这一步基本都会碰到一个函数——LCD_ShowChar(u16 x, u16 y, u8 num, u8 size, u8 mode)。这玩意儿看起来就是普普通通的“在指定位置显示一个字符”但真正自己写过一遍、调过一遍的人都知道里面藏着坐标基准、字库取模、逐位运算、边界处理一堆讲究。翻来覆去改Bug的那些日子我现在都还记得。这篇就把这个函数的来龙去脉、底层原理、具体实现和踩坑经历摊开聊透给正在跟显示屏较劲的朋友一个参考。1. 这个函数到底在解决什么问题1.1 从点阵屏显示原理说起液晶屏说白了就是一大堆像素点按行列排布你看到的所有内容——字符、汉字、图片、曲线——本质上都是让这些像素点按照特定规律亮起来或者灭掉。单色屏还好一个字节的8个bit直接对应8个像素彩色屏也就是把RGB565或者RGB888的颜色值填进显存而已。但这里有个很现实的问题屏幕不会自己把字母“A”显示出来。你得告诉它(x, y)这个位置开始哪些点要亮、哪些点要灭。平时写LCD_ShowString、LCD_ShowNum这些上层接口很爽真正干活的底层却是“把字符转成点阵数据、再逐位画到屏上”这么个枯燥重复的过程。LCD_ShowChar干的就是这件事它是整个字符显示体系里的最小单元其他函数都是在它的基础上做组合、循环和格式转换。理解了这层你会发现这个函数的本质是“像素绘画师”——把抽象的字符编码变成具体的屏幕像素操作。这也是为什么好多教程最后会追问一句你真的懂LCD_ShowChar吗懂它才算真正迈进了显示驱动的门槛。1.2 为什么单独封装一个“显示单字符”的函数可能有人会问我直接写一个显示一段字符串的函数不就行了干嘛还要单独搞一个单字符的这个问题我在刚接触液晶驱动时也困惑过直到自己动手去写驱动才明白——字符串函数是典型的“多对一”封装它一定会依赖于一个更底层的单字符函数。你想想看如果所有字符串功能都在一个函数里硬写那么每换一种字号、每加一种显示模式都得把这套逻辑复制一遍。代码臃肿不说改动一处可能满盘皆崩。而把“单个字符怎么画”这个核心逻辑抽出来再用循环去处理字符串整个结构就清爽多了。从工程角度讲这也是典型的“单一职责”思维显示一个字符是一件事显示一串字符是另一件事。前者解决“怎么把字符变像素”的逻辑后者解决“怎么把一串字符排列好”的逻辑两者解耦调试时定位问题也快。所以LCD_ShowChar不只是一个函数它代表着一种驱动架构的起点。写驱动时宁可把单字符函数写得扎实一点后面的字符串、数字、浮点数、进度条之类的高层接口都会变得顺理成章。2. 五个参数逐个拆解——设计背后的权衡2.1 坐标参数x、y定位基准与字体宽度函数签名里的u16 x和u16 y许多新手觉得只是个坐标随手填个数字就行。这里其实有两个隐性知识点。第一x和y是左上角起始点。也就是说字符点阵区域的最左上角那个像素会被放在(x, y)位置字符向右下方展开。这是绝大多数屏驱动遵循的约定但如果你用的屏驱动坐标基准不同比如有些屏以左下角为原点那就要小心了。第二字体不同x方向的步进不同。最常见的几种字号是6x12和8x16也就是说一个英文字符占6列或8列宽、12行或16行高。显示完一个字符后下一个字符的x坐标不是随便加个数字而是要加上当前字号的宽度。很多字符错位、重叠的问题根源就在于这里步进算错了。我在一个项目里就见过有人显示8x16的字符时x坐标每次只加8而不是加8加一个间隔结果两个字符之间快要贴上在窄边屏上显得特别拥挤。后来统一封装了一个LCD_ShowString内部根据size自动计算步进这种问题才彻底消失。2.2 num参数ASCII与扩展字符的边界u8 num要显示的是字符编码。绝大多数情况下这个值就是ASCII码比如A对应0x410对应0x30。但这里有个容易被忽略的边界问题——u8最大只能表示0~255也就是只能覆盖ASCII扩展字符集Latin-1之类遇到中文这种单字节搞不定的字符这个函数就无能为力了。实际工程中处理中文字符通常会有单独的LCD_ShowChinese函数其参数不再是单个编码而是指向中文字符串的指针配套的字库也得是UTF-8或者GBK编码对应的点阵数据。因此别想着靠一个LCD_ShowChar打天下它在设计上就锁定了“单字节字符”的边界。另外提一个隐藏细节传给num的值最好断言一下范围。比如小于0x20空格或者大于0x7E~的控制字符/扩展字符字库里可能没有对应的点阵数据不做保护的话函数会越界读数直接花屏。我自己的习惯是在函数入口加个判断超范围就当作空格处理至少界面不会乱。2.3 size参数字体大小背后的点阵规格u8 size这个参数表面是“大小”实际是指定字库中的点阵规格。常见的取值是12、16、24分别对应6x12、8x16、12x24这样的点阵尺寸。有些驱动会用size16表示16x16的点阵注意区分。为什么不是直接传“宽度x高度”两个参数因为字库在ROM里是按固定格式存的每个字符的字节数固定。比如8x16的字号每一行占1个字节共16行所以每个字符占16个字节而16x16的汉字每行2个字节、共16行所以每个汉字占32个字节。如果同时传宽和高字库寻址就要多好几步乘法直接传一个size、内部查表得到宽高效率更高代码也更简洁。参数设计上的这个“偷懒”其实是嵌入式开发的常态在性能和代码复杂度之间找平衡。说白了传size就是在用“有限集合的枚举值”去替代“宽高组合”让字库索引变成一个简单的查表操作。2.4 mode参数反白显示的位运算实现u8 mode这个参数最容易被新手忽略但它的作用相当实在。常见的取值就两个0表示正常显示白底黑字等效1表示反白显示黑底白字等效。实现原理其实很简单就是在把点阵数据写入显存时做一次按位取反。正常模式下字模数据里为1的位点亮反白模式下字模数据里为1的位反而熄灭为0的位点亮这样显示出来就是反色效果。很多驱动都是这么写的if (mode 0) { // 正常字模bit为1 - 点亮 LCD_DrawPoint(x row, y col, color); } else { // 反白字模bit为0 - 点亮 LCD_DrawPoint(x row, y col, !color); }反白显示在UI设计里太好用了菜单选中项、按钮按下态、高亮提示全都靠这一个参数切来切去。我印象很深的一次经历原来菜单没有做反白态用户根本看不出当前选中了哪一项后来给选中项改成反白整个交互立刻清晰了一个档次而且方案实现只需要在绘制时改一个传参几乎零成本。3. 核心实现全拆解——从字库到像素3.1 字库数据的组织方式与取模要理解LCD_ShowChar内部逻辑先得看字库数据是怎么来的。我们用取模软件比如常见的PCtoLCD2002把需要的字符逐一点出来生成C语言数组。以8x16的ASCII字符A为例它的点阵可以存成16个字节// 8x16 ASCII 字符 A 的字模 // 每行8个像素 - 1个字节共16行 0x00, 0x00, 0x10, 0x38, 0x6C, 0xC6, 0xC6, 0xFE, 0xC6, 0xC6, 0xC6, 0xC6, 0x00, 0x00, 0x00, 0x00上面这个数组每一个字节的8个bit从左到右对应屏幕上8个像素。bit为1像素就点亮bit为0就熄灭。你如果仔细对照ASCII码表去数会发现0x10的二进制是00010000即第4列有一个点这就是字母“A”的顶部尖角。实际项目里的字库内存排列有两种常见方式逐行式和逐列式。逐行式适合横向扫描的屏逐列式适合纵向扫描的屏比如某些OLED。使用之前一定要搞清你的屏幕扫描方向和字库的取模方式是否匹配否则显示出来就是躺着的或者镜像的字符。这个我在第一次驱动OLED时就踩了坑明明字模看着没问题烧进去全是横七竖八的乱码后来把取模方向从“逐行”改成“逐列”立刻正常。3.2 核心绘制流程与坐标计算现在看函数体本身。一个典型的LCD_ShowChar实现大致如下void LCD_ShowChar(u16 x, u16 y, u8 num, u8 size, u8 mode) { u8 temp, t, t1; u16 y0 y; u8 csize (size / 8 ((size % 8) ? 1 : 0)) * (size / 2); // 字符点阵字节数 num num - ; // 字库通常从空格开始存放 // 根据size确定字体宽度和高度取出对应字模 for (t 0; t height; t) { temp font_array[num * csize t]; // 取出当前行的字节 for (t1 0; t1 width; t1) { if (temp 0x80) { // 画点点亮点阵中该像素 } else { // 不画点 / 反之 } temp 1; x; } y; x x_start; // 回到行首 } }思路概括起来就三步查字模、逐位判断、画点。但这里有几个计算细节值得特别注意。先说num - 这句。字库为了方便通常从ASCII码0x20空格开始存放字符数组下标0对应空格下标1对应!以此类推。如果不做这个偏移直接拿num当索引那显示空格时会读到0的字模整个字符就错位了。类似的边界处理在写带中文字库的驱动时更要小心因为中文字库的索引规则往往跟汉字内码有关。再说行列扫描。外层循环按高度走行内层循环按宽度走列每画一个像素就x。一行画完后x要恢复成行首的x坐标y增加一行。这也就是为什么要先暂存y0和起始x的原因不恢复的话字符会画成一条斜线。3.3 反白模式的实现细节上面mode参数提到过反白本质就是取反。但想让它真正好用还有个关键点反白模式的“底色填充”要跟字模输出配合好。如果只做像素取反画出来的是字符轮廓被反色了但周围区域还是原来的底色视觉上看起来会有点“镂空感”。更好的做法是在绘制字符所在区域时把背景也刷一遍。比如对8x16的字符正常模式刷黑色背景再画白色字符或是白底黑字反白模式则刷白色背景再画黑色字符。这样整个字符块看起来是完整的高亮条菜单选中的效果就出来了。if (mode 1) { LCD_Fill(x, y, x width - 1, y height - 1, WHITE); // 先铺白底 } // 再按点阵绘制黑色前景这种“先铺底、再画字”的顺序让反白显示在不同屏之间表现一致。有次我在一款刷新率较低的屏上做菜单没铺底直接反色字符老是有刺眼的残影后来改成先填满背景色再画点观感立刻稳定了。4. 实操之下的关键步骤与性能考量4.1 驱动层API与传输优化真正的项目里LCD_ShowChar本身不是最底层的它下面还有一层更基础的“画点”函数或者“写显存”函数。接口分层大致是这样最底层LCD_DrawPoint(x, y, color)——在指定坐标画一个点中间层LCD_ShowChar(x, y, num, size, mode)——显示一个字符上层LCD_ShowString、LCD_ShowNum、LCD_ShowFloat——显示字符串、数字、浮点数性能瓶颈通常出在最底层。如果是SPI接口的屏每次写显存都要发命令数据逐点操作显然效率很低。这时候一般会加一层“帧缓冲”或者至少是“局部缓冲区”把画点的操作先写到RAM里的显存映射上最后一次刷到屏幕。但不是说每次都要全屏缓冲有些资源紧张的MCU可能就几百字节RAM全屏缓冲根本不现实。折中方案是“行缓冲”一次处理一行像素逐行刷到屏上。尤其显示字符这种操作它的点阵本来就是按行组织的配合行缓冲改动最小。实测下来同样是8x16字符的界面刷新加了局部缓冲之后刷屏速度能提升好几倍而且字符边缘不再有闪烁感。这个优化性价比极高强烈建议在画点密集的项目里优先做。4.2 行列位置动态计算如何让光标“算”得更准很多界面需求不只是显示一串固定字符而是要动态刷新数值比如温度传感器读数、倒计时数字。这种场景最忌讳直接把新数值覆盖上去因为旧数字的残影会残留。比较好的做法是把数值区域当作一个固定宽度的“框”。显示数字前先用背景色填充这个框再显示新数字。这其实是对LCD_ShowChar的高层复用#define NUM_X 60 #define NUM_Y 40 #define NUM_WIDTH 4 // 预留4个数字位 void RefreshValue(int val) { LCD_Fill(NUM_X, NUM_Y, NUM_X NUM_WIDTH * 8 - 1, NUM_Y 16 - 1, BLACK); LCD_ShowInt(NUM_X, NUM_Y, val, 16, 0); }这里有个细节预留区域的宽度必须根据字号来计算。8x16字体每个数字宽度是8像素4位数就是32像素所以填充区域x方向是NUM_X到NUM_X 31。如果算窄了刷新完最右边还会露出旧数字的一个角特别丑。坐标“算得准”本质上就是对字体尺寸、显示位数、对齐方式这些要素做到心里有数。后续做居中、右对齐显示时这种计算能力更是必需品。4.3 从单字符到界面字符串函数如何复用既然LCD_ShowChar是最小单元再往上的字符串函数就顺理成章了。典型的字符串实现是void LCD_ShowString(u16 x, u16 y, u16 width, u16 height, u8 size, u8 *p, u8 mode) { while (*p ! \0) { if (x width - size / 2) { // 换行处理 x 0; y size; } if (y height - size) { // 超出屏幕范围不再继续显示 break; } LCD_ShowChar(x, y, *p, size, mode); x size / 2; p; } }上面的x size / 2对于8x16字体就是每次x加8个像素。换行判断用的width - size / 2意思是坐标x如果超出显示宽度减去当前字符宽度就折行。这套逻辑看似简单但涉及“越界保护”不加的话超长字符串会把数据写到屏幕之外虽然大多数驱动无非是裁剪掉但有些底层的显存写入会越界直接造成硬件异常。我在做某个仪表盘界面时深有体会页面上的参数说明文字比较多一开始没做越界保护刷新界面偶尔会整屏闪烁。后来加了边界判断显示安全了闪烁的问题也顺带消失。5. 常见问题与排查技巧实录5.1 字符偏左或偏右起始坐标与宽度计算误差现象显示一行相同的字符第一个、第二个位置对的越往后越歪或者最后一个字符被切了一半。这种时候十有八九是步进宽度算错了。排查方法把字符显示循环里的步进值单独打印出来或者用调试器看对照当前size的字体宽度。如果你的字体是8x16步进就应该是8。如果你用的是自定义字体比如7x14那就必须用7做步进而不是拿16或者14当步进。还有一种是取模方向搞反了字符会“躺下”或者“镜像”。遇到这种情况先不要急着调坐标回到取模软件重新生成字库把“逐行/逐列”“高位在前/低位在前”这几个选项换一下通常就能解决。我一次调试某款OLED时字符全部是横躺的解决方案就是把取模方向从“逐行”改成“逐列”问题立即消失。5.2 花屏与残影缓冲区同步与清屏时序现象刷新屏幕上的数字时新的数字和旧的数字叠在一起像长了胡子的脸或者整个屏幕出现随机的噪点。常见的两个原因第一个是显存没有清干净。前面提到的LCD_Fill区域覆盖如果你预留的宽度不足以盖住旧数字残影自然会出现。第二个是SPI写入时序问题主控发送速度过快或者片选信号切换时机不对导致写入过程丢字节屏上就会出现随机乱码。这种问题用示波器抓一下CS、SCLK和MOSI的时序很容易定位。排查步骤建议从软件查起先确认清屏逻辑正确再查显示函数有没有越界。软件没问题再考虑硬件时序一步步来别一上来就动电路。实测经验里七成花屏问题出在显示区域的宽高算错两成出在缓冲区处理只有一成才是硬件时序。5.3 反白显示边界溢出跨行取模的特殊处理现象对一个字符做反白显示字符本身对但周围的背景没有完全反色或者反白区域边缘有毛刺。这通常是区域填充和字模宽度不一致导致的。如果字模实际占了9个像素比如加了字符间距而你填充时只填了8个像素宽那第9列就会露馅。解决办法是让“底填充区域”严格等于“字模占用区域”或者干脆每次反白前把全字符块宽度包含间距一起刷掉。还有种特殊情况如果你的字符设计了左右留白的字模比如为了美观字符“A”左右各空一列像素反白时填充区域就要把这部分留白也覆盖进去否则字符和背景之间会有一道细缝。这个细节在菜单高亮显示时特别明显填得不对整个选中项看起来就不干净。5.4 常见问题速查表现象常见原因解决思路字符乱码或错位字库索引偏移错误检查是否做了num - 偏移字符横向拉伸/倒下取模方向与屏幕扫描方向不匹配更换取模选项改为逐列或逐行数字刷新残影清除区域小于旧数字占用区域按最大位数和字号计算清除区宽度整个屏幕随机雪花SPI时序异常示波器抓时序检查CS与SCLK相位反白区域边缘有杂点背景填充区域和字模区域宽度不一致统一填充区域宽度大字号显示缺上半部分高度计算溢出或字库读取越界检查size对应高度和字库字节数计算写在后面LCD_ShowChar虽然是个函数够小但把它认真吃透对整个LCD驱动乃至嵌入式GUI开发都有扎扎实实的帮助。我自己现在写新屏驱动第一步永远是先把单字符函数调稳因为后面所有花里胡哨的界面全靠它撑底。给正准备自己写驱动或者正在调试显示问题的朋友几个建议字库取模规格要跟函数里的size严格对应别混用调试字符显示时先用一个已知字符比如A、0单点测试不要上来就刷一屏幕遇到显示异常优先怀疑索引计算和步进宽度它们出错的概率远高于硬件。有些坑真得自己踩一遍才会记住。我第一次调反白显示时硬是对着屏幕发了半小时呆后来发现只是背景填充区域少算了一列。这种事没法靠看书学会只能上手磨。你这会儿要是也卡在字符显示上不妨把代码里的坐标、步进、字库索引逐个验一遍问题往往就藏在最不起眼的那一行计算里。 
长河君 · 2026/10/14 18:00:11 · 阅读 1.2k LCD_ShowChar函数详解：嵌入式LCD字符显示驱动核心实现
做嵌入式的谁没跟液晶屏打过交道。无论是手头一块单色点阵屏还是TFT彩屏到了要显示字符这一步基本都会碰到一个函数——LCD_ShowChar(u16 x, u16 y, u8 num, u8 size, u8 mode)。这玩意儿看起来就是普普通通的“在指定位置显示一个字符”但真正自己写过一遍、调过一遍的人都知道里面藏着坐标基准、字库取模、逐位运算、边界处理一堆讲究。翻来覆去改Bug的那些日子我现在都还记得。这篇就把这个函数的来龙去脉、底层原理、具体实现和踩坑经历摊开聊透给正在跟显示屏较劲的朋友一个参考。1. 这个函数到底在解决什么问题1.1 从点阵屏显示原理说起液晶屏说白了就是一大堆像素点按行列排布你看到的所有内容——字符、汉字、图片、曲线——本质上都是让这些像素点按照特定规律亮起来或者灭掉。单色屏还好一个字节的8个bit直接对应8个像素彩色屏也就是把RGB565或者RGB888的颜色值填进显存而已。但这里有个很现实的问题屏幕不会自己把字母“A”显示出来。你得告诉它(x, y)这个位置开始哪些点要亮、哪些点要灭。平时写LCD_ShowString、LCD_ShowNum这些上层接口很爽真正干活的底层却是“把字符转成点阵数据、再逐位画到屏上”这么个枯燥重复的过程。LCD_ShowChar干的就是这件事它是整个字符显示体系里的最小单元其他函数都是在它的基础上做组合、循环和格式转换。理解了这层你会发现这个函数的本质是“像素绘画师”——把抽象的字符编码变成具体的屏幕像素操作。这也是为什么好多教程最后会追问一句你真的懂LCD_ShowChar吗懂它才算真正迈进了显示驱动的门槛。1.2 为什么单独封装一个“显示单字符”的函数可能有人会问我直接写一个显示一段字符串的函数不就行了干嘛还要单独搞一个单字符的这个问题我在刚接触液晶驱动时也困惑过直到自己动手去写驱动才明白——字符串函数是典型的“多对一”封装它一定会依赖于一个更底层的单字符函数。你想想看如果所有字符串功能都在一个函数里硬写那么每换一种字号、每加一种显示模式都得把这套逻辑复制一遍。代码臃肿不说改动一处可能满盘皆崩。而把“单个字符怎么画”这个核心逻辑抽出来再用循环去处理字符串整个结构就清爽多了。从工程角度讲这也是典型的“单一职责”思维显示一个字符是一件事显示一串字符是另一件事。前者解决“怎么把字符变像素”的逻辑后者解决“怎么把一串字符排列好”的逻辑两者解耦调试时定位问题也快。所以LCD_ShowChar不只是一个函数它代表着一种驱动架构的起点。写驱动时宁可把单字符函数写得扎实一点后面的字符串、数字、浮点数、进度条之类的高层接口都会变得顺理成章。2. 五个参数逐个拆解——设计背后的权衡2.1 坐标参数x、y定位基准与字体宽度函数签名里的u16 x和u16 y许多新手觉得只是个坐标随手填个数字就行。这里其实有两个隐性知识点。第一x和y是左上角起始点。也就是说字符点阵区域的最左上角那个像素会被放在(x, y)位置字符向右下方展开。这是绝大多数屏驱动遵循的约定但如果你用的屏驱动坐标基准不同比如有些屏以左下角为原点那就要小心了。第二字体不同x方向的步进不同。最常见的几种字号是6x12和8x16也就是说一个英文字符占6列或8列宽、12行或16行高。显示完一个字符后下一个字符的x坐标不是随便加个数字而是要加上当前字号的宽度。很多字符错位、重叠的问题根源就在于这里步进算错了。我在一个项目里就见过有人显示8x16的字符时x坐标每次只加8而不是加8加一个间隔结果两个字符之间快要贴上在窄边屏上显得特别拥挤。后来统一封装了一个LCD_ShowString内部根据size自动计算步进这种问题才彻底消失。2.2 num参数ASCII与扩展字符的边界u8 num要显示的是字符编码。绝大多数情况下这个值就是ASCII码比如A对应0x410对应0x30。但这里有个容易被忽略的边界问题——u8最大只能表示0~255也就是只能覆盖ASCII扩展字符集Latin-1之类遇到中文这种单字节搞不定的字符这个函数就无能为力了。实际工程中处理中文字符通常会有单独的LCD_ShowChinese函数其参数不再是单个编码而是指向中文字符串的指针配套的字库也得是UTF-8或者GBK编码对应的点阵数据。因此别想着靠一个LCD_ShowChar打天下它在设计上就锁定了“单字节字符”的边界。另外提一个隐藏细节传给num的值最好断言一下范围。比如小于0x20空格或者大于0x7E~的控制字符/扩展字符字库里可能没有对应的点阵数据不做保护的话函数会越界读数直接花屏。我自己的习惯是在函数入口加个判断超范围就当作空格处理至少界面不会乱。2.3 size参数字体大小背后的点阵规格u8 size这个参数表面是“大小”实际是指定字库中的点阵规格。常见的取值是12、16、24分别对应6x12、8x16、12x24这样的点阵尺寸。有些驱动会用size16表示16x16的点阵注意区分。为什么不是直接传“宽度x高度”两个参数因为字库在ROM里是按固定格式存的每个字符的字节数固定。比如8x16的字号每一行占1个字节共16行所以每个字符占16个字节而16x16的汉字每行2个字节、共16行所以每个汉字占32个字节。如果同时传宽和高字库寻址就要多好几步乘法直接传一个size、内部查表得到宽高效率更高代码也更简洁。参数设计上的这个“偷懒”其实是嵌入式开发的常态在性能和代码复杂度之间找平衡。说白了传size就是在用“有限集合的枚举值”去替代“宽高组合”让字库索引变成一个简单的查表操作。2.4 mode参数反白显示的位运算实现u8 mode这个参数最容易被新手忽略但它的作用相当实在。常见的取值就两个0表示正常显示白底黑字等效1表示反白显示黑底白字等效。实现原理其实很简单就是在把点阵数据写入显存时做一次按位取反。正常模式下字模数据里为1的位点亮反白模式下字模数据里为1的位反而熄灭为0的位点亮这样显示出来就是反色效果。很多驱动都是这么写的if (mode 0) { // 正常字模bit为1 - 点亮 LCD_DrawPoint(x row, y col, color); } else { // 反白字模bit为0 - 点亮 LCD_DrawPoint(x row, y col, !color); }反白显示在UI设计里太好用了菜单选中项、按钮按下态、高亮提示全都靠这一个参数切来切去。我印象很深的一次经历原来菜单没有做反白态用户根本看不出当前选中了哪一项后来给选中项改成反白整个交互立刻清晰了一个档次而且方案实现只需要在绘制时改一个传参几乎零成本。3. 核心实现全拆解——从字库到像素3.1 字库数据的组织方式与取模要理解LCD_ShowChar内部逻辑先得看字库数据是怎么来的。我们用取模软件比如常见的PCtoLCD2002把需要的字符逐一点出来生成C语言数组。以8x16的ASCII字符A为例它的点阵可以存成16个字节// 8x16 ASCII 字符 A 的字模 // 每行8个像素 - 1个字节共16行 0x00, 0x00, 0x10, 0x38, 0x6C, 0xC6, 0xC6, 0xFE, 0xC6, 0xC6, 0xC6, 0xC6, 0x00, 0x00, 0x00, 0x00上面这个数组每一个字节的8个bit从左到右对应屏幕上8个像素。bit为1像素就点亮bit为0就熄灭。你如果仔细对照ASCII码表去数会发现0x10的二进制是00010000即第4列有一个点这就是字母“A”的顶部尖角。实际项目里的字库内存排列有两种常见方式逐行式和逐列式。逐行式适合横向扫描的屏逐列式适合纵向扫描的屏比如某些OLED。使用之前一定要搞清你的屏幕扫描方向和字库的取模方式是否匹配否则显示出来就是躺着的或者镜像的字符。这个我在第一次驱动OLED时就踩了坑明明字模看着没问题烧进去全是横七竖八的乱码后来把取模方向从“逐行”改成“逐列”立刻正常。3.2 核心绘制流程与坐标计算现在看函数体本身。一个典型的LCD_ShowChar实现大致如下void LCD_ShowChar(u16 x, u16 y, u8 num, u8 size, u8 mode) { u8 temp, t, t1; u16 y0 y; u8 csize (size / 8 ((size % 8) ? 1 : 0)) * (size / 2); // 字符点阵字节数 num num - ; // 字库通常从空格开始存放 // 根据size确定字体宽度和高度取出对应字模 for (t 0; t height; t) { temp font_array[num * csize t]; // 取出当前行的字节 for (t1 0; t1 width; t1) { if (temp 0x80) { // 画点点亮点阵中该像素 } else { // 不画点 / 反之 } temp 1; x; } y; x x_start; // 回到行首 } }思路概括起来就三步查字模、逐位判断、画点。但这里有几个计算细节值得特别注意。先说num - 这句。字库为了方便通常从ASCII码0x20空格开始存放字符数组下标0对应空格下标1对应!以此类推。如果不做这个偏移直接拿num当索引那显示空格时会读到0的字模整个字符就错位了。类似的边界处理在写带中文字库的驱动时更要小心因为中文字库的索引规则往往跟汉字内码有关。再说行列扫描。外层循环按高度走行内层循环按宽度走列每画一个像素就x。一行画完后x要恢复成行首的x坐标y增加一行。这也就是为什么要先暂存y0和起始x的原因不恢复的话字符会画成一条斜线。3.3 反白模式的实现细节上面mode参数提到过反白本质就是取反。但想让它真正好用还有个关键点反白模式的“底色填充”要跟字模输出配合好。如果只做像素取反画出来的是字符轮廓被反色了但周围区域还是原来的底色视觉上看起来会有点“镂空感”。更好的做法是在绘制字符所在区域时把背景也刷一遍。比如对8x16的字符正常模式刷黑色背景再画白色字符或是白底黑字反白模式则刷白色背景再画黑色字符。这样整个字符块看起来是完整的高亮条菜单选中的效果就出来了。if (mode 1) { LCD_Fill(x, y, x width - 1, y height - 1, WHITE); // 先铺白底 } // 再按点阵绘制黑色前景这种“先铺底、再画字”的顺序让反白显示在不同屏之间表现一致。有次我在一款刷新率较低的屏上做菜单没铺底直接反色字符老是有刺眼的残影后来改成先填满背景色再画点观感立刻稳定了。4. 实操之下的关键步骤与性能考量4.1 驱动层API与传输优化真正的项目里LCD_ShowChar本身不是最底层的它下面还有一层更基础的“画点”函数或者“写显存”函数。接口分层大致是这样最底层LCD_DrawPoint(x, y, color)——在指定坐标画一个点中间层LCD_ShowChar(x, y, num, size, mode)——显示一个字符上层LCD_ShowString、LCD_ShowNum、LCD_ShowFloat——显示字符串、数字、浮点数性能瓶颈通常出在最底层。如果是SPI接口的屏每次写显存都要发命令数据逐点操作显然效率很低。这时候一般会加一层“帧缓冲”或者至少是“局部缓冲区”把画点的操作先写到RAM里的显存映射上最后一次刷到屏幕。但不是说每次都要全屏缓冲有些资源紧张的MCU可能就几百字节RAM全屏缓冲根本不现实。折中方案是“行缓冲”一次处理一行像素逐行刷到屏上。尤其显示字符这种操作它的点阵本来就是按行组织的配合行缓冲改动最小。实测下来同样是8x16字符的界面刷新加了局部缓冲之后刷屏速度能提升好几倍而且字符边缘不再有闪烁感。这个优化性价比极高强烈建议在画点密集的项目里优先做。4.2 行列位置动态计算如何让光标“算”得更准很多界面需求不只是显示一串固定字符而是要动态刷新数值比如温度传感器读数、倒计时数字。这种场景最忌讳直接把新数值覆盖上去因为旧数字的残影会残留。比较好的做法是把数值区域当作一个固定宽度的“框”。显示数字前先用背景色填充这个框再显示新数字。这其实是对LCD_ShowChar的高层复用#define NUM_X 60 #define NUM_Y 40 #define NUM_WIDTH 4 // 预留4个数字位 void RefreshValue(int val) { LCD_Fill(NUM_X, NUM_Y, NUM_X NUM_WIDTH * 8 - 1, NUM_Y 16 - 1, BLACK); LCD_ShowInt(NUM_X, NUM_Y, val, 16, 0); }这里有个细节预留区域的宽度必须根据字号来计算。8x16字体每个数字宽度是8像素4位数就是32像素所以填充区域x方向是NUM_X到NUM_X 31。如果算窄了刷新完最右边还会露出旧数字的一个角特别丑。坐标“算得准”本质上就是对字体尺寸、显示位数、对齐方式这些要素做到心里有数。后续做居中、右对齐显示时这种计算能力更是必需品。4.3 从单字符到界面字符串函数如何复用既然LCD_ShowChar是最小单元再往上的字符串函数就顺理成章了。典型的字符串实现是void LCD_ShowString(u16 x, u16 y, u16 width, u16 height, u8 size, u8 *p, u8 mode) { while (*p ! \0) { if (x width - size / 2) { // 换行处理 x 0; y size; } if (y height - size) { // 超出屏幕范围不再继续显示 break; } LCD_ShowChar(x, y, *p, size, mode); x size / 2; p; } }上面的x size / 2对于8x16字体就是每次x加8个像素。换行判断用的width - size / 2意思是坐标x如果超出显示宽度减去当前字符宽度就折行。这套逻辑看似简单但涉及“越界保护”不加的话超长字符串会把数据写到屏幕之外虽然大多数驱动无非是裁剪掉但有些底层的显存写入会越界直接造成硬件异常。我在做某个仪表盘界面时深有体会页面上的参数说明文字比较多一开始没做越界保护刷新界面偶尔会整屏闪烁。后来加了边界判断显示安全了闪烁的问题也顺带消失。5. 常见问题与排查技巧实录5.1 字符偏左或偏右起始坐标与宽度计算误差现象显示一行相同的字符第一个、第二个位置对的越往后越歪或者最后一个字符被切了一半。这种时候十有八九是步进宽度算错了。排查方法把字符显示循环里的步进值单独打印出来或者用调试器看对照当前size的字体宽度。如果你的字体是8x16步进就应该是8。如果你用的是自定义字体比如7x14那就必须用7做步进而不是拿16或者14当步进。还有一种是取模方向搞反了字符会“躺下”或者“镜像”。遇到这种情况先不要急着调坐标回到取模软件重新生成字库把“逐行/逐列”“高位在前/低位在前”这几个选项换一下通常就能解决。我一次调试某款OLED时字符全部是横躺的解决方案就是把取模方向从“逐行”改成“逐列”问题立即消失。5.2 花屏与残影缓冲区同步与清屏时序现象刷新屏幕上的数字时新的数字和旧的数字叠在一起像长了胡子的脸或者整个屏幕出现随机的噪点。常见的两个原因第一个是显存没有清干净。前面提到的LCD_Fill区域覆盖如果你预留的宽度不足以盖住旧数字残影自然会出现。第二个是SPI写入时序问题主控发送速度过快或者片选信号切换时机不对导致写入过程丢字节屏上就会出现随机乱码。这种问题用示波器抓一下CS、SCLK和MOSI的时序很容易定位。排查步骤建议从软件查起先确认清屏逻辑正确再查显示函数有没有越界。软件没问题再考虑硬件时序一步步来别一上来就动电路。实测经验里七成花屏问题出在显示区域的宽高算错两成出在缓冲区处理只有一成才是硬件时序。5.3 反白显示边界溢出跨行取模的特殊处理现象对一个字符做反白显示字符本身对但周围的背景没有完全反色或者反白区域边缘有毛刺。这通常是区域填充和字模宽度不一致导致的。如果字模实际占了9个像素比如加了字符间距而你填充时只填了8个像素宽那第9列就会露馅。解决办法是让“底填充区域”严格等于“字模占用区域”或者干脆每次反白前把全字符块宽度包含间距一起刷掉。还有种特殊情况如果你的字符设计了左右留白的字模比如为了美观字符“A”左右各空一列像素反白时填充区域就要把这部分留白也覆盖进去否则字符和背景之间会有一道细缝。这个细节在菜单高亮显示时特别明显填得不对整个选中项看起来就不干净。5.4 常见问题速查表现象常见原因解决思路字符乱码或错位字库索引偏移错误检查是否做了num - 偏移字符横向拉伸/倒下取模方向与屏幕扫描方向不匹配更换取模选项改为逐列或逐行数字刷新残影清除区域小于旧数字占用区域按最大位数和字号计算清除区宽度整个屏幕随机雪花SPI时序异常示波器抓时序检查CS与SCLK相位反白区域边缘有杂点背景填充区域和字模区域宽度不一致统一填充区域宽度大字号显示缺上半部分高度计算溢出或字库读取越界检查size对应高度和字库字节数计算写在后面LCD_ShowChar虽然是个函数够小但把它认真吃透对整个LCD驱动乃至嵌入式GUI开发都有扎扎实实的帮助。我自己现在写新屏驱动第一步永远是先把单字符函数调稳因为后面所有花里胡哨的界面全靠它撑底。给正准备自己写驱动或者正在调试显示问题的朋友几个建议字库取模规格要跟函数里的size严格对应别混用调试字符显示时先用一个已知字符比如A、0单点测试不要上来就刷一屏幕遇到显示异常优先怀疑索引计算和步进宽度它们出错的概率远高于硬件。有些坑真得自己踩一遍才会记住。我第一次调反白显示时硬是对着屏幕发了半小时呆后来发现只是背景填充区域少算了一列。这种事没法靠看书学会只能上手磨。你这会儿要是也卡在字符显示上不妨把代码里的坐标、步进、字库索引逐个验一遍问题往往就藏在最不起眼的那一行计算里。