Posted by Padmaraja on May 28, 2009 in
General The capacitive touch is a “cool” alternate to the tactile switches and membrane switches, but when it comes to the layout of the key board in a capacitive touch application, there are many challenges. Ideally, having the same trace length from the microcontroller to the Cap touch pad is desired. But in real life applications there are many challenges, the major challenges are the keys area being too small in size and the application needs the keys to be placed very close to each other,. In addition to this, the form factor of the board to fit the application can add another level of complexity, where the microcontroller may be on one end of the large board and the keys may be on the other end. This makes the traces to the touch pad are too long. Also in many applications a display may be placed in the middle of the board and the keys placed on the either side of the display.
In these situations, the trace resistance and inductances connecting the sensor to micro varies from each other based on the key placement with respect to the microcontroller. The Charge Time Measurement Unit(CTMU) on many PIC24F and PIC18F architectures give a solution to tune the channels to read more of less the same voltage. To state in simple words, the CTMU is a constant current source. The nominal current source selections available are 0.55uA, 5.5uA and 55uA. But it has this great feature where the current source can be trimmed upto + or – 62% of the nominal value. On the channel that uses long trace to connect to the capacitive senor, the current can be scaled up to compensate the transmission losses in the trace. On the channels that are short, it can be scaled down to keep the ADC reading at the same level as the other channel with long trace length. This simplifies the algorithm to a great extent, not having to have the trip levels and filtering mechanism much different for each channel. This reduces the code size used for the cap touch application.
A simplified flow chart below shows an automatic leveling of the channels, that trims the current according to the trace length and variation in sensor size.
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
Posted by Keith on May 7, 2009 in
Uncategorized In today’s power lean designs, the priority is to minimize current consumption without sacrificing performance, especially in the user interface where it would be most noticeable.
OK, so how do we minimize current while remaining responsive to the keyboard?
1. Reduce the clock frequency.
2. Put the part to sleep, basically set the clock to zero Hz.
3. And minimize, or hopefully eliminate, any external current sinks.
Let’s start with the reducing the clock, if we reduce the clock speed of the microcontroller when the system is idle, then we can see a significant reduction in the current consumption. Cutting the clock frequency in half will basically reduce the current of the microcontroller in half (barring current draw for reference voltage generators and any GPIO drive for external circuitry). Further more, when the system becomes active, we can return the clock to its normal frequency and restore all the processing power normally available to the system.
Alright, that reduces the current while maintaining the operation of the processor to monitor the buttons. However, we will need to speed up the button scanning rate to maintain the same responsiveness of the buttons.
However, what if we put the processor to sleep? That produces a very dramatic reduction in current, but it also shuts down the processor so we won’t be able to pole the button inputs. True, but there is a way around the limitation, we can use the interrupt on change or IOC function typically built into one or more of the GPIO ports.
The IOC latches the state of the inputs every time the microcontroller reads the port. If the input state of the GPIO ever changes, the miss-match triggers an interrupt, which wakes the microcontroller. So, if we connect our buttons such that they pull one of the pins on the port with IOC either high or low, we can wake up every time the user presses a button. The only caveat is that we have to make sure the button is completely released before we go back to sleep, or any bounce will wake the microcontroller again.
OK, that works for up to 8 buttons, but what if we have a larger group of keys. The current crop of microcontrollers typically has only one 8 bit port with IOC so we can only do a wake on IOC on the 8 buttons tied to the IOC port.
Well, that’s not entirely true, there is a way to do a wake on more buttons, we just have to setup the buttons in a matrix. Yes, that’s right, a matrix. We connect either the rows or columns to the port with IOC, and drive the other with a separate port configured as outputs. Normally, we scan the matrix of buttons by pulling each output low, one at a time, and look for a corresponding low on the inputs. But if the microcontroller is asleep, there is nothing to pull each line low individually.
So, what we do is pull all of the outputs low, read the IOC port, and put the microcontroller to sleep. Now if any of the buttons are pressed, the attached low output pint will pull the corresponding input on the IOC port low, which wakes the microcontroller, which then scans the matrix normally, and identifies which button was actually pressed. After the button is released, and the appropriate action is taken, the microcontroller can be put back to sleep and the current goes back into the uA range once more.
OK, so we can wake on individual button presses, and we can wake if the buttons are arrayed in a matrix, but what about inputs whice are toggle or slide switches? They can remain closed for a very long time, and if we use a pull up resistor on the input pin of the GPIO port, that will burn current continuously.
Fortunately, there is another new feature, programmable Weak Pull Ups, or WPUs. The WPUs are basically pull up resistors that can be turned on and off under software control. Now if an input is low, we can turn off the WPU and save the current draw. Then periodically turn the WPU back on and check the actual state of the pin, before turning it back off. The only problem is that we can’t generate an IOC, so we will have to have a periodic wake up call from a timer or the watch dog timer so the microcontroller can poll the state of the pin.
So, there you have it, a means of exploiting the low current consumption of the sleep mode, without loosing the ability to quickly respond to a button press. All you need is the IOC function on a GPIO port and you can wakeup and read the state of the button, or wake up and scan a matrix of keys. Further, if we have more permanent low inputs, we can even turn on/off the WPUs on the inputs so we don’t burn excess current on a steady state input.