Colour STN graphic LCD is doing my head in.

[Blueteeth]

Hi,

As usual the holidays have made me revisit a project I abandoned long ago. I couldn't remember exactly why I abandoned it.. until I started working on it again. I have a colour STN (CSTN) lcd display, 320x240, the SX14Q004.

After successfully knocking up some generic cheap monochrome LCD controllers using CPLD's and SRAM I wanted to try getting this display working with 256 colours. Anyone who knows about CSTN's knows you can only turn the R,G or B subpixels of a 'pixel' on or off, each frame, so unlike TFT/active displays - you can't simply give each pixel an 8-bit number (or 16-bit, or 24-bit like most TFT's which take a byte per colour for each pixel).

It became pretty clear that some sort of modulation/PWM of each pixel is used in order to achieve 'gray-scaling' of each colour to get an RGB mix, and *that* is what I'm stuck on. Say I use 8 sub-frames for frame, meaning each pixel has 8-level PWM (3-bit per colour). Rather than store all 8 subframes in ram (320x240 x 3 bits = 28.125kbytes per frame -> 225kbytes) I tried to be a clever clogs and just store one byte per pixel.... in the format RRRGGGBB. - with just two bits for blue. Along with a frame counter that counts from 0-7, I read in a pixel byte, compare each of 3/2-bit colour values with it, and get a 'yes/no' for each colour, for that pixel - essentailly low resolution PWM. However... the data format for the LCD is tough, because it reads in 8-bits, which includes two whole pixels (R,G and B for each pixel) plus the R and G of the next...

This means, for every 3 bytes I send to the LCD display (3 x 8 bit = 24 bits = 8 pixels), I need to read in data from the SRAM for 8 pixels (which is 8 bytes). As 3 and 8 don't go well together, the timing is confusing me no end.

Does anyone have any examples/descriptions of this or something similar? Preferably in a hardware description language, or code, or even a nice diagram? Google has provided hints from various LCD contorllers manufacturers, but happily skip over the actual method used.

I realise this is why Epson made their controllers, and I have a few, but thought it would be a handy exrecise in getting back into programmable logic. Alas, its making me tear my hair out.

Random question I know, but after googling for an hour, I tend to come here

 

[Blueteeth]

Ook, answering my own post seems a bit silly, but I'm sure it can't hurt on the off-chance someone else is designing LCD controllers with CPLD's - more info the better eh?

I managed to get a test pattern up and running, but using a 'back porch' on the horizontal and vertical pulses. Essentailly, adding more pizels per line, and adding more lines. I know often these delays/extras are added by the controller to slow down the frame rate to fit into the 60-80Hz range when using different oscillators, but it seems that this LCD (and probably all) require it.

So, with a 320x240 Colour STN, there are 120 LCD writes per line (each write is a byte = 8*120 = 960, divided by 3 for 3-bits per pixel = 120), I'm writing 128. So thats 8 'dummy writes' at the end of each line. Also, I'm writing 244 lines - so thats 4 dummy lines.

With a burst of 4 reads from RAM, I then write a byte to the display. Another burst of 4 reads, leads to another LCD write. Finally, a delay period of 4 reads, then the last byte is written. Thats 8 RAM reads = 3 bytes written to display = 24 bits = 8 pixels. The gap between the second and third byte write to the display is used as a window to write to the ram, so one can write to the controller every 8 pixels. This is quite frequently meaning there is no need for a FIFO for incoming data, and a microcontroller would struggle to write any faster than this anyway. (every 3.6uS).

So far, looks like the entire thing will just about fit into an XC9572XL CPLD. I'm afraid 64-macrocell devices just aren't big enough, although would be fine for a monochrome 4-bit display up to 640x480. With the XC95144XL I'm using, I have room for a status register, config register, and the posibilty of display rotation (memory is arranged as 0-512 pixels/bytes per line, with 0-256 lines) - so one could just increment the 'line' part of the memory address, instead of the 'pixel' part, meaning the display is rotated 90 degree's.

Because of the distinct lack of examples on the web - ones that aren't designed to fit into a massive FPGA - I am hoping to put this up either in here, or on a website. My design isn't particularly special, although I'm quite pleased with myself that it fits into relatively small/cheap programmable logic devices And if one already has the facility to work with CPLD's, its a hell of a lot cheaper than current LCD controllers. (S1D13700 is $9, SSD1906 is around $15, vs $3 for a 64 MC CPLD).

Next port of call is an actual screen photograph, then a full edsign for some Planar EL displays.

Apologies for using this forum as a 'platform' for my own blog-like rambling. But hopefully someone can get some use out of it.

Blueteeth.