Posted by Carol on May 27, 2009 in
Touch Screen There are many different types of touch screen technologies currently available, and many emerging technologies in development, but fewer than ten can be considered commercially viable at this point. In terms of market share, analog resistive is still by far the leader with well over 80% of all applications (and often cited as much more depending on the market data source and product definitions).
Analog resistive, referred to as just “resistive” from this point forward, is the workhorse of all touch screen technologies due to its low cost, acceptance of finger and stylus input, and overall ease of manufacture and integration. The main drawback of resistive touch screens is their relatively low durability and poor optics because of the standard construction of ITO coated film on ITO glass construction. The top film layer degrades with activations over time which reduces the touch screen life and the air gap between the film and bottom layers also causes the transmissivity to drop to the low-mid 80% range.
Another common touch screen technology is surface capacitive. This technology makes up a small percentage of all touch screens, traditionally with a focus in casino gaming, ATM’s and POS applications. Surface capacitive touch screens have fewer suppliers because they are relatively difficult to manufacture. A major disadvantage of surface capacitive touch screens is that they must be activated by a human finger as well as the need for periodic calibration and a good ground plane. Due to the single-layer glass construction, the transmissivity is very good at typically >90% and the durability is also very high in general.
When I use a touch screen on a kiosk, for example at an airline check-in station where most likely it is either a resistive or surface capacitive application, just for fun I’ll check to see if my fingernail or credit card will activate the touch screen. If a fingernail or credit card works, it’s a telltale sign of resistive. If not, it exhibits one of the drawbacks of surface capacitive technology. And, by this time, the people behind me are wondering what is going on – they don’t care about what type of touch screen technology the kiosk has, they just want it to work!
Tags: capacitive, controller, resistive, Touch Screen
Posted by Rawin on May 15, 2009 in
Displays,
General,
Output 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 3rd 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