All Classes Functions Variables Typedefs Enumerations Enumerator Pages


Within these pages you will find the complete documentation of the TouchGFX graphics framework. Aside from a brief introduction it contains a Getting Started guide, and a User's Manual covering the various aspects of TouchGFX.

Included is also the API documentation as well as a chapter describing the Examples distributed with the framework.

What is TouchGFX?

TouchGFX is a framework written in C++ that enables you to create modern graphical user interfaces on embedded systems with limited resources. That means a smartphone-like look and feel on hardware an order of magnitude less powerful than smartphones.

TouchGFX was designed to be user-friendly for application programmers

  • object-oriented extendable API
  • automated build chain for generating assets like bitmaps and fonts
  • PC simulator for prototyping and ease of debugging
  • built-in (but optional) scheme for efficient memory allocation
  • standardized structure for interfacing the GUI with the rest of the system.

At the same time, TouchGFX contains cutting-edge invalidation routines, that rival those found in the smartphone segment, but are specialized for modest hardware.

  • occlusion culling
  • rendering algoritms
  • drawing mechanisms

To that end, TouchGFX is unique in its ability to provide the user interface experience people have come to expect today, in applications that for reasons of unit cost, power consumption or otherwise cannot use the hardware platforms normally associated with that type of UI.

Background and Philosophy

The development of TouchGFX started in 2009 where we found that existing solutions were either not suitable for the types of hardware we are concerned with, or took an approach to user interface design and implementation we felt were not quite up to date. While solutions like Qt or Android are certainly capable of delivering great-looking UIs, they simply cannot run on cost-efficient, low-power hardware. Other alternatives are comparable to TouchGFX in resource requirements but with concepts like resizable and minimizable windows, focus, cursors and standard look and feel widgets seem more targeted towards creating interfaces reminiscent of desktop PCs rather than smartphones.

A key design decision of TouchGFX is to prefer prerasterized (bitmap) graphics as opposed to arithmetical (vector) graphics. Apart from text rendering, almost everything is done with bitmaps. This present the drawback of not easily supporting rotations and zoom/scaling. It does, however, mean we can use the DMA extensively when rendering, thereby significantly reducing the MCU load. We can also heavily optimize occlusion culling by using offline-generated data from the bitmap conversion tool. In essence, this is what enables TouchGFX to run well on the target platform range. We have also found that the missing support for scaling and rotating does not mean much in practice, as it is rarely needed on smaller touch screen interfaces anyway.

Another important design decision was to not include standard look and feel widgets. That means there is no built-in definition of how e.g. a button should look like. The graphics associated with the button must be supplied as part of the application. This is because we found that our clients are not interested in a standard appearance anyway. The application should have a unique look and feel, tailored to the specific application and the client's brand and style guides. By taking this approach we can reduce the footprint and better tailor the framework to be customizable to a very high degree.

Last, but not least, the framework was designed with extreme focus on memory usage and MCU load. Very rarely does an application consist of just a user interface, so there must be plenty of resources available for the system to do "real work" as well. The footprint of TouchGFX is very low and it is capable of rendering even very complex full-screen transition effects with an MCU load typically less than 10%.

Target Platforms and Resource Requirements

TouchGFX is able to run on a multitude of hardware platforms. A natural fit is any Cortex-M based platform, with the exact parameters of course depending on display resolution, memory latency and bandwidth, etc. Example platforms are:

  • Cortex-M3 MCUs at 48-64MHz for 320x240 QVGA displays
  • Cortex-M3/M4 MCUs at 96-120MHz for 480x272 WQVGA displays

TouchGFX can run on systems where the TFT controller is integrated in the MCU with frame buffers in external memory, or on systems that use an LCD with integrated frame buffer + controller. In some cases a Cortex-M0 based solution could also be sufficient.

The resource requirements of TouchGFX depends, of course, on the size and complexity of the concrete application. Below are figures for the usage of the framework itself as well as typical requirements for concrete UI implementations. The lower bound represent user interfaces like the simple examples included in the framework distribution. The higher bound represent very complex applications with ~200 different screens.

  • Internal RAM:
    • 10-20 KB (framework+stack)
    • 1-15 KB (widgets)
  • Internal ROM:
    • 20 KB (framework)
    • 1-40 KB (screen definitions, UI logic)
  • External RAM
    • 1, 2 or 3 frame buffers in external RAM or integrated on display
  • External Flash
    • 1-8 MB for graphics data, fonts, text strings/translations.
  • Operating System
    • OS independent. Can run with or without OS.
    • With an OS (recommended), it requires a single task and two semaphores.

The framework comes with builtin support for two evaluation boards:

  • EnergyMicro EFM32GG-DK3750 (Cortex-M3 / 320x240 TFT)
  • EmbeddedArtists NXP LPC4357 Developer's Kit (Cortex-M4F / 480x272 TFT)

For using TouchGFX on your custom hardware, expect a small porting effort to tailor the HAL specific code optimally for your platform.