LCD Displays - Embedded control

[annodomini2]

Hi all,

Probably not the best topic for this forum, but I have seen a few software engineers on here.

Currently looking at driving a TFT display from an embedded controller (through whatever required interface), I am an embedded systems programmer. However I have no experience with graphics specifically driving displays. Now I can see the simplicity of driving a 40X2 text display, but I wish to apply graphics etc in colour preferably.

I was wondering if anyone could point me in the right direction, i.e. links or books etc. To allow me to study and understand the subject.

TIA
Anno

[TheExcession]

Hi Anno,

take a look at this site

www.crystalfontz.com/

I ordered a fairly plain 20x4 character jobbie from here that had a serial interface, I then hooked it up to a PIC and way able to drive it quite sucessfully with only two wires.

They seem to have planty of different types there and you can get the data sheets which will give you plenty to read through.

Let me know how you get on, I love embedded-display type projects

[annodomini2]

TheExcession said:

Hi Anno, take a look at this site www.crystalfontz.com/ I ordered a fairly plain 20x4 character jobbie from here that had a serial interface, I then hooked it up to a PIC and way able to drive it quite sucessfully with only two wires. They seem to have planty of different types there and you can get the data sheets which will give you plenty to read through. Let me know how you get on, I love embedded-display type projects

Thanks, good link!

[Plotloss]

www.windowsfordevices.com

If you're going full TFT then thats your first port of call I reckon.

If its just a VFD type display then there are a number of toolkits out there that do it.

[Zad]

Okay, the jump from character based modules to colour graphics is quite a big one. Controllers in character modules are fairly simple, such as the Toshiba T6963 or Hitachi 44780 and are dirt cheap. Commonly available dot matrix-addressable modules tend to be fairly low-res (160x32 or so) and black/white rather than grey scale. Colour graphics (TFT) modules tend to "dumb" (no controller) and either fed an analogue signal in a way similar to a conventional monitor, or a fairly complex LVDS (low voltage differential signal) in a fearsomely fast multiplexed digital format.

Many experimenters still get their fingers burned by buying a fancy LCD panel off Ebay and then discovering that they need a separate controller to get it to do anything. As an aside, I have got 4x20 character modules from Ebay for a lot less than Crystalfontz etc are selling them!

However! If you don't mind your LCD being comparatively small (160x160 or so, 40x40mm-ish) then the way forward is to use replacement mobile phone LCDs. Either from Ebay or your local phone fixing place. Many of the Nokia ones have integrated standard Epson or Philips controller ICs, with publically available data sheets, and above all they are easy to feed, squirting data down a standard I2C line. Obviously, the backlight can need it's own voltage source, but these things display 12 bit colour and the controller is pretty fast and flexible.

Can I be nosey and ask what hardware you are going to connect to it? I spend quite a lot of time developing with PIC and ARM based devices. Drop me a line if you need any help. Here are a couple of URLs which might assist:

http://forum.lcdinfo.com/viewforum.php?f=9
www.apetech.de/article.php?artId=3&nnId=12 (in German)

Mike

P.S. If you get a TFT, make sure it has a controller!

[annodomini2]

Zad said:

Okay, the jump from character based modules to colour graphics is quite a big one. Controllers in character modules are fairly simple, such as the Toshiba T6963 or Hitachi 44780 and are dirt cheap. Commonly available dot matrix-addressable modules tend to be fairly low-res (160x32 or so) and black/white rather than grey scale. Colour graphics (TFT) modules tend to "dumb" (no controller) and either fed an analogue signal in a way similar to a conventional monitor, or a fairly complex LVDS (low voltage differential signal) in a fearsomely fast multiplexed digital format.

I guessed as much, my aim is to gain an understanding of writing drivers for controllers for TFT drivers (so I can display what I want without relying on propriatory sw) and subsequent generation of the graphics. No 3D a stuff as yet, just simple bar graphs, numbers characters and bitmaps to begin with.

Zad said:

Many experimenters still get their fingers burned by buying a fancy LCD panel off Ebay and then discovering that they need a separate controller to get it to do anything. As an aside, I have got 4x20 character modules from Ebay for a lot less than Crystalfontz etc are selling them! However! If you don't mind your LCD being comparatively small (160x160 or so, 40x40mm-ish) then the way forward is to use replacement mobile phone LCDs. Either from Ebay or your local phone fixing place. Many of the Nokia ones have integrated standard Epson or Philips controller ICs, with publically available data sheets, and above all they are easy to feed, squirting data down a standard I2C line. Obviously, the backlight can need it's own voltage source, but these things display 12 bit colour and the controller is pretty fast and flexible.

I was looking at the kits from Crystalfontz and EarthLCD, but the cost appears to outway the benefit. This sounds like a good plan, as they can be cheap. One question though, don't TFT panels need an inverter power source? Do you drive it from a H-bridge on the micro or external circuitry?

Zad said:

Can I be nosey and ask what hardware you are going to connect to it? I spend quite a lot of time developing with PIC and ARM based devices. Drop me a line if you need any help. Here are a couple of URLs which might assist: http://forum.lcdinfo.com/viewforum.php?f=9 www.apetech.de/article.php?artId=3&nnId=12 (in German) Mike P.S. If you get a TFT, make sure it has a controller!

PIC's IMHO are a great little training device for learning simple assembler (as the compiler is a joke! ) and how to do complex instruction set operations with RISC, but I was looking for something with a little more grunt.

Looked at ARM, never used them personally, but may be an interesting challenge. May go against the grain for you but I like to program in C, is there a GNU or Freeware compiler for these?

Was also looking at an MPC555 (PowerPC) chip as i've used them before and possibly the Hitachi SH4, which I know are both supported by gcc. Certain variants of the Hitachi come with built in TFT LCD driver chips (Palm pilots use them I think!), One of the development boards they provide has an LCD interface and embedded linux, so its plug and go. Although I don't know the cost as yet!!

Thanks for the links will do some more research, may be in touch if I have any questions.

>> Edited by annodomini2 on Tuesday 17th January 08:55

>> Edited by annodomini2 on Tuesday 17th January 13:42

[Zad]

Many of the standalone graphics controllers already have GNU/Linux/ucLinux drivers (ucLinux is a version of Linux for embedded controllers without a memory controller) so it may be worth having a look at the existing source code. The S1D13806 is/was notably popular, with 1.2MB of embedded video ram, and all sorts of whizzy things, but in their infinite wisdom Epson decided to discontinue it when the industry started to go lead free. Here's the data sheet so you can get an idea if what it can do:

http://suncrusher.turkeyland.net/~jeff/stuff/477/S1D


TFT panels *can* need an inverter, although some have it onboard which just requires plugging into 3.3v/5v/12v or whatever. Larger panels require 48-60v AC which can be sourced from a separate commercial inverter module. These are relatively simple things, just an oscillator and transformer. Having the module separate helps keep some nasty voltages and RF spikes away from the rather sensitive digital electronics. Which reminds me, some LCDs need a negative bias voltage which can either be sourced from a power supply or from a relatively simple 555 oscillator/charge pump. H bridges are only usually used when you want to control a motor speed and direction

Small TFTs, such as the mobile phones, tend to run off an LED side or backlight which simplifies things nicely.

I admit, most PICs are feeble! But then most microcontroller apps only need a feeble amount of intelligence, and PICs are incredibly cheap in quantity, and power consumption can be pushed into the sub-microwatt territory. Quite a few people use them simply to interface the LCD with their PC serial or parallel port, translating commands, buffering etc. Letting the PC do all the heavy duty grunt.

There are 2 main flavours of ARM cores, the ARM7 and ARM9. The difference is that the ARM9 has a full virtual memory controller and will run "proper" Linux. The ARM7 will still run ucLinux however. Both core types have active development communities and are supported by hardware manufacturers. I guess that has answered the GNU compiler availability question Third parties like Keil etc also supply compilers, IDEs and other tools. Similarly to the Palm Pilot, quite a few palmtops are based in the Intel ARM cored chips, with integrated video controllers. I confess I haven't used the PowerPC myself, but it is certainly a respected and popular architecture with a good amount of power.

I have no problem with you programming in C, most controllers are so complex now that higher level languages are the only realistic way to get anything meaningful done! I do still program in assembler, but most of the work does tend to be in C now. I still haven't progressed to the newfangled C++ or C#...

I would love to find a decent controller chip which doesn't have a BGA pinout though! As a freelance (mainly) hardware bloke, BGA chips are expensive to create prototype PCBs for and to populate. Grr!

Good luck in finding a dev kit at a decent price!