Re: SED1335/Densitron LM4733 LCD Module
- From: John Devereux <jdREMOVE@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 16 Mar 2006 21:14:17 +0000
"Richard Phillips" <raphillips@xxxxxxxxxxxx> writes:
Hello,
I'm looking for some help, I've written some code for this LCD module that
uses the SED1335 controller, and am 99% there, but I'm experiencing a bit of
a problem. I am aware this could well be just a driver coding issue of my
making, but I've almost exhausted all avenues of investigation now so am
hoping that the symptoms of my problem will ring a bell with someone out
there.
Basically I am drawing a bitmap on screen (approx 50 * 50 pixels), row at a
time, using the "command byte+stream of data bytes" (per row) method.
Sometimes a problem occurs where an additional 8 (or so) pixels can be
written on the end of the row. It *appears* that an extra byte has been
inserted during the row write for some reason, since the first byte of the
row is always written correctly and the last few bytes seem to have been
pushed along by 8 (or so) pixels. I know this looks like a silly coding
error, but bear with me!! I've checked the WR strobe pulse and I am not
strobing it once too often or anything stupid like that.
What is extremely confusing though is that this behaviour becomes
better/worse under certain conditions:
1) It happens much less frequently if I disable the screen (using the
command) then do the write, then re-enable the screen, but this is
undesirable due to screen flicker.
2) It happens much less frequently if I write only one data byte per command
byte, i.e. "command byte+databyte+command byte+databyte...".
3) It happens much less frequently (and this is the biggest puzzler of all)
if the data bytes I send tend to comprise of mostly 0s! How can this be?!
My code should in theory work the same regardless of data byte values, I've
done a quick check for any unusual optimisations etc but can see nothing.
Exactly the same code runs in all cases, apart from the described
differences.
One other thing worth mentioning, when writing data bytes (following memory
write commands) I synchronise the writes with the status flag on D6 and
write no more than 4 data bytes before the next screen line draw. This
should not really affect write reliability anyway though, it's just to avoid
momentary distortion on screen.
If anyone out there can offer any advice about what's going wrong I'd be
grateful! I've looked at everything I can, the code looks fine, the timings
all look fine, it can run for about 15 hours and this problem might only
occur 3 times, but I am worried because I can't explain why it happens, and
of course it might occur 10 seconds after powerup, not really ideal!!
I don't really expect anyone to figure out my code for me, but I am hoping
that anyone who is familiar with either this module or this controller just
*might* have encountered this and know the root cause.
It does all sound like the typical things you get when the timing is
wrong. For example, changing the data at the same time as you apply
the clock edge that latches that data.
An alternative theory would be that the correct logic levels for the
part are not being met, or that a lot of noise is present.
All these things are consistent with the data-pattern-dependent
behaviour you see. You need to get a scope and look carefully at the
signals.
--
John Devereux
.
- References:
- SED1335/Densitron LM4733 LCD Module
- From: Richard Phillips
- SED1335/Densitron LM4733 LCD Module
- Prev by Date: Re: SED1335/Densitron LM4733 LCD Module
- Next by Date: Re: SED1335/Densitron LM4733 LCD Module
- Previous by thread: Re: SED1335/Densitron LM4733 LCD Module
- Next by thread: Core module
- Index(es):
Relevant Pages
|
