Hi
I have used the Keil Blinky example as a starting point to configure an Embedded Artists LPC2478 board external 32 bit SDRAM. I have recently started to run the eval board supplied QVGA LCD screen in RGB mode i.e. using the external SDRAM as a frame buffer for the LCD.
The problem I have is one of general SDRAM access speed. I have slowed the LCD controller refresh to the slowest speed possible so the LCD doesn't flicker so as not to occupy the SDRAM bus access too much. Then when clearing a block of SDRAM memory to clear the LCD display it takes a finite time but is clearly visable to the human eye when looking at the LCD. I can see the LCD 'swipe' across as the SDRAM is written to in a loop.
The micro is running at 72MHz and the LCD is only 320x240 pixels, I hope to finally use a 800x480 pixel LCD but then the LCD clearing time would be even more noticable.
Am I expecting too much from this micro and its built in LCD controller? Ideally I need to get the SDRAM block writes much faster so the LCD updates are less noticable.
Thanks in advance for any suggestions.
I implemented a double buffering system and that looks nicer to the eye but my original problem still exists, the time it takes to write to the external SDRAM is still too slow to be able to get any fast graphics, in particular scrolling text box.
Are there other preferred ways to write faster to SDRAM? For example is it better to say draw a bitmap font to on chip RAM and then move that block to SDRAM using DMA? Would that be faster than writing the bitmap font directly to SDRAM?
Likewise, to clear the LCD graphics buffer is memset faster than a C for..loop? Does this make SDRAM access more effcient?
Yes and no, memset() is a kind of for loop. But normally a very optimized one, to avoid having to perform a single byte / iteration with one comparison and one jump / byte.
In some situations, it can be faster to draw in internal RAM. A mempcpy() from internal RAM to the LCD would be not too much slower than a memset().
But have you measured if it's your memcpy() or memset() that consumes the time, or how much time your actual drawing takes? Step 1 is always to actually check where the time is spent. No reason to optimize until you know.
I have not been working on the display part of our LPC2478 line of products, but I can tell you that at some point the clock source of the LCD needed to be changed to make the display stable. I don't remember the details - have a look in the user manual for all the possibilities.
The latest edition of the user manual of the LPC2478 (4) reveals a set of registers responsible for bus arbitratio (LCD, DMA, USB, external bus). Maybe these can help you.
Did you try the sample programs provided by EA? Do you have the same problem with them? You are not asking too much of the controller - we are working at 64[MHz] at 640X480 - no flickering. This must be a configuration issue of some kind. You can probably make drawing more efficient given the format of a pixel's color bit composition.
I am runnning the LCD as 4 bytes per pixel for full RGB so can appreciate that is the slowest interface.
Slowing the LCD refresh rate to the slowest speed before flickering was noticable improved the SDRAM throughput a great deal.
I will look into other bus settings over the next few days, my guess, as others here have noted, is the SDRAM access is not configured for full speed.