SED1335/Densitron LM4733 LCD Module
- From: "Richard Phillips" <raphillips@xxxxxxxxxxxx>
- Date: Thu, 16 Mar 2006 20:43:22 GMT
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.
Regards,
Richard.
.
- Follow-Ups:
- Re: SED1335/Densitron LM4733 LCD Module
- From: John Devereux
- Re: SED1335/Densitron LM4733 LCD Module
- From: Wolfgang Mahringer
- Re: SED1335/Densitron LM4733 LCD Module
- Prev by Date: msp430 MCLK doesn't work with XT2 clock source
- Next by Date: Re: Early C ?
- Previous by thread: msp430 MCLK doesn't work with XT2 clock source
- Next by thread: Re: SED1335/Densitron LM4733 LCD Module
- Index(es):
Relevant Pages
|
