How to use the color LCD from the Nokia 6100 mobile phone with your own microcontroller project? Inside: Description of full-color (4096 colors) LCD mode, connecting the display to the µC and free graphics library to download.

I was looking for small color LCD display for my embedded experiments. The best choice for such purposes is the LCD from an old mobile phone. They are cheap enough and well-documented.

I have bought a Nokia 6100 LCD on eBay for cca 5-6 US$. SparkFun has this LCD too, for US$ 19.95 - you can buy it here . I have also bought the carrier board from SparkFun . It's really the better way than experiments with soldering iron and 8-pin 0.5mm pitch connector. (Thanks to Refik Hadzialic for this idea!)

I've no spare AVR or PIC board at this moment, so I have used the LM3S811 Eval Board from Luminary Micro . The LM3S811 microcontroller is an ARM7 Cortex-M3 based microcontroller with 8kB RAM and 64kB FLASH. Luminary Micro eval kit, mentioned above, contains also the FTDI USB chip, an OLED display, a serial FLASH and other stuff. But the greatest feature for me is embedded USB interface for programming and debugging.

My library contains two "uC-specific" parts: The initialization and I/O operations (pin set/pin reset), but it is really simple to use it with another 8bit microcontroller, because it is written in "basic C language" with no ARM-specific things.

So - I took a soldering gun, a piece of wire and connected it together this way:

• Display GND with EvalBoard GND
• Display +Vin with EvalBoard 3.3V
• Display RST with EvalBoard PA1 (U0TX)
• Display SDATA with EvalBoard PA5 (STX)
• Display SCLK with EvalBoard PA2 (SCLK)
• Display /CS with EvalBoard PA0 (U0RX)

Here is my device (picture is taken after some time of experimenting. There was no image immediatelly after soldering, of course):

I planned to use a built-in SPI interface, but controller used in 6100 LCD needs a 9-bit communication protocol, so the interface can use any of output pins (really output; there is no LCD-to-µC channel, so no input is needed).

I took the code from the great Refik Hadzialic's article as the base point of my own experiments. I´ve made some uC-specific changes (initializing and pin output operations). And voila - everything works OK on the very first attempt!

Great work, Refik!

After a bunch of experiments with Refik's code I have feel a little bit disappointed. My LCD can display 4096 colors, but the code I used can work only with 256 colors. What a shame!

I have start to experiment with full-color mode. After a lot of mistakes and a lot of rides on the road to nowhere I realized that basic fact about a full-color mode:

1. Full-color mode (12 bits-per-pixel mode with 4096 colors) is simple and straightforward, there is no mystic things, no kabbala in this mode.

2. Every pixel takes 3 nibbles (the nibble is a half of byte, or 4 bits), simply one for R, one for G and one for B component.

3. Two neighbour pixels shares 3 bytes by this way: R1G1 - B1R2 - G2B2. So the first byte is Red and Green values of the pixel 1, the second byte contains Blue value of the pixel 1 and Red value of the pixel 2, and the third byte is remaining Green and Blue values of the Pixel 2.

BUT!!!

4. When controller sets up the pixels, it must send always the "three-bytes-aligned" amount of data.

SO:

5. It is possible to set only even number of pixels (2, 4, 6, 8, ...) at once

AND:

6. You must start everytime with the pixel on the even column (0, 2, 4, ...)

This is very limitating condition to write some complex graphic library (don't forget you can't read any values from LCD, so it's impossible to set only one pixel by "read-modify-write" technique).

There is number of ways to deal with this:

The first way is to forget about 4096 colors and use only 256 colors. It's simple, quick and good enough for most of applications.

The second way (used in my library) is to respect these limitations. You can't simple manipulate with each pixel, but it's possible to "degrade" the resolution of the display. It means, for example, doing the graphic operations aligned on 2-pixel-boundary.

And finally you can allocate the memory buffer in your µC and do the "double buffering" technique. But, unfortunatelly, LED with 132x132 pixels needs more than 17kB of RAM. In 12bpp mode the buffer consumes 26 kB... But RAM is the most expensive thing in microcontroller - I don't know much µCs with at least 32kB RAM on chip. But if you have such one, you can use this double buffering method.

There is another way I want to try in the next days... I wrote an article if it will be possible.

My demo:

Look at that 2x6 color shaded rectangles at bottom of the display. On the first row are the paletted (8bpp, 256 colors) rectangles, on the second row are the rectangles in full 12bpp mode. Notice the "quantizing stripes" in the first row, due to the low color resolution in 8bpp mode.

You can download my alpha source code. There are the basic I/O routines, the initializing routine and some drawing routines (8bpp pixel, horizontal and vertical line, general line, rectangle, circle and filled circle; 12bpp horizontal line, font and buffer copy routines are included too) in the library.

My library is also available from Google Code - Nokia 6100 LCD . You can check it out by Subversion too, using svn checkout https://nokia6100lcd.googlecode.com/svn/trunk/ nokia6100lcd

Stay tuned for the next version of the library with more capabilities, mainly with full-color support without buffering and without "pair-of-pixels" limitation!

(Thanks to Refik Hadzialic , Thomas Pfeifer and other people experimenting with this LCD.)