Next I'm going to study the glcd library and hopefully find a way get this T6963 display working with the glcd lib.
So far I think at least the functions readData, writeData, writeCommand, WaitForStatu, goTo, init need to be adapted for this controller.
Correct.
Those are the primary functions that are needed to make all the higher level class functions operate.
But technically it is only readData(), writeData(), Init(), and gotoXY() as the other functions are support functions used by those 4 functions.
For those following along:
While providing the same yet expanded functionality
the glcd library code implementation is very different under the hood compared to the ks0108 library.
The ks0108 library was a single class with all the code
lumped into the ks0108 class.
The glcd library is broken into 3 classes
- glcd (in glcd.cpp)
- gText (in gText.cpp)
- glcd_Device (in glcd_Device.cpp)
The glcd class provides graphic functions as well as access functions into both gText and glcd_Device.
gText is obviously for the text areas but calls into glcd_Device.
glcd_Device handles the low level hardware i/o.
Both glcd and gText currently make some assumptions about the underlying display capabilities and orientation.
The biggest ones being:
- glcd memory is readable as well as writable.
- glcd memory to display pixel mapping consists of 8 pixels per byte
(glcd page) and pixels in that page are 8 vertical pixels on the display.
- x & y coordinate values will not be larger than 255
- 0,0 origin is upper left corner of the display.
- Font data is stored in the same bit/pixel order as display memory.
- a read from memory does not advance the memory address while
a write to memory does advance the memory address.
This allows fast read/modify/write operations as the upper
layers simply read a byte, modify it, then do a write and can then
do the next read without having to worry about setting memory
addresses.
It also allows fast write updates for things like bitmaps and font data
as the code can do back to back writes and the address increment
is handled by the glcd_Device layer or the hardware itself.
All the functionality currently provided by the glcd library (graphics & text) lives on top of these capabilities/assumptions.
Displays that cannot support these capabilities/assumptions
either directly or with library code will be much more difficult to get working with the glcd library.
Displays that can provide those capabilities and operate within those assumptions shouldn't be that difficult to get working with the glcd library.
Conceptually, glcd_Device's job is pretty simple.
Read & Write glcd memory and provide the ability to alter
the address where memory is read/written based on x & y coordinates.
The glcd_Device code may be a bit painful to get up to speed on.
It uses many macros and conditional ifdefs. Many of these were to make the
code more portable, more easily adapted to other displays, or to increase
the digital i/o performance by avoiding the Arduino digital i/o library functions
(digitalWrite(), digitalRead(), pinMode() etc...) and talking directly to the AVR ports/pins.
While it would be possible to add in a new device by replacing
the readData(), writeData(), GotoXY(), and Init(), it would be
better to take a look at the structure that is already in place for supporting other displays to see if that can be leveraged.
There is a collection of macros and defines which are used by the glcd_Device code that are defined in the device directory and in glcd_io.h
While a structure is in place for alternate displays, sometimes a new display will have a certain need that is unaccounted for in the glcd_Device code.
Should that occur, it can usually be handled with new or additional code that is conditionally compiled in based on macros or defines in device specific header.
For example, the Init() code already looks for a macro called
glcd_DeviceIinit() which can override the default init code for
a given chip.
The reason that it is best to look at using the device macros, is that this will allow the library to support a new device and still support all the devices already supported through the existing configuration mechanism.
While only a general overview, hopefully it provides some insight as to the inner workings of the glcd library.
--- bill