★ FEATURED ARTICLE 嵌入式界面开发里中文字库这件事看起来不起眼但真到落地阶段十个人里有八个会在上面卡上一两天。emWin 这套图形库在工业控制、医疗设备、智能家居面板上用得非常多它的英文显示开箱即用可一旦要显示中文很多人就开始抓瞎要么是一屏乱码要么是编译报内存不足要么是字库烧进去之后屏幕一片空白。这篇内容就是把我这些年反复折腾 emWin 中文字库的经验完整摊开讲一遍从字库的生成、转换、挂载到实际调用每一步都给出可以直接照抄的做法也会把那些文档里不会写的坑一并说清楚。这篇适合谁看如果你手上有一块跑着 emWin 的屏需要显示中文菜单、提示语、参数标签那这篇就是给你准备的。不管你是刚接触 emWin 的新手还是已经用过但总在字库环节翻车的朋友下面的内容都能直接拿去用。核心关键词就三个emWin 中文字库、字库生成、字体挂载围绕这三个词把整条链路走通。1. 先想清楚emWin 显示中文到底难在哪1.1 中文字库和英文字库的本质差异很多人第一次接触 emWin 字库会觉得莫名其妙英文显示好好的加个中文怎么就这么多事。根子在于字符集规模完全不是一个量级。ASCII 可打印字符不到一百个一个 8x16 的点阵字体撑死也就几 KB而常用汉字三千多个每个汉字在 16x16 点阵下就要占 32 字节三千字就是接近 100KB如果上到 24x24 或者带抗锯齿的矢量字体体积直接飙到几百 KB 甚至上 MB。这个体量差异决定了中文字库不可能像英文那样随手塞进代码里必须认真规划存储位置和加载方式。再往深一层说emWin 内部对字符的索引方式是基于编码的。英文用单字节编码一个字节对应一个字符查找直接中文在 GB2312 或 GBK 编码下是双字节UTF-8 下是变长字节emWin 需要知道当前字体是按哪种编码组织的才能正确地把屏幕上的字符串映射到字模数据。这就是为什么你随便找个字库文件丢进去emWin 根本不认——编码对不上它连字模在哪都找不到。1.2 三种主流方案的取舍逻辑实际项目里emWin 显示中文常见三条路各有各的适用场景选错了后面全是麻烦。第一种是内置点阵字库把需要的汉字生成 C 数组直接编进固件。优点是运行时零依赖、查找快、不占外部存储缺点是字库大小直接吃 Flash而且改字就得重新编译。适合汉字集合固定、Flash 充裕的小型项目比如只有几十条固定提示语的设备。第二种是外部存储字库把字库文件放到 SPI Flash、SD 卡或者外部 Nor Flash 里运行时按需读取。优点是字库可以做得很大、支持多字号多字体、后期换字库不用动固件缺点是要写读取接口、要考虑访问速度SPI Flash 随机读延迟在几十微秒级别频繁刷新文本时可能拖慢界面。适合汉字量大、需要多语言或者经常更新文案的产品。第三种是矢量字体用 FreeType 之类的引擎在运行时渲染。优点是任意字号、边缘平滑、体积相对小缺点是对 MCU 算力和 RAM 要求高渲染一屏文字可能吃掉几十毫秒低端芯片根本扛不住。适合有 GPU 或者主频较高的平台。我个人的经验是资源紧张的 MCU 项目优先内置点阵界面复杂、文案多的项目上外部存储只有对显示效果有硬要求且芯片够强才考虑矢量字体。下面主要围绕前两种展开因为这是绝大多数人真正会用的方案。1.3 编码这件事必须先定死在动手生成字库之前有一件事必须先确认你的工程用的是 GBK 还是 UTF-8。这个决定会影响字库生成工具的配置、源码文件的保存格式、以及 emWin 的字符编码设置三者必须一致否则就是乱码。GBK 的好处是每个汉字固定两字节emWin 处理起来简单直接很多老项目和国产屏的默认配置都是 GBKUTF-8 的好处是跨平台、和现代开发工具链兼容好但变长编码在 emWin 里需要额外配置。我的建议是如果项目没有历史包袱统一用 UTF-8如果接手的是老工程别折腾跟着原来的 GBK 走。中途换编码的代价远比想象中大源码文件、字库、显示函数全要跟着改。2. 字库生成从字体文件到 emWin 能认的格式2.1 工具选型与版本匹配emWin 官方提供了一套字体转换工具常见的是 FontCvt 这一类能把 Windows 的 TTF 字体转成 emWin 的 C 文件或者外部字库文件。这里第一个坑就是工具版本要和 emWin 库版本匹配我见过有人用新版工具生成的 C 文件丢进老版本库编译能过但运行时字模解析错位屏幕上全是花屏。稳妥的做法是去你手上 emWin 库的同一发布包里找配套工具别去网上随便下。除了官方工具还有一些第三方的小工具能做点阵字库提取适合只需要固定几个字号、想精细控制每个字模的场景。但第三方工具良莠不齐生成的 C 数组格式不一定符合 emWin 的结构体定义用之前一定要拿几个字验证一下字模数据对不对。2.2 字符集范围怎么圈生成字库时工具会让你选字符集范围这一步直接决定字库体积。全选 GB2312 是六千多个字符全选 GBK 是两万多很多人图省事全勾上结果生成出来几百 KB编译直接爆 Flash。正确的做法是按项目实际用字来圈。先把界面上所有可能出现的文字整理成一份文本清单包括菜单项、提示语、单位符号、参数名然后用工具提供的“从文件导入字符”功能只生成这份清单里出现的字。这样通常能把字库压到几十 KB 甚至十几 KB。如果文案会动态变化比如显示用户输入的内容那就得把常用汉字范围选上一般 GB2312 一级字库三千多字够覆盖 99% 的日常用字。提示整理用字清单时别忘了标点符号和全角字符中文界面里冒号、括号、顿号都是全角的漏了它们运行时显示成方框排查起来很费时间。2.3 字号与点阵的匹配计算字号选择不是拍脑袋要结合屏幕分辨率和显示需求算。假设你的屏是 320x240界面上一行提示语希望占 20 像素高那字库点阵高度至少要 20考虑到行间距选 24x24 比较合适。如果屏是 800x480正文用 16x16 就偏小了24x24 或 32x32 更舒服。这里有个容易忽略的点点阵字体的宽高比。汉字是方块字宽高应该一致但英文字母和数字在同样点阵下会显得瘦长。如果界面中英混排要么接受英文偏窄要么给英文单独配一套字体。我一般会给中文配 24x24英文数字配 16x24 或者直接用 emWin 自带的 ASCII 字体混排效果更自然。字库体积的估算可以这么算单字字节数 点阵宽 × 点阵高 ÷ 8向上取整再乘以字符数量。比如 24x24 点阵单字 72 字节三千字就是 216KB这个数字在选型阶段就要心里有数别等生成完才发现 Flash 不够。2.4 生成 C 文件还是外部 bin工具生成时通常有两种输出C 源文件字模以数组形式存在和二进制字库文件。选哪种取决于你前面定的存储方案。生成 C 文件的话工具会输出一个包含字模数组和字体结构体的 .c 文件直接加进工程编译即可。要注意的是数组要加 const 修饰并放到只读段否则会被加载到 RAM几百 KB 的数组瞬间把 RAM 吃光。很多编译器的默认配置里 const 全局变量是放 Flash 的但有些工程的自定义链接脚本会把它挪到 RAM这一点要检查链接脚本确认。生成 bin 文件的话工具输出的是纯字模数据需要你自己写读取函数通过 emWin 的字体驱动接口把数据喂给它。这种方式灵活但工作量大后面第 4 节会详细讲。3. 把字库挂进 emWin三种挂载方式实操3.1 内置 C 数组的挂载步骤这是最直接的方式。假设工具生成了FontCN24.c里面有一个GUI_FONT结构体叫GUI_FontCN24挂载流程如下。第一步把 .c 文件加入工程确认编译通过。如果报重复定义检查是不是工具生成的字体名和已有字体重名了改个名字即可。第二步在需要显示中文的地方调用GUI_SetFont(GUI_FontCN24);然后正常用GUI_DispString()输出。这里的关键是字符串的编码要和字库编码一致。如果字库是 GBK 生成的源码文件也必须是 GBK 保存字符串字面量才会是 GBK 字节流如果源码是 UTF-8 而字库是 GBK显示出来必然是乱码。第三步验证。先显示一个最简单的“中文测试”如果正常再逐步加长字符串、混入英文数字标点看有没有越界或者缺字。缺字通常表现为方框或者空白说明该字符不在字库里回去补字符重新生成。注意内置数组方式下字库是只读的运行时不能动态加字。如果产品需要显示用户输入的中文比如姓名必须提前把可能用到的字都生成进去或者改用外部字库方案。3.2 外部 Flash 字库的读取接口外部字库的核心是写一个符合 emWin 字体驱动规范的读取回调。emWin 在渲染字符时会调用你注册的函数传入字符编码和要读取的字模缓冲区你负责从外部存储把对应字模读出来。实现上有几个要点。第一字模在外部存储里的布局要固定通常是按编码顺序排列每个字模定长这样可以用“编码偏移 × 单字长度”直接算出地址查找是 O(1) 的。如果字库是变长的比如矢量字体就得建索引表复杂度上一个台阶。第二读取要加缓存。SPI Flash 一次读几十字节也要几十微秒如果每次渲染都直接读滚动列表时会明显卡顿。我的做法是在 RAM 里开一个几十字的 LRU 缓存把最近用过的字模缓存起来命中率能到 90% 以上界面流畅度提升非常明显。第三注意字节序和对齐。外部存储读出来的数据要按字库生成时的字节序解析有些工具生成的是大端有些是小端读的时候要确认。另外 SPI 读取最好按扇区对齐跨扇区读会慢不少。3.3 多字号多字体的管理策略产品做大了往往需要多套字体标题用大号、正文用中号、注释用小号可能还有粗体。这时候如果每套字体都单独写挂载代码维护起来很乱。我的做法是建一个字体管理表把每套字体的名称、字号、编码、存储位置、读取接口都登记进去界面上按名称取字体。这样换字体、加字号只改表不动业务代码。表的结构大概是这样字体名点阵编码存储方式读取接口CN1616x16GBK内置数组无CN2424x24GBK外部FlashFlashReadFontEN168x16ASCII内置数组无实际调用时用GetFontByName(CN24)拿到GUI_FONT指针业务层完全不关心底层怎么存的。这个抽象在项目后期加字号、换字库时能省大量返工。4. 显示环节让中文真正出现在屏幕上4.1 字符串编码转换的实操前面反复强调编码一致但实际项目里经常出现“字库是 GBK、数据来自 UTF-8 协议”的情况比如从串口收到的 JSON 是 UTF-8要显示到 GBK 字库的屏上。这时候必须做转换。转换函数要自己实现或者用现成的库核心是把 UTF-8 的多字节序列解析成 Unicode 码点再查表转成 GBK 双字节。要注意的是转换缓冲区要留够空间UTF-8 一个汉字三字节GBK 两字节转换后长度会变缓冲区按最大可能长度开别按输入长度开。还有一个隐蔽的坑转换失败的处理。遇到 GBK 里没有的字符比如某些生僻字、特殊符号转换函数要返回一个占位符而不是直接崩溃或者输出乱码。我一般用问号或者方框代替至少界面不会花掉。4.2 文本换行与对齐的处理emWin 的GUI_DispString()不会自动换行长文本会直接画出屏幕边界。中文没有空格分词换行比英文更麻烦。常用的做法是用GUI_DispStringInRect()配合GUI_TEXTMODE_WRAP让 emWin 按矩形宽度自动折行。但要注意它对中文的折行是按字符来的不会考虑词语边界可能出现一个词被拆到两行观感一般但功能没问题。如果对排版有要求就得自己算按字库点阵宽度累加超过矩形宽度就换行同时避免标点出现在行首。这个逻辑不难但琐碎建议封装成一个DrawChineseText()函数统一处理别在每个界面里重复写。对齐方面中文界面常用左对齐和居中。居中可以用GUI_GetStringDistX()先算字符串像素宽度再用(矩形宽 - 字符串宽) / 2算起始 x 坐标。注意这个宽度是按当前字体算的切换字体后要重新算。4.3 刷新性能的优化手段中文文本刷新慢是常见抱怨尤其是列表滚动或者参数实时变化时。优化手段有几个层次。最基础的是减少重绘区域用WM_SetInvalidRect()只标记变化的区域别整屏刷新。其次是避免频繁 SetFont字体切换有开销同一段绘制里字体不变就别反复设。再往上是双缓冲emWin 支持内存设备绘图把一屏内容画到内存再一次性刷到屏上能消除闪烁代价是多占一块和屏幕等大的 RAM。如果用了外部字库前面说的字模缓存是性能关键。我实测过一个 240x320 的屏滚动一个二十项的列表不加缓存时每帧要读上百次 Flash帧率掉到十几加了 64 字的缓存后命中率九成以上帧率回到四十多肉眼已经感觉不到卡。5. 踩坑实录那些文档不会告诉你的问题5.1 乱码问题的排查顺序乱码是最高频的问题排查要有顺序别瞎试。我的固定流程是先确认源码文件编码。用编辑器看文件是 GBK 还是 UTF-8和字库编码比对。再确认字库编码。看生成工具里选的字符集是 GB2312、GBK 还是 Unicode。然后确认 emWin 的编码配置。有些版本的库有全局编码设置要和字库一致。最后用单字验证。显示一个“中”字如果单字正常说明编码链路通问题在多字节处理如果单字就乱问题在字库本身或者挂载。这个顺序能覆盖九成的乱码场景比盲目改代码高效得多。5.2 内存不足与编译报错的应对内置大字号字库最常见的报错是“region overflow”或者“section too large”本质是字库数组超出了链接脚本给该段分配的空间。解决办法有三条一是缩小字符集只保留实际用字二是降低点阵24 改 16 能省一半多三是把字库挪到外部存储彻底不占内部 Flash。还有一种隐蔽情况是字库数组没加 const 被放进了 RAM编译能过但运行时初始化失败或者 RAM 不够。检查 map 文件里字库符号落在哪个段确认在只读段就对了。5.3 显示缺字与方框的定位缺字表现为方框或者空白原因通常是字符不在字库里。定位方法是把出问题的字符单独拿出来用工具查它的编码再在字库的字符列表里搜搜不到就是没生成。补字重新生成即可。还有一种情况是字符在字库里但显示错位字模数据对不上。这多半是字库生成时的点阵参数和 emWin 字体结构体里声明的不一致比如结构体写 24x24 但实际数据是 16x16检查生成配置和结构体定义是否吻合。5.4 常见问题速查表现象可能原因排查动作全屏乱码编码不一致核对源码、字库、库配置三者编码部分字显示方框字符未生成查编码补字符重新生成字模错位花屏点阵参数不匹配核对结构体声明与生成配置编译 region overflow字库超 Flash 段缩字符集、降点阵或改外部存储运行时 RAM 不足字库未加 const检查 map 文件段归属滚动卡顿外部字库无缓存加字模 LRU 缓存长文本出屏未做换行用 InRect 或自写折行6. 几个提升效率的实操心得6.1 建立可复用的字库生成脚本每次改文案都要手动开工具、选字符、生成、替换文件重复劳动很烦。我的做法是把字符清单维护成一个文本文件写个脚本调用工具的批处理接口一键生成并自动拷贝到工程目录。工具一般支持命令行参数把字符集文件、点阵、输出路径传进去就行。这样文案变更时改清单、跑脚本、编译三步搞定不会漏字也不会用错版本。6.2 字库版本与固件版本绑定字库和固件是强耦合的字库换了固件没跟上或者反过来都会出问题。我在工程里给字库文件加版本号固件启动时校验字库版本不匹配就报错提示。这个机制在多人协作或者产线烧录时特别有用能避免“为什么这台设备显示正常那台乱码”的扯皮。6.3 预留字符余量产品迭代时文案总会加字如果字库卡得刚刚好每次加字都要重新生成、重新评估 Flash 占用。我的习惯是生成时在清单基础上多留 10% 到 20% 的常用字余量Flash 多占几 KB 换来后期改动的从容很划算。当然余量也别留太多否则又回到体积失控的老路。6.4 用模拟器先验证再上板emWin 有 PC 端的模拟器字库和显示逻辑可以现在模拟器上跑通确认编码、挂载、换行、对齐都正常再烧到板子上。模拟器调试比上板快得多不用反复烧录尤其是排查乱码这种编码问题模拟器里改一下重新编译几秒钟的事。我现在的习惯是任何字库改动都先在模拟器验证上板基本一次过。这套流程走下来emWin 中文字库这件事其实没那么玄乎核心就是把编码、存储、挂载、显示四个环节的对应关系理清楚每一步都验证到位。真正花时间的往往不是技术本身而是那些编码不一致、参数不匹配的细节把上面这些坑提前避开一天的工作量能压到两三个小时。
阅读完成 · 觉得有帮助？
