GLCD framebuffer library

[LGR]

Several interesting new 128x64 GLCDs are on the market (Newhaven, DOG) using the ST7565R controller and others, which as nearly as I can tell is incompatible with KS107, T6963c, and s1d13700. The general problem with this proliferation of controllers that aren't quite compatible with old standards is that there's no way to re-use all the draw and text functions from the libraries, because there's no good way to use drivers in the mP environment.

Here's a solution that I think could work on the larger PICs; the 32s and some 24s, and it would speed up display refresh as well, at the expense of 1k of RAM: create a GLCD library that instead of writing directly to the devices as the current ones do, writes to a 1024 byte array in RAM (framebuffer). Then, all one needs to do to accommodate a new controller is write one single procedure to write the entire frame from the buffer to the device. This would make working with new controllers a LOT easier.

[LGR]

Thinking about this a little bit, there would have to be two variations; one for when the bytes are stacked vertically (like KS107), and another for when bytes are stacked horizontally (like T6963c). I hope there aren't big endian and little endian variations.

[janni]

Hi LGR,

The general problem with this proliferation of controllers that aren't quite compatible with old standards is that there's no way to re-use all the draw and text functions from the libraries, because there's no good way to use drivers in the mP environment.

You probably meant that it's hard to add drivers to present libs, as in general there's nothing in mP that prevents writing a lib in layered form, i.e. separating higher graphical/textual functions from lower ones (like dot, line, etc.) and from hardware driver.

Here's a solution that I think could work on the larger PICs; the 32s and some 24s, and it would speed up display refresh as well, at the expense of 1k of RAM: create a GLCD library that instead of writing directly to the devices as the current ones do, writes to a 1024 byte array in RAM (framebuffer). Then, all one needs to do to accommodate a new controller is write one single procedure to write the entire frame from the buffer to the device.

This method is actually indispensable for displays with one-way serial communication and may be used also on PIC18s.

[LGR]

That's a valid point; if the present libraries were structured differently, you could have library-independent device drivers. The sticky thing, as I noted in the second comment, is that even the graphical meta data can have more than one format. As a minimum, there would have to be vertical and horizontal byte versions. But, I think this could be worked out.

There are a lot of interesting devices devices out there.

And btw, one other advantage of having a RAM frame buffer is that it makes it a lot easier to turn the display upside down, which is sometimes necessary.

[LGR]

One more comment on this: for PIC32, this would lead nicely into a library that drives LCD glass directly using DMA per Microchip's app notes. Once the image is in the framebuffer, you would simply start the DMA process with a procedure like LCDON() or something like that, and the image simply appears on the glass.

Of course, this would potentially require a much larger buffer than 1024.