再议图形液晶模块的应用

嵌入式系统中常常会有图形液晶模块，这些图形液晶模块和常规的显示系统有些不太一样。常规的显示系统常常有一块称为 Frame Buffer 的线性内存空间， CPU 可以直接用 load/store 的访存指令直接访问。图形液晶模块中也带有显存，但是 CPU 却不能用 load/store 访存指令直接访问它。例如有些常见的液晶模块和 CPU 之间的连接是 SRAM 接口，包括： 2 片选 128x64 图形点阵液晶模块， 3 片选 192x64 图形点阵液晶模块， 240x128 液晶模块（控制芯片为 6963 ）和 320x240 液晶模块（控制芯片为 SED1335 ）等等。我也见过 SPI 总线和 I2C 总线的液晶模块（大多是 COG 液晶）。访问这些液晶模块的显存都需要一套复杂的过程，而不能通过简单的内存读写实现。

另一方面，有些液晶模块显存的组织格式和我们想像的非常不一样。例如： 3 片选 192x64 图形点阵液晶模块，实际是由 3 块 64x64 的模块拼接而成的。按照它现有的显存格式存放数据，最后将显示一个 64x192 的屏幕。如果要让它显示成 192x64 ，就一定会使用到专门的屏幕旋转处理。

因为上面的这两点，在这类液晶模块上开发 GUI 应用非常麻烦：既不能设计通用的软件系统，也不能利用现成的开源资源。

03 年的时候，我们公司的一个项目就使用了一块 3 片选 192x64 液晶模块，我负责开发它的 Linux 内核驱动。当时我就犯难了：到底是使用 Frame Buffer 设备模型呢，还是使用常规 char 设备模型。最开始选择的是常规 char 设备模型，把 192x64 个点划分为 24x8 个 8x8 的格子。每个 8x8 的格子用于显示汉字或者 ASC-II 字符，然后又在上面做 GUI ，花费了很大的功夫。但是，客户对最后效果非常不满意，最后自然是返工了。

返工后，我们选择的是 Frame Buffer 设备模型。具体的做法是：在系统内存里划分出一块空间来虚拟 192x64 点阵的 Frame Buffer ，然后使用一个 timer 定期去检查虚拟 Frame Buffer 是否被改写，如果有改写，那么就把整个虚拟 Frame Buffer 的内容刷新到液晶模块的显存里去。最后，我们只是做了一个简单的交叉编译，就在这个 Frame Buffer 设备上运行起来一个开源的 GUI 系统，后面的应用开发简单了很多。

其实，如果不把液晶模块设计成 Linux Frame Buffer 设备。我们还可以不使用那个无厘头的 timer ，充分利用虚拟 Frame Buffer 和液晶模块内部显存构成的天然 double buffer 结构来作设计，无论是系统效率还是显示效果都可以做得更好。