Driving a TFT display with a Microcontroller: Is it possible?


tft display module driven by a MCUUpgrading the user interface of a small, microcontroller-based device can be achieved cost-effectively using skilful management of hardware resources, and careful attention to software design.

Designers of small devices such as remote controls, meters, wearables, and appliance displays are under pressure to keep costs down while setting the bar higher in terms of performance and features. Colourful, fast-moving graphics could help upgrade the user experience, but the options could be limited if the system is hosted on a low-cost or low-power microcontroller (MCU).

Understanding the interactions between the MCU and TFT-LCD can help engineers achieve an optimal trade-off between factors such as MCU power and performance, screen resolution and size, refresh rate, colour depth, and BOM cost. What we'll discuss in our whitepaper:

Hardware considerations
The display interface
Buffer size and frame rate
Designers choices
Software design support
Conclusion

Hardware Considerations

While displaying information on a dot-matrix or segment display is relatively straightforward, a TFT-LCD requires more intensive commands and pixel data, to display images accurately and in the correct position. The sharper, more dynamic, and more vibrant the desired user interface, the greater the demands placed on the display interface, system memory, and microcontroller CPU.

The Display Interface

Typical TFT-LCD interfaces tend to range from a simple I2C, SPI, or 8080 interface that are natively supported or can be easily implemented on many types of MCUs. To connect with these types of interfaces, the display integrates suitable controller and driver chips. Higher-resolution, or larger, displays may have an RGB interface, or a more sophisticated parallel LVDS or serial MIPI-DSI interface. Although some high-end MCUs now provide a DSI port, expressly to satisfy demands for more sophisticated displays with MCU-based products, RGB displays are typically the largest and most sophisticated units suitable for use with a MCU.

Buffer Size and Frame Rate

In addition, the display resolution and colour gamut influence the number of pixels per frame and the number of bits per pixel, which must be considered in relation to the MCU’s on-chip RAM available for frame buffering and the maximum possible frame-refresh rate.

Managing a frame buffer can be unfamiliar territory for developers familiar with basic dot-matrix or segment displays, which usually only require a few bytes of data to run the display. Depending on the required colour depth, a frame buffer of a few hundred kilobytes, or more for a high-resolution display, will be needed. This could exceed the on-chip RAM density of some MCUs. Another factor to consider is that even more RAM may be needed – depending on the frame size in relation to interface speed - to prevent unwanted visible effects such as tearing. This can occur if new data starts writing to the frame buffer before the current data has been fully read out. 

  Screen Resolution   Number of Pixels   Frame Buffer Size
  8bpp   16bpp   24bpp   32bpp
  QVGA (320 x 240)   76800   75   150   225   300
  Custom (480 x 272)   130560   128   255   383   510
  HGVA (480 x 320)   153600   150   300   450   600
  VGA (640 x 480)   307200   300   600   900   1200
  WVGA (800 x 480)   384000   375   750   1125   1500
  SVGA (800 x 600)   480000   469   938   1407   1875
  XGA (1024 x 768)   786432   768   1536   2304   3072
  HD (1280 x 720)   921600   900   1800   2700   3600
Table 1. Frame buffer sizes for TFT displays.

Table 1 shows the frame buffer sizes for common TFT displays, in relation to resolution and colour depth. If the MCU has insufficient on-chip RAM then an external RAM would be required, which increases both complexity and BOM cost. The MCU may also need to provide a high-speed interface and controller for the off-chip memory.

Of course, the number of bits per frame includes not only the bits per pixel data but additional bits associated with horizontal and vertical syncs and front-porch/back-porch. These need to be considered in relation to the available frame-buffer RAM and the frame-refresh rate. A high frame rate is desirable, to ensure smooth, fluid animation, but may be limited by the speed of the MCU and the type of interface.

Designers’ Choices

Overall, the desire to add a large, high-resolution display, with rich colours and smooth, responsive animations, on a low-cost, low-power MCU-based embedded system, is tempered by typical MCU limitations on the type of interface that can be supported, the maximum bus speed, and the available frame-buffer RAM.

Typical MCU-to-display interfaces are I2C/SPI, 8080, or RGB, and only a small number of high-end MCUs can support LVDS or MIPI-DSI interfaces. This can restrict the choice of displays that are suitable for direct connection to a MCU, and may preclude the use of more sophisticated, high-resolution units.

Limited on-chip RAM can restrict the maximum frame size and hence place a limit on display resolution and colour depth.

The microcontroller CPU frequency and I/O clock speeds can restrict the interface bandwidth and hence the frame rate, depending on the number of bits per frame.

By understanding the nature of these limitations, the MCU’s capabilities can be assessed to make an informed decision about the type of display to select and the graphical design including colours and animations. The resolution, frame rate, and colour depth can all be optimised to achieve a solution that satisfies the priorities of the application: if the product-marketing strategy calls for a particularly colourful user interface, or exciting animations, the colour depth and frame rate could be boosted if a smaller display or lower resolution are acceptable. If the colour depth could be reduced without adversely affecting the user experience, a higher-resolution display could be chosen.

If the MCU simply cannot deliver the visual performance required, with the chosen display, several other options could be considered. Upgrading to a higher-specification MCU could give access to larger RAM or allow higher bus speeds. Choosing a MCU with a LVDS or DSI interface can broaden the choice to more sophisticated high-end TFT-LCDs.

If upgrading the MCU is not an option, a bridge chip may be inserted between the MCU and the display (figure 1) to translate data from the serial I2C/SPI bus into RGB signals. The bridge chip also integrates frame-buffer RAM, thereby relieving demands on the MCU bus speed and on-chip RAM to give extra freedom to select the display resolution, colour depth and frame rate.

  Figure 1. An external IC can assist a low-cost MCU to control a higher-resolution display.

Alternatively, a more sophisticated graphics controller chip provides most of the capabilities of a dedicated GPU in a single external device that can communicate with the MCU via I2C/SPI and connect to almost any type of display including those with LVDS or MIPI-DSI inputs thereby allowing the widest possible choice of displays.

Taking one step further, if space limitations prevent the use of an external bridge IC or graphics controller, or if an existing board is to be used without redesign, a smart display can be considered. These connect to the MCU via a simple serial interface, and contain a programmable display processor and driver electronics for high-resolution TFT-LCDs. A proprietary development environment is usually provided, to help configure and fine-tune the GUI.

If none of these options can allow the required display to be used, the time could be right to upgrade to a microprocessor-based (MPU) design. Bringing up an MPU-based system is considerably more complex than designing with MCUs. Turnkey hardware such as a Core Module, Single-Board Computer (SBC), or complete HMI solution help overcome these challenges by integrating the complete subsystem including DDR memory and high-end industry-standard display interfaces.

Figure 2: Upgrade your MCU with an MPU/SBC solution

Software-Design Support

Whatever the choice of display, coding a good-looking user interface in C or other low-level language is very difficult. Choosing an MCU that comes with an effective ecosystem for GUI design can be important to make the most of the carefully selected display. Within such an ecosystem, a design environment that lets users define their UI graphically by dragging and dropping features from a palette, and selecting size/shape, position and colour, can simplify the designer’s task and automatically generate code with an efficient memory footprint. Complementing the IDE, extensive graphical libraries can simplify design and layout, and accelerate code generation. 

One disadvantage of this approach is that the ecosystem is often proprietary. Even where the IDE and some software may be provided by third-party partners, the resources are typically closely linked to the selected MCU family and vendor. This could compromise flexibility in the future, if a suitable device for the following generation of products cannot be found in the same MCU family. Similarly, an all-in-one HMI solution may enjoy the support of a high-quality proprietary design environment and software libraries, with the same potential restriction of freedom for future product generations.

Developing software for an MPU-based system is less constrained by proprietary hardware limitations. Graphical software stacks provided by popular operating systems such as Windows Embedded or Linux distributions are inherently portable, and developers are also at liberty to take advantage of cross-platform graphical libraries such as Qt.

Finally, it is worth considering options for adding touch functionality to the GUI. Touch controllers are commonly integrated in a wide variety of MCUs, from high-end to entry- and mid-level devices. Moreover, developing touch drivers is a well-trodden path; although not difficult, project planning should take into consideration the time for development and debugging. Of course, an MPU-based platform running an operating system can take advantage of the plentiful touch drivers that are already developed and debugged, for example by the open-source Linux community.

Conclusion

A clear, sharp, colour graphical display can bring extra market appeal to small devices. Smooth and polished animations can add even more to the user experience, but a simple host MCU could struggle to handle a high-speed, high-resolution colour TFT-LCD. Understanding how to balance aspects like display resolution, colour depth, and frame rate with the MCU’s performance and on-chip resources is vital to make the best engineering judgements. The major options are to design the GUI within the capabilities of the chosen MCU, add an external bridge or graphics-controller IC, consider a higher-performing MCU, or take the plunge and adopt a ready-to-use HMI or microprocessor-based host system.

If you would like to dicuss your project with one of our skilled engineers, please contact us today.

 

Want to know more?
Download your free Ebook: Giving Small Devices A Bigger Visual Impact

Occasionally we'd like to send you technology and product updates relevant to you. Submitting your details tells us you're OK with this and you agree to our privacy and cookie policy. You can opt out at any time by clicking on the link in the emails we send you.

Want to know more?<br>Download your free Ebook: Giving Small Devices A Bigger Visual Impact



Latest From The Knowledge Centre

Understanding Display Technology: Colour

How Anders are continuing to display evolution

Understanding Display Technology: Monochrome

Challenges with integrating a PCAP touch screen

Driving a TFT display with a Microcontroller: Is it possible?

TFT-LCD and OLED Displays: a Colour vs Colour guide

Mono or Colour – making the right choice

Walking you through designing a custom display solution

Custom or Customised Display - what is the difference?

Please call us +44 (0)207 388 7171