good evening to every one..i am new to this website..i want to know how to use 10 inch TFT display and LVDS colour formet??? can anyone help me..? thanks advance
is it possible to use the 10.1" TFT lcd by using Htotal,Hac,Vtotal,Vac and Vsync.without using horizontal front porch,back porch value and pulse width ?
if its possible how?
"Guessing" the Front Porch, Back Porch and Sync Pulse timings are often difficult, but I'm positive you'll get through it. First time is always the hardest one.
I just got back from vacation, so my reply is a bit late. I'll try replying the best I can, so that if you're still stuck, you may find the answer.
Normally, you will need the 4 timing values for both the Horizontal and the Vertical directions.
The Horizontal/Vertical Active Video is the "visible" resolution; the one you normally mention, when you speak about visible pixels; for example 1024 x 600 in this case.
The Horizontal/Vertical Sync Pulse time is required for the screen to find out when to synchronize the pixels and lines.
The time between the Sync Pulse and the Active Video is also needed, so that the picture can be adjusted left/right/up/down. You can see it as a "black border area".
On the image shown, the yellow area is the Vertical Sync Pulse.
The white area is the Horizontal Sync Pulse; this overlaps a part of the Vertical Sync Pulse, which means both pulses happen in that area.
The black (grey) areas represents the Back Porch, the blue areas represents the Front Porch.
The ducklings are in the Active Video area.
(The illustration is not 100% correct, but it should give you a fair idea about the placements of the timings)
So first you'll have the Vertical Sync Pulse, then the Vertical Back Porch, the Vertical Active Video and finally the Vertical Front Porch.
For each pixel-line you'll have the Horizontal Sync Pulse, then the Horizontal Back Porch, the Horizontal Active Video and finally the Horizontal Front Porch.
The Front Porch is usually smaller than the Back Porch.
In your case, you know the total number of pixels per line and the total number of lines per frame:
Typical values are 1344 and 625.
You also know the number of active pixels/lines: 1024 and 600. Subtract these from the total...
1344 pixels - 1024 pixels = 320 pixels
625 lines - 600 lines = 25 lines
Usually Vertical Sync Pulse is 2 or 3 lines. So assuming it's one of those, we'll get 23 lines left for front and back porch.
The front porch is usually smaller than the sync pulse, so we'll assume vertical front porch is 1 line, leaving 22 lines for the vertical back porch.
For the horizontal values.... These should usually be divisible by 8.
Often (but not always), the Horizontal Back Porch is half of the pixels left over from the above subtraction; eg. (1344 - 1024) / 2.
So assuming the front porch is 160 pixels, we'll try giving the back porch 24 pixels and the sync pulse 136 pixels.
So we'll have something like...
VSP: 2 lines
VBP: 22 lines
VAV: 600 lines
VFP: 1 line
HSP: 136 pixels
HBP: 160 pixels
HAV: 1024 pixels
HFP: 24 pixels
Sometimes the horizontal values must be divisible by 16, so you may need to make HFP either 16 pixels and HSP 144 pixels OR HFP 32 pixels and HSP 128 pixels.
I believe you should try and make the pixel clock as low as possible (44 MHz); since that is easier for the LPC's LCD controller to handle.
the Vsync and Hsync may be the problem for flickering.and one more thing friend i thought we cant shift the pixel ,if we want we can shift the pixel location so the pixel can blink in that particular location.if you keep on moving left or right it will be invisible because it ill go to inactive area .
sir what is the use of finding active area?we already know active area is 1024*600.so if we want to display the image in horizontal x vertical (e.x) 0x10 location mean it will display there .
i thought the problem is Hsync,Vsync value and RGB TO LVDS convertor also .because in RGB interface there is no problem ,in LVDS interface only lcd its flickering and color is changing(mean if we set white=(255,255,255),Its displaying grey block=(60,60,60 ).
.i attached video clip just see and tell me.if u have any idea.
i attached the video clip In previous post.just see and tell me if u have any idea .one more doubt friend.how to use TFT lcd in DE Mode.in HS MODE We need the following value
Vertical Sync Pulse,Vertical Back Porch,Vertical Active Video,Vertical Front Porch,
Horizontal Sync Pulse,Horizontal Back Porch,Horizontal Active Video,Horizontal Front Porch.By using this value we can initialize the TFT lcd.
In DE mode i have the following value only i don't have Hsync,Vsync value and all.how to use the following value to initialize TFT lcd.
The flickering could also be because the sync polarity need to be changed.
DE mode is "Display Enable" mode. That means that the Display Enable pin must be connected for this to work.
You would also need to connect the DCLK signal.
Using Google to search for TFT DE mode, I got some interesting results, especially LPC2000 results containg useful information.
According to this page, both SYNC signals should be held low on the display.
I also tried searching for a resolution and found a modeline, which could be interesting:
Modeline "1024x600" 48.96 1024 1064 1168 1312 600 601 604 622 -hsync +vsync
It seems this modeline is within your display's specifications.
(You can try using Google to search for the following words Modeline 1024 600 if you want more example resolutions)
Now, to convert the modeline, you'll need to do some simple math...
The first string mentioned in the "Modeline" is the name of the resolution: "1024x600"
The next is a number, which is the PixelClock. This is 48.96 MHz.
After that, we have the Horizontal Active Video, Front Porch, Sync Pulse and Back Porch.
After those, we have the same for the Vertical direction.
HAV = 1024
HFP = (1064 - 1024): 40
HSP = (1168 - 1064): 104
HBP = (1312 - 1168): 144
VAV = 600
VFP = (601 - 600): 1
VSP = (604 - 601): 3
VBP = (622 - 604): 18
Hsync pulse is negative.
Vsync pulse is positive.
I recommend trying the resolution first with DE mode disabled.
If you have an oscilloscope (or a logic analyzer), I think it's important to measure that the HSync signal is correct.
Also please verify that DCLK is running at 48.96 MHz.
If it still flickers, you can try changing to DE mode.
When using SYNC mode, please verify that DE is low all the time (DCLK is also unused, so I would expect it to be low).
When using DE mode, please verify that both HSYNC and VSYNC are held low all the time.
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 ...
... 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.
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).
I think I forgot to mention that NXP has a LCD bus bandwidth calculator spreadsheet available. It works both on Excel and Apple's Numbers.app.
It would be helpful to know your board's configuration, by the way...
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.
Now i changed data format and reduced pixel color to 18 bit.now my standard color is coming. but not brightly color, i mean pixel is displaying in low brightness.how can i improve pixel brightness?
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).
View all questions in Cortex-A / A-Profile forum