Each controller has its own set of commands.
From a low level perspective, parallel, SPI, and I2C are common.
For u8glib I have two software layers:
1) the low level communication api for the transfer of bits and bytes to the controller
2) the device level api for tasks like display init and page transfer.
The ST7920 has a special kind of SPI and parallel interface,
where only 4 bit are tranfered within one byte. The low level com api for the st7920 is here:
See here: http://code.google.com/p/u8glib/source/browse/csrc/u8g_com_arduino_st7920_spi.c
The device level api is here:http://code.google.com/p/u8glib/source/browse/csrc/u8g_dev_st7920_128x64.c
You can see that init and page transfer are quit simple on parallel mode, but the SPI interface
made me a lot of trouble because of its special 4 bit mode.
From an enduser perspective u8glib is just another graphics lib. But it has been designed
to provide a framework for low level communication and controller command abstraction.
So we can (hopefully) add support for new kind of displays/controller combinations. I can
reuse the com low level procedures (ok, not for the st7920) and there is a simple interface
(a callback procedure) for the pixel transfer.
So for the S6B0724 the first thing is to check if it is compatible to some
existing and supported controller (e.g. ST7565). If not, than (inside u8glib) check if
some existing low level com driver can be reused and only the init sequence and
page transfer have to be programmed.
Regarding the datasheets, i agree, that it tooks a lot of time and testing to understand
the behavior of the controller. Maybe i could give a more detailed answer to a more detailed
The use of the Serial.begin might be possible for a display which supports exactly this
low level com protocol, but it will be too inflexible.
Indeed the low level com structure of u8glib replaces the Serial.begin class.