Add graphics without using a dedicated graphics controller

by Adam Folts , TechOnline India - November 17, 2011

The author describes the various means by which integrated peripherals on a microcontroller along with graphics libraries enable embedded designers to push down costs by driving an LCD display without a graphics controller.

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).

Graphics Basics

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. 

Controller Configurations

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.

Controllerless Configuration

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.

The system sets up the DMA controller to transfer one line of the frame-buffer data at a time through the PMP (each line consisting of many pixels). A PMP interrupt request is used to trigger the DMA to perform the next line transfer. In microcontrollers with non-persistent interrupts, a timer can be used as the DMA trigger source. During the DMA data transfer, the PMP strobes a read or write signal after each pixel transfer. 

The read/write strobes of the PMP peripheral act as the pixel clock for the display glass. At the end of transferring each line of the frame buffer, the DMA controller interrupts the CPU to update the required timing signals, such as HSYNC (horizontal sync), VSYNC (vertical sync), and DEN (data enable), which enable the LCD panel to know the proper frame position at all times (see Figure 6 below). This process is repeated continuously until an entire frame buffer has been transferred.


 

Figure 6 Timing signals enable the LCD panel to know the proper frame position at all times.

 

The HYSNC signal tells the LCD panel when the data is at the start or end of a line. The VSYNC signal tells the LCD panel when the data is at the start or end of a frame. TFT LCD panels need the DEN signal to enable it to set up the panel to properly place the pixel locations. The PCLK signal is the clock source for the whole system. One clock pulse from the PCLK updates the LCD panel, and all of the other clock signals need to be synchronized with the PCLK to enable the LCD panel to produce a proper image output.

There are many different types of LCD panels from which to choose. The controllerless graphics method outlined here was designed to work with TFT (Thin Film Transistor) LCD panels, but can also work with CSTN (Color Super-Twist Nematic) or MSTN (Monochrome Super Twisted Nematic) panels, with minor modifications. LCD panels that do not contain all of the highlighted signals, such as HSYNC and VSYNC, can still benefit from using a controllerless configuration.

The LCC (low-cost, controllerless) software driver from the microcontroller supplier should help with synchronizing timing parameters, such as pulse-width, front-porch, and back-porch, for both horizontal and vertical pulses. These timing constants can be found in the data sheet of the specific LCD Panel to be used. It is usually a value given in pixel clocks. These constants help set up the proper frequencies needed to produce an accurate image data on the display. 

The following code snippet from an LCC driver library illustrates the steps to set up a system that operates a controllerless graphics configuration.


//Suspend ALL DMA transfers
DMACONbits.SUSPEND =1;

#define PMP_CONTROL
(PMP_ON|PMP_MUX_OFF|PMP_READ_WRITE_EN|\PMP_CS2_EN|PMP_CS2_POL_LO|PMP_WRITE_POL_LO|PCLK_POLARITY)

#define PMP_MODE
(PMP_DATA_LENGTH|PMP_MODE_MASTER2|\PMP_WAIT_BEG_1|PMP_WAIT_MID_1|PMP_WAIT_END_1)

// Set up the PMP
// PMP is setup to use data and address lines, in 16 bit PMP mode
// PMP wait states are set to fastest
mPMPOpen(PMP_CONTROL, PMP_MODE, PMP_ADDRESS_LINES, PMP_INT_ON);

//Set PMP address to 0
PMADDR = 0x0000;

// Open the desired DMA channel
DmaChnOpen(1, 0, DMA_OPEN_DEFAULT);

// Set the transfer event control: what event is to start the DMA transfer
DmaChnSetEventControl(1, DMA_EV_START_IRQ(_TIMER_2_IRQ));

// Set the transfer parameters: source & destination address, source & destination size,number of bytes per event source is the PMP, destination is a dummy array, source size is
2 for 16-bit color, first destination size is the backporch, transfers per event is two.
DmaChnSetTxfer(1, (void*)&PMDIN ,&GraphicsFrame[0] , 2, HBackPorch, 2);

// Set INT controller priority to 7 for highest priority
INTSetVectorPriority(INT_VECTOR_DMA(1), INT_PRIORITY_LEVEL_7);

// Set INT controller sub-priority
INTSetVectorSubPriority(INT_VECTOR_DMA(1), INT_SUB_PRIORITY_LEVEL_3);

// Enable the transfer done interrupt, when all buffer transferred
DmaChnSetEvEnableFlags(1, DMA_EV_BLOCK_DONE);

// Enable the interrupt in the INT controller
INTEnable(INT_SOURCE_DMA(1), INT_ENABLED);

// Once configured, enable the DMA channel
DmaChnEnable(1);

// Turn on Timer2 to act as a "trigger" for the pixel clock (DMA transfer)
OpenTimer2(T2_ON | T2_SOURCE_INT | T2_PS_1_1, 10);

// Start ALL DMA transfers
DMACONbits.SUSPEND = 0;

Additional Considerations

Just because you can use a controllerless configuration to manage the graphics display does not mean it will always be the best idea. For example, a graphics controller may make more sense if your graphical interface needs the performance benefits of hardware acceleration, such as to implement alpha blending, transparency, or scrolling functions. 

Using larger display resolutions can push the processing requirements beyond the range that a controllerless implementation can support. Also, a deep color depth, such as using a 24-bit color depth, can exceed the performance that the controllerless method can deliver.

These considerations aside, using a controllerless approach usually provides cost benefits, but there are some trade-offs for those benefits. For example, there is some CPU overhead for managing the continuous LCD refresh. The Interrupt Service Routine (ISR) that updates the LCD timing constraints is the only part of the system that consumes CPU bandwidth because everything else is handled by the DMA transfer. 

The ISR executes during each of the two interrupts per line of the frame buffer. The CPU bandwidth consumed is typically less than 5 MIPS, based on the how the frame buffer is stored and the resolution and refresh rate of the display. For example, a WQVGA display refreshing at 60 Hz with 272 lines and two interrupts (80 clock cycles per call) per line uses roughly 2.6 MIPS (60 x 272 x 2 x 80).

Rendering changes to the pixels on the display is just as important as refreshing the display. The contents of the display are changed by the application code writing directly to the frame buffer. If the frame buffer is stored in external memory, the DMA transfer will be suspended while the CPU is updating the frame-buffer contents. This is necessary if the microcontroller has only one PMP peripheral because it is being shared with the DMA transfer that is acting as a virtual graphics controller. 

However, a developer must take care not to affect the refresh rate by updating too many pixels at a time; otherwise, the change will become perceptible to the human eye. One way to avoid this is for the application software to maintain and enforce a changed-pixel-count maximum within the virtual graphics controller that is cleared during every DMA interrupt.

Microcontroller companies may offer a demonstration or evaluation board to enable designers to explore how the controllerless configuration can meet their needs (see Figure 7 below). Any such evaluation board should specify for which types of displays it supports controllerless capabilities, such as for 9/12/18/24-bit TFT, 4/8-bit STN, and 4/8-bit CSTN LCD interfaces. It should also specify what memory resources it includes to ensure it can meet your sizing requirements for the frame buffer, especially if you need to use double or triple buffering.

Figure 7 Microchip’s Low-Cost Controllerless (LCC) Graphics PICtail Plus Daughter Board (part # AC164144) provides an evaluation platform for exploring a virtual graphics controller implementation with a 32-bit PIC32 microcontroller.

 

Along with the hardware in the evaluation kit, there should be support software, drivers, and/or demonstration software to assist in implementing the virtual graphics controller. The demonstration software may provide examples of using both internal and external memory access methods, so that you can evaluate the timing and processor loading differences. The support libraries should provide tools to assist in building a graphical user interface, such as automating the conversion of a screen layout to software assets and the code to access and manipulate them.

It is also useful to identify the update modes that the graphics library supports. For example, display assets may all be stored as bitmap pictures that are block transferred into the frame buffer as needed. Another way to support updates in the frame buffer is algorithmic or through the use of graphic widgets. Using bitmaps can be easier, but they can also use significant amounts of memory to store and recall the bitmaps. 

Depending on your situation, the extra memory may increase your bill-of-material costs. In contrast, graphic widgets support changing a single pixel, drawing a line, or the outline of a geometric shape. A system that relies on using graphic widgets trades off between consuming CPU runtime bandwidth and using less runtime memory. Which approach is best for you to use depends on your design’s specific details, and a mixed or hybrid approach may provide significant benefits.

Adding a simple graphical user interface does not necessarily mean you have to incur the extra cost of a graphics controller—whether it is a discrete component, or integrated within your LCD panel or microcontroller. Today’s contemporary microcontrollers, with the appropriate peripherals and available memory resources, can provide a virtual graphics controller that enables your design with the graphics capability you need without incurring the cost of a dedicated controller.

 

About the author:

Adam Folts is an applications engineer for the PIC32 Product Family at Microchip Technology. In his early years with Microchip, he was involved with PIC24 16-bit microcontrollers and several software solutions such as Graphics, MiWi, and USB. Now, Adam is primarily involved with PIC32 products and related technologies. Adam has experience ranging from software development, graphical embedded systems development, and wireless connectivity. Adam received his BSEE degree from Arizona State University.

About Author

Comments

blog comments powered by Disqus