Number of color on an STN screen

The problem with using a microcontroller to drive an LCD is that an LCD requires constant attention. This can be mitigated with a CPLD driven over SPI (using DMA, of course), but then you run into the other problem: Color LCDs require a lot of data. 320x240 in black and white is marginal at 9.6KB, but make it 24 bit color and suddenly you need to deliver 230KB of data in 1/60th of a second. (Don't forget, though, that you can get 4-bit, 16-color control just by tieing the low 20 bits to one setting). A 24-bit frame buffer no longer fits in onboard RAM on most microcontrollers, and you probably don't have time to read from an external RAM chip, clock the data out, and still do other processing. Trying to do this with a CPLD (or an FPGA) and a RAM chip gets you well over the $2 price that caused you to balk in your question.

The traditional solution to interfacing a microcontroller with a color LCD is a display controller like an SSD1963. Here's a very simple block diagram:

Parallel input to a big RAM frame buffer (Translation: More than $2) interfaced with a register-configurable parallel LCD interface. The parallel input is usually compatible with a memory bus interface.

The color LCD market is not always easy to find on the web, usually being the domain of OEMs only, with the rest buying displays from companies who integrate the controller with the display. The best resource I've found has been Crystal Fontz, specifically this page on choosing graphic LCDs. Scroll to the bottom for the controllers, which include the following options (note: Not all are color controllers):

• Epson S1D13521B01 E Ink Broadsheet (1 module)
• Epson S1D13700 (11 modules)
• Epson SED1520 Compatible (8 modules)
• Himax HX8345 Compatible (1 module)
• ILITek ILI9325 Compatible (3 modules)
• KS0107/KS0108 Compatible (26 modules)
• Novatek NT7534 (14 modules)
• Orise Technology OTM2201A (1 module)
• Orise Technology SPFD5420A (1 module)
• RAiO RA8835 (1 module)
• Sanyo LC7981 (13 modules)
• Sino Wealth SH1101A (2 modules)
• Sitronix ST7920 (29 modules)
• Solomon SSD1303 (1 module)
• Solomon SSD1305 (9 modules)
• Solomon SSD1325 (2 modules)
• Solomon SSD1332 (1 module)
• Solomon SSD2119 (2 modules)
• ST STV8105 (1 module)
• Toshiba T6963 (23 modules)

In your proposed scheme you would need to be aware that each position of the DDRAM represents 8 x 5 pixels for a normal display. When you program a pattern into the CGRAM only 5 bits in each byte are used. Look at the Table 5 of the data sheet and you can see this - CGRAM Data b7, b6 and b5 are not used.

If you program the DDRAM with a constant pattern of 00 - 01 - 02 and 03 in the first row of the display and 04 - 05 - 06 and 07 in the second row then you can control a total of 8 x 5 x 8 = 320 total pixels on the screen. You'll get support for the 2 rows x 8 = 16 commons. In addition since only the first four character positions of the DDRAM are used by this scheme you get a total of 4 x 5 = 20 segments. This does not match up with the requirements of your display.

So if your display really does look similar to the one pictured I would venture to guess that you have another option to be able use more of the segments of the St7066 than the first 20. You may very well find that the various 7 segment displays are arranged in the panels scan matrix in a way that you you can use additional segments of the display controller to select various of the 7-segment sites. With a bit luck you may find bit patterns in one of the normal CGROM fonts that can be used select the patterns of the seven segment sections. By selecting the codes that you would write to the DDRAM you could maybe get the 0->9 + blank of each site to give the needed display combinations. This would take some work to see what the possibilities are.

If the scheme I outlined above does not work out then your choice would be to look instead at a graphics display controller chip. These offer a RAM bit for every intersection of the COMMONs and SEGMENTs matrix.