Connect with us

Any idea of minimum safe pixel clock for an 800x600 TFT LCD?

Discussion in 'Hobby Electronics' started by Josh Lowe, Apr 6, 2004.

Scroll to continue with content
  1. Josh Lowe

    Josh Lowe Guest

    Howdy all,

    I'm an undergraduate Computer Systems Engineering student in Western
    Australia, and need, as part of my final year to project, to interface
    a 12.1" 800x600 TFT (Toshiba LTM12C275C)to either a C6711 DSP or a
    Mitsubishi M16C micro.

    I'm finding the thought of interfacing the display to the DSP more
    elegant conceptually, but altogether more scary in terms of
    implementation, largely due to the lack of general purpose IO pins and
    the attendant need to interface the LCD to the External Memory
    Interface data bus. (BTW, if any of you guys have suggestions of a
    reasonable way to do this, it would also be appreciated).

    As such, I'm hoping to interface the LCD to the M16C, which is much
    more microcontroller-ish but also _much_ slower than the DSP (16Mhz vs

    The LCD uses an 18 bit data interface (6 bits per colour) with a pixel
    clock (NCLK) to latch the colour information into each pixel and an
    Enable line which is high for the duration of the displayable pixels
    on a line, but low for the horizontal and vertical blanking periods.

    My question is this: if the M16C is used, and is to have any hope of
    performing tasks in addition to driving the LCD, what is the lowest
    pixel clock which is likely to be safe? On the datasheet for the TFT
    itself, a note below the timing specs says (without giving specific

    "Don't fix NCLK to "H" or "L" level while the Vdd is supplied. If NCLK
    is fixed to "H" or "L" level for certain period while ENAB is
    supplied, the panel may be damaged".

    My concern is that if I use the M16C, and slow down the pixel clock to
    2 or 4 MHz to free it up somewhat, I risk causing the above damage.
    Given the cost of the panel, I imagine my supervisor could be a mite

    I look forward to being on the receiving end of your collective

    Thanks very much,
    Josh Lowe
  2. Sounds ominous...
    With a warning like that, it sounds like the NCLK line is doing more
    than simply shifting data - it may be tied into the LCD multiplex and scan.
    You don't say what you want to display on the LCD, but I'd make these
    comments :
    - Any uC is going to have trouble keeping up with pixel clock rates,
    - Best solution is 'dual port memory', which is std VGA card scheme,
    where silicon hardware scans (reads) the display memory every frame,
    in a very predictable way, and the uC can write when it likes,.
    - Anything that has explicit clock-rate warnings should not be connected
    to a software dependant layer.

  3. Hi Josh,

    Usually there is minimum refresh rate or pixel clock in the datasheet
    for your LCD.

    Fixing NCLK: if you stop shifting the bits, the display image isn't
    anymore refreshed, a usually black line shows up, because now you have
    applied a DC voltage to the LCD panel.
    These panel don't like DC voltages at all.
    You should avoid stopping the clock for more than a few milliseconds or so.

    I have made a project, where a small PIC processor scanned an LCD display.
    It scanned "full power" in the main loop to achieve satifactoy refresh
    rates. When an interrupt occured, I processed it (just a few ms) and
    then continued scanning.
    The effect was barely visible on the display.

    Wolf, visiting "down under" soon :)
  4. CBFalconer

    CBFalconer Guest

    You are worrying too much. The clock will never stop. Think of
    the enable as the sync pulse on a black and white tv signal. You
    may need to serrate the vertical sync for the same reasons as a tv
    does. You need no color carrier or back porch. You need to know
    the time needed for a horizontal sync, in terms of clocks, which
    expands the 800 number. Then the vertical sync, in terms of
    lines, expands the 600 number. From this you get a range of
    suitable refresh rates.

    Now worry about failures and how they leave the enable set.
  5. I'm an undergraduate Computer Systems Engineering student in Western
    "Interfaced to" does not necessarily mean "driven directly by". Have
    you considered using external hardware - an FPGA or an ISA-esque LCD
    controller, for instance - to drive the LCD? Dual-ported RAM and an
    FPGA is one option, but using something like the S1Dxxxx series of
    controllers from Epson is another. The debug cycle for either of these
    paths has downsides... Personally I prefer the Epson route solely
    because the debugging is all software hackery, whereas the DP RAM will
    mean a lot of time playing with the scope and logic analyzer :)

    The inherent danger in using out-of-spec clocks on LCDs is that the LC
    material will be electrolyzed by applying a constant-polarity voltage
    for too long.
  6. [/QUOTE]

    Not exactly a difficult process to interface, the real issues are more
    often the transfer of data and how to handle icons, screen colours in the
    software layer.

    Pretty standard for most LCDs, 6 bits per colour, clk, enable and if lucky
    H and V Sync.

    Work out how many TOTAL pixels are displayed (blanked and non blanked),
    for a 50Hz or 60Hz refresh rate on 800 x 600, typical vertical and
    horizontal blanking times and total pixels per line are normally given
    on the datasheets.

    Considering the normal pixel clock rate for an LCD is in the region of
    30 to 60 MHz (depending on resolution etc..) a dedicated piece of
    hardware is normally used (even on 2GHz machines) to continuously read out
    a frame buffer, which is dual ported to the processor.

    If you can add a hardware DMA or bit blitter to copy large areas of
    external memory or another part of the frame buffer to the active
    frame buffer, you will also help yourself to better performance from
    either the DSP or the M16C.

    Just have the clock as a continuous clock, from an oscillator source
    or buffered or subdivision of another clock. Basically just make sure
    it is a continuous clock.

    I would not even bother using the M16C to directly drive the LCD as your
    refresh rate will be abissmally slow, and you may have problems viewing the
    image (image fade).
    Actually it is more akin to the combination of V Sync, H Sync and
    BLANKING. Having had to create interfaces to many different LCDS for
    real time video display at 50Hz.
    Badly worded....

    You know 800 ACTIVE pixels per line
    600 ACTIVE lines per frame

    You should know your refresh rate (target at least), some of which is
    determined by the TFTs data spec on response time and persistence for a

    The data sheets normally give some figures for min and max TOTAL pixels
    per line, and min and max TOTAL lines per frame, if not they will specify
    these items as blanking intervals.

    From these you can work out your timings

    Pixels per line TOTAL = H blanking interval + Active pixels
    = H blanking interval + 800

    Lines per frame TOTAL = V blanking interval + Active Lines
    = V blanking interval + 600

    The MOST important thing about these types of interfaces is that once you have
    established the timing regime make sure that it is rigid, so from one frame to
    the next there is EXACTLY the same number of pixel clocks for the inactive
    periods. Even one clock cycle extra/less between two consecutive frames can
    cause some interesting effects on the image as the vertical then horizontal
    timing is decoded internally from the enable signal. That is the voice of
    experience from a video point of view, on the same interface setup from
    the saem manufacturer.
    If you have a continuous clock there is no problem.
  7. Unfortunately for this type of display if that update was done once a minute
    it would be fine, multiple times a second and it screws up the LCD timing.
    These enable signal which is actually a combined H and V Sync and Blanking
    signal are then decoded to give internal H and V drives, so even one pixel
    difference on a line or frame causes jitter of the image. Do that sort of
    interuption too often and you will notice it.
  8. Josh Lowe

    Josh Lowe Guest

    Thanks to all for your replies - the project is an enhancer for the
    visually impaired, comprising an image source, DSP + possibly a micro,
    and the LCD - it will enhance a video stream to make reading and the
    like easier for those with general sight problems and also who have
    difficulties with low-contrast colour combinations... thus the display
    will essentially be showing a video stream, and potentially a rough
    menu of some sort.

    The total area including the blanking intervals would be 860*615).
    Since 860*615=528600 NCLK/frame, using a 16MHz micro would probably
    only allow an 8 or 4Mhz NCLK to be generated, giving ~15 or 7.5 fps,
    respectively. I'm happy enough with that admittedly abysmal frame rate
    (the project is just a proof-of-concept and we're somewhat limited in
    terms of available hardware and budget), but if a low NCLK (period of
    ~125-250nS) is going to cause damage to the LCD, I'll have to find an
    alternate way. The alternative would probably involve using some
    programmable logic as a line buffer tied to the memory bus of the DSP.
    As I said before, the DSP approach appeals to me in terms of elegance,
    but if the M16C can be used at all, that is likely to be the

    As far as the clock source goes, it would be derived from a clock
    output on the chip (either a divided-down version of the system clock
    or an output from a timer set up for this task), so it would be
    continuous. Ultimately

    BTW Wolf - good to see the travel plans :)
  9. And where down under might you be visiting?
  10. On 6 Apr, in article
    Then you will meet some interesting challenges for your project.
    'Line buffer', I would simply use a frame buffer with dedicated hardware
    control that can fit in a small FPGA/CPLD to control the frame buffer.
    Even possibly using a double frame buffer if your update rates are
    slower than refresh rate of the LCD. This is not a costly thing to do
    and with Video RAM devices or similar could be quite small in board area.
    That way you can have your continuous clock from power up.
    If you use the M16C, it will probabbly for setup/control/menu OSD control
    whilst the DSP is doing the grunt work of video processing. Last bit of
    real time enhancement onto LCDs I did recently had dedicated hardware and
    CPLDs controlling video in through to LCD, the onboard micro dealt with
    setup, mode changes, backlights and user interaction.
    If the software hangs or you are debugging the startup and have the LCD
    connected, you could end up with the clock not running for a period of time.
  11. Josh Lowe

    Josh Lowe Guest

    Thanks for the electrolysis explanation guys. Makes that operating
    danger somewhat clearer. Paul - I'm going to see whether we have any
    decent FPGA EVB's around which I can play with - it look as though
    setting up an external controller would be brighter (and ultimately
    easier from the DSP/M16C side of things).

    Given that the memory interface for the DSP can interface to async
    memory devices as well as SDRAM, I guess the operating frequency of
    the programmable logic is not likely to be a problem.
  12. On 7 Apr, in article
    One book you may find useful on video, filtering and digital design
    (if you can find it) is Video Demystified by Kieth Jack of Brooktree
    ISBN 1-878707-09-4, which covers digital decoding and encoding including
    genlocking of video.

    This should at least help you with understanding of colour video
    standards and conversions, interlace to non-interlace conversion.
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.
Electronics Point Logo
Continue to site
Quote of the day