Selecting a Color TFT LCD display for your embedded application – Part 2

In the previous post, we talked about the terminologies of color depth, display size, resolution, and backlight. I’d like to dedicate this post to discuss about the frame buffer and why understanding if your display has a built-in frame buffer or not is important. As always, Wikipedia has a good generic summary on the frame buffer, http://en.wikipedia.org/wiki/Framebuffer. I will elaborate more from the perspective of an embedded system. First, let’s imagine a typical embedded system with a display; this will help illustrate key points in this article. At its simplest, there are 4 components, a microcontroller, a frame buffer, a display controller, and a display glass as shown in Figure 1.

Figure 1:

The potential confusing part is you may see other names in the real world for some of the four components that I’ve mentioned. So to avoid any confusion, I will explicitly explain what each of the above components does in my imagined system.

Starting from the right of Figure 1, we have the display glass; it displays screen images from the data-stream fed by the display controller. If the display controller stops feeding data to the display glass, it will stop showing meaningful images, and stay blank/dark. Next is the display controller, its only job is to continuously read from the frame buffer and stream pixel data to the display glass. The frame buffer stores color information for each pixel on the display glass. If the display glass supports 1-bit color depth, then 1-bit of frame buffer memory is required to represent 1 pixel. If the display glass supports 16-bit color depth (RGB 565), then 2 bytes of frame buffer memory are required per pixel.

Assuming that we have a display glass with a resolution of 320×240 and 16-bit color depth, how much frame buffer memory would be required to display one full screen? Well, the calculation is easy:

Frame Buffer Required in Byte:

= Number of Pixels x ( Color Depth in Bits / 8 )

= 320×240 x (16/8)

= 153,600 bytes

Let’s try another example. You may see a device advertised as having a frame buffer size of 256Kbytes. Is this big enough for a 480×272 display with 16-bit color depth? Let’s calculate:

Frame Buffer Required in Byte:

= Number of Pixels x ( Color Depth in Bits / 8 )

= 480×272 x (16/8)

= 261,120 bytes

A 256KBytes is equal to 262,144 bytes. Since 262,144 is larger than 261,120, a 256Kbytes frame buffer is therefore large enough to support a 480×247 display with 16-bit color depth. I hope you are now more comfortable with the concept of the frame buffer and how its size relates to the display resolution and color depth.

The last piece of the puzzle is putting useful data into the frame buffer. This is typically done by a microcontroller transferring data into the frame buffer. The microcontroller does not need to update everything in the frame buffer to change the screen. It only has to update what needs to be shown differently from the previous screen. This could be something as simple as changing a red square area on a yellow background to blue. See Figure 2 as an example, assuming a display resolution of 8×8, 16-bit color depth.

Figure 2:

Assuming the application is already displaying a red square on a yellow background. When the screen information is to be updated, the microcontroller doesn’t need to write color yellow to the frame buffer again, that information is already there. It only needs to write to memory areas that store the color red and change them to blue. In this case, only 4 pixels have to be updated, represented by 8 bytes of memory. Processing just 8 bytes of data once instead of having to always update the whole screen continuously (which would be 8 x 8 x (16/8) = 128 bytes in this case) is the key architectural factor which allows a non 32-bit microcontroller to be used in an embedded graphical application. Do also note that when there’s nothing to change on the display screen, the microcontroller doesn’t have to spend any CPU time to deal with the graphical sub-systems at all.

So far I’ve described 4 basic components that make up an embedded display system, but how are they packaged and sold in the market? Figure 3 shows four common architectures of an embedded display system available in the market place.

Figure 3:

In Figure 3-A, when a display has a built-in frame-buffer, I call it a display module. This is not a standard terminology, but it helps differentiate what I’m referring to in this article. The size of the built-in frame buffer varies, depending on what the display glass needs. A microcontroller can typically connect to a display module via a parallel or serial interface. Not every display has a built-in frame buffer. Smaller displays with lower resolution tend to have a built-in frame buffer, while bigger displays do not.

When a display doesn’t have a built-in frame buffer, it is often referred to as a ‘dumb glass’. In this article, I refer to the dumb glass purely as just a display glass, while a display with a built-in frame buffer is referred to as a display module. A display glass typically has what’s called the RGB interface. An RGB interface is identifiable when you see the following signals: HSYNC, VSYNC, Pixel Clock (Dot Clock), and Red/Green/Blue data lines. A RGB interface is not the same as the parallel interface mentioned in Figure 3-A. When I talk about a parallel interface, I’m talking about the Intel 8080 or Motorola 6800 like buses. I hope this is clear.

So when you shop for a display, you can identify if it’s just a display glass or a display module by checking if it has a RGB interface and/or a built-in frame buffer. Most display datasheets do not use the term ‘module’ or ‘dumb glass’; so the only way you could tell what it does is to look at the specifications and be knowledgeable about you what you are looking at. As a recap, if you see a built-in frame buffer and a parallel interface, the display is a module; and if you see a RGB interface, it is just a display glass. Some devices support both modes, such as any displays with the SSD1289 from Solomon-Systech (http://www.solomon-systech.com).

If your display has just a RGB interface, you will need to use either architecture B, C, or D shown in Figure 3. Not all microcontrollers have a built-in display controller, so I won’t spend too much time on architecture C or D. Let’s focus on Figure 3-B for the moment. A microcontroller may not have enough processing power to continuously feed data over the RGB interface, let alone having enough RAM to be used as a frame buffer. In this case, a 3^rd device is required to interface between the display glass and the microcontroller; I call this device a graphic controller chip. A graphic controller chip has exactly the two things that were missing, a frame buffer and a display controller. It connects to a microcontroller via a parallel or serial interface, and to a display glass using a RGB interface. There are many choices available for a graphic controller chip, an example is the SSD1926. Chip suppliers tend to have different names for this kind of device, such as image processor, graphic controller, LCD driver, LCD controller, etc. They all tend to have at the basic level, a frame buffer and a display controller, but some do have additional features such as 2D hardware accelerator, JPEG decoder, etc. The discussion related to these additional features is beyond the scope of this article.

To wrap things up, architectures C and D show a microcontroller with a built-in display controller, this means it can drive a display glass with just a RGB interface directly. Do beware though that some of these microcontrollers have internal frame buffer, and some don’t. When they don’t, an external memory will be required. Knowing these differences and requirements is crucial in being able to calculate the total cost in implementing an embedded display system. Now that you are armed with the understanding of frame buffer, you would have no problems when someone tells you “The display I’m using in my project is a 3.5″ display with 320×240 resolution, supporting at least 16-bit color depth, with LED backlight, and 256KB frame buffer, connected to the main microcontroller using Intel 8080 16-bit parallel bus.” Way to go. There’re still a lot of materials left to be covered in future posts, but this one will have to do for now. Happy shopping for a display!

Tags: backlight, controller, display, frame buffer, Graphics, lcd, pixel, resolution, RGB

Selecting a Color TFT LCD display for your embedded application – Part 1

I’ve been astounded by the number of electronic gadgets with small to medium size color TFT LCD displays that are in the market. Looking back at a recent weekend trip, I remembered calling friends on the cell phone to arrange the trip, there’s a LCD display on the phone. Then while driving, I used my GPS to get to the destination, there’s another LCD display there. Then trip’s moments were captured on my digital camera, there’s another LCD display there. Coming home, I loaded the pictures onto the digital picture frame in the living room, there’s another LCD display there. The small size LCD displays are everywhere! I looked around the house and pondered, what else could use a small LCD display? A quick glance, and I came up with – thermostat, security system, stereo system, light control panel (see Figure 1 for example), remote control, running treadmill, washing machine, car’s instrument cluster, .. and the list goes on and on. The bottom line is, as a human interface, the LCD display can help enhance the end users’ experience which is a competitive advantage.

Figure 1: A Control Interface for RGB LED Lighting

In the past, not so many products could afford to feature a color LCD display, but the price has come down dramatically in recent years driven by the economies of scale and competitions between display manufacturers. As an embedded application designer, you maybe looking at using a color LCD display in your next product design. There are a number of things to understand in order to make informed design decisions, the major steps are:

- Selecting a color TFT LCD display for your project

- Selecting a microcontroller and interfacing the display

- Drawing something on the screen, display driver development

- Saving some time, using existing tools, Graphics Library, development hardware platforms

In this first post, I will cover the topic of selecting a color TFT LCD display from the aspects that relate to the end usage experience. As with any other specialized field, the display market has its own unique terms and terminologies. So let’s get that out of the way first so we all can speak the same language. When talking to a display manufacturer, you may hear something like, “This display model is a color 3.5″ QVGA with LED backlight.”

Let’s break this sentence down one by one:

Color – In the simplest sense, one may think of this as either ‘black and white’ or ‘color’. But there’s more to it than that. We will cover more on this later.

3.5″ – This is simply the size of the display, similar to when buying a TV.  You get different sizes. The bigger the screen the further you can see from a distance, but also more expensive.

QVGA – A reference name for a display with the resolution of 320×240 pixels. Similar to a digital camera, given a display area, the higher number of pixels shows more details of an image.

LED backlight – Without a light source from the back, you won’t be able to see anything on a TFT LCD display

I will now cover each of the four factors above in more details.

Color Depth:

The topic of color depth seems trivial at first and in a way it is. But I’d like to spend some time explaining the details because it will have a significant implication on the interface between microcontroller and display, and also the firmware. A monochrome screen has only two states for each pixel, on and off, and only requires one bit of memory per pixel. When more colors are desired, more bits are required per pixel to represent the color of that pixel. If using 2 bits per pixel (bpp), then each pixel can display 4 different colors. Typically, with low number of bits per pixel, the display only supports different shades of gray colors. For example:

1 bpp

2 bpp

Moving away from black, white, and grays, we enter the realm of RGB colors. What is RGB you may ask. In short, RGB is a color model that represents each color with the intensity values of the prime colors Red, Green, and Blue. Wikipedia has a detailed explanation on RGB and I will not try to reinvent the wheel here. Check out http://en.wikipedia.org/wiki/RGB_color_model to read up more on RGB. Do pay close attention to the section ‘Digital Representations’.

In the market place, some display vendors will simply state that a display is an RGB screen. This is good enough to recognize that a display supports colors in the sense that you and I would expect. Some will also specify either 65K, 262K or 16.8 million colors, it may be true that human eyes are probably not capable of differentiating all these different colors, and the display do not have enough pixels to show all the different colors it can do in one screen; but knowing that a display supports either 65K, 262K or 16.8 million colors is still important for an application designer.

If a display supports 65K colors, it means each pixel is represented by a 16-bit value, the RGB color model used is 565, meaning Red is represented by 5-bit, Green 6-bit, and Blue 5-bit. Therefore, to represent each pixel, 2 bytes of memory are required.

If a display supports 262K colors, it means each pixel is represented by a 18-bit value, the RGB color model used is 666. It gets tricky to represent 18-bit in memory since 2 bytes and 2 bits are required per pixel.

If a display supports 16.8 million colors, it means each pixel is represented by a 24-bit value, the RGB color model used is 888, and 3 bytes of memory are required per pixel.

Without going too much into further details just yet, it’s clear that color depth has an impact on memory usage, often known as (image) frame buffer. I will cover this more once other basic terms are explained.

Display Size and Resolution:

Most of us are familiar with the concept of display size and resolution from buying a computer monitor. My laptop’s display size is 15 inches measured diagonally with the resolution of 1400×1050 pixels, this resolution is also known as SXGA+. I don’t remember all the names given to a particular pixel resolution, but a decent reference can be found on Wikipedia, http://en.wikipedia.org/wiki/Display_resolution

In an embedded systems, the screen size and resolution are much smaller. For example, there is a 320×240 pixels screen, also known as QVGA (Quarter VGA, where VGA is 640×480). I personally think using the name reference is dangerous, the actual pixel resolution should always be used when communicating with suppliers, design team members, customers, basically everyone. It is dangerous to use reference names because misunderstanding can happen. Try asking someone what the WQVGA resolution is, and you will probably get different answers from different people ranging from 480×272, 480×247, 432×240, 400×234, … You get the idea that this can be pretty confusing.

For a given resolution, you can find different sizes of the display to fit your application requirements. A 320×240 display can be found in the range from 2.4″ to 5.7″. You won’t really find a screen bigger than 5.7″ with 320×240 resolution because each pixel becomes too big and the granularity of each pixel becomes too coarse to an average end user at that point. From my experience, one doesn’t really choose a display resolution first, then the size. It’s more of an iterative process, you define a combination that fit kind of what you are looking for, then check the market to see what out-of-the-shelf components are available, then go back to fine tune your selections and requirements again. Alternatively, you have the option to work with a display manufacturer to custom tooled a display that would fit your need, tooling charge typically applies and what you want has to still be manufacturable by the existing manufacturing process.

Backlight:

Again, wikipedia has a short article on backlight, http://en.wikipedia.org/wiki/Backlight, check it out. Most small to medium size LCD displays for embedded applications are available with LED or CCFL backlight. What you need to know is, most screens that you would choose use LED backlight. The forward voltage to turn on the LED array is different from display to display, but is specified in the display data sheet. The backlight power supply is typically separated from the operating power supply of the display itself which can be 3.3v and/or 5v. Additionally, all LCDs require positive and negative drive voltage. Many displays have this circuit built-in, simplifying the design process. But some don’t and additional external circuitry will be required, so do pay attention to this.

Tags: backlight, display, Graphics, lcd, pixel, resolution, RGB