Re: Microcontroller with QVGA or VGA LCD controller

larwe wrote:
On Feb 27, 9:04 am, David Brown <da...@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
wrote:

If we find something that needs some external memory, that's OK - but
I'm hoping it will be something like a single SRAM device and the
microcontroller's internal flash, rather than external flash and large
fast SDRAM/DDR memories for a big processor.

Again, this is not the usual course of events. It is very unusual to
drive large framebuffers like this from SRAM. The current normal
practice in low-end devices (DVD players, PDAs, etc) is to use [SDR]
SDRAM; 100 or 133MHz bus speeds. Remember that these devices are UMA;
the bus is shared by the processor - so you need a lot of bandwidth
available to keep a 75MHz 32-bit cached core happy and well-fed with
data, plus 16bpp VGA video!


If you need the full power of the processor, such as for video decoding, then you need fairly fast ram, and you probably need quite a bit of it. In my case, the processor will not need to do much work - pretty much all the external ram bandwidth will be available for the LCD. So if we estimate a 5 MHz pixel clock for the 320x240 case, there should be no problem using a simple low-power SRAM. At 640x480, and especially if it is not as wide as a pixel, then we would need a faster bus.

If we have to use sdram, or if it's the cheapest and easiest solution, then that's fine. It just seems to me that if I need 5 MHz x 16-bit memory bandwidth for 160kB, then sdram is a bit over specified.

Note: There may be an ASSP that does exactly what you want. Look for
instance at ESS Technologies' media player ASSPs. They require
external SDRAM and flash of course, but such chips are available in
TSOP package, not too difficult to work with.


I just had a brief look at their site - it seems to be much more advanced than we need. I am only planning on displaying some text (with a few different sizes), and maybe a logo and some simple graphics.

The NXP part looks interesting - ARM7 is the sort of core we are
expecting to use. Their website is so awful that I gave up trying to

:)

find anything by myself. I hadn't thought of Cirrus Logic (we have not
used ARM devices before, so I'm not familiar with all the suppliers),
but I'll look into their devices later.

Very very similar part to the 79520.

You can also drive the panel directly in software. This isn't exactly
fun but it is doable. Of course you still have the RAM issue to
What sort of pixel clock are needed for a typical QVGA LCD panel (if

Very roughly between 4-5MHz, but it does vary quite a lot. Of course
there is a grayscale here in terms of CPU loading - you can generate
the pixel clk from a high-speed timer, output the raw clock to an
external pin, and use an external FIFO (some number of cascaded 8-bit
or 18-bit latches) to offload the data multiple pixels at a time.
Unfortunately I have yet to find a CPU with a DMA engine that does
exactly what I would want in this regard. Some CPUs have very high
speed synchronous serial interfaces that could be used to deliver 8bpp
data to such a panel (again with an external shift register).

Certainly the DMA engine in the ColdFire v2 processors would need a bit of external glue logic, but it would be possible. However, it quickly gets to the point when it would be just as easy to use programmable logic - a simple LCD controller would not be difficult (I made a VGA controller in an FPGA for another application - they are not that different).
.

Relevant Pages

  • Re: Memory selection for an embedded system
    ... For example, SDRAM will be fast ... SRAM is often times use instead as it doesn't require this, ... Flash, on the other hand is non volatile, fairly high ... often times used as ROM while EEPROM is ...
    (comp.arch.embedded)
  • Re: WARNING:Xst:1778 - Inout
    ... use unidirectional ports in sub modules. ... ports for top level devices (SDRAM, SRAM, Flash, etc.) ...
    (comp.arch.fpga)
  • Re: Sync option destroys flash! Now Im confused...
    ... Front part of the flash was heavily ... little bit of SRAM for one page of I/O. ... the flash-RAM page that was ... offset into the page, ...
    (Linux-Kernel)
  • Re: SRAM vs Flash based FPGA one more time
    ... On the other hand SRAM FPGA are much easier to manufacture. ... that has access to big flash etc. ... can be protected via encrypted configuration streams in most of the new ...
    (comp.arch.fpga)
  • Re: Front Element Condition
    ... A good 3-5 pixel edge softness on everything too. ... I guess the problem wasn't resizing and compression. ... that's caused by using a large sensor for macro-photography. ... No, that's not the case, you clearly used flash in that image. ...
    (rec.photo.digital)