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![Smile :) :)](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
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
Last edited: