Graphical LCD dilemma

[michael_rodrigues]

I am required to use a graphical lcd with atleast 320(RGB) x 240 resolution. I have gone thru a lot of datasheets. the one thing i could not figure out is that:

1. these data sheets give the pinouts etc, but they don't mention if it's using a controller or just a dumb driver, similarily if there is an onboard RAM or do i have to implement it externally.

2. If i don't have to care about the above point then, i am currently using a ADUC831 8bit controller running with a 16MHz crystal. this controller is burdened with a realtime task. SO is it sufficient to use this controller to for display purpose of i will have to implement a second controller "only for display".

3.Again if i purchase a 320(RGB) x 240 color graphical LCD module and interface it (obviously proper connnections etc,) to my main board which is using an "8 bit controller", without any major problems.

All that is required is once during my program flow (typically 30 to 50ms ) i send the required instructions and data to the GLCD for display and the controller/driver on the GLCD will accordingly refresh the screen.

Another question i'd like to ask is(probably similar meaning to the above):

i already know the difference between a driver and a controller (in a GLCD module). Now a module datasheet refers to a driver (toshiba or seiko, whatever), and also pinouts showing D0 to D15 along with R/W, E etc. pins, does this mean that all i have to is properly interface these pins to my controller(already burdened with an RT task) an send instruction/data.

Again, if i send a screen data once, the LCD driver has accordingly updated the screen, then even for 1 minute or so if i don't do any communication with the GLCD, does the image continue to remain there or will it stop being displayed

THANX

 

[michael_rodrigues]

I have another question, i didn't know how to create a new post so i am posting it here itself

I have been using 8 bit controllers until now. Now i may have to shift to the 32 bit domain, in which i am zero. I gone through a lot of stuff about 32 bit controllers. What i wanted to know,

if i have two controllers:
Controller A is 8bit, single cycle(like the AVR,etc)
Controller B is 32bit

1. Now if both are run using an 8 mhz oscillator, since B is 32 bit, it can process a 32 bit data in 1 cycle, whereas A will require around 4 cycles. Now does this mean that B is 4 times faster than B.

2. On the same lines if i have to output 3MBytes/s on both the controllers, then will B output this data 4 times faster than A.

3. When it comes to a data of 8bit, will both the controllers take the same time.

Thank You

 

[ericgibbs]

hi Michael,
I would suggest you post the datasheets for GLCD type you are considering using, there are so many unknowns in the questions you ask.

Usually the GLCD has a controller which has to be initialised before the display works,, it will also retain the data written to it, no need to 'refresh'.

 

[michael_rodrigues]

the Glcd is TFT640480-7-E, by truly semiconductor. attached is the datasheet.

 

[ericgibbs]

the Glcd is TFT640480-7-E, by truly semiconductor. attached is the datasheet.

hi,
That looks a fairly major task of interfacing.

I would suggest you contact Truly Semiconductors Ltd and ask for the application data they are offering, it could save you lots of development time.


**broken link removed**

 

[ronsimpson]

Michael,

Raw LCDs are refreshed (updated) 60 times/second. If you do not send new data it will go blank.

Send the whole picture 60 times a second.
Send one line about 39,000 times a second.
I don’t think you have enough computer to send out R7—R0,G7—G0,and B7—B7 at (640+20) x (480+10) x 60hz.

I do not see a timing diagram. The TFT-G800480 does have a timing diagram.

 

[michael_rodrigues]

Thanks for the guidance.

ronsimpson: could you help me understand how did you get the equation "(640+20) x (480+10) x 60hz".

If i use a 32bit controller(i'm sure i may have to), will my troubles reduce, or just increase.

I have sent a request to truly sem for their app notes over the LCD, i'm hoping they reply soon enough.

 

[michael_rodrigues]

Thanks for the guidance.

ronsimpson: could you help me understand how did you get the equation "(640+20) x (480+10) x 60hz".

The thing is, the LCD datasheet refers to a response time of 30ms, and the figure that you gave me is 39000 times per line. Am i going wrong somewhere by connecting these to two.

If i use a 32bit controller(i'm sure i may have to), will my troubles reduce, or just increase.

I have sent a request to truly sem for their app notes over the LCD, i'm hoping they reply soon enough.

 

[ronsimpson]

The DOC Clock (Pixel Clock) needs to be in the range of 5 to 40mhz.

Each Horizontal line has 640 pixels + (110 min, 160 typical, 260 max blank pixels).

Each frame has 480 lines + (35 min, 45 typical, 80 max blank lines). Must have a rate of 55 to 60 to 65Hz.

So the data rate is (640+160) x (480+45) x 60hz = 25.2mhz typical.

Data rate could be (640+110) x (480+35) x 55hz = 21.24mhz minimum.

These numbers are from the data sheet.

So at 25mhz you need to:
Get three bytes of data from memory, Inc points.
Output R 8 bits, G 8 bits, B 8 bits. Toggle the clock.
Loop 640 (DE=0) + 160 times (DE=1).

This is one line.

Repeat 480 with DE=0, + 35 times with DE=1.

This is one frame. (60 hz)

 

[ronsimpson]

Can you live with less than 2^24 colors?
If you can live with using 2^8 (256) colors out of a pallet of 2^24 colors then I know a way of reducing the CPU work.

 

[michael_rodrigues]

If you have seen this LCD (TFT640480-7-E, "Truly Semiconductor"), it is a 24 bit per pixel LCD, could you tell me if it could be used in 18 or even 9 bit per pixel mode, and if so what would be the hardware/software considerations

if we go for a 9bit per pixel config then can we use an 8 bit controller.

 

[ronsimpson]

What I was hinting at is using a color pallet RAM. (it could be ROM)
8 bits of data comes form memory and goes to A0-A7 of the RAM. This calls out 1 of 256 colors. The memory is 24 bits wide so there are 24 lines that drive the panel in 24 bit mode. You could use three small RAMs with all the address lines tied together. A0 red, A0 Green and A0 Blue are tied together. D0 R, D0 G and D0 B are separate. This reduces your ‘move data’ problem to 1/3. If you are just doing text, use 4 bits/pixel. This gives you all 2^24 colors, you can only use 256 or 16 of them in one picture.

If you only care about text and do not need the colors then; use R7, R6, R5, G7, G6, B7, B6 and B5. Tie all unused lines to 0.

I hate to see you doing this with a little computer. We are using a ARM computer that directly drives our 1/4VGA panel. I have used a FPGA to connect a micro, memory and a LCD together. That way there is no CPU overhead.

 

[michael_rodrigues]

Thanks for the help. It's a really good idea. I have one doubt in this though, this setup will solve my color palette issue, but i will still have to remember which pixel on the LCD gets this color, right. Say if i'm drawing a red line in the middle of the lcd (from 10,10 to 40,40), and this line will be moving up or down depending on inputs from a keypad (or sensor), does this mean i will require one more ram to remember the location, etc, of the line.

You said you use an ARM, what is the core frequency that u guys set for driving a 1/4 vga lcd.

 

[michael_rodrigues]

One more question, my application requires a large LCD (i.e around 100 x 100 mm, AND 640 x 480 res), do you know of any particular LCD that has only a 3 bit per color component (or 9bit per pixel) interface. What is happening here is we'll be getting a 24 bit interfaced lcd and then "dumb" it down to 12 bit (or probably lesser) so some lcd panel with a 16 bit interface (or lesser) should be a good choice

 

[ronsimpson]

Dumbing down a panel is simple. Use R7,6,5 G7,6,5 B7,5,4 and ground the rest of the inputs. Panels with 12 bits are old and hard to find.

We are using a 100mhz ARM. That is not important. There is a built in video controller that moves data from RAM to LCD with out CPU overhead. That is big.

You need 640 x 480 x 3 bytes of RAM. That about 1M byte. If you use 8 bit video that helps by 3:1.

To draw a red line from 10,10 to 40,40 you need to:
Make red 10,10 11,11 12,12 13,13 ……39,39 40,40.

To move the red line up one pixel you need to:
Clear the red line at location 10,10 to 40,40 made of 31 red pixels.
Draw a new line 10,11 11,12……39,40 40,41 made of 31 pixels.
At the lowest level you need to write to every pixel you want to change. This may involve erasing the old line before making the new line. To make pixel 10,10 red you need to write FF to 10,10,red 00 to 10,10,blue and 00 to 10,10,green. Using 24 bit video and a 8 bit CPU moving the line up requires erasing 31 x 3 bytes and drawing 31 x 3.

At the same time you need to keep the LCD refreshed. 25mhz video 24 bits wide. That means 75 mega bytes/second.

Is this a hobby or a work project?

 

[michael_rodrigues]

Thanks a million. Actually, its my work project. I may take the pixel depth to 8 bits. But i still wanted to know what would go in taking it all the way to 24 bit per pixels.

 

[michael_rodrigues]

i'm suddenly changing the topic a little..

for an application where my lcd displaying images/data, placed inside a car on/near the dashboard. Which type of lcd panel would be better/enough -> a TFT or an STN

the image refresh rate may not be a problem.. i would take the viewing angle, brightness, contrast into account for this selection.

 

[blueroomelectronics]

Thanks a million. Actually, its my work project. I may take the pixel depth to 8 bits. But i still wanted to know what would go in taking it all the way to 24 bit per pixels.

Based on your previous posts you are light years away from the experience and skill required for such a project. Did your employers hire you to do this or is it some form of hobby project?
What is your project supposed to do? Is it a TV for the dash? A message center? A GPS?

 

[michael_rodrigues]

The datasheet of the TFT LCD refers to a parameter called "response time", as something around 30ms (max). Could anyone explain what does this value signify.

What i wanted to know is within(or rather, after) this time, if the pixel is not refreshed, will it go black (or vice versa)

 

[michael_rodrigues]

What i wanted to know is within(or rather, after) this time, if the pixel is not refreshed, will it go black (or vice versa). i.e. if the datasheet specifies 15ms as he response time, then within 15ms the pixel data should be refreshed or the pixel will go blank.