1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

SED1335 LCD Controller: Screen Disturbance

Discussion in 'Embedded' started by Richard Phillips, Jun 20, 2006.

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

    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.

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

    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!

    Regards,
    Richard.
     
    Richard Phillips, Jun 20, 2006
    #1
    1. Advertisements

  2. Richard Phillips

    Tom Lucas Guest

    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.
     
    Tom Lucas, Jun 20, 2006
    #2
    1. Advertisements

  3. 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.
     
    Richard Phillips, Jun 20, 2006
    #3
  4. Richard Phillips

    larwe Guest

    Can you just flip the front polarizer and run the framebuffer in
    "positive" mode?
     
    larwe, Jun 20, 2006
    #4
  5. Richard Phillips

    John Starr Guest

    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.
     
    John Starr, Jun 20, 2006
    #5
  6. 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.
     
    Richard Phillips, Jun 20, 2006
    #6
  7. 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.
     
    Richard Phillips, Jun 20, 2006
    #7
  8. Richard Phillips

    John Starr Guest

    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.
     
    John Starr, Jun 20, 2006
    #8
  9. 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.
     
    Richard Phillips, Jun 20, 2006
    #9
  10. He could use a thermoelectric cooler to chill the display, and thus
    slow it down.


    Best regards,
    Spehro Pefhany
     
    Spehro Pefhany, Jun 20, 2006
    #10
  11. A fridge you mean? ;)

    R.
     
    Richard Phillips, Jun 20, 2006
    #11
  12. 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.
    It is often possible to by panels that are inverted or not, in the same form
    factor.
    Its an old chip. I used used it years ago.
    Peter
     
    Peter Dickerson, Jun 20, 2006
    #12
  13. 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.
     
    Richard Phillips, Jun 21, 2006
    #13
  14. Richard Phillips

    cbarn24050 Guest

    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.
     
    cbarn24050, Jun 22, 2006
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.