Using a 16 bpp LCD instead of a 24 bpp LCD?

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Using a 16 bpp LCD instead of a 24 bpp LCD?

630 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by rcsison on Tue Mar 27 11:50:38 MST 2012
Have any of you decided to use a 16 bpp LCD instead of a 24 bpp LCD for a performance reason.

We have some problem running an 800 x 600 display at 24 bpp using our Phytec development kit. I am trying to determine if going to 16 bpp would require much less "horsepower" for our data-handling? If we do not need 24 bpp, perhaps 16 bpp would be the way to go to help with this problem?

Thanks for any advice out there!
Labels (1)
0 Kudos
3 Replies

440 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by rcsison on Wed Mar 28 07:32:09 MST 2012
wellsk, thanks for the response to my post!
0 Kudos

440 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wellsk on Tue Mar 27 15:44:32 MST 2012
Ooops - the argument above was more for the LPC3250, but the same argument applies to the LPC4350. The 40MHz was obtained via testing, the LCP4350 might be different based on bus clock rates.
0 Kudos

440 Views
lpcware
NXP Employee
NXP Employee
Content originally posted in LPCWare by wellsk on Tue Mar 27 14:01:20 MST 2012
When using large displays with fast pixel clock rates, the latency of the system becomes a bigger factor in LCD performance than system bandwidth needed for the display. The 32x0 can drive an 800x600 display at 32bpp, but if something else monopolizes an internal bus or the DRAM too long, the LCD FIFO will underflow giving an annoying glitch on the display. As the high clock rates and data consumption needed for that display @32bpp, the system probably just can't keep up.

You can try toggling the state of the watermark bit in the LCD controller. This will cause the LCD controller to request FIFO servicing more often. Also examine the bus timeouts (see the EMC bus timeout registers) and make sure the timeouts are not too long. Shortening the timeouts will allow the allow the EMC to release the bus faster if something is accessing it too long while another access is pending. It usually works in favor of the LCD with a high clock rate as the LCD data burst usually can easily meet the timeout requirements, but can slow other things down in the system.

The 800x600 display has a clock rate of about 38MHz? That should be ok with 16bpp and at least the EMC bus timeouts set to around 0x20. Other customers have used 800x600 and 800x480 without problems (and using Linux) at 16bpp in production systems.

I guess I'm trying to say the pixel clock rate and data transfer per clock are more important than the display size. As a general rule of thumb, I would never go over over a 40MHz pixel clock at 16bpp or a 20MHz pixel clock with 32bpp. (This is with a 133MHz DRAM bus with 16-bit DDR or 32-bit SDR DRAM). I hope this helps.
0 Kudos