How to configure a 10 inch TFT LCD in ARM Cortex-M3?

Unfortunately, it seems the video didn't make it. (you can edit your previous post, and try adding it again).

If the flickering is caused by the VSync / HSync timings being incorrect, my guess is that this could also be the reason why the pixel is not "pure white" but gray.

Yes, we know the size of the active area, but we do not know the position. Finding the position of the active area will give us the usable values for the front porch and back porch in both horizontal and vertical directions.

Hi ..,thanks for your reply.i tried your values still i am getting flickering.i am keep on concentrating in TFT lcd mode(DE mode and HSYNC) and LVDS convertor output sequence.DE mode pin is not available in my pin connection see page 12/23 .really i dont know how to interface the lcd by using this available value and pin connection.there is no perfect details about timing details.if you have any idea from pin connection tell me .once again thanks for your response.

Hmm, from what I can tell, it seems like DE mode is not supported by the display.

I think the next thing to do (if you haven't done it already), is to enable the DCLK signal and check that it's 48.96 MHz.

-Do you have a 50MHz+ oscilloscope / analyzer / frequency meter available ?

yeah,i checked Hsync and Vsync i am getting Hsync=18.5 khz and Vsync 1 or 2 Hz ..can you tell me how to increase the Hsync,Vsync value ?because you said range should be  Hsync=44 -65Mhz Vsync=55-65 Hz .

Now i am going to try this.

Before you do that, please verify the polarity of the HSync and VSync signals.

The last modeline I mentioned needs a positive HSync and a negative VSync.

At the top of your file, you have the following two defines. I believe they're meant to be the polarity of the HSync / VSync signals:

#define HORIZONTAL 0XFF

#define VERTICAL 0X00

...I recommend changing them to ...

#define HORIZONTAL 0X00     /* positive */

#define VERTICAL 0XFF     /* negative */

The following line ...

     LCD_POL_REG |=IVS|IHS;

... needs some modification. I believe it should be something like...

     LCD_POL_REG |= (((int8_t) VERTICAL) < 0 ? IVS : 0) | (((int8_t) HORIZONTAL) < 0 ? IHS : 0);

... I haven't thought too much about the above line; so if it does not produce the correct polarity for HSync and VSync, try changing it to the the line below...

     LCD_POL_REG |= (((int8_t) VERTICAL) < 0 ? 0 : IVS) | (((int8_t) HORIZONTAL) < 0 ? 0 : IHS);

... One of them should have a chance of working.

Now, when you've verified the polarities, we can move on to the PixelClock and perhaps changing the color depth if necessary.

I'm mentioning the color-depth, because the more colors you need, the higher bandwidth you require from the LCD controller.

Since there's a limit to how much data you can transfer per second, you may need to compromise here.

First line to experiment with is the following:

LPC_LCD->POL |= (LCD_ClockDivide(72300000)<<0);

The higher the clock-frequency, the better.

Regarding the color-depth, you'll need to have a look at the LCD_CTRL register. I recommend changing ...

LCD_CTRL_REG |= (5<<1)|LCDTFT;

... to ...

LCD_CTRL_REG |= (3<<1)|LCDTFT;     /* color-depth: 8-bit */

... or perhaps even ...

LCD_CTRL_REG |= (2<<1)|LCDTFT;     /* color-depth: 4-bit */

... That's of course a bit boring, but it should increase the PixelClock frequency.by a factor 2 for 16-bit, factor 4 for 8-bit or factor 8 for 4-bit.

Now, when you do this, you'll probably experience that the display does not show anything pretty. This is because the size of each pixel is changed.

The picture will look weird, but the goal here is to increase the PixelClock.

If you really need 24-bit colors, then the alternative is to reduce the screen resolution. There are several possibilities, but I recommend resolutions that divide the vertical or horizontal or both directions by 2, 3 or 4. For instance, you could divide the horizontal resolution by 2 and the vertical resolution by 3, so you would get 512 x 200 pixels. This would give you  a PixelClock which is 6 times faster than 1024 x 600 - but the pixels would look much more clumsy / blocky.

Hi,

      i got almost exact output for 900*600 pixel resolution .but my resolution is 1024*600.still color changing issue is there in 900*600 resolution.i don't know how to rectify this.i thought it cant able to generate 40 mhz above for lcd clock.but we need 44mhz and above .explanation is in (314/1108 page) polarity and clock control register (PCD_HI&PCD_LO).But still trying.

It's good to hear that you've got progress. The solution may be just around the corner.

The LCD controller supports 1024 x 768, so it should be possible, perhaps you'll need to reduce the color-depth further, which is of course not an attractive solution - but at least it could be a start.

There might be trade-offs between higher resolution, more colors and higher refresh rate.

(You've heard it before: You can have coffee or cake, but not both).

Hi,

1)my microcontroller running in 120 MHz speed.i can generate 40 MHz max by using PCD bit.but i can generate upto 60(or)120 MHz maximum for LCDCLK(panel lcd clock) by using BCD bit(Bypassing the core clock).but if i enable BCD bit clock my required clock got generated but more flickering is there.even i cant able to see my data pixels.if u think why i have to use BCD bit mean?when i need more than 40 MHz i cant generate clock from PCD bit. that's why i am using PLL concept and generating required clock and passing to pannel clock by enabling BCD bit.

2))i am using 256Mbit (16M x16) Synchronous DRAM.

what is the use of reducing color data pixels?

and tell me how to use that excel sheet?what is the use of this excel sheet?what i have to check in this sheet.

It's good it runs 120MHz; I believe it should.

The SDRAM may be the bottleneck.

Since the databus is only 16-bit, you may need two SDRAM chips wired up so you get a 32-bit databus. This will improve the bandwidth on the bus.

-So if it's possible for you to add a second SDRAM chip on the board, or change the existing to a 32-bit, I would recommend that.

If you can't change the SDRAM, try and see if you can add external SRAM. The SRAM is quicker, but you don't get as much SRAM per chip as you get SDRAM.

If you had external SRAM, the external SRAM would be faster than the SDRAM.

Since the bit depth is the size of a pixel, changing the bit depth means that you will change the total size of the screen in bytes.

For instance... If you have a 1024 x 600 pixel display, you do not know the number of bytes required per 'frame'; you only know the number of pixels, which would be 1024 x 600 = 614400 pixels total.

Now, to get the number of bytes required for a frame, you would have to multiply by the bit depth, then divide by the size of a byte in bits.

The size of a byte in bits is always 8, as you probably know already.

-So we multiply 614400 pixels by 24 bits per pixel, we'll get 14745600 bits per frame.

We then divide 14745600 by the size of a byte (8 bits), and we get 1843200 bytes per frame.

Since a kiloByte is 1024 bytes, we now divide 1843200 by 1024, to get the size of the frame in kiloBytes, and we get 1800kB.

We can divide this again by 1024, in order to get the number of MB... 1.758MB.

This tells us two things:

1: Since you have 256M * 16b = 256*16Mbit = 4096Mbit = 4096/8 MByte = 512MB RAM, this should be enough to contain your 1.76MB frame buffer.

2: Since you want 60 Frames Per Second, the required bandwidth would be 1.758 MB * 60Hz = 105.48 MB/sec; this is quite a lot.

If you try reducing the bit-depth to for instance 8, you will get a frame buffer that is only 600kB. The required bandwidth would be reduced to 35.16MB/sec.

Thus changing the bit-depth would also change the required bandwidth.

Hmm, that is strange.

The brightness should normally not change, when you change bit-depth.

But you can try something else: Try changing to indexed color (that's 8-bit), which has a 24-bit palette, then see if the brightness returns.

I've learned a little more since last reply.

You may be able to increase the brightness of the TFT display by lowering the VSync time.

(I believe that's called TFT_V_PULSE in your source code).

-Try and see if that will help.

Start slowly, by subtracting only 1. If the picture moves off screen, add 1 to either TFT_V_FRONTPORCH or TFT_V_BACKPORCH.

Normally, you would add to those what you subtract from the VSYNC pulse timing, in order to keep the balance right.

The minimum number of lines per VSYNC is 1. The LCD controller does not allow you to have a VSYNC length of 0 lines, as far as I know.

Also: If you can send commands to your display (perhaps via SPI or I2C), you may be able to change the gamma-table.

(For those who thinks that is pointless: There would be plenty of reasons to have a 0-length vsync pulse; one is to interface to a LVDS display, another is to use the controller for other things than driving a LCD/TFT screen; further reasons: To customize your video source address on each line update).