Re: SED1335 LCD Controller: Screen Disturbance

Peter Dickerson wrote:
"Richard Phillips" <raphillips@xxxxxxxxxxxx> wrote in message
news:e78lk8$7k0$1@xxxxxxxxxxxxxxxx
Hello all,

I've been using this chip (built into an LCD module) for a while and
have the LCD inverted, i.e. background "black" and characters
"green".

I find that when I write info to the screen I often get very slight
disturbances (tiny horizontal lines) appearing on the screen that
vanish again almost immediately.

This is caused by writing in the active refresh time.

I have written my code so that it only updates the SED's memory
inbetween LCD screen-line writes (if I don't do this, the problem is
MUCH worse!) to minimise flicker.

This is a common problem. If you are writing to the controller when
it wants to read for refresh it substitues 0x00. So the problem is
much worse if you have mostly 0xFF. Doing the writes in the line and
frame sync is definitely the right thing. But be careful if you use
the line sync because this can be very short, so you don get much
chance for the update. Think interrupts! Suppose an interrupt comes
along when you have just decided there is time to transfer another
byte. The transfer gets delayed in the active part of the line and...

I found it better to only use the frame sync period since this is
longer. I program the controller for a relatively long sync (slightly
slower refresh) to give a larger proportion of the time available for
updating.

I am going to study how the timings are working out today hopefully,
although I know I did this when the software was originally written, by
calculation and with a scope.
I worked out that I had time for approx 5 or 6 writes at the end of each
line (I wait for the D6 status flag to change from 1 to 0 to ensure I start
writing my data at the start of the retrace period).
I have tried reducing the writes per line to just 1 and disabling interrupts
during writes. These things help a fair bit, but I can't seem to completely
remove the problem, only minimise it!

That's interesting what you say, about the controller substituting 0x00 when
there is a clash. I definately have mostly 0xFF.
I wonder if the controller does something similar if you are in the middle
of writing e.g. 8 bytes, you write 4 then stop for the line draw, then write
the next 4. I wonder if it does some substitution in this case, even though
I'm not actually writing at the moment it tries to read memory?

I will also consider changing the sync time, although the downside may not
be worth it (slower refresh).

I always use the line sync, I don't think I have access to frame sync via
the interface to this module.


I find that if the LCD is not inverted, the effect cannot be seen at
all (at the moment, the spec I am following requires inversion).

It is often possible to by panels that are inverted or not, in the
same form factor.

Does anyone have any experience of this problem with this chip? I
have poured over the device spec and can't see anything I can do,
it's not a terrible problem because the disturbance is only slight,
but I'd like to get it as good as possible!

Its an old chip. I used used it years ago.

I got the impression from reading old forum posts etc (it's proved hard to
find people using this chip, due to it's age?) that it's both an old chip,
and not particularly well thought of?!

Regards,
Richard.


Regards,
Richard.

Peter



.