Pages: [1]   Go Down
Author Topic: "Bad Data" from LCD  (Read 952 times)
0 Members and 1 Guest are viewing this topic.
Offline Offline
Newbie
*
Karma: 0
Posts: 2
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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... ;-)   )
Logged

United Kingdom
Online Online
Tesla Member
***
Karma: 224
Posts: 6614
Hofstadter's Law: It always takes longer than you expect, even when you take into account Hofstadter's Law.
View Profile
WWW
 Bigger Bigger  Smaller Smaller  Reset Reset

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.
Logged

Formal verification of safety-critical software, software development, and electronic design and prototyping. See http://www.eschertech.com. Please do not ask for unpaid help via PM, use the forum.

Offline Offline
Newbie
*
Karma: 0
Posts: 2
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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. :-)
Logged

Dallas, TX USA
Offline Offline
Faraday Member
**
Karma: 67
Posts: 2694
View Profile
 Bigger Bigger  Smaller Smaller  Reset Reset

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
Logged

Pages: [1]   Go Up
Jump to: