Content originally posted in LPCWare by Wouter on Tue Sep 03 01:46:19 MST 2013
Hi zp,
I don't think I fully follow, perhaps you can explain a bit more?
Note that the sheet is only meant to give you an indication of the bandwidth required on the EMC for the LCD controller to refresh the display.
In addition to that, indeed you need to add the bandwidth required to update the content of the framebuffer. Since we don't know how often and how much a customer will update the framebuffer, we cannot add this to the sheet.
Quote:
Though Data Rate is calculated quite right you can use this value if your framebuffer is about the same every frame.
I think you're mixing up two things here; the framebuffer is the same size for every frame, and always the complete frame will be written to the LCD by the LCD controller. How much you change in your framebuffer per frame indeed differs, but as explained before, this fully relies on your graphics library and the content you want to show.
Therefore, the calculated data rate should be equal to the data rate of the EMC required for refreshing the LCD.
Quote:
F.e. for a standard 640x480x60Hz VGA the real horizontal pixel count is 800 and a full frame consists of 525 lines. This leads to the 25.2 Mpixel/s bandwidth. You shoud use this value instead of (640x480x60) = 18.432 Mpixel/s. The latter is just an average bandwidth for a one second basis but the peak value of 25.2 Mpixel/s does matter. The difference is quite big - about 40%.
There is some additional overhead send to the LCD by the LCD controller (e.g. horizontal/vertical front/back porch) but these values are not fixed and depend on the LCD. for 640x480 LCDs indeed 800x525 is often used, but even for 640x480 LCDs other values are possible. But, since this overhead does not need to be stored in memory, it has no influence on the EMC/AHB bus data rate. Since the sheet only specifies the EMC bandwidth, the front/back porch values do not need to be taken into account
Quote:
Of course, if you have a QVGA display or the static content in framebuffer, the SDRAM bandwidth does not get so big influence.
But in the single VGA mode and up LCD eats more than one third of the SDRAM bandwidth. F.e. for a fullscreen 3D rendering (i am working on) you need to refresh background, Z-buffer etc every frame. This leads to the situation when only two masters can do long-term work on an AHB bus. If more masters (SD, co-processor,GPDMA etc) are requesting the SDRAM, it does lead to more frequently LCD FIFO watermark level crossing and to round robin with a preference to LCD. Or even worse this means the exhausted FIFO. A tripple buffering is also impossible (more precicely - useless as it'll take more time than a double buffer scheme).
A resolution of 640x480, combined with 3D rendering is indeed no easy task, even for a 200MHz dual-core microcontroller. I'm curious to your progress!
Regards,
Wouter