I am testing Adafruit's ks0108 based GLCD with an AtMega2560 and Arduino IDE v 1.8.13. Library is openGLCD, and I am using its sketch "GLCDiags.pde" to test. I have checked all connections many times but there still seems to be a pixel addressing error from the start (see "1 first screen.jpg"). The test results shown below indicate the write/read back is failing and not displaying the diagonal draw correctly (see "2 walk test.jpg"). But if it is just an addressing error, shouldn't the write and the read still access the same pixel even if it is the wrong pixel?
I'm about to pull out a scope and rigorously check all the lines, two at a time, comparing them to the timing diagrams and state tables in the datasheet. Before I do, maybe someone has some quick advice from looking at the screen shots, or suggestions on how best to proceed.
?? Is it possible to tell from these images which data line, control line, or chip select may be the culprit?
unfortunately with the ks0108 interface it is easy to tell something is not working correctly but trying to figure out the issue is not always easy given so many wires are involved.
Issues like this are almost due to wire / connection issues.
i.e. poor connections or incorrect wiring.
The good news for this case, is you are seeing some proper rendering so nearly all the wires must be correct and the timing is very unlikely to be an issue.
chip selects affect left vs right. That doesn't seem to be an issue.
EN must be working to see anything.
DI, must be working to see as much as you do (commands and data are working)
R/W is correct since the display is being written to.
I notice that the top part of the display is not addressable and the character rendering is having issues at bit position 2
If you look closely at the character rendering, pixel controlled by D2 is high when D3 is high and pixel controlled by D2 is low whenever D3 is low
It almost looks like D2 is floating (not connected to Arduino pin24) and possibly picking up noise from the D3 wire and mirroring it.
(I have seen this behavior before)
I'd look closely at all the wires but very closely at the wires/connections for D2 and possibly D3
Also in the walking ones test there are issues with data bits 2 and 3 so further indication that there is some issues with the wiring / connections for the D2 and D3 signals.
I.e. the test wrote 0x4 and read 0xc, and wrote 0x8 and read 0xc
Thank you bperrybap! This is exactly the kind of help I needed, and you are right on the mark.
D2 shows no activity. I wrote a sketch doing nothing but toggling D2 and it appears the atmega's D2 output driver stays high impedance. Must have had a fatal bus contention in a previous setup. I'll replace the Mega and be more careful this time.
I can't tell you how much time and effort you saved by providing an experienced perspective: "I have seen this before."
I spent a lot of time developing the diag tool. While it typically can't pinpoint much other than backwards CS pins, it can be quite useful to help narrow things down.
Unfortunately, it didn't offer as much assistance to people as I had hoped since in many cases, it takes a deep understanding of how the chips and library works to be able to make much of what is shown.
I saw lots of strange stuff during the tests I did, which included incorrectly wiring tings up, pulling wires, and shorting pins.
If you are worried about bus contention issues, you could put a series resistor on each wire.
Something on the order a few hundred ohms would protect the AVR pins from being damaged from a short and shouldn't affect the signals enough to cause issues.
bperrybap:
Something on the order a few hundred ohms would protect the AVR pins from being damaged from a short and shouldn't affect the signals enough to cause issues.
Specifically, 180 Ohms limits the current to about 22 mA into a dead short.
