In comp.arch.embedded,
David Brown <david@westcontrol.removethisbit.com> wrote:
We use the Epson S1D13706 in 8bpp mode for a QVGA display (TFT 18-bit).

--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

"Computers in the future may weigh no more than 1.5 tons."
(Popular Mechanics, 1949)

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.

On Feb 27, 7:22*am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
What color depth? I'd suggest one of the low-end ARM7 parts such as
NXP (Sharp) LH79520 or Cirrus Logic CL-EP7312. You will still require
external memories and I don't think you'll get away from that anyway -
big displays need lots of framebuffer RAM and it's not common to find
a micro with 512K of on-chip RAM - rarer still for that to be an
inexpensive, low pin-count part.

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
contend with, but at least you can make your own decisions about color/
text encoding, etc.

The Epson parts another poster mentioned exist, and they have on-chip
framebuffer. However they certainly don't have a low pin count (QFP
devices) and I would DEFINITELY not describe those parts as easy to
work with! You have to glue the bus onto your micro, which is not too
hard, but then you have to work with their semi-operable development
system to get the chip set up for your panel. Argh. Unless things got
a lot better since 2002, I wouldn't describe this as an easy route.

Stef wrote:
Thanks for that suggestion - it could well be that one of Epson's
display controllers (I see they have a whole series) combined with a
smaller microcontroller would be the best solution for us.

mvh.,

David

David Brown wrote:
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.


donald

On Feb 27, 9:04*am, David Brown <da...@westcontrol.removethisbit.com>
wrote:

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!

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.



Very very similar part to the 79520.

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).

larwe wrote:
I don't know off-hand what colour depth we'll be looking at (I don't
have the technical details on the displays as yet). My guess is that
the displays are 18-bit, and we can run them at 16-bit or 8-bit colour
depth. We haven't yet decided on the QVGA or VGA panel, or if we want
to support both - it depends on the options available. With
320x240x8-bit, the frame buffer is small enough to fit within the
internal memory of some high-end integrated microcontrollers - we're
considering many options at the moment.

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.

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.


What sort of pixel clock are needed for a typical QVGA LCD panel (if
there is such a thing as a "typical" panel - I haven't got the technical
details yet)? I would guess it would be a few MHz - that's quite
demanding for a processor if it needs to do anything else. Perhaps
something could be set up using DMA transfers and some glue logic - but
then it might be just as easy to use a programmable logic device (which
is another possible solution - an LCD controller is pretty simple).

QFP packages at around 140 pins are perhaps not low pin counts, but
compared to the 200-300 pin bga packages of the ARM9 and ColdFire v3
devices I found earlier, they are low pin count! I've done boards
before using large, fast bgas and memory buses before, but I'm hoping to
make something smaller and cheaper here.

I have no experience with Epson devices, but they do look a bit overly
complicated to configure. I had a look at the information about the
Linux framebuffer drivers for the devices (not that we'll be running
Linux on this board - it was merely for curiosity) - I thought it was a
little odd that to configure the chip you need a windows-only program!

Thanks for the info,

David

In comp.arch.embedded,
larwe <zwsdotcom@gmail.com> wrote:
The Epson configuration utility is indeed not very user friendly. But
it's only function is to generate settings for the 50-60 registers
(s1d13706). Something you can do by yourself as well, just read the
datasheet. It only has to be done once.

In 8bpp mode the framebuffer and LUT where fairly easy to setup IIRC.

Even if you use the utility, I suggest checking every register setting
by hand. We found that the pixel clock divider will not be set up
correctly. We only discoverded this when we switched to another display
and that one didn't work and we did not understand why. It seems the
old display was happy to use the undivided 48MHz clock, while the new
display realy needed the clock to be in spec. :-) So we edited the
config file to set the pixel clock to /8 and all was well again.


--
Stef (remove caps, dashes and .invalid from e-mail address to reply by mail)

"Computers in the future may weigh no more than 1.5 tons."
(Popular Mechanics, 1949)

donald wrote:
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.

On Feb 27, 7:22*am, David Brown <da...@westcontrol.removethisbit.com>
wrote:
We are using a QVGA panel with ARM7 and interfacing it to a epson
controller.
Configuring epson controller might take a while, but its a good chip
which will take care of most of
the work. I heard of this new nxp chip which is all in one, but i
believe its still in the works. The PCLK we are looking
at is 6.25 MHz

Suresh M. Shenoy

People in the neighbourhood here began testing an OLED QVGA display
which comes with a controller and framebuffer memory.
The controller chip is some Samsung part IIRC, S6E63D6 ,
yes, found its datasheet at
http://www.cec-mc.ru/comp/lcd/powertip/pdf/S6E63D6.pdf

The complete display part is some C0283QGLC device, they
reported - I saw some photos - good looking results apart from
the fact that one may have to live with up to 4 bad pixels (up to
one dead colour per bad pixel, that is). The other catch may be
the lifetime, they specify 10k hours. Two guys had bought
a single piece, one had 2 bad pixels and the other had 1.
The price they mentioned was something like $70 (1 piece).

I have some more data on it on my disk, let me know if you
need some.
I have not tested this nor actually had it in my hand, I only
tell a story I have been told.

Dimiter

------------------------------------------------------
Dimiter Popoff Transgalactic Instruments

http://www.tgi-sci.com
------------------------------------------------------
http://www.flickr.com/photos/didi_tg...7600228621276/

David Brown wrote:

"David Brown" <david@westcontrol.removethisbit.com> wrote in message
news:47c54d13$0$14998$8404b019@news.wineasy.se...
The latest issue of EETimes had an ad from Renesas for a line of H8S and
H8SX microcontrollers that support TFT-LCD in VGA/QVGA with external SRAM.

Scott

larwe wrote:
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.

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.

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).

Didi wrote:
The display type and supplier has already been picked - it's quite a lot
cheaper than the price you have there (I don't know how it compares in
quality). But perhaps Samsung also have LCD display controllers
equivalent to the Epson ones, which might be an alternative? I had a
quick look at the datasheet - it doesn't look like it is much harder or
easier to configure than the Epson parts, based on a very quick look.

Thanks for the suggestion anyway,

mvh.,

David

suresh shenoy wrote:
I guess that's another vote for Epson!

mvh.,

David

Not Really Me wrote:
I've not used the Renesas microcontrollers at all - but I'll have a look.

mvh.,

David

On Wed, 27 Feb 2008 13:22:45 +0100, David Brown
<david@westcontrol.removethisbit.com> wrote:

There are QVGA TFT displays with built-in controllers.

For example:
http://www.ampire.com.tw/Eng_web/r1_am.htm
http://www.gpegint.com/tft.html

These displays only require a 3V Intel style MPU interface - D0-D7 or
D0-D15, RS, /WR, /RD, /Reset. Period. Nothing else. OK, plus LED backlight
supply and 4-wire analog interface for the ones with touch panel.

Just google for ILI9320 or ILI9325 or HX8312, and you'll find more of these.

The only problem is getting these displays in low quantities. Ordering lots
of 10k is easy.

Mit freundlichen Grüßen

Frank-Christian Krügel

On Wed, 27 Feb 2008 17:27:38 +0100, Frank-Christian Kruegel
<dontmailme@news.invalid> wrote:

Addendum: Mouser part # 668-MTF-TQ24NN731-LB is what I mean. 36$ for Q1 and
in stock. The ILI9320 data sheet should also work for the 9325.

Mit freundlichen Grüßen

Frank-Christian Krügel

VGA LCD controller?
this any good to you?
http://www.dontronics-shop.com/4d-Mi...1-p-16683.html

Cheers Don...


--
Don McKenzie

Affiliate Program: http://www.dontronics.com/affiliate
Site Map: http://www.dontronics.com/sitemap
E-Mail Contact Page: http://www.dontronics.com/email
No More Damn Spam: http://www.wizard-of-oz.com

Parallax Propeller Powered .96" OLED module
http://tinyurl.com/2vr2gr

Don McKenzie wrote:
We are going to be making a fair number of these boards - your module
might make sense for a small series, but I don't see it as a good fit
for us here. Besides, as far as I can see from your webpage it has a
VGA output, while we need to control the TFT LCD screen directly.
Thanks anyway,

David