Re: Microcontroller with QVGA or VGA LCD controller

"David Brown" <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> skrev i meddelandet
news:47c6914b$0$15004$8404b019@xxxxxxxxxxxxxxxxxx
Ulf Samuelsson wrote:
"David Brown" <david@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx> skrev i meddelandet
news:47c56945$0$14989$8404b019@xxxxxxxxxxxxxxxxxx
donald wrote:
David Brown wrote:
Does anyone have any recommendations for microcontrollers with LCD
controllers for QVGA (320x240) or full VGA (640x480) displays?

I've found a few large devices (a ColdFire v3 device, and a number of
ARM9's from Atmel) that have LCD controllers supporting much larger
screens, but these are pretty big and fast microcontrollers, with
large pin counts and needing sizeable external memories.

I'm hoping to find something a bit smaller and cheaper, and easier to
work with.

Stand-alone LCD controllers would be an alternative, if such a thing
exists these days.
Wouldn't a smaller controller be slow in up-dating the display ??

640x480 monochrome display = 307200 pixels; /8 = 38400 bytes.

I don't think any smaller controller can address that large of a frame
buffer memory.

And color could be 4, 8 or 16 times larger.

Something to consider.

I'm expecting to use a 32-bit controller, with a large enough external
databus (or large enough internal memory if I'm lucky) to handle the
memory needed. I'm not going to need to update the display very quickly
(it will mainly be text messages - no video or anything). I expect
something in the class of 40-100 MHz ARM7 or ColdFire v2 to be
appropriate. So "smaller and cheaper" here is relative to the 200+ MHz
devices I found in my first searches.

If you use VGA resolution, you need 36 MB / second bandwidth
from your memory system, just to do refresh.
On top of that you have overhead for CAS/RAS precharge.
The LCD refresh would eat up significant part of the bandwidth
so your ARM7 would slow down to crawl.


That would be for a full VGA, 40 Hz refresh, 24-bit colour. We won't need
that much - I am not even sure if we are going for full VGA instead of
QVGA (at the moment, we are considering the advantages and disadvantages
of both), and we won't need that level of colour fidelity.

Also, the processor won't be doing much work anyway - all it will have to
do is write to the screen on occasion.

The AT91SAM9261 has 160 kB of memory on chip, and
there is no conflict whatsoever if you do display refresh

The AT91SAM9263 has a dual bus system so you can realisticly
use up to 800 x 600.


These two are devices I've already found, and are definitely under
consideration (I haven't used ARM's before, but we use a lot of AVR
devices from Atmel - so they are an obvious candidate as a supplier). They
are greatly overdimensioned in power and features for what we really
need - but we are still looking at possible options at the moment.

To give you an idea, the prototype system today is running with an AVR
controlling the card and a 32x140x1-bit graphics display with its own
attached LCD controller. We want to have a larger and nicer screen, with
support for colour and simple graphics. It's even possible that with a
LCD controller such as the Epson devices mentioned in this thread, we'd
use an AVR to control the screen (with an external serial flash to hold
logo bitmaps).

[snip]
It's just that a card using a 200-300 pin bga 200+ MHz processor and
matching memory is going to be a lot more expensive to design and produce
than one using a 140-pin TQFP 50+ MHz processor.


If you shoot for QVGA graphic and 8 bit per pixel, you will need
75 kB for the screen, and this leaves 85 kB for the controller
in the AT91SAM9261. It is not double buffered of course...

The part will need an SPI flash to boot using AT45 flash.
Only 4 pins needed to communicate.

While the part has 217 pins, you can probably ignore the
absolute majority of the pins, simplifying the layout.
You do not need any parallel RAM memory
which would be required for the ARM7 stuff.

Fonts etc can be in the dataflash and it can
accessed using DMA (PDC) at 4 MByte/second.

Even if the part runs at 200 MHz, you can still run it at 50 MHz.

mvh.,

David





--
Best Regards,
Ulf Samuelsson
This is intended to be my personal opinion which may,
or may not be shared by my employer Atmel Nordic AB


.

Relevant Pages

  • Re: Microcontroller with QVGA or VGA LCD controller
    ... I've found a few large devices that have LCD controllers supporting much larger screens, but these are pretty big and fast microcontrollers, with large pin counts and needing sizeable external memories. ... I'm expecting to use a 32-bit controller, with a large enough external databus (or large enough internal memory if I'm lucky) to handle the memory needed. ...
    (comp.arch.embedded)
  • [Fwd: Console stops scrolling]
    ... The FC5 kernel appears to have a problem with the on-board VGA ... controller in this very old Compaq Proliant 2500 server. ... This machine does have an odd memory config, ...
    (Fedora)
  • Re: VGA controller for embedded project?
    ... > controller, which should take care of this problem. ... you still need to interface special memory to the VGA ... These are moving in a more usefull embedded direction, ...
    (comp.arch.embedded)
  • Xilinx TFT controller
    ... Is TFT Controller v1.00a for Microblaze 7 the easiest way to output ... video buffer to VGA screen? ... I was thinking of writing my own VGA ... I would have to cut down on the originally planned resolution of 24- ...
    (comp.arch.fpga)
  • VGA card id?
    ... It says..new hardware... ... Vga card/ ... controller.. ... I have run Belarc Advisor it is not listed there.. ...
    (microsoft.public.windowsxp.hardware)