Page 1 of 7

Connecting the LTD222QV-F01 2.3" QVGA LCD (LCD-08843)

Posted: Fri Sep 05, 2008 5:22 pm
by Narkaleptic
My currrent project is that I am determined to get the LTD222QV-F001 (the LCD being sold for a buck on Sparkfun) to display something pretty.

The connector is a ribbon with 33, 0.8mm contacts.

I don't have any wire small enough to solder directly to it without melting the ribbon (mostly a lack of skill and accuracy with an iron, methinks) and there are no readily available FFC/FPC connectors for 33-pin at 0.8mm (give or take a few pins). Pins #1 and #33 are dummies and #32 connects to the same ground as #31. So essentially 30-pin is doable with some scissors.

Because 34 is an even number (and I found a datasheet on an obsolete 34-pin 0.8mm FFC/FPC connector), I created a PCB sketch for it to convert to standard 0.1" pins.

Can anyone think of a way to connect the LCD to this board? Or if you have a better way for me to put it in my breadboard, that'd be fine too.

Click for 600dpi version
Image

28mm wide, 1.9mm deep
Image

Posted: Fri Sep 05, 2008 8:35 pm
by Dan_attacker
Well, if you are going to plug it in to a breadboard, then I'm not sure how your design would work because each column of pins would make contact with each other. You want one single row of 34 pins or possibly a layout resembling a DIP. Also, the trace going to pin 17 isn't quite centered on the via. But, I guess other than that, I can't think of much more for a simple breakout. I just ordered 10 of these LCDs also, so eventually I'll get around to hooking them up, but I'm busy with getting the PSP LCD working at the moment.

Posted: Fri Sep 05, 2008 10:07 pm
by Narkaleptic
I plan to run wires from the PCB (or ribbon directly, if possible) to the breadboard.

Posted: Fri Sep 05, 2008 11:54 pm
by lain
Hey guys, good to know someone else is also working on this. I've got mine wired to a Digilent Spartan-3E FPGA dev board, I'm actually running the LCD on 3.3V rather than the datasheet's mentioned 2.5V, however it should be within spec (max is listed as 3.6V). I've whipped up some verilog that should generate HSYNC, VSYNC, and DOTCLK signals and some colors to display, however it does nothing.. I've been playing with the code on and off the past couple days to no avail.

I can see the LCD display some 'junk' (a few barely visible colored lines) briefly when I send it a reset pulse after power is applied. This leads me to believe the unit is at least functioning and I'm just controlling it wrong. Currently my DOTCLK is operating at 5MHz, I've also tried 6MHz (datasheet recommends at least 4.8MHz or so). I think the problem is the need to send it some initialization commands before using it, as 'dv' mentioned in the comments on the product page. I've tried blasting out some data over both the parallel and SPI ports, mostly guessing here.

I'm a little confused as to how the pins at the flex cable map to the bumps on the driver, for instance the driver shows an SPI data out pin, but that apparently isn't broken out to the flex cable. As far as I can tell, you have to control the "RS" pin to select a register so you can read or write from/to it, but I don't see an RS pin on the pinout... Am I missing something?

I'd be glad to share more information, but I'm afraid I am at a loss for now.. suggestions welcome and good luck to everyone else trying to get these things up and running :)

Posted: Sat Sep 06, 2008 12:26 am
by Dan_attacker
Oops, sorry i didn't know you were going to use a ribbon cable.

I'm also using a Spartan-3E FPGA right now for my PSP lcd, but I have no problems sharing code when (if) I get these QVGA lcds working. Good luck.

pin driver

Posted: Sat Sep 06, 2008 5:56 pm
by dv1
It mentions in the spec sheet that the booster circuit of the controler must be used for proper pin voltage. I assume this is controled by one or more of the registers and needs to be programmed.

Posted: Mon Sep 08, 2008 4:23 pm
by mikeselectricstuff
I've done some initial playing around... a few observations etc...
Yes, it will need a bunch of SPI commands to turn on the DC/DC converter(s) and set up teh drive timings & voltages.

On startup, the converters are off, however when viewed at an extreme angle, some vertical lines etc. can be seen, and these do react to changes in hsync timing, but not in any obvious or consistent way. It does not appear to react to changes in the input RGB data.

All the other HD66xxx controllers share the same SPI format and 'start oscillation' command, the only unknown being how the ID pin is tied, which determines the required state of bit 2 of the ID byte. However I've yet to get any response to any SPI commands sent in this format ( I've been monitoring power draw to look for any changes in response to commands).
One major difference between the 66790 and others is the lack of on-chip RAM, which in turn means it may be expecting pixel clock to always be there, and hence may not have an internal oscillator - this may mean things work significantly differently.

Posted: Tue Sep 09, 2008 2:47 pm
by doctek
The SPI seems like the way in to me - simplest approach. So I'm thinking I'll implement an RS-232 to SPI interface using an ATmega168 and Atmel Apps note AVR303 "SPI-UART Gateway".

The SPI protocol is described on pages 125 to 127 of the HD66781 document. The instructions appear much earlier. I think the first one I'll try will be to read Register R0x0000. This should read back as 0x0781 - an ID. The value for the HD66790 may be different, but it should be consistent. If I can't read that reliably, then I don't think much else is going to work.

I'm hoping to get my Sparkfun shipment today and will start implementing the Interface with the ATmega168.

This project has a high "coolness" factor, but it could just be the path to a lot of frustration. Hopefully with several folks working on it, we'll crack it.

Posted: Tue Sep 09, 2008 3:03 pm
by mikeselectricstuff
doctek wrote: The SPI protocol is described on pages 125 to 127 of the HD66781 document. The instructions appear much earlier. I think the first one I'll try will be to read Register R0x0000. This should read back as 0x0781 - an ID. The value for the HD66790 may be different, but it should be consistent. If I can't read that reliably, then I don't think much else is going to work.
Problem is the SPI DOUT pin is not bonded out, so reading from the device isn't possible without getting the chip off the glass and wafer probing (unless it's there as a test-point on the flex, which seems unlikely). And if you could read it you might expect to see 790, not 781...
All the other devices I've got data on share a 'start oscillation' command, which ought to show at least a step in current draw and some funky voltages appearing on the caps on the flex, however as I mentioned above, the lack of RAM may mean this device doesn't have a self-oscillating mode as dotclock whould always be there.

Posted: Tue Sep 09, 2008 8:44 pm
by doctek
Your right - at least SDO isn't cabled out - it might be pinned out. (Hadn't looked closely since I'm still waiting for my shipment.) 790 seems like a good guess for the ID, but I'd be open to any stable value. Need more of the data on the HD66790. Without it, we're pretty much in the dark.

Since there is a little more data on the HD66782, maybe that's the place to start. SDO still doesn't come out the cable, but the Tosh/Mats data seems to imply that SDO might be accessible from the chip. I don't know if it's possible to get to the chip itself however. There's also the little matter of the mode control bits. They don't seem to be available either, so how does one put the thing in SPI mode anyway?

Maybe we just bought some coasters?

Posted: Wed Sep 10, 2008 12:52 am
by mikeselectricstuff
doctek wrote:There's also the little matter of the mode control bits. They don't seem to be available either, so how does one put the thing in SPI mode anyway?
As SPI is the only interface connected to the flex connector, the mode control pins will have been tied correctly for SPI mode.

Posted: Wed Sep 10, 2008 11:04 am
by doctek
This is a good insight! I was confused by the Data (R5:0,G5:0,B5:0) lines, thinking they could be used as the Control in an 18 bit format. But now I realize that's wrong. These lines are only for pixel data to go with DotClock and the syncs. Config and control comes over the SPI lines. Makes sense.

Now I'm slightly more encouraged - and certainly on a better path. Thanks.

Posted: Wed Sep 10, 2008 11:07 am
by Random
Out of interest, how are you guys connecting to your LCDs? I've also got one here and an ARM that should be able to talk to it, but I've not yet wired it up physically. I do have some 30 AWG wire that would work to connect to even the small screen, but I'm not sure it's the most practical solution. I'd love to make a 0.8mm PCB for it but all I can get is 1.6mm PCB stock.

Posted: Wed Sep 10, 2008 12:08 pm
by mikeselectricstuff
Possibly a little premature to claim 'first light', however I can consistently make it do this:Image
After a 'brute force' approach of throwing tons of random SPI commands at it and waiting for a supply current change, I've determined that the
SPI interface does appear to be similar to the others. It seems to like 3 byte commands (CS low for all 3 bytes.)
DC/DC converter does need pixel clock and/or syncs present to run as I suspected earlier.

Send 76 00 nn, (hex) where nn has any of bits 1 to 3 set & bit 0 clear turns on the DC/DC ( VGH pad on flex goes to about +25V).

Once DC/DC is on, display does react to changes in sync timing. I'm currently sending some fairly arbitary sync timing - will play with this later. Note that extended time with DCDC on and rest not set up and/or bad sync, panel damage might occur due to electrolysis.

Sending 74 00 00 prior to the above command has no effect, but 74 00 <anything but 00> makes above command not work, suggesting it is the register select as per the other chips (and that the address register is 00 on reset).

Incidentally there is data on HD66787, 66773 and 66780 at
datasheetarchive.com which may be worth a look.
I'm away for a couple of days now but will resume playing at the weekend.

PS. for anyone looking at the small LCD, I'd put money on the corresponding SPI commands being 72 and 70 - ID line tied low so both controllers can be addressed on the same SPI bus.

HD66790 datasheet search progress update

Posted: Thu Sep 11, 2008 6:18 am
by Narkaleptic
I've been probing around for a datasheet on the HD66790. Renesas replied with:
Renesas Technology no longer sells or supports LCD controller/drivers. Please contact Renesas SP Drivers:

http://www.rsp.renesas.com/en/index.htm
I emailed Renesas SP Drivers Inc and haven't gotten a response, so I followed up with the first distributor on their list, AllAmerican:
Renesas has spun off the LCD driver group to a new Company in partnership with Sharp and Power Chip. It is still in a state of flux and I am not going to be able to support you. I guess that's why there isn't any info.
AllAmerican is still going to check a couple of resources. I'll keep waiting for Renesas SP Drivers Inc. Anyone not mind a long distance call to Tokyo? http://www.rsp.renesas.com/en/inquiry/inquiry.htm

On a side note, bravo mikeselectricstuff!