Idea of Minimum Safe Pixel Clock for an 800x600 TFT LCD

Reply to Thread

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

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
periods):

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

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

Thanks very much,
Josh Lowe

 

Without knowing the duration of the blanking periods I can only make a
rough guess at the minimum dot clock (doesn't the Toshiba data sheet
give a range for NCLK frequency?). If we assume a low refresh rate (say,
50Hz) we get a raw dot frequency of a bit less than 2.5MHz, which is in
the range you are thinking of. I doubt very much that the blanking
intervals eat half the bandwidth, so we have a hard upper limit on my
minimum dot frequency of about 5MHz. A more reasonable refresh rate
would probably be in the 60-70Hz range, which pushes the minimum dot
clock up to 3-6MHz, still within the range you are targeting.

My advice would be to aggressively ponder the data sheet for an evening
and then go talk to your advisor, who probably has some idea of the design
parameters for this device (or devices like it).

 

Thanks for your reply Jeff - Toshie's datasheet for the display
indicates a maximum NCLK of 40MHz, but omits any indication of a
minimum (the max clock period box has only a hyphen in it). The
blanking intervals should use about 10% of the bandwidth in total (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 in terms of frame rate (the
project is just a proof-of-concept), but if the low NCLK is going to
cause damage to the LCD, I'll have to find an alternate way.

 

An LCD segment gets activated only on a transition (in theory), and
the old black/clear ones will work on DC.
Therefore, there is no "minimum" clock rate; once per day would be
fine, but a bit hard to "read".

 

Robert Baer, it would do well for you to read the original post.

As far as the dot clock, (I didn't know LCDs had _blanking_!)
I wouldn't go below 6 MHz, as someone suggested, because below
that it'll start to flicker.

How much leeway do you have with hardware design? I'd think
a couple of VRAM chips and a little glue logic (a couple
of counters and gates, maybe a SR (unless it comes in the
VRAM) or a pipeline register to make it sexy) would give
you a perfect adapter, with no data bus rate requirements at
all. And since you can do practically anything you want to
with timings, (software, baby, software!) you don't need any
special sync generator chip or anything.

Have Fun!
Rich