Liquid crystal displays (LCDs) are becoming more immersed into everyday life, as evidenced by their pervasion of mobile phones and other modern electronics. LCDs are a simple way to improve the user experience in a product; an LCD drastically improves the customer interaction and ease of use. As a result, many ultra-low-power products are beginning to integrate LCDs for additional features and functionality. Low cost and low power solutions are crucial to these products. Using design techniques to optimize the system hardware and software, low-cost, ultra-low-power microcontrollers can be used to drive dot matrix LCD displays that previously required larger, power-hungry processors.
Segmented LCD displays have had their place in the market for quite some time in specialized niches. Old alarm clocks and digital watches featured the 7-segmented digits that provided the time in a simple and straightforward manner. These segmented displays have a few advantages over more complex dot matrix LCDs: they are cheaper, consume less power, and can interface with simpler microcontrollers. This remains true today, but the demand for an enriched user interface calls for products to start designing in more capable LCDs.
Graphical dot matrix LCD displays have revolutionized the user experience in modern products. Products with LCD screens give the user immediate feedback and provide a much better user experience compared to those without an LCD. A dot matrix display provides the user with improved aesthetic appeal compared to archaic segmented displays, and can simplify the system hardware as well. Just a few buttons can provide several functions as the LCD screen dynamically changes their functionality. Mobile phones for example, have evolved from having many buttons to just a few as more advanced LCD displays are used.
Figure 1: Segmented versus dot matrix LCD displays
A key feature of dot matrix LCDs is the use of a chip-on-glass solution. This type of LCD display module has a display and an integrated circuit (IC) called an LCD controller. The LCD controller translates incoming microcontroller data to signals required for the LCD display. Chip-on-glass solutions allow for any microcontroller with a standard data bus to communicate with the LCD. Because these LCD modules have an IC, power is always consumed when the LCD is on. However, many chip-on-glass LCDs have low-power modes implemented to cut down on the amount of power consumed. These chip-on-glass LCDs allow for a wider range of low-power applications due to their power footprint.
There are many ultra-low-power microcontrollers on the market, many with sleep modes that consume less than 1µW of power. These microcontrollers are becoming more advanced in terms of peripherals and CPU clock speeds. Built in hardware modules make certain interfaces such as the serial peripheral interface (SPI) communicate more efficiently because there is less software overhead. Parallel interfaces can also be leveraged for fast bit-banged operations with an LCD. For many LCD applications, a fast CPU clock speed is desirable to draw the large number of pixels required by a dot matrix display at a faster rate. For low-cost, low-power microcontrollers, special software techniques can be implemented to compensate the lack of CPU speed to retain the graphics performance while minimizing power consumption.
Figure 2: Hardware block diagram
In an LCD application, the software on the microcontroller can be divided into three main layers: the application layer, the graphics primitives layer, and the display driver layer. The graphics primitives layer draws simple elements onto the LCD such as pixels, lines, circles, rectangles, text, and images. The display driver layer is the hardware abstraction layer where the communication with the LCD actually takes place. With optimized software in these two layers the graphics performance will be better because pixels can be written to the LCD at a much faster rate. While updating a display, the microcontroller is consuming the most power because it is in active mode with the CPU running at a high speed. During this time it is crucial to cut out every unnecessary CPU cycle so that the microcontroller can return to sleep as fast as possible. Efficient software for updating the LCD is inherently a power saving solution and will also provide better graphics performance.
Figure 3: Software block diagram
When optimizing the LCD display driver layer, there are two main considerations, the software efficiency and the built in features of the LCD. The efficiency of the LCD display driver has a direct impact on the draw speeds of every graphics primitive. Eliminating even a single instruction can have a significant impact on drawing speed because the LCD driver layer functions are called for every pixel drawn. This layer will contain the function required to write data to the LCD, and this function must be optimized more heavily than any other because it is called for every single pixel written to the LCD display.
Most LCDs have built in features that can provide a significant boost in the efficiency of the LCD driver layer. These features provide functionality that would otherwise need to be written into the microcontroller software, causing additional overhead. Common LCD features include pixel auto-increment, pixel inversion, clear display, display orientation rotation and mirroring, and contrast and backlight controls. Many LCDs have the auto-increment functionality where the cursor position of the next pixel to be written is automatically incremented following a pixel write.
A simple example of drawing a horizontal line can be used to illustrate the effectiveness of taking advantage of the auto-increment feature. When drawing a horizontal line, the easiest way to think of implementing it is to sit in a loop and repeatedly draw a single pixel. A single pixel draw function requires the cursor coordinate location to be set and then the pixel data to be written. The following pseudo-code example shows this implementation on the top, along with an implementation that is optimized using the auto-increment functionality on the bottom.
Figure 4: Optimizing the LCD display driver
layer using built-in LCD features
For this example, it is assumed that SetCursorLocation() requires 40 clock cycles and WriteDataToLCD() requires 10 clock cycles.
Total clock cycles (un-optimized) = (x2 x1 + 1) * 50
Total clock cycles (optimized) = 40 + (x2 x1 + 1) * 10
Neglecting the small overhead of the initial SetCursorLocation(), the optimized version is five times as fast as its un-optimized counterpart! With this small and simple change, all horizontal lines now drawn at five times the speed. Although this is a simplified example, it illustrates realistic gains that can be made by taking advantage of the auto increment feature of the LCD controller. This feature should be used throughout the LCD display driver whenever possible.
The graphics primitives layer also needs to be optimized. This layer can be customized to a particular LCD, or this layer can be made generic to work across a broad range of applications. An LCD graphics library contains an efficient graphics primitives layer, requiring minimal effort in optimization for each new application. A graphics library can significantly cut down on development time because it can be used with any LCD paired with any microcontroller. This type of flexibility allows for a graphics library to simplify and accelerate development to create the user experience desired.
If creating a custom graphics primitives layer or just further optimizing an existing graphics library, there are many methods to improve software performance. Minimizing calculation is the primary goal of optimization, especially considering the limited hardware math capabilities of low-cost, low-power microcontrollers. Intrinsic functions of the microcontroller should be leveraged as well as any hardware math operations available. Utilizing look-up tables instead of performing calculations, replacing function calls with macros, and setting compiler optimization for speed are additional ways to optimize the software. These methods are a tradeoff of increasing code size for improved execution speed, and this can be balanced as necessary in any application.
When designing LCD applications it is often beneficial to maintain a frame buffer in RAM that contains the data of all pixels displayed on the current frame of the LCD. Keeping the frame buffer in RAM allows for fast data access. A frame buffer facilitates manipulation of the current pixel data without the added step of reading out data from the LCD. This is particularly useful when working with simple displays that require pixels to be represented by less than one data byte or any application that will be refreshing the screen often. The size of the required frame buffer can vary greatly and depends on the resolution of the screen as well as the color depth. The resolution of the screen determines how many pixels must be saved, while the color depth determines how many bits are required to represent each pixel.
With color displays and even high resolution monochrome displays the frame buffer can grow very large. In a low-power, low-cost application, the frame buffer may quickly outgrow the amount of RAM present in the microcontroller.
Ferroelectric random access memory (FRAM) eliminates the partition between RAM and flash on traditional microcontroller devices. FRAM provides unified memory with dynamic partitioning allowing for full customization of the memory to fit the requirements of any application. With FRAM the memory requirements can easily be met when implementing an LCD application that requires a significant amount of RAM due to a frame buffer or other elements. FRAM memory is non-volatile, images and other data can be stored without fear of loss during a power cycle or a battery replacement.
Texas Instruments' (TI) offers a vast portfolio of ultra-low-power microcontrollers, including its MSP430 microcontroller family with embedded FRAM devices with unified memory. TI also provides the MSP430 Graphics Library, an open source set of graphics primitives for creating graphical user interfaces on LCD displays. The MSP430 Graphics Library provides the flexibility to interface any dot matrix LCD to any MSP430 microcontroller. It is compatible with a wide variety of LCDs through customization of a low-level abstraction layer where up to 16-bit color is supported, as well as grayscale. Additionally, there is no inherent limit to resolution; an MSP430 microcontroller running the graphics library performs well on monochrome to QVGA LCDs. These aspects of the MSP430 microcontroller family offer a great fit for any ultra-low power LCD solution.About the author
Michael Stein is an embedded applications engineer focusing on TI's MSP430 MCU customer applications.
His responsibilities include designing and engineering system-level hardware and software using MSP430 MCUs, providing training and support to TI's customers and field teams as well as providing applications expertise during development of next generation MCU products such as silicon, tools, software and more.
Michael holds a Bachelor of Science and Master of Science in electrical engineering from the University of Colorado.
If you found this article to be interest, visit Microcontroller / MCU Designline
where in addition to my Max's Cool Beans
blogs on all sorts of "stuff" you will find the latest and greatest design, technology, product, and news articles with regard to all aspects of designing and using microcontrollers.
Also, you can obtain a highlights update delivered directly to your inbox by signing up for my weekly newsletter just Click Here
to request this newsletter using the Manage Newsletters tab (if you aren't already a member you'll be asked to register, but it's free and painless so don't let that stop you [grin]).
Last but certainly not least, make sure you check out all of the discussions and other information resources at All Programmable Planet
. For example, in addition to blogs by yours truly, microcontroller expert Duane Benson is learning how to use FPGAs to augment (sometimes replace) the MCUs in his robot (and other) projects.