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

[Josh Lowe]

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

 

[Jim Granville]

Josh Lowe wrote:

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

Sounds ominous...

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!

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.

-jg

 

[Wolfgang Mahringer]

Hi Josh,

Josh Lowe wrote:

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

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.

HTH
Wolf, visiting "down under" soon

--
From-address is Spam trap
Use: wolfgang (dot) mahringer (at) sbg (dot) at

 

[CBFalconer]

Josh Lowe wrote:

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

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.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

 

[Lewin A.R.W. Edwards]

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.

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

 

[Paul Carpenter]

On Tuesday, in article <407289AF.5A1CFE5C@yahoo.com>
cbfalconer@yahoo.com "CBFalconer" wrote:

Josh Lowe wrote:
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.

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.

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.

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

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

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.

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

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.

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

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

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.

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.

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

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.

Now worry about failures and how they leave the enable set.

If you have a continuous clock there is no problem.

--
Paul Carpenter | paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/> Main Site
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info.
<http://www.badweb.org.uk/> For those web sites you hate.

 

[Paul Carpenter]

On Tuesday, in article
<l6wcc.23$xx1.267469@news.salzburg-online.at> yeti201@gmx.at
"Wolfgang Mahringer" wrote:

Hi Josh,

Josh Lowe wrote:

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

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.

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.

HTH
Wolf, visiting "down under" soon

--
Paul Carpenter | paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/> Main Site
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info.
<http://www.badweb.org.uk/> For those web sites you hate.

 

[Josh Lowe]

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

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

 

[Meindert Sprang]

"Josh Lowe" <joshtlowe@yahoo.com.au> wrote in message
news:ff40ef64.0404061848.32b8a211@posting.google.com...

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

When this clock is needed all the time to prevent electrolysis of the LCD, I
am inclined to think that the frequency of the clock is not all that
important. The important issue is that it is always there, with a 50%
dutycycle, in order to have a DC level of 0. A DC level is what is causing
electrolysis. Would that be a fair assumption?

Meindert

 

[Andrew Jackson]

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
preference...
If you are going to use an M16C then your best hope for a reasonable display

lies with the M16C's DMA. The best that this can do is 16 bits every two
cycles. Given that the LCD requires 18 bits you might also choose to
sacrifice the LSB of each pixel to fit within the DMA constraints (it would
also reduce your circuit complexity). Using DMA would mean that you get a
consistent data feed. Even with a relatively low frame rate I suspect the
persistance of the LCD itself will help you. (I think that Meindert is
correct in that you only need the 50% duty cycle to prevent damage.) There
are a couple of difficulties with DMA: the transfer length is limited to
128k (for 16 bit transfer) and, of course, the CPU is stalled while the
transfer continues. Therefore, it might be better, as others have said, to
have the DMA feeding a small dual ported "RAM". A small FPGA would suffice,
and that could generate all your video timing for you too.

Andrew

 

[The Real Andy]

"Wolfgang Mahringer" <yeti201@gmx.at> wrote in message
news:l6wcc.23$xx1.267469@news.salzburg-online.at...

HTH
Wolf, visiting "down under" soon

And where down under might you be visiting?

 

[Paul Carpenter]

On 6 Apr, in article
<ff40ef64.0404061848.32b8a211@posting.google.com>
joshtlowe@yahoo.com.au "Josh Lowe" wrote:

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.

Then you will meet some interesting challenges for your project.

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.

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

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

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.

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

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.

--
Paul Carpenter | paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/> Main Site
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info.
<http://www.badweb.org.uk/> For those web sites you hate.

 

[Josh Lowe]

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.

 

[Paul Carpenter]

On 7 Apr, in article
<ff40ef64.0404072029.61f08c5c@posting.google.com>
joshtlowe@yahoo.com.au "Josh Lowe" wrote:

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.

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.

--
Paul Carpenter | paul@pcserv.demon.co.uk
<http://www.pcserv.demon.co.uk/> Main Site
<http://www.gnuh8.org.uk/> GNU H8 & mailing list info.
<http://www.badweb.org.uk/> For those web sites you hate.