Hacking the ultra-cheap Sparkfun TFT LCD

Sparkfun super-cheap QVGA LCD  hacking progress....

Resources : Datasheets for other drivers that may have a few similarities, but don't let the closeness in part numbers fool you...

Pinout details HD66781  HD66789  HD66773,66780 and 66787 datasheets are at http://www.datasheetarchive.com/
Sparkfun forum thread

DATASHEET FOUND!!! hd66790 Datasheet

Info below is all I know so far. Last update 18 Sep 2008. Lunchtime GMT. 

Best image to date : (assorted waveforms being thrown at RGB, G channel varying delay down the frame to produce diagonal)

Please DO NOT ask for code examples or ask dumb questions like how to send SPI commands, where to get a connector, how to power the backlight, how to connect it to an Arduino etc. etc.  If you need to ask things like this, please wait until people have figured out all the hard stuff for you.

Any helpful data/results of experimentation/corrections/suggestions please email.  Most values have been hand-tested so errors are likely!

Connector is designed to be soldered, so don't bother looking for an FFC connector for it. You may be able to improvise something using a SODIMM socket as it has the same pitch.

The small 1.1" LCD, HD66782 based LCD  is possibly similar, and is likely to have its SPI ID tied low, so commands would be 70 to set register index, 72 to write register value. I think this display has RAM so setup likely to be somewhat different. This datasheet has a setup sequence for a different LCD that uses the same driver  chip.
This LCD is too small to be of interest to me so I will not be investigating, but if any one finds any info I'd be happy to add it here or link to it.

Display has no RAM, hence needs a continuous stream of 'video' data via RGB port, DE, Hsync.Vsync and DOTCLK. DE low indicates the active part of the HSYNC period.

When thinking about sync pulses etc., Remmeber that this display is 240 wide x 320 high, i.e 320 lines per frame...

Setup is via SPI interface  :

Take SLCD_CS low, write 3 bytes via D_SCL, D_SDA, then take SSEL high.Data clocked on rising edge of D_SCL ( NB this is SPI, NOT I2C as may be inferred from pin names). MS bit sent first.

To write a register, send ( all hex)  74 00 rl to set address, then send 76 dh dl to write data. Reg address does not auto-increment.

e.g. to set register 6 to 0823 send : <SSEL Low> 74 00 06 <SSEL High> <SSEL Low> 76 08 23 <SSEL High>

Suggested Initialisation sequence so far - UPDATED in light of datsheet
All tests have been done at 3.3v supply - some of the power supply setup may be more critical to get best contrast at lower voltages.

Assorted random notes

It appears to be able to get the driver into a state that requires power-cycling to recover.

HS and VS appear to only look at falling edge - low width seems to have no effect.

HS period can be extended with no obvious effect (apart from effect on framerate) - using PCLK*256 may simplify drive logic. Hsync width = 128 PCLK would also probably simplify things as it could be bit 7 of the pixel clock counter.

DE looks like it can be held low continuously, however I don't yet know if this may cause addressing issues - e.g. pixels at edges not displayable, or rows lost in the VSYNC back porch.

<Ignore stuff below now the datasheet is found - left for historical interest....)