Recently i had purchased a graphics Color TFT lcd with Touch screen from Taiwan. I m not sure abt the manufacturer of the lcd. The size is 5.7" with 640x480 resolution and 4- wire resistance interface for TSCR.
The LCD module is having Source and Gate Driver IC namely HX8250A and HX8678A. The output of the module has 18-bit parallel TTL interface(Red - R0 to R5, Green - G0 to G5, Blue - B0 to B5).Along with this HSYNC,VSYNC, DE,CLK are also present.
But i m not sure how to write a application program for the lcd module. As i dont have any datasheet of the LCD module i m not quite sure where should i start from and how to write the program for this?
Anybody can suggest in this??
Since you selected C166 as architecture when posting, I'm assuming you are going to use an MCU from the C166 or XC166 family. If that's the case, you are going to need a graphics controller between the MCU and the LCD. I have used S1D13A05 from Epson. It has display buffer RAM on-chip. Since it only has 256K bytes, it will be able to support 4bpp colour depth at 640x480 resolution. It's a nicely intergrated chip that's easy to use and it has some 2D acceleration functions. Start your search there and see if you can find something that suits you. Getting the interfaces MCU<->GPU and GPU<->LCD right does require some skill. Do read the manuals carefully.
One more note. You noticed that you didn't have any datasheet for the LCD, but you do know its pinout. That information had to come from somewhere. From my experience, datasheets for LCD modules don't have much more info that the part numbers of IC's used in them and required supply voltages. This information is normally sufficient to get them working.
Correction: 128K bytes is only going to be able to support 2bpp at 640x480. The newer graphics controllers from Epson have more RAM on-chip: S1D13742, S1D13743 and so on.
As you said the there should be a graphics controller between the MCU and the GLCD. The graphics controller is given along with the LCD module as Source and Gate Driver IC separately.
It is to and from these IC's the controls and datas are going in and coming out.
I m intended to interface a SDRAM with the 16-bit MCU to hold the datas for the 640x480 resoultion and connect all other pins from the LCD module directly to the MCU.
As we had seen in normal LCD for example 2x16 LCD, we write the 8-bit data at the corresponding address given in the LCD, depending the RS and the Enable line.
In a similar manner is there any addressing for this color TFT to display the fonts or 2D-graphics?
An LCD with an RGB interface expects image data to be fed into it at 60 frames per second. That's 640x480x60=18430000 pixels per second. That's what a graphics controller does: it stores the image in the display buffer and refreshes the LCD at required frame rate by scanning the display buffer. Source and gate drivers are there to provide appropriate voltages and waveforms for the TFT panel. There are LCD modules with source and gate drivers as well as graphics controller built-in, but I've only seen them at up to 320x240 resolution. I've heard that some people manage to drive RGB data out of an MCU to an LCD with an RGB interface. Essentially, that would be emulation of a graphics controller. But that would consume a lot of CPU time and achieving good frame rate would be a challenge.
I just had a look at Epson GPU's. The S1D13781 looks very nice. Too bad it seems hard to buy. It's probably very new, hasn't reached many distributors yet...
I agree with what you had said Mike.
But the situation is like this. In that case how we can make use of external SDRAM as a image buffer and interface with the Graphics LCD and do the application programming.
There are MCU's that have an external DRAM interface as well as a graphics controller on-chip. Have a look at LPC2478 for an example. If replacing the MCU is not an option, I think some graphics controllers can do the job. That is, if a graphics controller has two busses (one for DRAM and one for MCU) then it can expose the DRAM to the MCU for general-purpose programming. I've worked with the Fujitsu Jasmine GPU and it does just that, if I'm not mistaken. The Fujitsu Jasmine had its DRAM on-chip, though. I'm sure there are other examples. One word of caution. When sharing the same DRAM between display buffer and general-purpose memory you have to remember that scanning the display buffer for LCD refresh takes up memory bandwidth. That bandwidth will not be available to the MCU.
Your life would be so much simpler had you dropped the C166 for this application and turned to use an LPC2478, for example, or any other microcontroller with a built in LCD peripheral.