LCD-embedded controller or separate controller

embedded inside a microcontroller. forgot to mention.

Seperate controllers take up more board space. However, they mean you can use a simpler microcontroller which will cost less than one with a built in controller. Whether the saving on the MCU pays for the cost of the external controller is a question of production quantities.

A point I suspect more valid to you is that there are relatively few microcontrollers with built in LCD controllers so you narrow the number of devices to choose from. An external controller makes many more available.

Bearing in mind your previous question about GUIs then I suspect you are still in a preliminary stage in specifiying your system. I recommend a MCU with a built in controller - I like the Sharp (soon to be NXP) parts. Get a development kit with an LCD panel and you'll save yourself a lot of effort (LogicPD are good). If cost is an issue then think hard about whether you can complete this project - it's hard to do LCDs on the cheap.

Is there specific/standard pinout for LCDs? I was searching for same, but I can see different LCDs have different pinouts. I have many LCDs available with the required specification. How do I choose one?

Integrated controllers almost invariably use UMA, which has performance implications.

That is very true. My system runs 64K colours at 640x480 resolution and running code from flash causes significant screen jitter. I have to copy into RAM and run from there or drop to 256 colours. To maintain a 50Hz refresh rate something like 30% of my processor bandwidth is taken up with just keeping the screen refreshed. At 75Hz it takes nearly half of it.

There are many. Don't base your screen choice on the connector alone but it would be nice if you had a second choice that was compatible with the first. There are more important things in choosing a screen - cost, brightness, contrast, cost.

It depends on the Design w.r.t Size, Cost factor , the Type of Application/Product and Use.

Karthik Balaguru

text -

Though the pinouts & naming conventtions look bit different. The core cocept of Driver here will be the same and simple.

Karthik Balaguru

text -

I haven't read much theory about LCDs. What I know is there are many LCD types.(active, passive) then TN,TNR,STN,FSTN,TFT,TFD,etc. How do I know which is suitable for me? Do I need to study all of these??? :-(

It depends what your device is doing. TFT gives good all round quality but STN is a bit cheaper. If you just want grayscale then TFT is a waste of time. If you want things that are readble in sunlight then you need to start thinking about transflective screens and the like - I've seen some good Hitachi ones demonstrated.

If you are going to buy a reasonable quantity (100+) then get a rep to come in a demonstrate some of their models. The best way to decide is to see the image for yourself. And then look at the price and see what you can afford. Don't forget to factor in the price of inverters, connectors and/or cabling.

You may find that your required resolution will drive whaqt technologies you can use. If you need graphics under 320x240 and you are not looking for color there are planty of STN and DSTN options. When you get to QVGA (320x240 pixels) TFT displays are taking over in price and number available.

When my team was considering display and controller options we found that the memory requirements for larger displays was a serious consideration and I would recommend if you are looking at VGA (640x480) resolutions you use a separate controller with its own memory bus because even at only 16-bit color (8-bit actually uses as much processing overhead since it requires a color lookup table that is note required by most video controller for 16-bit color) every framebuffer is going to require 640x480x2 bytes of RAM (600KB). This doesn't sound like a lot, but you need at least two framebuffers so one can be displayed and one can be updated. Some separate video controllers have their own dedicated RAM and only need a full framebuffer loaded occasionally when there is a full screen update. On-board video controllers may not have this feature and instead require interleaving memory accesses of the framebuffers with other bus activity and consequently slow things down at a rate that depend on the display refresh frequency and display size (resolution). My team eventually selected the Freescale 5329 Coldfire processor and we are using the on-board video controller to drive a

320x240 color display for an industrial machine controller design. The controller was capable of driving TFT and STN technologies of resolutions up to 800x600 with 18-bit color, but like I said that is at the expense of processor performance elsewhere so our balance ended up at 320x240 16-bit color.

If your product can afford the extra $30+ in cost (video controller + dedicated video RAM) and video is an important feature, you probably want a separate controller. If you simply need graphics and integrated controller might work. Our design with the Freescale part is working out but I have heard of problems from other groups using other processors with a similarly built-in controller where they ended up using an external controller anyway. I'm not sure what the issues were in those cases but you can see the trade offs we considered.

Can anyone give me any application notes which will help me to understand the uC and LCD (or uC and LCD controller) interfacing ?

... snip about 115 lines ...

Can anyone explain why this query required quoting roughly 115 lines of former conversation? Or why it was posted as a reply in this thread?

--
 Chuck F (cbfalconer at maineline dot net)
   Available for consulting/temporary embedded and systems.

ok ...I have put a new query... :o) If you have some application notes, you can post there.