OLED中文乱码全解析：取模、编码与驱动避坑指南

搞嵌入式显示的人几乎都绕不过OLED这块屏。尤其是0.96寸的SSD1306价格便宜、驱动简单、效果又亮项目里做个状态显示、做个交互菜单、甚至拿来做充电桩显示UI都是常见操作。但一到显示中文就总有人卡壳英文字母好好的汉字要么是一团莫名其妙的方块要么完全乱掉要么显示出来是倒的、反的翻遍教程也不知道哪里出了问题。我调这类问题少说也有几年了今天把这套东西从头到尾捋一遍从取模工具的参数设置到编码匹配再到HAL库驱动代码的写法一次性说清楚。这篇文章适合刚接触OLED的嵌入式爱好者也适合正在做量产项目、被显示问题折磨的开发人员。中文乱码的坑其实就藏在“取模—编码—显示”这条链路里把每一环的原理弄明白乱码自然就消失了。1. 乱码根源从OLED点阵显示原理说起1.1 一块OLED屏幕是怎么把字“画”出来的要想搞清楚中文为什么会乱码得先弄明白OLED屏幕显示一个像素点需要经过什么流程。以最常用的0.96寸SSD1306驱动为例屏幕分辨率是128x64也就是一共128列、64行像素。这块屏幕内部有一块1KB的显存GDDRAM屏幕上的每一个点都和显存里的某一位对应。关键点在于SSD1306的显存不是按“行”顺序排列的而是按“页Page”来组织的。64行像素被分成8页每页正好8行。每一页里有128个字节对应128列。往某一页的某个字节里写一个数据这个字节的8个bit就决定了对应那一列的8个像素是亮还是灭。所以从软件角度看屏幕更像是一张“竖着扫描”的纸先画第0页的最上面8行再往下画第1页的8行。这就是为什么显示英文字母简单、显中文容易出问题。英文字母高度小一般用8x16或者6x12的点阵一个字符一两行像素就能装下。而汉字至少需要16x16的点阵才能看得清楚也就是要占2页高度、16列宽度总共32个字节的数据。数据量大了以后取模方式、字节顺序、写入方向任何一个地方没对齐显示出来的东西就会和预期完全不一样。1.2 中文乱码的本质像素数据和预期不一致很多人一看到屏幕乱码第一反应是屏幕坏了、驱动不对、甚至连屏都换了。其实屏幕本身几乎不会坏乱码的本质只有一个你写进显存的数据组合不是你期望的那个汉字的点阵数据。具体拆开看有三种最常见的“数据不对”第一种是取模方向不对。字模工具里明明看着是个完整的“中”字但是生成数据时是按“逐行式”取的驱动代码却按“逐列式”往显存里写。结果每个字节对应的像素位置全错位汉字在屏幕上就变成了一堆横竖条纹交织的乱码。第二种是编码不对。代码里的字符串和字模数据的索引对不上。汉字在取模工具里是按GB2312编码查到的但你的源文件是UTF-8编码编译后字符串常量的字节序列完全变了自然查不到正确的字模。第三种是数据组织和显存布局不匹配。比如字模数组定义小了读取越界或者坐标设置超出128x64范围数据写到屏幕外面去了。这类问题表面上看也是乱码实际是内存访问错误。记住这句话乱码不是“屏幕看不懂汉字”而是“屏幕收到的像素数据不是汉字该有的样子”。想通这一点排查问题的思路就清楚了。1.3 为什么英文正常、中文乱码这个问题被问得最多。英文显示正常说明I2C通信、驱动初始化、显存刷新这些底层功能都是好的为什么唯独中文有问题因为英文和中文走的是两套完全不同的数据体系。英文一共就95个可见字符代码里通常内置一张ASCII字模表比如0x41就对应字母A的点阵所有字符的索引是固定的、全世界统一的。取模工具做英文字模时大家用的参数也基本一致所以英文很难乱。汉字不一样。汉字有几千个常用字字模表需要自己做。做字模时要指定编码GB2312还是GBK甚至UTF-8、指定点阵大小12x12还是16x16、指定取模方向这套字模表还得和驱动代码里的索引方式完全匹配。只要某一环约定不一致英文正常、中文乱码就是必然结果。2. 取模环节90%乱码问题的源头在这里2.1 取模软件选型做OLED字模社区里最常用的就是PCtoLCD2002和Image2Lcd这类小工具体积小、免费、操作直观配合汉字输入就能直接生成点阵数组。做中文字模、ASCII字模我一般都开PCtoLCD2002处理图片、做成动画帧数组用Image2Lcd。这里要特别提醒一句不同版本的取模工具、同一个工具里不同的选项组合生成的数据结构天差地别。很多人在网上找到一段教程里的字模复制过来用发现是乱的就是因为教程用的取模参数跟你用的不一样。字模数据本身没有“绝对正确”只有“和驱动代码约定一致”才是关键。所以我强烈建议项目一开始就把“取模参数规范”定下来写成文档后面所有字模都用同一套参数生成。2.2 关键参数逐项解读别再凭感觉选了打开PCtoLCD2002的取模设置会看到一串选项每一项都影响最终生成的数据排列。我逐项说清楚这是避坑的核心。阴码/阳码这个决定了“1”代表亮还是“0”代表亮。阳码就是1亮0灭生成的数据直观我习惯用阳码。阴码则是0亮1灭显示效果正好反色。如果你在驱动里直接写显存数据用了和取模相反的极性文字就会变成“黑底白字”的负片效果。取模走向扫描方向这是最重要的选项也是最容易出错的选项。常见的有逐行式和逐列式。SSD1306显存是纵向8位一组的布局所以我推荐用“逐列式”也叫“列行式”。取出来的数据一列一列排列正好可以直接按页写入显存。如果用了逐行式取模就需要在驱动里做数据转置很多新手就是在这步败下阵来。顺向/逆向决定了同一行或同一列的字节是从高位开始还是从低位开始。菜单里通常叫“顺向”和“逆向”对应MSB First和LSB First。这个参数必须和驱动里送数据的位顺序一致否则字符会变成镜像效果。每行/每列显示数常见的有“每行8个点”和“每行16个点”等选项对应的是取模的宽度一般结合点阵大小来选。16x16的汉字按逐列式取模通常是每列8个点、共16列生成32字节或者每列16个点、共16列生成32字节两种显示效果一样但数据结构不同。我喜欢用“每行16点”的取模方式这样两列之间的边界更清晰。为了便于对照我把常用参数组合和对应的显示效果列成一张表取模参数形成的数据排列直接按页写入显存的效果逐行式 顺向数据按行排列出现“躺倒”或散乱效果需要用转置算法逐列式 顺向数据按列排列页内字节与显存对应正常显示逐列式 逆向列内位序颠倒左右镜像或上下颠倒阴码0亮1灭反色显示我在自己的项目里固定了一套组合阳码、逐列式、顺向、16x16点阵。所有驱动代码都按这套约定写几年下来没再因为取模参数出过乱码。2.3 中文字库选择16x16还是12x12中文字模最常用的是16x16点阵一个汉字32字节显示效果接近印刷体辨识度高。缺点是占存储空间如果显示几百个汉字字库数组会很大一般放在片内Flash或者外部存储里不能塞进RAM。12x12点阵的字模一个汉字18字节左右显示小字号的场景能省不少空间但笔画多的时候容易糊成一团观感远不如16x16。还有一种14x14的中间选择但应用不多。我的建议是屏幕是0.96寸这种小屏优先用16x16显示效果最稳妥。如果确实要做多级菜单又想紧凑可以16x16汉字配8x16的ASCII一行放8个汉字加若干英文字符信息量完全够用。字模数据多了以后记得在工程里分文件管理比如font.h放ASCII字模hz.h放汉字字模别堆在一个文件里。2.4 取模参数与驱动不匹配时的几种乱码现象很多读者问我怎么看出来到底是哪个参数不匹配我根据经验总结了一下对号入座就行文字整体旋转了90度大概率是取模走向用成了逐行式而你按逐列式去写显存反过来也一样取模和写入方向不一致。文字左右镜像取模顺向/逆向和驱动位序不一致。比如取模用了“逆向了”驱动还按MSB先送镜像就出来了。文字反色阴码/阳码设置相反。处理办法是取模参数改一下或者在驱动里对每个字节取反。文字像“切碎”了一样上半部分在左边、下半部分在右边这是页地址计算出了问题写位置时y坐标对应错了页。16x16字要占两页第二页的起始地址没设置对。整个屏幕全是乱麻条纹这种情况往往是数组越界驱动读字模数据时读到了空白区域或者地址指针偏移错误。把这些现象和原因对应起来排查效率会高很多。不要一乱码就反复初始化屏幕那是浪费时间。3. 编码问题你代码里的汉字和字库对上号了吗3.1 GB2312/GBK与UTF-8的恩怨取模工具生成字模时会在内部把汉字转成对应编码然后根据编码去点阵字库里查出字形数据。而驱动代码里查找字模的方式和汉字在源码中的编码形式强相关。这里潜伏着一个巨大的坑编译器、编辑器和取模工具各自的编码可能不一致。最典型的场景是你从网上复制了一段OLED中文显示的代码源文件是UTF-8编码里面有一行OLED_ShowString(你好)。你的取模工具却按GB2312编码生成字模建立索引时用的是GBK内码。UTF-8编码的“你”是三个字节GBK编码的“你”是两个字节索引对不上显示出来自然是一堆乱码。STM32的Keil工程默认源文件编码通常是GB2312/GBK而很多现代编辑器、VSCode默认是UTF-8两边一碰就出问题。所以关键在于统一编码而不是纠结哪种编码“更好”。我的做法是把工程里所有源文件统一设为GB2312/GBK编码取模工具也用GB2312这样字符串常量和字模索引天然对齐。如果你更习惯UTF-8那就全部转成UTF-8然后在代码里自己处理汉字到GB2312内码的转换多一层麻烦但不难。怕的是一会儿这个文件GBK、那个文件UTF-8最后排查到怀疑人生。3.2 获取汉字内码的几种方式在做字模索引时有时需要直接操作汉字内码。比如你自己写一个简易的字库管理程序根据汉字内码计算它在字模数组中的位置。这种情况常见于字库文件比较大、不方便预生成索引表的时候。获取汉字GB2312/GBK内码有几种办法用Notepad打开文本文件选择十六进制查看就能看到“中”字的GBK编码是D6 D0UTF-8编码是E4 B8 AD。用在线编码查询工具查“汉字内码”也能得到类似信息。如果自己写程序更常用的方法是利用C语言的字符串在GBK编码下中在内存里就是两个字节0xD6和0xD0。如果你想手动计算GB2312编码有个固定的公式先查出汉字所在的区和位比如“中”字在GB2312里的区位是54-48那它的内码高位是区号0xA0也就是0xD6低位是位号0xA0也就是0xD0组合起来就是0xD6D0。这个算法在很多字库管理工具里都在用理解它有助于排查字库索引问题。3.3 源码文件编码导致的“假乱码”有一种乱码屏幕显示本身没问题问题出在源代码层面。比如你打开一个工程发现代码里的中文字符串显示成“涓€娈电爜”或者“鍝堝搱”这就是典型的编码错位文件在保存时是GBK编码而编辑器用UTF-8去解释或者反过来。这种“假乱码”会让新手非常困惑因为代码里的汉字常量已经面目全非存进内存的字节序列自然也是错的屏幕端跟着乱。排查方法很简单看编辑器右下角的编码标识把文件另存为当前工程统一的编码格式。Keil里可以在Edit-Configuration-Editor-Encoding里设置默认编码VSCode里可以通过“重新打开文件时选择编码”来调整。我见过一个项目程序烧进去之后OLED全屏雪花排查到最后发现是main.c被一个在线编辑器改成了UTF-8而里面其他源文件全是GBK字符串全都错位了。恢复编码之后屏幕立刻正常。所以遇到乱码先分清是“屏幕乱码”还是“源码乱码”别一上来就怀疑屏幕和驱动。4. 完整实操HAL库驱动OLED显示中文4.1 硬件连接与工程准备先说硬件我用的是STM32的HAL库配合0.96寸I2C接口的SSD1306屏接线只有四根VCC、GND、SCL、SDA。大多数模块板载了电平转换和上拉电阻直接和单片机的3.3V引脚相连没问题。如果是自己画的板子SCL和SDA一定要加上拉电阻4.7kΩ到VCC没有上拉的话I2C通信会时好时坏屏幕偶尔点亮偶尔黑屏这个坑很多人踩过。在CubeMX里配置I2C1速率我一般选100kHz。虽然SSD1306手册上说支持400kHz但在实际项目中尤其是带长线缆的时候把速率降下来能少很多麻烦。400kHz在实验室桌面环境可能没问题到了现场环境、线缆一长就容易出现通信错误。I2C设备的地址默认是0x3C7位地址部分模块是0x3D拿到新模块先用I2C扫描程序确认地址别上来就写死。工程组织上我推荐把驱动代码拆成两个文件oled.c和oled.h负责SSD1306底层驱动初始化、清屏、坐标设置、画点、显示字符font.h放ASCII字模hz.h放16x16汉字字模。这样代码清晰后期加字、换屏都方便。4.2 SSD1306必要的初始化命令SSD1306的初始化命令序列比较固定网上流传的版本大多能工作但我建议至少包含以下几项关键配置关闭显示、设置显示时钟分频和振荡器频率、设置多路复用率0x3F对应64行、设置显示偏移0x00、设置显示起始行0x00、设置段重映射0xA1让左右显示不镜像、设置COM扫描方向0xC8上下不颠倒、设置COM引脚硬件配置0x12、设置对比度0x7F左右、设置预充电周期0xF1、设置VCOMH电压0x40、开启内部升压、开启显示。值得强调的是段重映射和COM扫描方向这两条命令。如果初始化时省略了它们或者参数设置反了整个屏幕会左右镜像和上下颠倒。很多“中文倒着显示”的问题根本不是字模方向而是初始化命令里这两条配置不对。验证方法很简单清屏后显示一个全屏边框看看四边是否居中整齐如果边框显示不完整优先检查这两条命令。4.3 显示一个中文字符的完整逻辑底层驱动准备好以后显示一个16x16汉字的核心逻辑其实很简洁。我直接给出关键代码并解释每一步在干什么。首先驱动里要有最基础的单字节写函数。在HAL库环境下I2C写SSD1306的格式是先发送控制字节再发送数据。控制字节0x00表示后续是命令0x40表示后续是显存数据。void OLED_WriteCmd(uint8_t cmd) { uint8_t buf[2] {0x00, cmd}; HAL_I2C_Master_Transmit(hi2c1, 0x3C 1, buf, 2, 100); } void OLED_WriteData(uint8_t data) { uint8_t buf[2] {0x40, data}; HAL_I2C_Master_Transmit(hi2c1, 0x3C 1, buf, 2, 100); }然后是设置坐标。SSD1306的显存是页地址模式时要分别指定页地址和列地址。我的驱动里坐标x、y的语义是x表示列位置0~127y表示页位置0~7一页对应8个像素高。这样理解起来直接。void OLED_SetPos(uint8_t x, uint8_t y) { OLED_WriteCmd(0xB0 y); // 设置页地址 OLED_WriteCmd(x 0x0F); // 列地址低4位 OLED_WriteCmd(0x10 | (x 4)); // 列地址高4位 }显示一个16x16汉字时因为汉字高16像素所以会占用连续两页。字模数据按“逐列式、每列8点”的方式排列那么列方向就是按16列排列每列2个字节。写入顺序是先写第0页的16个字节再写第1页的16个字节。void OLED_ShowChinese(uint8_t x, uint8_t y, uint8_t index) { uint8_t i; OLED_SetPos(x, y); for (i 0; i 16; i) { OLED_WriteData(HZ_Data[index][i]); } OLED_SetPos(x, y 1); for (i 16; i 32; i) { OLED_WriteData(HZ_Data[index][i]); } }这里的HZ_Data就是字模数组每一行对应一个汉字的32字节数据。index是汉字的编号。这样写的好处是显示汉字不需要解析字符串编码只需要一个数字索引彻底绕开了编码混乱的问题。4.4 显示字符串ASCII与中文混排实际项目中几乎不可能只显示汉字通常是“电压12.5V”这样的混合内容。我的做法是把ASCII和中文分开处理ASCII用8x16字模一个字符占8列宽中文用16x16字模一个汉字占16列宽。这样中文正好占两个ASCII字符的宽度排版非常整齐。调用时可以先判断字符范围ASCII走英文显示函数汉字部分用一个单独的编号表管理。比如界面里要显示“温度”就在代码里显式地用两个编号OLED_ShowChinese(0, 0, HZ_TEMP); // “温” OLED_ShowChinese(16, 0, HZ_DU); // “度”虽然看起来比直接写字符串麻烦但稳定性极高既不用管源文件编码也不用担心编译器优化出幺蛾子。在要求快速上手的演示项目里这是最省心的方案。如果确实想用字符串方式比如在代码里写OLED_ShowString(0, 0, 你好)那就必须保证源文件和字模索引编码一致并且有一个从字符串到字模编号的转换函数。这种方案更灵活但对编码管理要求高新手容易踩坑。4.5 性能与内存优化建议几个在实际项目中经常遇到的问题提早规划能省不少事。字模数组一定要定义为const类型让它存放在Flash而不是RAM里。一个16x16汉字32字节显示500个汉字就是16KB如果全塞进RAM小容量单片机直接内存溢出。const修饰后编译时会自动分配到FlashRAM占用几乎清零。频繁刷新整个屏幕会导致明显的闪烁和I2C总线占用。要求流畅的场景比如充电桩充电百分比的实时刷新可以建一个1KB的帧缓冲数组先把所有要显示的内容画在帧缓冲里再一次性刷新到屏幕这样能做到不闪烁。代价是多占1KB RAM换来的体验提升很值。I2C传输函数建议加上超时判断并且在通信失败时做错误处理。屏幕在量产设备上偶尔出现黑屏很多时候是I2C总线被干扰或者卡死重试机制能显著提高稳定性。5. 扩展场景图片、动画与UI显示中的“隐性乱码”5.1 用Image2Lcd把图片变成数组除了文字OLED还经常用来显示logo、图标甚至做动画。图片转数组我用的是Image2Lcd。生成数据前有几个参数必须确认输出类型选“C语言数组”最大宽度和高度按屏幕来128x64灰度选“单色”你要是选了RGB565之类出来的数据完全没法直接用。图片显示成乱码或者花屏最常见的原因是取模方向和显存布局不一致。Image2Lcd里有一个“自下而上”还是“自上而下”的选项对应不同屏幕的扫描顺序。SSD1306的显存是按页从上往下扫描的一般选“自上而下”生成的数据可以直接按页写。方向选错图片会上下颠倒或者变成镜像。小技巧做logo之前先把原图缩放成128x64或者64x64这种整数倍尺寸再转单色最后在电脑上预览一下效果。如果肉眼看着都糊上屏也不会好到哪去。5.2 动画实现的帧缓冲思路OLED做动画网上搜“动态图取模软件”能找到不少工具原理都是一帧一帧图片取模生成数据然后在单片机里定时切换显示。我实际做过的项目里动画主要分两种一种是简单帧动画比如充电桩屏幕上的充电图标用一个转圈的圆弧表示充电中。这种动画每帧数据量不大可以把几帧数据直接存成const数组用一个定时器中断周期性切换显示的帧索引到了最后一帧再回到第一帧看起来就是动画了。另一种是复杂进度条或者波形图需要动态生成画面。这种情况直接在RAM里维护帧缓冲把要画的点写进缓冲数组然后整帧刷新。动态绘制时要注意写入越界帧缓冲是128字节一页共8页总共1024字节操作时把x、y范围检查好否则写到缓冲区外面轻则画面错乱重则系统崩溃。动画帧与帧之间不需要每次都整屏清屏再重画那样闪得厉害。正确做法是把变化的区域重绘比如转圈动画只更新圆弧那些像素列其余区域不动画面会流畅很多。5.3 充电桩等工业UI场景的注意点充电桩显示UI是OLED很典型的工业应用场景。这种设备和实验室环境最大的区别在于工作温度范围大、电磁干扰强、线缆可能较长。这些因素会直接影响显示稳定性很多在现场偶发的乱码、黑屏根源都在这里。I2C总线在长线缆和强干扰下容易出错。我处理充电桩项目时把I2C速率从400kHz降到100kHzSCL和SDA线上各加一个10pF左右的滤波电容屏幕供电端并联一个100uF电解电容和0.1uF瓷片电容实测下来通信错误率明显下降。如果是新设计建议直接选SPI接口的OLED抗干扰能力比I2C强不少。多页面UI的显示建议在底层维护一个“脏矩形”机制哪个区域的显示内容变了就只更新哪个区域。比如充电电压变了只刷新数字显示那块不要整屏刷新。这样既省I2C带宽也能减少闪烁对用户体验提升很明显。另外工业场景很多需要调节亮度SSD1306支持设置对比度我用它来根据环境光切换显示亮度效果很好。6. 排错实战乱码问题定位速查表6.1 “中文乱码”现象对照速查表把常见的“中文乱码”现象和对应的根因整理成一张表调试时可以对号入座。现象可能原因排查方向汉字显示成“黑底白字”阴码/阳码反了检查取模参数或在驱动中对字节取反文字整体躺倒90度取模走向和写入方向不一致改用逐列式取模或增加转置算法文字左右镜像顺向/逆向参数不一致检查取模位序和驱动送数顺序文字上下颠倒SSD1306初始化扫描方向配置错误检查段重映射、COM扫描方向命令汉字被拆成两半页地址计算错误16x16字检查是否同时对连续两页写入部分汉字显示成空白或错字字模索引越界或编码不匹配核对字符串编码与字模索引顺序整个屏全是乱麻条纹数组越界或读字模地址错乱检查取模数组大小和读取逻辑我在调试时习惯写一个OLED_Test()函数里面依次执行全屏点亮、全屏熄灭、画十字边框、按已知正确字模显示固定的“测试”两个字。这个函数放到上电初始化最后如果这几项都正常再跑业务代码能快速把问题范围缩小到驱动之外。6.2 0.96寸“批量点不亮”排查清单“OLED 0.96批量点不亮”是很多批量生产项目会遇到的问题。明明是同一批模块有的亮有的不亮这时候先不要怀疑屏幕质量按顺序排查先看供电。用万用表量模块VCC对GND电压很多“点不亮”其实是供电不足尤其是用LDO供电的板子OLED瞬间电流一大电压就跌了。再看I2C地址。我遇到过同一个批次模块地址不一致的情况写死0x3C会有一部分模块无法应答。看复位时序。SSD1306的RESET引脚如果悬空或者上电复位太慢初始化有可能失败。看焊接。批量中偶尔几块虚焊非常正常重点检查SDA、SCL引脚。最后用示波器看波形确认SDA SCL上确实有信号且幅度在芯片高电平阈值以上。还有一种常见情况是模块本身板载了3.3V稳压和电平转换但实际工作电流偏大多块并联在同一个3.3V电源上电源纹波过大导致初始化时序不稳定。给每一块模块的电源加滤波电容或者分组供电能解决很多“偶发不亮”。6.3 别把串口乱码、文件乱码和OLED乱码混为一谈搜索“乱码”相关问题时你一定会看到大量串口乱码、Linux解压文件乱码、VSCode中文显示乱码的帖子。这些问题的排查思路和OLED乱码完全不同不要生搬硬套。串口乱码大概率是波特率不匹配、校验位不对、或者发送端和接收端的字符编码不一致。Linux解压文件乱码通常是文件名编码格式问题要用convmv之类工具转换。VSCode中文显示乱码多半是文件编码识别错误切换一下编辑器的编码重新加载就好。OLED显示乱码的核心永远在显存数据和字模数据是否一致链路是“取模参数—编码匹配—显存写入”和终端显示、文件编码是两码事。6.4 独家避坑经验总结最后分享几条反复踩坑后总结出来的经验都是常规文档里不会写的东西。第一项目初始就把取模参数规范写死并在代码注释里标明“字模取模参数阳码/逐列式/顺向/16x16”。这样即使几个星期后再打开工程或者同事接手也不会因为改了取模参数导致莫名其妙乱码。第二字模数据尽量用工具一键生成不要手工改。手工增删一个字节导致整个字模数组错位的情况我见得太多了。需要加字时重新用同一套参数生成并追加到数组尾部。第三验证字模正确性时不要只看一个汉字。汉字中“永”字笔画结构全是检验字模的好样本再配合“龘”这类复杂字能检验16x16点阵的极限密度。字模库做好之后用一屏把所有汉字循环显示一遍确认每个字都正常。第四批量生产前把“上电自检显示图案”固化到固件里用一张确定图案验证屏幕接线和初始化能省去大量现场排查时间。我做了这几年显示相关的项目最深的感觉是中文字符乱码本质上不是技术难题而是“约定”问题。取模工具、驱动代码、源码编码只要三方约定统一乱码就无机可乘。反过来只要有一方“自由发挥”显示必定出妖蛾子。定好规范、写好自检函数这套流程跑顺之后OLED显示中文字符会和显示一个字母一样轻松。最后再分享一个小技巧我习惯在菜单里加一个“关于”页面把所有字模库里的汉字循环滚动显示一遍平时看着像彩蛋实际上它就是我验证字模完整性的专用工具。