SED1335 LCD Controller: Screen Disturbance

I use a Sharp 79524 with an on chip LCD controller reading, via DMA, from SDRAM so this may not be at all relevant to you. However, when I was running VGA at true colour and running code from flash then there wasn't quite enough time to keep the screen updated and I got exactly the little lines that you describe. If I was running cached code then everything was fine but pulling anything from flash caused considerable horizontal jitter.

Are you absolutely positively sure that nothing is interfering with the busses while the screen is refreshing? Perhaps this is not a relevant question where your controller is concerned.

Maybe the flickers are always white. What is the default state of the pixels?

Not me, I'm afraid. So feel free to ignore me.

Hello Tom,

The problem only occurs when my micro writes to the controller (which then stores the data in local RAM). When I am not writing to the controller, it's normal fetch-draw cycle has no problems. I understand that this controller doesn't halt screen refresh when memory is being updated, hence the interference when you write data; the controller copies the data in at the same time it's being used for updating the screen (like I say, so I understand!).

I don't think anything is interfering with the buses, the controller is part of an "off the shelf" LCD module, so I would imagine it's been put together by someone who knows what they are doing...(!)

Default state of pixels are off, i.e. "green".

Thanks for the reply anyway!

Regards, Richard.

Can you just flip the front polarizer and run the framebuffer in "positive" mode?

I had the same problem with another SED controller about 10 years ago. The faster I wrote to memory, the worse the problem. I could never get a satisfactory answer from Epson/Seiko. The best explanation I ever received was that a "cursor" was being drawn each time you modified the controller's memory.

Fast-forward to the present and I am using a S1D13700 (same as SED1370?). Guess what, it still has the same problem. It is not as bad as ten years ago, but still there. My workaround was to minimize the cursor size, which is possible on the S1D13700.

This is a nasty problem. I wish I knew a real solution.

I doubt it, the module comes "off the shelf", I don't think I'd be able to get away with this kind of hardware mod to solve such a minor problem!

R.

It's not a massive problem, in fact nobody else on my project has even noticed/commented on it. I just want to be at a point where I can say I've done all I can and it can't get much better, should a question ever arise...

I do find (as you say) that the faster I write to the module, the worse it gets.

I will try minimising the cursor size and see what happens, thanks for that, although I *may* be using the smallest cursor already!

Cheers, Rich.

Another workaround is to use the slowest-responding LCD your application can tolerate. Pixels that change only for a short time will not be seen at all.

I am using a module that is a combined SED/LCD unit so have no flexibility. It's not a huge issue, but I just want to feel like I've explored all avenues!

R.

He could use a thermoelectric cooler to chill the display, and thus slow it down.

Best regards, Spehro Pefhany

A fridge you mean? ;)

R.

This is caused by writing in the active refresh time.

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.

(at

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

get

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

Peter

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

Its caused by writing to the video ram at the same time as the controller is reading from it. You should be able to write at the end of the line, or at the end of the frame. Some controllers let you slow down the clock to give you more time. You may even be able to disable the display for a whole frame period if you need to write a lot of data.