Peter,
I'm the author of the diag sketch included in the glcd library
as well as co-author of the library.
With the diags passing, that is a very good thing.
This means that the data communications between the library
code and the GLCD is working and the memory on the GLCD passes
memory tests.
The only things not tested is the contrast circuit and the backlight.
That said, there is a potential issue around RESET that can cause this
type of issue (display not being enabled - so no pixels are visible - regardless of contrast setting).
I also noticed that you are not using an arduino pin to reset the glcd module.
(doesn't show up in diagnostic output - thanks for including that)
-->>Do you have the reset pin on the glcd hooked up to a reset signal on
your board? (not sure which arduino board you are using)
The reason that I ask is that down low in the initialization code
if the reset pulse going into the ks0108 module is slow rising,
then I have seen an internal hardware race condition (bug) on several
ks0108 glcd modules in which the module will say reset is complete
but the internal ks0108 chips are still held in reset.
---- Gory details.......
The problem (on some glcds) is that
the reset signal is fed directly to the glcd status register
as well as holds the internal ks0108 processors in reset. If the reset pulse
rises very slowly, the reset bit in the status register goes away
before the processors are reset.
To make things worse the busy bit is held clear
when the processors are in reset state and is only set by the processors.
The first thing the low level glcd libarary code does is turn on the displays.
(128x64 ks0108 modules actually have 2 displays internally that are side by side)
If this slow rise reset condition occurs, the low level code commands to the glcd
will be lost because the low level software saw the the glcd module
was no longer in reset and was not busy, so it started talking to it.
Because the glcd processors are still in reset, the busy bit does not show
up when commands are sent to it, so it looks like they are working.
-----------------------end of details
To ensure that this is not the issue either hook up an arduino pin
to reset the module (recommended if you can spare the pin),
or make sure that the reset pin the glcd (pin 14 on your glcd)
is hooked up to a reset signal in the Arduino sp that the glcd is
reset with the arduino reset button is bashed.
(Just reviewed the code and noticed another potential issue -
Not sure why I turned off the reset status check code by default)
So... another thing that can be possible is that glcd board is slow
initilizing. Currently with all the reset issues, the code has the
RESET bit polling disabled and so it it may jump on the glcd module
too quickly if it is slow initializing.
This can occur if the GLCD.Init() is called first thing in
a sketch on slow initializing glcd board.
To turn on the reset status polling, add this line
#define GLCD_POLL_RESET
to the glcd_Config.h file down near the bottom
with the user defines.
Another thing I noticed that seems strange is that I have dealt with
many different glcds with about 10+ different pinouts, and while
things move around and many others are also a bit "strange" or just flat
wrong, I've not run across any ks0108 modules
that didn't include the negative voltage (vee) signal, which
most modules have on pin 18.
Since you said that you have now are seeing 0 to -5 on the wiper which
should be hooked to pin 3 on your glcd, I'm assuming that the data sheet is
wrong with respect to pin 18. That it really is Vee vs Vss.
-->>But can you confirm that you see 0 to -5 now showing up on pin 3
on your glcd?
Verify this before you run down messing with the reset stuff.
-- bill
