Microcontroller with QVGA or VGA LCD controller

[...]

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."
 Click to see the full signature
Reply to
Stef
Loading thread data ...

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.

Reply to
David Brown

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.

Reply to
larwe

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

Reply to
David Brown

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

Reply to
donald

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

Reply to
larwe

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

Reply to
David Brown

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."
 Click to see the full signature
Reply to
Stef

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.

Reply to
David Brown

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

Reply to
suresh 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

formatting link

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

formatting link

------------------------------------------------------

formatting link

David Brown wrote:

Reply to
Didi

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

Reply to
Not Really Me

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

Reply to
David Brown

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

Reply to
David Brown

I guess that's another vote for Epson!

mvh.,

David

Reply to
David Brown

I've not used the Renesas microcontrollers at all - but I'll have a look.

mvh.,

David

Reply to
David Brown

There are QVGA TFT displays with built-in controllers.

For example:

formatting link
formatting link

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

Reply to
Frank-Christian Kruegel

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

Reply to
Frank-Christian Kruegel

VGA LCD controller? this any good to you?

formatting link

Cheers Don...

--
Don McKenzie

Affiliate Program:   http://www.dontronics.com/affiliate
 Click to see the full signature
Reply to
Don McKenzie

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

Reply to
David Brown

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.