small colour LCDs

It appears that colour TFTs are too expensive, so I'll have to settle with a monochrome LCD like the one at

What do I need to look for in a microcontroller in order to drive this LCD?

cheers,

C3

You can get one with a controller built in. Eg. T6963C, SED1520, whatever. Then worry about memory size and speed for the size of the display and whatever it is that you're planning on doing with it, it only takes a dozen or so lines to interface to the LCD.

There are microprocessors with graphic LCD controllers on-board, (eg. Sharp 32-bit ARM LH75400) but I suspect that's more than you want. There may be microcontrollers too, I've not looked lately.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

a I

Sharp has some ARM7 microcontrollers that will do this, such as the LH75410 in your case. It's about $9 in moderate quantity, down to about $6 in consumer volumes. While this seems expensive, it's still competitive compared to an 8-bit uC + LCD controller IC. Also, it gives you grayscale capability with any STN LCD, it has a boatload of peripherals to complete your product, and it's well supported with cheap development tools.

Although Sharp calls these microcontrollers (no doubt due to the wealth of peripherals that are on-chip, making them almost complete systems), I'm not sure I agree. They require external program memory.

Best regards, Spehro Pefhany

--
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

That's only part of the story though. I would not wish a "from-scratch" project (handful of chips and my blessing) based around one of these parts on a relative beginner. There are a fearsome number of interconnects (SDRAM, flash, LCD), potentially some external logic, quite a bit of bring-up code before you can even be sure it's powering up right, and basically it's a fairly daunting first-timer challenge. So, you need to factor the cost of a prefabricated EVB and maybe a JTAG pod into the equation.

Although the '520 is more expensive per-unit, it's supported by the $199 RMS101 board, and that makes it the "cheapest" overall BlueStreak part for a project of this nature. I'm not aware of a comparably priced EVB for Sharp's other parts. Sharp's official development kit is kilobucks ($4500 I think, for the 520's EVB anyway - it's been a while since I looked at it. They loaned us one for a few weeks to get our bring-up code validated).

Color TFTs are too expensive? I can happily sell you one out of my collection of samples that I keep "just because I can't bear to throw them away". How about a 6.8" LG Philips VGA-resolution (640x480) panel with parallel input for $60, including backlight inverter and shipping within CONUS? I have larger panels but they are mostly LVDS inputs (I could probably find a 10.4" parallel-interface panel in my box-o-joy).

For about the same price, I can supply a 4" color TFT with an NTSC input board. (It's also possible to drive with an analog RGB and CSYNC signal, but you have to solder direct to pins of one of the interface ICs, and I don't have documentation on how to do it).

However, that's the easy part of the equation. How are you going to drive it? It needs to have data clocked in regularly to keep showing a picture. You can do it in software using a reasonably fast 32-bit microcontroller (Tauno, in this NG, has done it on Atmel ARM7s).

Plus a few logic chips, plus the bias generation hw, plus the backlight controller. Not very expensive, but a lot of things to design and debug.

Also, the timing requirements of a LCD panel may really be an uncomfortable feeling in the low lower back. The data must not be clocked in too fast, and there may be some timing requirements (line strobes) which really need to be accurate to avoid all sorts of flickering. Finding the timing specs may be rather difficult even with a "standard" connnection (DVI is another animal, I am quite sure it cannot be reasonably done in sw).

In our case, a conventional interrupt was way too slow, and

32-bit FIQ interrupts were used in the middle of 16-bit thumb code. The code is rather tricky.

The application mentioned above uses a 50 MHz AT91R40008, and the display controller eats up almost half of its performance. That is 20-25 MIPS on a 32-bit machine! The panel is only a 320x240 BW panel, one bit per pixel. The situation will be even worse for more sophisticated panels.

Display controlling is much easier in hw than sw. Unfortunately, the controller chips are quite difficult to command; even that route is rather bumpy.

- Ville

--
Ville Voipio, Dr.Tech., M.Sc. (EE)

I don't know about DVI per se either, but the relatively simple LVDS interface on most panels can be converted from a regular parallel LCD signal using readily-available encoders ($2.50 last I checked). As long as you can generate a good parallel signal, the converter will handle all the gory details of embedding clock and encoding everything onto the serial lines.

Yeah, don't I know it :( Sometimes the LCD controller macrocells in uCs can be surprisingly easy, though. Cirrus 7212/7312 is refreshingly simple (also unfortunately quite limited, but that's another story).

I think the problem is rather on the speed side; the data rate of DVI is so fast that any micro will have trouble coping with it in sw. However, I think DVI is better documented than the various parallel interfaces found on LCD panels. (My experience is mostly from smaller panels, so the situation may be different in VGA size.)

- Ville

--
Ville Voipio, Dr.Tech., M.Sc. (EE)

The datasheets I've used are fairly accurate, usually. The problem is more typically in the controller, especially if it's a fancy controller with 3D graphics, 2D blitter, etc etc built in. I thought I was a guru from having mastered the OCS chipset on the Amiga (with multiple resolution changes in every frame!), but really it was nothing compared to the difficulty of sorting out a simple fixed-resolution image on a modern SVGA chip.

Worst problem is they don't tell you what MUST be initialized and what can safely be left at factory defaults. So it can take three weeks just to get a sync signal out of the chip.

Uuuugggghhhhh... I feel sick already...

Our problem was that the far-east display module came with very little documentation. The 14-pin interface is assumed to be a standard interface. And it is, in a way. Most LCDs use the same raw driver signals. However, the timing specs, etc. may differ from one panel to another. The data may also be fed in from left to right and up to down or in some other way.

The only way to go was to have a close look at the module and track the connections. The datasheets of all chips onboard were available, so all specs could be derived from them and the PCB.

After that it was only a bit of trial and error; I made a CPLD- based system which fed a simple bouncing ball picture into the panel. Fter the image was visible, everything was extremely simple and easy. (From my point of view, that is. Tauno wrote the software, not me :)

The funny thing was that even the basic electrical specs shown on the display module datasheet were slightly odd. First of all, the signal names had been somehow mixed from those used in the driver chip datasheet. They had also slightly miscopied the application example from the driver datasheet. Furthermore, the panel was spec'd to +5 V, while all the chips were specified from 3 to 5 V. (Why? I dunno.)

So, nothing awfully difficult, but a lot of stupid little things that keep you busy for days.

- Ville

--
Ville Voipio, Dr.Tech., M.Sc. (EE)

If it is my personal small project, I would find some here:

I am not in anyway related to them.