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

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

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.

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.

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.