Artifacts on GLCD?

Using Arduino Displays
21

So there must be some sort of wiring or connection issue.
First verify that all the pins on the AVR are connected to the proper glcd lines.

In the test with the IDE cable the tests that failed were the full display tests.
The individual chip tests all passed. This type of failure can happen if the
chip select lines are incorrect or are not making proper contact.

In the most recent tests without the data cable there were many additional failures.
The first test almost looks like data bit 0 is not hooked up correctly.

How are you connecting things to the Mega?
Is it a small gauge wire being pushed into the sockets?
It could be that the connections are marginal and not making full contact.

--- bill

22

I had rerun all the wires last night based on the v3 diagram, just to make sure. But the artifacts/output were the same. DB0 is wired like diagram for the mega to version B, 22-7.

Connections are those flexible jumpers for setup and testing on breadboard. The picture below is basically what it looks like now.

1023×612 108 KB

I'll rewire at a different location on the breadboard and see if that leads to any improvement.

23

I'm assuming that was the setup when using the IDE cable?
Jumpers are going from the mega connectors to the IDE cable connectors?
And the glcd has a header on it that plugs into the IDE cable connector as well?

I'd like to focus on getting the display working with diags without the IDE cable
before tossing in anything else to try to rule out any issues in the library, the wiring connections,
the glcd, or even the mega itself.

Given how much is "working", the pin mappings from the mega to the glcd
pretty much have to be correct.

So lets step back for a moment.

Do you have a datasheet for this display?
(I'd like to verify its timing and power needs just to be sure)
Has this display worked correctly in the past?

Is it possible to plug the glcd directly into the breadboard and wire
between the mega and the breadboard?
and not have any other components hooked up to the mega?

--- bill

24

Actually that was a pic from a week or 2 ago, but most recently I've had the GLCD plugged straight into the breadboard, on the most recent test results.

I don't have a data sheet, it was part of a kit bought through ebay from Hong Kong. From what I gathered it's a ks0108 series B (if that's worth anything).

The display has always worked until I upgraded to v3. The artifacts had always been present but to a much lesser degree until my most recent sketch in which they became frequent and numerous.

25

So it sounds like the glcd has never worked entirely correctly yet.

v3 pushes the display closers to its limits, but it will be considerably slower
with the delay value modifications you made.

Have you run diags on the glcd in the breadboard with nothing else hooked to the
mega? This is what I recommend doing until the glcd issue is sorted out.
Running the glcd by itself will eliminate any other sources of noise or current drain.How

In looking at your photo, maybe it is the lighting and focus but pins 6 and 11
on the glcd module look kind of suspicious. Have you checked the solder joints
on the 20 pin glcd header?

How about your power? Have you checked the 5v voltage with the glcd hooked up?
Some backlights draw lots of current (up to 500ma) and need additional current limiting to avoid
over stressing the power supply.

Was this glcd ever hooked up incorrectly?
That can potentially damage the glcd or an AVR i/o pin.

--- bill

26

Sorry, yes I've pulled everything else, and the last couple of tests were run with only the GLCD.

While under direct 5v only the display has less over all 'flicker' but it does still have the artifacts. I've typically only used it with with either USB or 5v power but not typically both. Should I test using both going forward? I don't think I ever hooked it up incorrectly.

Resoldered 6 and 11 because they do/did look a little sketchy but still failed with 5v power feed as well:

Serial initialized
--------------------------------------------------------------------
GLCD Lib Configuration: glcd ver: 3 glcd_Device ver: 1 gText ver: 1
Panel Configuration:ks0108
Pin Configuration:ks0108-Mega
--------------------------------------------------------------------
GLCD:ks0108 DisplayWidth:128 DisplayHeight:64
Chips:2 ChipWidth:64 ChipHeight:64
 CSEL1:33(PIN_C4) CSEL2:34(PIN_C3)
 RW:35(PIN_C2) DI:36(PIN_C1) EN:37(PIN_C0)
 D0:22(PIN_A0) D1:23(PIN_A1) D2:24(PIN_A2) D3:25(PIN_A3)
 D4:26(PIN_A4) D5:27(PIN_A5) D6:28(PIN_A6) D7:29(PIN_A7)
Delays: tDDR:1320 tAS:1140 tDSW:1200 tWH:1450 tWL:1450
ChipSelects: CHIP0:(33,0x1, 34,0x0) CHIP1:(33,0x0, 34,0x1)
Data mode: byte
--------------------------------------------------------------------
Diag Loop: 1
Initializing GLCD
Displaying ChipSelect Screens
Walking 1s data test
Wr/Rd Chip Select Test
Testing GLCD memory pages
Horizonal Page Test Chip: 0 Pixels 0-63
 Verify error: (0,0) 42!=81
 Verify error: (2,0) 44!=43
 Verify error: (3,0) 45!=44
 Verify error: (4,0) 46!=45
 Verify error: (5,0) 47!=46
 Verify error: (6,0) 48!=47
 Verify error: (7,0) 49!=48
 Verify error: (8,0) 4A!=49
 Verify error: (9,0) 4B!=4A
 Verify error: (10,0) 4C!=4B
 Verify error: (11,0) 4D!=4C
Vertical Page Test Chip: 0 Pixels 0-63
 Verify error: (0,0) 5!=FD
 Verify error: (61,0) F2!=FA
 Verify error: (44,0) 6C!=74
 Verify error: (12,0) 6E!=76
 Verify error: (45,0) 79!=6D
 Verify error: (62,0) 1!=9
 Verify error: (6,0) 44!=4C
 Verify error: (12,0) 72!=7A
 Verify error: (61,0) FB!=3
 Verify error: (63,0) 11!=19
 Verify error: (32,0) 19!=21
Horizonal Page Test Chip: 1 Pixels 64-127
Vertical Page Test Chip: 1 Pixels 64-127
Full Module Horizontal Page Test:Pixels 0-127
 Verify error: (29,0) 9D!=9E
 Verify error: (42,0) 2A!=2B
 Verify error: (60,0) 3E!=3F
 Verify error: (8,0) 8A!=8B
 Verify error: (19,0) 16!=17
 Verify error: (0,0) 4!=43
 Verify error: (63,0) 43!=42
 Verify error: (0,0) 5!=44
 Verify error: (57,0) 3E!=3D
 Verify error: (58,0) 3F!=3E
 Verify error: (59,0) 40!=3F
Full Module Vertical Page Test:Pixels 0-127
 Verify error: (8,0) 43!=4B
 Verify error: (2,0) 18!=20
 Verify error: (58,0) DD!=E5
 Verify error: (55,0) C4!=CC
 Verify error: (25,0) DE!=E6
 Verify error: (15,0) 90!=98
 Verify error: (53,0) C4!=CC
 Verify error: (16,0) 9D!=A5
 Verify error: (41,0) 64!=6C
 Verify error: (26,0) F1!=F9
 Verify error: (58,0) EE!=F6
TEST FAILED
27

USB power should be fine. (as long as the backlight isn't drawing too much current)
I haven't looked at the schematic to see what happens when more than one power
source is hooked up, so just stick with the USB.

There isn't much else left to try.
It looks like some kind of wiring/connection issue.

When diags runs, are there any missing pixels on the display
during the initial triangular display?

When you get these diag failures, are they "hard" errors (always the same) or
do they change on each run?

The reported errors are a bit strange.
I can imagine several things that could cause that type of behavior
but they all involve things like wires not hooked up or hooked incorrectly.

Maybe try re-soldering all the pins on the glcd header?
If you can post a clear photo of the 20 header pins,
I could take a look to see if anything looks suspicious.

What sized pot are you using for the contrast lines and how is it hooked up?
And what about the backlight resistor?

Are there any markings or part numbers on the back of the glcd?
If so, can you post a photo, maybe we can locate a datasheet for the module.

There is a "read cache" option that can be turned on.
This is a special mode that uses a read cache buffer for all the reads and only writes
to the display. It uses extra ram (1k for this display).
The only reads done in this mode is for the BUSY status.
(all read data comes from the cache instead of the glcd)
You can turn this on by editing the glcd/glcd_Config.h file and un commenting
the GLCD_READ_CACHE define.

--- bill

28

Sorry for the delay. Got frustrated and had to step away from it for a day. I appreciate the time you are taking. Triangular display test has always been 100% perfect, no aritfacting.

I've got a a 200 resistor running between the pin 20 ground and the of the pot to ground of the pot. Just like the layout diagram for the B series indicates.

I took a close look at the 20 headers and after touching up those 2 all of them look good. I did also resolder the K and A places on the middle right side in the back.

I changed out the pot from the tiny one it came with to a big B10K ( with no difference to test results) and then I uncommented GLCD_READ_CACHE define and it passed the test and I didn't notice any artifacts!

I then hooked up the ribbon with jumpers and even though it still passed I got artifacting in the middle:

1023×612 76.7 KB

And on some of the scrolling image tests there was a lot of negative artifacting along the vertical middle line with the ribbon jumpered in. I've got some hardware on the way to make a breakout board so to ensure better connectivity, but's probably a week out.

Would I be better served to use 20 wires of a larger gauge rather than the 40 wire ribbon?

Here is the GLCD back:

1023×612 91.2 KB

29

It looks like the IDE cable is a bad choice. I'm not entirely convinced :roll_eyes:
I'll fire up mine sometime this week with a 40 pin IDE cable and a wider (50-pin?) SCSI cable. My cables are around 12" and 6" so may be better than your longer ones. Thank you for keep doing your testing and sharing your results. I'll always think twice before using those cables after this.

BTW, I was able to run a 20*4 character LCD over about 9" floppy cable (34 pin) just fine a few days ago. Just FYI.

30

I'm not clear on the exact configuration and
what is working/not-working between the using/not-using the IDE cable.
Can you explain a bit more about the exact configuration you are using
and what is happening with each.

Things like

  • the added delays - (I assume those are still in there)
  • the uncommenting out the GLCD_tAS delay in WaitReady() inside glcd_Device.cpp
  • more information about your contrast pot and it is hooked up.
    (I didn't understand your comment about your original pot and using a "big B10k")
  • what configuration worked when the GLCD_CACHE was enabled?
  • when using the IDE cable, which connectors are you using?
    (if you have more than 2 connectors, which 2 are you using? Ideally it should be the ones on the ends)

In particular what was the configuration in the photo that has the missing text near
the center of the display?
Was that text missing through that particular entire test or did it flicker and vary?

I've got a few IDE cables. I'll hook one up today and see how it works on my end.
Although my cables are only about 8-12 inches long and I don't have a mega board.
I've got Teensy's and BBB m328p board.

--- bill

31

Ok, so I hooked up my glcd using an IDE cable using my Modern Devices BBB board
and a breadboard.
It worked ok for me. But then my environment is slightly different.

  • I'm not using a mega in byte mode; I'm using nibble mode on a m328p board.
  • I have a different glcd.
  • My cables are slightly shorter.
  • I am using a 10k pot for the contrast control.

But other than that..... its all the same... :slight_smile:

My configuration is using the "as is" code from the v3 library

  • default timing and no mods to any code.
  • READ_CACHE is disabled.

My concern with your setup is that it still sounds like it is not fully working when
the glcd is plugged directly into the breadboard.

--- bill

IMG_2695.JPG

IMG_2698.JPG

IMG_2700.JPG
IMG_2700.JPG480×640 72.9 KB

32

The delays are still in

GLCD_tAS is not commented out.

The original pot was a small blue and white plastic one with "103" on it. The current pot is marked B10K and looks like this:

The config that worked was the GLCD directly into the breadboard with no ribbon cable. And technically it passes with the ribbon cable but the display gets all messed up in the middle.

The IDE cable has no middle connector. Just a 18 inch cable with 2 ends.

The text more or less flickers. It's ass if a | or ! or i of pixels is removed or added rapidly.

The setup seemed to work fine with the READ_CACHE enabled and the GLCD mounted directly to the breadboard.

Once my new hardware gets here I'll try to use an old parallel cable to run the wires and see if it makes any difference.

33

So you are saying diags is now passing all tests? in both configurations
and it is now that the display has some flickering of some of the pixels?

If that is the case, I'm not sure what could be causing it. Maybe there
is an issue with the display itself.

Some other things to look at:

You don't have any wires sharing the same socket physical hole in the breadboard
or the mega? (specifically the ground wires)
Check the grounds and make sure all of them are getting good connection.

Is the contrast control working? i.e. at one end all pixels are on and at other end
of adjustment all pixels fade away to off?

Do you have a multimeter so you can verify the resistance of the pot?

And for clarity, the pot is hooked up with the center going to pin 3 on the glcd
and the ends going to pin 18 and gnd.

--- bill

34

So you are saying diags is now passing all tests? in both configurations
and it is now that the display has some flickering of some of the pixels?[/i]
Yes, on a whim I tried a printer cable (a delicate operation of time and patience) and got the exact same results as the 40 wire IDE. Passes all tests but lots of flickering of pixels especially in the middle.
If that is the case, I'm not sure what could be causing it. Maybe there
is an issue with the display itself.
Some other things to look at:
You don't have any wires sharing the same socket physical hole in the breadboard
or the mega? (specifically the ground wires)
Check the grounds and make sure all of them are getting good connection.
Is the contrast control working? i.e. at one end all pixels are on and at other end
of adjustment all pixels fade away to off?
Yes contrast pot/s has always worked.
Do you have a multimeter so you can verify the resistance of the pot?
Not yet should have one next week. I'll check the ground as well.
And for clarity, the pot is hooked up with the center going to pin 3 on the glcd
and the ends going to pin 18 and gnd.
Yes and the gnd is going through a 200ohm resistor.
At this point I'm kind of burnt out with the artifacts issue. I'd be interested in getting my original sketch to display under GLCD v3, as it is (after correcting syntax) compiling and uploading fine but the screen is blank.

35

Molehs:
And for clarity, the pot is hooked up with the center going to pin 3 on the glcd
and the ends going to pin 18 and gnd.
Yes and the gnd is going through a 200ohm resistor.

At this point I'm kind of burnt out with the artifacts issue. I'd be interested in getting my original sketch to display under GLCD v3, as it is (after correcting syntax) compiling and uploading fine but the screen is blank.

So how is the contrast pot hooked up? (your comment confused me)
I'm assuming you have it wired correctly but just for clarity,
1 end of the pot should be directly connected to gnd,
1 end should be directly to Vee/contrast-out (glcd pin 18) and
the middle directly to contrast-in (glcd pin 3).

The 200 ohm resistor does not come into play with the contrast pot.
It is used to current limit the backlight, for your display, it will be between
pin 20 on the glcd and ground.
Also, glcd pin 1 will be connected straight to ground.

A blank screen is often due to the glcd library code being stuck waiting on BUSY status
(there is no timeout for this) but if the diags are working, then it is not a wiring issue.

With your same hardware all hooked up that is showing a blank screen with your sketch, does diags still work?
If so, then there is something outside the library happening.
Maybe duplicate pins? or Something else hanging.
A quick diagnostic to see if the glcd library is hanging is to print a message out the serial port
just before and after GLCD.init() in your sketch to make sure the glcd initialization is completing.

--- bill

36

LOL seems that in my conversion I had commented out the GLCD.init() because it had a non_inverted qualifier. And because it compiled with out it, I figured I was good. heh.

Now I just have to figure out why my code has messed up the first menu screen.

I'll come back to this thread once I get proper headers and can ensure connectivity next week. I still 'need' to have my GLCD located separately so I eventually will need to get the cable thing sorted.

Thank you for all your time and patience.

EDIT: Is there anything in particular that would cause my main/menu screen to rapidly alternate between the normal screen and the entire screen moved up about 8 pixels? It's as if every other drawing it's got -8 to the y axis. moved up text and images...Will take a closer look after dinner...

37

Molehs:
EDIT: Is there anything in particular that would cause my main/menu screen to rapidly alternate between the normal screen and the entire screen moved up about 8 pixels? It's as if every other drawing it's got -8 to the y axis. moved up text and images...Will take a closer look after dinner...

I am assuming you are updating the display when this happens vs this happening on its own.
And I'm also assuming when you say things are moved up, they are moved up vs rolled around
on the display.

The v3 library now supports wrapping and automatic scrolling of the text area. So if you write enough
text, the text will automatically be wrapped to the next line,
then if it is along the bottom (assuming you are using the normal upward scrolling),
the library will scroll up the text area to make room the new text line.

The default text area is the full display and scrolls text up.
note: pixels are "scrolled" vs "rolled". i.e. on an up scroll the upper pixels are lost and rolled around to the bottom.

Since a wrap/scroll operation affects an entire text area, and default text area is the full screen,
a wrap/scroll would move everything on the screen up enough pixels for a new row
of text. If you are using the default 5x7 font, that is 8 pixels.
Because graphics don't have their one plane/area, any graphics on the display that are inside/on-top-of
a text area will be scrolled up as well.

I'm guessing that since sketch was originally on v2 that it is not using a custom text area and
is using the default text area.
So my guess is that the menu is sometimes writing text that will land just beyond the right edge of
the display along the bottom and this is causing the entire display to be scrolled up.

EDIT:
The rendering, wrapping of text, and how the "left margin" works with respect
to locating text on the display is not quite compatible between v3 and v2.
See the "Sketch Migration" section in the HTML documentation for some additional details.

Overall, while final text rendering is slightly different from v2, v3 is substantially better and for most
applications there is no impact with respect to compatibility.
It is now consistent between fixed vs variable fonts, and variable fonts are now rendered
correctly on all pixel boundaries. The text areas are very powerful for controlling text in
multiple areas of the display.

--- bill

38

Just want to say again how much I appreciate the time you take for your responses.

I moved a couple of things around and the screen doesn't flip out any more. But now I have a new wierdness. If I turn the contrast up high enough I get a ghost of an image from the diag????

1023×612 74.3 KB

Other than that it seems that I am pretty close back up and running now. I have some layout issues with the v3 but I'm working thought them.

39

I have no idea why you are seeing the "ghosts".

So what changed? Are you talking s/w changes or wiring changes?

Knowing the before and after might help others or might be something
useful to put into the glcd v3 documentation if it related to some
kind of accidental incorrect wiring or incorrect calling sequence.

--- bill

40

The wiring I did hasn't changed. I uploaded my sketch to continue working on and accidentally noticed the ghosting as I was switching between power sources. The 5v source has a different contrast setting than the USB.

It's almost as if the old sketch isn't wiped when the new one is uploaded. Should I be doing some sort of purge/format between uploads?

Pretty sure my Arduino is possessed.