Graphical displays give more flexibility in creating a user interface, compared to segmented or character displays. However, they can be more complex to operate and they do require more CPU time to update than their simpler counterparts. To create a useful GUI (Graphic User Interface) it is helpful to have a graphical library. A graphical library provides the software developer with functions to draw shapes, texts and images and take care of drawing operations like alpha blending and anti-aliasing.
When designing an application with a graphical display, there are some important display concepts, challenges, and requirements which need to be aware of.
Memory and Frame Buffer
The frame buffer is the memory location holding the pixel data which are currently displayed. The display controller needs to read this memory every update of the display. On displays without an internal frame buffer, the frame buffer has to be stored in RAM. It is then the MCU’s responsibility to update the display from this frame buffer.
If the display has a small enough resolution, the frame buffer can be stored in internal RAM. However, this can be impossible for larger displays. For example, a QVGA (320 x 240) display with 16-bits color depth requires 320 * 2 / 1024 = 150 KB of RAM for one frame. Take the case where an EFM32GGF1024 is used. This device has 128KB of internal RAM. In this case an external memory block is required to store the frame buffer.
To calculate the frame rate we need the pixel clock frequency, the size of the display (in pixels) and porch intervals. The size of the porch intervals in the equations below are given in pixel clock cycles.
Number of pixel cycles for 1 frame
NLINE = HBP + WIDTH + HFP
NFRAME = (VBP + HEIGHT + VFP) * NLINE
This equation gives the number of pixel clock cycles needed to update one full frame. To calculate the total frame rate we then need to know the pixel clock period.
Total frame rate (Frames Per Second)
FPS = FPXCLK / NFRAME
When both an external frame buffer (RAM) and display controller is connected to the EBI bus, bus access can become the bottleneck of the system. The pixel data first has to be written to RAM over EBI and then transferred from RAM to the display over the same bus.
In RGB mode it is possible to take advantage of the porch intervals to optimize this. During these intervals no pixel data is sent to the display, so this is a good time to write pixels to RAM.
Flickering and Tearing Effects
Flickering and tearing are visual artifacts that reduce the overall user impression of an application. When drawing a frame it is common to first fill the background with a color or image and then draw text, buttons or other user interface elements on top. If the drawing is done directly to the display, there will be a small time window where only the background is visible to the user. When the frame is redrawn several times per second it will look like the UI elements are blinking or flickering.
Tearing occurs if the display controller is in the middle of displaying a frame and then suddenly switches to the next frame. The top of the display will then show the old frame, while the bottom shows the new one. To the user it will appear to be visible lines across the screen between the two images.
Multiple buffering is a technique for avoiding flickering. When multiple buffering is used with, the MCU is drawing to one frame (the back buffer), while the display controller is showing the other (the front buffer).
There are two schemes: double or triple buffering. The advantage of triple buffering is that the CPU never has to wait for the display controller to finish. In the double buffering scheme, when the CPU has finished drawing a frame to the back buffer, it then has to wait for the display controller to switch buffers before it can start writing to the other buffer. In triple buffering, the CPU can just start drawing on next buffer and flag the finished buffer as pending.
Triple buffering example
Energy Micro provides the emWin Graphical Library from SEGGER through Simplicity Studio, for free. In addition to the standard drawing operation, this library also provides its own window manager, has support for touch inputs, cursors and skinnable widgets. It also has several PC tools available, including a bitmap converter and font converter. These tools produce C-files which can easily be compiled into your application.
Take a look at the video of the real product example using an autonomous low power direct drive TFT controller for the large color display, which features a smartphone-like interface with on-screen icons and ‘touch’ and ‘swipe’ functions.