next topic »

[on:]

Hello,

i have connected a HP12542R-DYO 128x64 parallel driven LCD to my Arduino Mega 2560.
I use this library to control it:
http://henningkarlsen.com/electronics/library.php?id=49

Most of the functions are working almost perfect, i can display converted bitmaps on it and also text by using the fonts provided by the library,
but there is a problem with the setpixel function.
This function use bit-manipulation.
A whole page/byte is read from the ram of the lcd, "bit-or'ed" with the new data and finally written back to the lcd.
Every bit which is set results in a black pixel on the display.
The problem is, that my controller think that some bits are set to 1 which are really set to 0.
I tried a shorter cable - no changes.
The D5 have the most problems.
If i touching the isolation of this wire, the readings from the ram seems to be very better.
Touching the wire itself with a metal pair of tweezers fix it completely (but THAT can´t be the solution... ;-)  )
I tried to activate the built-in resistors before the reading process by adding the lines ( DigitalWrite(2...9,HIGH) ) to the function for data-direction of the library,
but after that the display showed bullsh... .
Does anybody have an idea how i can fix this issue?

(Sorry for my bad english - i know i have to learn a lot... ;-)   )

[Reply #1 on:]

It sounds to me that the library is not getting the timing right for reading data from your lcd. Here are 3 possible solutions:

1. Quick and dirty fix: connect a low value capacitor (between 20pF and 100pF should be about right) between D5 and ground. This should have the same effect as you holding the wire with metal tweezers.

2. Fix the library.

3. Try a different library, such as GLCD 3.

[Reply #2 on:]

1. Quick and dirty fix: connect a low value capacitor (between 20pF and 100pF should be about right) between D5 and ground. This should have the same effect as you holding the wire with metal tweezers.

Thank you that sounds like a very good idea. I will try it and tell about my experience here. :-)

[Reply #3 on:]

Sven,
The glcd v3 library currently does not currently support the SED 1565 so the glcd library is currently not an option.

I have seen this type of data corruption while I was debugging the low level glcd library code and it
is almost always due to the the software violating the low level hardware timing of the glcd panel.

I had a look at the library code you are using and the code makes no attempt to ensure that the
timing is not violated.
Luckily it seems to be "mostly" working, but there are some places that look suspicious.


Try adding these to the code in MGLCD.cpp
(I can't test it, but here are some changes I'd make)

in _read_data() it needs time to honor tacc6 to allow the data bits to be ready to read so change this:

Code:

*P_RW |= B_RW;
*P_EP |= B_EP;

if (!dummy)

to this:

Code:

*P_RW |= B_RW;
*P_EP |= B_EP;

asm("nop");
asm("nop");
asm("nop");
        asm("nop");

if (!dummy)

And _send_com() and _send_data() while the datasheet doesn't say it needs it,
I would put a bit of extra time for  tEWHW.
so change this:

Code:

*P_EP |= B_EP;
*P_EP &= ~B_EP;

to this:

Code:

*P_EP |= B_EP;
asm("nop");
asm("nop");
*P_EP &= ~B_EP;

This assumes the datasheet is correct and that the processor is running at 16Mhz.

--- bill