A buffer can be very handy when using a graphics LCD module. However there are few instances where this is not necessary.

The main reason to use a buffer is where it is necessary to read back a part of the already composed pixel image to merge in a new part. Say you are writing 9x7 character glyphs to the display. Such glyphs will require you pack part of the font item bitmap into bytes that already may contain parts of other adjacent glyphs. Using a buffer allows this type of operation to take place with a series of read/mask/merge/write operations to the image buffer. If the buffer is in the MCU memory space you can then have the benefit of fairly fast random access to the image to perform these operations. Once a whole message is composed to the buffer you can use very efficient code with tight loops to fast copy the buffer to the GLCD controller. The loops can be fast because you can set page and row registers once inside the GLCD controller and take advantage of the controller's internal auto-increment feature to point to the next storage location after each write.

Sometimes when speed is less of an issue, and if you are using a parallel bus interface to the GLCD, then you can eliminate the use of the buffer by reading out the existing image bytes from the controller memory and then perform the mask/merge/write of the info back into the GLCD memory. For almost all GLCD controllers this type of operation is much much slower because of the need to keep sending commands to the GLCD to position the internal memory pointer to the correct location for the next access address. Plan for screen updates to be 5 to 10 times slower using this scheme over using the buffer scheme.

Another implementation where a buffer is essential is in the case for GLCD modules that have been implemented with low pin count flex cables and this require a serial interface. Most of the GLCDs that I've worked with that operate in a SPI-like serial mode only support write data transfers to the display controller. In these cases then the buffer is needed so that you can perform the read/mask/merge/write operations.

The read/mask/merge/write operation is also an important operation for supporting graphics primitives such as drawing lines and boxes or supporting inverting an existing image over or near to where other graphic elements have already been written.

The only case that I have seen where you can realistically get by without a buffer for the GLCD is when you utilize a fixed pitch font that you can map to even byte boundaries in the GLCD image on a fixed character cell mapping. Using this scheme you are also limited to drawing boxes by using "box drawing characters" in your font table. I can assure you though that using this type system with small 8x8 or 8x6 character character cells can lead to rather ugly looking screen displays!!

Michael Karas