I’m trying to work out how Double buffering works with respect to the DAL API.
The grlib_Demo seems, on the surface to use double buffering but when you look deeper maybe it doesn’t.
It seems to be turned on:-
RasterDMAConfig(SOC_LCDC_0_REGS, RASTER_DOUBLE_FRAME_BUFFER,
RASTER_BURST_SIZE_16, RASTER_FIFO_THRESHOLD_8,
RASTER_BIG_ENDIAN_DISABLE);
But a few things don’t make sense to me and I don’t find any clarification in the documentation, eg:-
/* configuring the base ceiling */
RasterDMAFBConfig(SOC_LCDC_0_REGS,
(unsigned int)(g_pucBuffer+PALETTE_OFFSET),
(unsigned int)((g_pucBuffer+PALETTE_OFFSET) +
sizeof(g_pucBuffer) - 2 - PALETTE_OFFSET),
FRAME_BUFFER_0);
RasterDMAFBConfig(SOC_LCDC_0_REGS,
(unsigned int)(g_pucBuffer+PALETTE_OFFSET),
(unsigned int)((g_pucBuffer+PALETTE_OFFSET) +
sizeof(g_pucBuffer) - 2 - PALETTE_OFFSET),
FRAME_BUFFER_1);
Why do both frame buffers appear to be allocated to the same buffer?
The LCDIsr is never called in this sample (a counter placed in it is never incremented), so the apparent buffer toggling it does never happens (but again there only seems to be a single buffer)
I would expect double buffering to require/need some kind of ‘buffer commit’ / ‘buffer swap+copy’ call, yet I can’t see anything of that type either in this demo, how is this done or otherwise not needed?
Why is
CacheDataCleanBuff((unsigned int)g_pucBuffer , ((480*272*4) + 32));
So fundamental to the correct operation of the display? I was initially thinking this was the ‘buffer commit’ call, but the documentation doesn’t desceibe it that way and it obviously isn’t as without it the display to the ‘previous display’ but more like the ‘previous display’ partially corrupted with the new display (to see this effect place a while(1); at the end of OnPrimitivePaint)
