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
Any idea of minimum safe pixel clock for an 800x600 TFT LCD?
Started by ●April 6, 2004
Reply by ●April 6, 20042004-04-06
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
Reply by ●April 6, 20042004-04-06
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
Reply by ●April 6, 20042004-04-06
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!
Reply by ●April 6, 20042004-04-06
> > 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.
Reply by ●April 6, 20042004-04-06
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. YouActually 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.
Reply by ●April 6, 20042004-04-06
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.
Reply by ●April 6, 20042004-04-06
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 :)
Reply by ●April 7, 20042004-04-07
"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
Reply by ●April 7, 20042004-04-07
> 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