原创 再议图形液晶模块的应用

嵌入式系统中常常会有图形液晶模块，这些图形液晶模块和常规的显示系统有些不太一样。常规的显示系统常常有一块称为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系统，后面的应用开发简单了很多。