dc42:
The 2-pin interface is quite quick if you use the SPI pins and the SPI hardware to drive it. Unfortunately, the ST7920 it doesn't have a CS input, so it can't share the SPI pins with anything else unless you use external clock gating hardware.
"quite quick" is relative.
While it is definitely usable,
it is not anywhere close to the speed of being able to control the pins directly.
For example, it takes 3 bytes across the SPI and 24 sclk transitions to transfer a single byte on the st7920
Even if the the AVR was pushing the SPI at 8mhz that is 3us.
(fastest sclk rate on AVR is F_CPU/2 or 8mhz on 16mhz parts. so 24clock is 3us at 8mhz)
Just for a single byte transfer.
While 3us may sound fast, when doing thousands of updates it makes a difference.
The BIG issue when using SPI on glcds, is that there is no read capability.
That puts a big constraint on things. The library either has to create a full shadow buffer
or has to live with certain limitations.
Oliver took a balanced approach in u8glib by using a partial shadow buffer that moves around
to paint the display.
It does come with some limitations in that the user code must paint the display a
particular way. It also requires re-drawing the screen L/s times to update the display
where L is the size of the LCD display memory, and s is the size of the shadow memory.
For example on a 128x64 display the paint routine code will have to be called 8 times as the shadow
buffer is 8 pixels tall. It has to be called and run to full completion for each lcd page.
During each iteration, pixels that land in the shadow buffer are updated and at the end
of the iteration, the shadow buffer is pushed to the display.
This further slows things down.
And even after dealing with that, there is still some functionality that cannot be provided
without having full read access to the display data. Things like scrolling or being able draw
on top of the existing pixels.
It is still very usable but because of these issues and limitations, it ends up being quite a bit
slower than having direct control with read access.
That said, I do agree you do pay for the additional speed and capability it in terms of pins.
I've looked at supporting the st7920 in parallel mode. (It also has a 4 bit mode)
The issue that came up immediately is that the pixels in the st7920 are not
stored in its memory the same way pixels for ks0108, sed1520, and ks0713 are stored.
The existing code in glcd is highly optimized for a different pixel mapping and can't really
be made to easily work with the st7920.
The real answer, is to have a full shadow buffer and then you get the best of all worlds.
This would allow the library to have full access to the display pixels regardless of the interface used.
Because of the local shadow buffer the pixel to glcd memory pixel mapping becomes irrelevant.
It would also allow things like rotating the geometry on the display.
Lots of code in glcd could get smaller and faster if a shadow buffer were always used.
This issue is that the AVRs used in most Arduing boards don't have enough RAM to do that.
The chipkit, Maple, DUE, and even some of the "duinos" by third parties like teensy or the "sanguino" boards
do have enough ram to have a full shadow buffer.
I've been considering a glcd v4 design that may change things up and even
potentially require a frame buffer.
I also think, oliver could easily tweak u8glib to use a full shadow buffer
which would allow it work more like glcd and would give it a speed bump as well.
But as mentioned above, it requires more ram that is available on many AVR platforms.
--- bill