1.本文目的
做嵌入式图形开发，我们往往都会利用到各种GUI进行交互设计，但是对于GUI的字符串处理与中文字库显示，也许并不会特别关注，因为GUI已经帮助我们封装了一些通用的API，在调用相对应的API就可以显示想要的图像和字符串了。那么这些底层原理到底是什么呢？
正好和朋友讨论，我们做嵌入式开发都是将输出信息定位到串口，那能不能定位到I2C、SPI、网络等各种协议上去呢？这个确实是有意思的事情，那正好手上有个树莓派，可以通过DSI或者HDMI来显示，那就把rt-thread的console重定位到LCD上去吧，让树莓派的屏幕代替我们的串口调试助手控制台，这样就不用接上串口看输出信息了。
有了这个想法，于是立即付诸行动。需求很明确，开发平台也已经确定，树莓派4+HDMI屏（分辨率1280x800）。或者接DSI的MIPI屏，我发现树莓派的HDMI驱动原来和DSI的MIPI屏的驱动一样，所以两者没有区别。为了简化验证的操作流程，可以选择rtos，这里我就用比较熟悉的rt-thread。因为rt-thread有着和Linux类似的控制终端，这样更加方便对接。
2.资源评估
有了想法，若要想进行下去，必须评估一下手上的资源是否齐全。下面列出必要的资源
1.树莓派4
选择树莓派4作为验证平台，是我因为现在手上环境搭建已经很方便了。嵌入式开发的痛点和难点就是在环境搭建上，一个好的的开发环境可以达到事半功倍的效果。环境搭建值得好好整理，对于验证各种功能，实现各种特性的验证都十分的好用。
2.hdmi屏
由于已经完成树莓派4的hdmi屏驱动的研究工作，并且hdmi驱动和最后抽象出来的就是FrameBuffer。操作起来不用管底层的实现，只需要向这个Framebuffer的地址处写数据，会自动将这个数据显示到LCD的屏上，十分的方便。并不用关心x,y坐标，像素等等。
3.字库
这里先通过英文字库进行演示，后面再谈中文字库。目前抽取的是开源的GUI中的font_dejavu_40字库进行研究。后面的40表示每个字符高度为40个像素，因为屏的分辨率为1280x800。如果每个字符的高度太小则看起来文字非常的小，在大屏上看起来十分不友好，所以这里选择40个高度的字体，而宽度不定是因为字符的宽度是不是确定的，每个字符有着自己的宽度比如L和l两个数字的宽度就不一样。
有了上述资源，就可以进行后面的探究了，下面来梳理一下显示原理。
3.显示原理
计算机图形本质上就是像素点的集合，更加具体的就是红黄蓝三原色的组合。
三原色的排布组成了一个像素点。实际LCD放大后像素点看起来如下图所示。
而这些像素的亮度决定了最后显示在屏幕上的效果。像素深度(bits per pixel,简称bpp) 描述了每个像素的位数，比如32位则是RGBA8888，24位常见的RGB565和16位常见的565等等。这些都是一个像素所能够表示的信息。
而多个像素可以表示一个图像信息。像素是图像操作的最小单位，所以下面暂时不要考虑颜色信息。
来看一个字库中一个字符的信息
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
0x1f, 0x80, //..+%@@@@@.....
0xff, 0x80, //@@@@@@@@@.....
0xff, 0x80, //@@@@@@@@@.....
0xe3, 0x80, //@%%+..@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x03, 0x80, //......@@@.....
0x7f, 0xfc, //.@@@@@@@@@@@@@
0x7f, 0xfc, //.@@@@@@@@@@@@@
0x7f, 0xfc, //.@@@@@@@@@@@@@
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
0x00, 0x00, //..............
上述就是字符1在字符中的存放信息，每个字节按位展开，.表示0，@表示1。则右边的注释展示了该串字符的信息。如果我们将上述信息告诉给cpu，然后CPU处理这些信息放到LCD上显示则可以显示字符串1。
如果把上面的数组用程序解析交给LCD该如何设计。
1.拷贝上述数组到程序里，作为只有一个字符的字库数组array
2.申请一块和framebuff一样大的内存palette，作为图像输入的画板
3.读取array第一和第二个元素，将第一个元素按高位解析，如果是0向palette填充黑色像素点，1向palette填充白色像素点。
字库中的每一位对应LCD的一个像素，如果对于RGB565来说，则表示2个字节。那我们可以做这样的理解。字库中1的宽度是32个像素，高度是40个像素。
于是可以做标准字库的解析了。一个标准字库是包含多个这样的字符串结构的，所以字符串需要一张表记录这些信息，根据asiic码表排序，字库的存放顺序也可如此，然后一个索引表记录着每个字符串的宽度，数组所在的起始地址信息，有了这些信息，就可以依次做解析然后转换成像素进行显示了。
4.嵌入式上汉字处理
嵌入式上受到资源限制，汉字字库一直都不好解决，不能为了显示汉字把2500~7000个汉字都收录进去，这样需要的内存资源和flash资源十分庞大。为了解决这个问题，一般都是自定义字库，就是首先列出该项目中实际会用到的所有汉字，然后利用特定的软件生成对应的像素字符数组，生成的同时，也会对应这一张map表，方便查找具体汉字的位置。
在处理英文的时候，由于所需的字符很少，可以通过ASCII码进行索引，汉字则可以自定义索引规则，这些都是需要自己设计处理的。但是原理是一样的。
5.结果验证与展示
经过上述的操作，已经完成了lcd console的任务，可以给自己交差了。
其实现的代码也已经放到百度网盘上可以供参考。
链接：https://pan.baidu.com/s/17A37ISKT0tW3WWq2oXJASw
提取码：dgr6
上述代码仅供参考，优化部分还需完善。
6.总结
需要注意的是，对于不同的LCD，需要自己找到合适的大小的字体，这样才能看起来清楚。另外在实现的细节上需要注意的是最好不要在framebuffer上直接绘图，可以放到一个与framebuffer大小一样的数组中，叫做palette，也就是画板。当绘制一帧画面完成后，再刷新到framebuffer中，这是因为framebuffer是非cache的，操作起来会影响刷屏的帧率，看起来帧率会很低。
对于英文字库的显示、中文汉字的处理，有很多东西需要去拓展。其中汉字的抗锯齿问题就很值得研究学习，汉字模糊，汉字的锐化等等，万变不离其宗，其核心都是对像素的处理。LCD绘图，理解像素处理流程，所有的上层应用实现都非常好理解。
1.2020年第11期《单片机与嵌入式系统应用》电子刊新鲜出炉！
免责声明：本文系网络转载，版权归原作者所有。如涉及作品版权问题，请与我们联系，我们将根据您提供的版权证明材料确认版权并支付稿酬或者删除内容。
1764
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
