Content originally posted in LPCWare by zp on Tue Sep 17 14:42:36 MST 2013
Quote:
I can do 2D simple graphics
Me too :)
2D allows to switch the VSYNC on. F.e. With a VGA mode and 200 32x32 sprites you can freely get 60 FPS. I experimented with as many as 125000 sprites as well (the sprite is a 32x32 bitmask with an attributes like color, position, speed etc). The LPC 4357 gives me about 0.25 FPS in this case :). One thousand though keep the framerate above 30.
Quote:
you are using DRAM for the frame buffers and internal FLASH for code execution
Of course. the SDRAM is used for all the graphics data. Code is placed in MCU's flash. The stack and system heap are both in SRAM. For my programs I'm using a custom memory management with some mix of the statically allocated buffers and dinamically allocated chunks. With 64 megabytes of a 32-bit SDRAM onboard, f.e. the first 8MB used for video buffers (tripple buffered chain for video output) and some other needs, then is the area for a dynamically allocated blocks ( by 1KB, 16KB or 256KB chunks). So where needed I can freely use my own zpmalloc, zpcalloc, zprealloc and zpfree commands instead of intrinsic malloc, calloc, realloc and free. The last 4MB are for a RAMDISK.
But the main performance bottleneck is not a stack placement but the SDRAM speed and its bandwith distribution. By the way it is a pity LPC does not implemented CCM/TCM memory like in STM or Freescale Cortex-M4, it really can boost the performance especially in our case.
In every frame for the single render target you must
a) restore/recreate the background
b) clear Z-buffer and all the similar common structures
c) process input and update the 3d world logic (AI)
d) apply frustum and backface culling
e) render the 3d world {here goes a long list what does it mean and in which order}
f) get some statistics about the frame and swap/shift the buffer chain
All these steps are not so strictly ordered in the real life.
The SDRAM is a shared resource and the LCD AHB master eats one third of it (in VGA 16 bit resolution), every next master requesting the SDRAM sequentally decreases the transfer speed for the rest of masters. So no DMA or coprocessor can help if there are present a huge data streams to and from SDRAM. But they really are.
There are some ways to improve the situation, from the common conception revsion to trying to use non-SDRAM memory. The last free 16KB ETB SRAM block is too small for the our needs. It is possible to connect an external SPI SRAM (f.e. 128KB 20MHz Quad SPI from Microchip, 512KB 40MHz SPI from EverSpin or 128K 40/104MHz SPI from Cypress; the best cost per MB ratio here wins EverSpin) or to implement a CPLD + dinamic or (pseudo) staic RAM, connecting it to the SPIFI or SGPIO interface.
Even better is using of a standalone pixel conveyer, adding the one more MCU. Where are the LPC437x MCUs with their dedicated third core to SGPIO transfers?
But we have to be a little bit more tolerant to the LPC43xx though - they are not intended to be used as a 3D multimedia processors. You should change the platform to ride the 3d performance up.
And the blending is a very hard task without a hardware acceleration. The number of blended areas (layers) will be very limited in case of pure software renderer. It will be very interesting how the 2d acceleration works on STM32F4x9. And surely i'll try the newest Vybrid3 with its free multilevel blending. By the way lightweighted FTDI FT800 videochips (with TS and audio) are already available and are the perfect addon to all MCU without internal LCD controllers like LPC8xx, 11xx, etc. FT800 uses framebufferless technology (as the Vybrid does), creating all the graphics on the fly.
Quote:
Which display are you using with that?
The common standard VGA monitor. I just added to the LPC4357 the simpliest buffered R-2R video DAC and a standard (slim) VGA-DSUB onboard. It is very convinient (for my taste) to have the very robust construction with normal angles of view and high detalization. The standard 40-pin socket for the RGB panel is present as well. So there is no problem to create a binary demo for a 480x272 output. Because I'm the victim of a poor design of Embest LPC4357-EVB and still have this piece of [metal] may be I'll choose this one as a demo target. But the ETA is not defined yet.