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
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...
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.
Hi jensbauer.,
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).