字体显示驱动概述
做嵌入式开发这些年，我接触过不少显示相关的项目。从最早的单色LCD屏，到后来的彩色TFT，再到现在的智能屏，字体显示始终是个绕不开的话题。说白了，不管你的界面多炫酷，用户第一眼看到的还是那些文字。
字体驱动是什么？我个人的理解是：它是一套让硬件把字符“画”出来的软件层。你敲个'A'，屏幕上就该出现一个'A'。这中间涉及字符编码、字形提取、像素渲染、显存搬运……每一步都可能踩坑。
字体在嵌入式系统中的作用
你想想看，一个嵌入式设备如果没有字体显示能力，会是什么样子？
- 菜单只能靠图标猜
- 调试信息没法看
- 用户交互基本归零
字体显示直接决定了产品的可用性和专业感。我在做工业手持终端时遇到过一件事：客户反馈设备“显示乱码”。查了两天，最后发现是字库文件在烧录时被截断了。从那以后，我每次做字体驱动都会加一道CRC校验。
核心观点：字体驱动不是“能显示就行”，它关乎产品的稳定性、响应速度和用户体验。一个成熟的字体驱动层，应该做到“上层调用简单，底层适配灵活”。
常见字体格式介绍
嵌入式领域常见的字体格式，主要分两大类：点阵字体和矢量字体。它们各有各的脾气。
点阵字体
点阵字体，说白了就是用像素点拼出字符。每个字符对应一张位图，比如16×16的点阵，就是256个像素点。
优点很明显：
- 渲染速度快——直接拷贝位图就行
- 实现简单——不需要复杂的数学计算
- 占用资源少——适合MCU这类小内存设备
缺点也很突出：
- 放大后锯齿严重
- 每种字号需要单独一套字库
- 不支持旋转、倾斜等变换
我记得刚入行时，用8×8点阵在12864屏上显示英文菜单。那时候觉得挺酷的，现在回头看，那锯齿简直能割手。
经验之谈：如果你的产品只需要显示固定大小的数字和字母（比如电子秤、计算器），点阵字体是最省心的选择。但如果是中文界面，建议至少用16×16点阵，否则笔画会糊成一团。
矢量字体
矢量字体用数学曲线来描述字形轮廓。常见的格式有TrueType（.ttf）、OpenType（.otf）等。
它的优势：
- 任意缩放不失真
- 一套字库覆盖所有字号
- 支持加粗、斜体、旋转等效果
代价呢？
- 渲染需要解析轮廓、填充像素，计算量大
- 需要浮点运算或高效的定点数库
- 字库文件体积大，一个.ttf动辄几MB
我曾经在一个Cortex-M4项目上移植FreeType，结果发现渲染一个汉字要几十毫秒。后来改用预渲染缓存，才把速度提上来。嗯，这里要注意：矢量字体在嵌入式上不能直接“裸用”，必须做缓存和优化。
| 对比项 | 点阵字体 | 矢量字体 |
|---|---|---|
| 渲染速度 | 极快（位图拷贝） | 较慢（需解析轮廓） |
| 内存占用 | 低（每字号独立） | 高（字库文件大） |
| 缩放质量 | 差（锯齿明显） | 好（平滑缩放） |
| 实现复杂度 | 简单 | 复杂 |
| 适用场景 | 小屏、固定字号 | 大屏、多字号需求 |
避坑指南：我曾经在一个项目里直接用了Windows上的宋体.ttf，结果设备上电后显示全是方块。原因很简单——嵌入式系统没有对应的字符编码映射表。矢量字体驱动必须处理好Unicode到字形索引的转换，否则再漂亮的字体也是白搭。
字体驱动在系统中的位置
为了让你更直观地理解字体驱动在整个显示链路中的角色，我画了一张图：
从这张图可以看得很清楚：字体驱动层是连接应用和硬件的桥梁。它接收应用层传来的字符编码，从字库中提取字形数据，经过渲染后交给显示驱动去刷屏。
我习惯把字体驱动拆成四个模块：
- 编码解析——处理UTF-8、GB2312等编码
- 字形提取——从字库文件中找到对应字符的轮廓或位图
- 像素渲染——把字形数据转换成显存中的像素点
- 缓存管理——缓存常用字符，避免重复渲染
这四个模块，任何一个出问题，屏幕上都会“翻车”。
总结一下：字体驱动不是简单的“读字库→写显存”。它涉及编码、存储、渲染、性能优化等多个维度。选点阵还是矢量，取决于你的硬件资源、显示需求和开发周期。没有银弹，只有权衡。
这一章我们先把概念理清楚。后面我会带你一步步搭建一个完整的字体驱动框架，从点阵开始，再到矢量，最后做一个混合方案。你准备好了吗？