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.