Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

About ARM and TFT LCD

Status
Not open for further replies.
M

maniac84

Full Member level 6
Joined
Mar 4, 2012
Messages
337
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,298
Activity points
3,661
Hi guys,

Been studying how to interface my ARM LPC1768 mcu with a 3.5 inch TFT LCD. I've been searching the info on the internet. There's this digital data input (for RGB) which is around 18 (3x6) or 24 (3x8) pins on the LCD. I've been referencing other people's design from the internet and found out that some of them just connect these digital data input pins to the ground. But some people connect these pins to LPC1768 GPIO. Do you guys know why?
 

Hello!

It very much depends on what kind of controller your LCD has. In many cases, there is no
internal ram, so that you have to refresh the LCD data permanently otherwise it fades out.
If you want to refresh by software, be aware that you have to transmit 320 x 240 (supposing
it's the resolution of your screen) x 3 bytes (230400 bytes). And if you want some responsively,
you need at least 5 frames per second (based on my experience, less than 4 frames, and the
image starts fading before the next frame). So you have to transmit about 1,2 MBytes per second.
That will be a very heavy load for your processor.

Now if you have an LCD with internal memory, it is feasible with a very low specs CPU.

Dora.
 
doraemon said:
Hello!

It very much depends on what kind of controller your LCD has. In many cases, there is no
internal ram, so that you have to refresh the LCD data permanently otherwise it fades out.
If you want to refresh by software, be aware that you have to transmit 320 x 240 (supposing
it's the resolution of your screen) x 3 bytes (230400 bytes). And if you want some responsively,
you need at least 5 frames per second (based on my experience, less than 4 frames, and the
image starts fading before the next frame). So you have to transmit about 1,2 MBytes per second.
That will be a very heavy load for your processor.

Now if you have an LCD with internal memory, it is feasible with a very low specs CPU.

Dora.
Click to expand...

So what you mean is, if the LCD that I have got a internal RAM, then my digital data input pins will all be connect to ground. And if my LCD does not have internal RAM, then I would have to connect the digital data input pins to the GPIO of my MCU.
Am I right?

And by the way, how do we determined whether or not the LCD got internal RAM?. I have studied a few LCD datasheet but they did not state the RAM. Could you show me an example?
 
Last edited:

Hello!

No, that's not what I meant.
If you have a regular TFT (I mean the most common type, without internal RAM), then you have
to send permanently data to the screen to refresh it, even if you don't change the screen contents.
You have to keep a RAM somewhere because the LCD does not have one. Even if you want e fixed
image, you have to send and resend again the same data.

Now there are some LCDs which do that by themselves, so you send data to it and it displays it.
You don't have to send data permanently in case of still images because the LCD keeps the data
in its RAM and processes the refresh operations by itself.

Basically the small LCDs made for cellular phones often have RAM on board. And larger displays don't,
but this is not an absolute rule.

Dora.
 
doraemon said:
Hello!

No, that's not what I meant.
If you have a regular TFT (I mean the most common type, without internal RAM), then you have
to send permanently data to the screen to refresh it, even if you don't change the screen contents.
You have to keep a RAM somewhere because the LCD does not have one. Even if you want e fixed
image, you have to send and resend again the same data.

Now there are some LCDs which do that by themselves, so you send data to it and it displays it.
You don't have to send data permanently in case of still images because the LCD keeps the data
in its RAM and processes the refresh operations by itself.

Basically the small LCDs made for cellular phones often have RAM on board. And larger displays don't,
but this is not an absolute rule.

Dora.
Click to expand...
So that's the RAM part on LCD.
But my question still haven't been answered. Why do some designers connect the data input pins to ground and some connect it to the GPIO of MCU?
 

Hello!

I suppose they connect SOME of the data pins, not ALL the data pins. Otherwise, I guess it would
stay black all the time.
For example: you have a 24-bit LCD, but you want to use it with an MCU that has 16-bit ports.
One way is to multiplex (add external bus drivers). The other way is to work in 16-bits 5-6-5.
In this case, you connect the 3 lsb of red, 2 of green and 3 of blue to ground, and you work
with the remaining bits.

Dora.
 
doraemon said:
Hello!

I suppose they connect SOME of the data pins, not ALL the data pins. Otherwise, I guess it would
stay black all the time.
For example: you have a 24-bit LCD, but you want to use it with an MCU that has 16-bit ports.
One way is to multiplex (add external bus drivers). The other way is to work in 16-bits 5-6-5.
In this case, you connect the 3 lsb of red, 2 of green and 3 of blue to ground, and you work
with the remaining bits.

Dora.
Click to expand...

I've uploaded two schematic design I found in the internet to discuss here. Both are connecting the LCD data pins to the ground. I think they connect ALL data pins to the ground. Could you explain further?
I saw that in the design, the LCD also use SDO and SDI to communicate. Are they using SPI communication? Are they just use this two pins to communicate that's why connect ALL other data pins to the ground?
 

Attachments

  • keil_lpc1768_-schematics.pdf
    831.3 KB · Views: 61
  • ET-NXP-ARM-KIT-LPC1768-SCH.pdf
    97.9 KB · Views: 53

Hello!

OK, I looked at the LCD wiring. Indeed, all data pins are on the ground, but SDI / SDO and SCK are used,
which means that this LCD communicates serially. So that should be easy, you can drive it with a micro controller.
Apparently this LCD has both interfaces (there is a VSYNC / HSYNC, dot clock, etc). Probably it can be used
with that latter interface for fast video signals, and with the MCU interface for more MCU-like applications
with static images.
Anyway, interfacing should be easy.

Dora.
 

doraemon said:
Hello!

OK, I looked at the LCD wiring. Indeed, all data pins are on the ground, but SDI / SDO and SCK are used,
which means that this LCD communicates serially. So that should be easy, you can drive it with a micro controller.
Apparently this LCD has both interfaces (there is a VSYNC / HSYNC, dot clock, etc). Probably it can be used
with that latter interface for fast video signals, and with the MCU interface for more MCU-like applications
with static images.
Anyway, interfacing should be easy.

Dora.
Click to expand...
Yup. These LCD is connected to a mcu.
Is it that if the LCD can communicate serially to mcu with SPI, there is no need for the RGB data signal be connected to the mcu?
May i know which is the best interface? Using the RGB data input pins only to communicate with the mcu? Or use the SPI serial to communicate with the mcu? Or we should connect both?
 

I read through both of your conversations.

Using RBG is difficult when compared to interfacing serially. As entire load of the processor will be dedicated in handling RGB.

Interfacing through RBG allows more flexibility to change the image what is displayed, but Serial interface will probably have limited flexibility.

Dora!! Am I right? I am a begineer.

With regards,

Ram
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top