As embedded applications continue to deliver ever more flexible and powerful user interfaces, the need to include a graphical interface in a design puts pressure on the designer trying to keep costs low. A typical system with a graphical display relies on an internal or external graphics controller to drive the display, but this can increase the complexity of the design and add cost. For a simple graphical interface, the extra cost for a graphics controller may not be justifiable. However, some microcontrollers include a mix of peripherals coupled with a specialized graphics library, which enables designers to incorporate simple graphical interfaces without incurring the cost of a dedicated graphics controller.
A low-cost, controllerless approach is to use a microcontroller’s peripherals and memory resources as a substitute for a graphics controller, thus creating a virtual graphics controller that can render graphics and continuously update an LCD display, while consuming approximately six percent of the total CPU bandwidth.
A microcontroller only needs Direct Memory Access (DMA) and Parallel Port Master (PMP) peripherals to create a virtual graphics controller. This approach is appropriate for use in cost-sensitive consumer applications such as thermostats, cordless phones, remote controls, coffee machines, washing machines, and ovens. It may also be appropriate for commercial and industrial applications such as ATMs, digital instrument gauges, storage controls, remote terminals, and movie-rental boxes. Medical applications that can benefit from a controllerless graphics display include glucometers, blood-pressure monitors, and portable Electrocardiograms (ECGs).
A pixel is a fundamental unit that denotes a single dot of color in the display area. The pixel color depth defines how many possible colors a pixel can be drawn, which has a direct impact on the amount of memory a system requires to represent and store each pixel of the display. Color depth is commonly represented as Bits-Per-Pixel (BPP).
A common color depth for LCD displays is 16 BPP, with the color data represented in a 565 RGB color format. The 565 RGB format specifies a pixel color as a 5-bit red value, a 6-bit green value, and a 5-bit blue value that together directly define the blended color. In contrast, a 24 BPP color depth represents the pixel color as three 8-bit bytes-each byte specifying the 8-bit value of the red, green, and blue components of the blended color.
The display resolution specifies the number of pixels contained within the display area, and it is defined by its horizontal and vertical pixel dimensions. There are a number of standard resolutions used for display resolutions. For example, a Quarter Video Graphics Array (QVGA) display is defined to be a rectangle of 320 by 240 pixels. A Wide QVGA (WQVGA) display is defined as a rectangle of 432 by 240 pixels, and it supports wide displays. Note that the resolution specifies the number of pixels, not the actual size dimensions of the display (see Figure 1 below). The resolution, combined with the dimensions of the display, affect the size of each individual pixel.
Figure 1 The display resolution specifies the dimension of the display in pixels, not the actual size of the display.
The frame buffer is a block of volatile memory where all of the pixel-color data for the display is stored. In addition to acting as the work area for changing the contents in the display area for the application code, the frame buffer is a necessary part of the refresh process for the LCD. The size and configuration of the frame buffer directly correlate with the display resolution and the pixel-color depth (see Table 1 below).
For example, a QVGA display with a 16 BPP color depth would require a frame buffer of at least 320 x 240 x 16 bits, or 153,600 bytes. In contrast, a WQVGA display with a 24 BPP color depth would require a frame buffer of at least 432 x 240 x 24 bits, or 311,040 bytes. The size of the frame buffer may contain more than the minimum number of bytes to support windowed scrolling functions, double or triple buffering, or to simplify drawing bitmaps of pixels near the display edges. Details about how the frame buffer is used to refresh the LCD are explained later in this article (details about implementing window scrolling, multiple buffers, and drawing bitmaps is beyond the scope of this article).
Table 1 The display resolution and the color depth, taken together, determine the amount of memory needed to contain the contents of the frame buffer.
The display refresh rate is defined in Hertz, and it is the rate at which the entire LCD panel frame is redrawn per second. The refresh rate affects not just how animations/updates on the display will appear to the user, but in a controllerless implementation, the refresh rate affects how much processing load on the microcontroller is necessary to keep the LCD refreshed.
The pixel clock (PCLK) signal enables the LCD panel to synchronize the sampling of incoming color data; the clock signal needs to be faster for higher refresh rates, as well as higher-resolution displays, so that all of the pixels in the frame can be properly clocked. The pixel throughput is the speed at which a pixel can be redrawn on the LCD screen. The time to draw an entire frame is the pixel throughput multiplied by the display resolution.
To better understand how to implement a virtual graphics controller, it is helpful to understand how graphics controllers are used with LCD panels. There are three basic configurations for using a dedicated graphics controller. A “smart glass” configuration consists of a LCD panel that has a graphics controller integrated within the panel (see Figure 2 below).
This configuration simplifies the integration effort for the designer because the frame buffer and graphics controller have already been matched to the display panel. The application software may make changes to the contents of the frame buffer through Application Programming Interface (API) calls that are based on the specific controller contained within the LCD module. If the designer needs to change the LCD panel, there may need to be changes made to the application code unless the new module supports the same controller APIs.
Figure 2 A smart-glass configuration integrates the frame buffer and graphics controller within the LCD module.
While a smart-glass configuration always includes an external graphics controller that has been integrated within the LCD module, a “dumb glass” configuration may be used with an external graphics controller located on the system board or with an internal controller that has been integrated into the microcontroller package. Using a dumb-glass configuration means that the system designer is responsible for the integration of the controller with the LCD screen.
Using an external controller is similar to the application software used with the controller that is integrated in the smart-glass configuration, in that the microcontroller communicates with the frame buffer and controller through a parallel interface and API calls (see Figure 3 below).
If the design needs to change the LCD panel or controller, the designer has the most control and flexibility in how to make the change with an external-controller configuration. On the other hand, using an external controller involves managing additional components on the system board, which all the other approaches avoid.
Figure 3 An external controller affords the most flexibility, but it requires an additional component for the controller.
Using an internal-controller configuration, the graphics controller and possibly the frame buffer are integrated within the microcontroller (Figure 4 below). The frame buffer may or may not be able to reside entirely within the on-chip memory resources, depending on the display resolution and color depth chosen by the designer.
If the on-chip resources are insufficient to contain the entire frame buffer, the designer may be able to use external memory, such as an SRAM module, to hold the frame buffer. An advantage of using an internal controller is that the interface between the microcontroller and graphics controller has been taken care of by the microcontroller supplier.
Another advantage is that swapping out the LCD panel does not mean the controller has to be changed, so the application software may not need significant updates to reflect a different LCD panel. On the other hand, the flexibility of selecting which graphics controller a design can use is limited to the choice made by the microcontroller supplier.
Figure 4 An internal controller simplifies the board design by hosting the frame buffer and graphics controller within the microcontroller package.
Adopting a controllerless configuration means a designer can keep using the same microcontroller they’re already using for the system, and may be able to add graphics to the design without additional components or having to use a different microcontroller.
In general, a system using a controllerless configuration needs to send a frame of pixel information to a “dumb” LCD display panel at the refresh rate of the display-typically around 60 Hz. To accomplish this, the system must continuously send frame data to the LCD panel. This could consume too much of the CPU processing bandwidth, and in that case using one of the three other configurations that rely on a dedicated graphics controller would be preferable.
However, a microcontroller that includes a DMA controller and a PMP peripheral can transfer the necessary pixel data to the LCD panel without consuming significant portions of the microcontroller’s CPU bandwidth (see Figure 5 below). The DMA controller can manage the transfer of the frame buffer’s contents to the LCD panel without requiring constant intervention from the CPU. Depending on the size of the frame buffer, it can reside completely within the microcontroller’s on-chip memory, or the frame buffer could reside within an external SRAM chip.
Figure 5 A controllerless configuration simplifies the board design by hosting the frame buffer and graphics controller within the microcontroller package.