Add graphics without employing dedicated graphics controller(5)

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 60Hz 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. Any such evaluation board should specify for which types of displays it supports controllerless capabilities, such as for 9/12/18/24bit TFT, 4/8bit STN, and 4/8bit 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.

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 16bit 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.

To download the PDF version of this article, click here.