Accelerate your Embedded GUI development and test

This is a brief introduction to tools and design methods that can accelerate your GUI program development and test, which are supported by all the GUI display driver library products.

Background:
The GUI C source library modules are completely processor and platform independent. Only the I/O hardware operations really matter. This fact opens for use of a number of alternative methods to accelerate your Embedded GUI development.

Take advantage of PC mode development and test

Concept: Complete the logical and visual test of your "embedded" GUI application on the PC before first, before moving the (fully logical tested) GUI C source code to the target processor.

Both the display controller simulator included with all display driver libraries, and the IOTester tool, take advantage of this C source code portability to provide developers with a faster way to development AND test embedded GUI software, simply by make use of common efficient, and often free, PC program development tools.

Some advantages with PC mode development:

  • Simpler development system
  • Get faster turnaround times during test and debugging iterations.
  • Assure stable and repeatable GUI stimuli and data during test and debugging.
  • Open for easy use of input data which trigger border-line cases. Create more throughout tested source code.
  • The "embedded" application have free access to the PC file system during testing.
  • Easy to create and view runtime debug messages.
  • Easy to create runtime logging and to save the "GUI look" for documentation.
  • Reuse your PC programming and tool experience with common C/C++ PC programming to create Embedded GUI applications, for instance the Microsoft Visual C++ IDE.
  • Test your GUI look and design ideas without any target hardware constains.

Teamwork and early prototyping

  • The PC simulation mode also enable multible team members to work in parallel without competing about the embedded hardware development resources.
  • Take advantage of distributed development. Embedded GUI application development can easily be done at physical locations different from the hardware development.
  • Create distributable demos for GUI look and data presentation approval, early prototyping, or customer acceptance, long before the final hardware is ready.

More information about PC simulation here.

All GUI display driver library packages includes the PC simulator tool free of extra charge

All GUI display driver library packages includes ready-to-run PC-mode examples as fast Getting Started solution.

Use of IOTester

  • Same development and debug advandages as with the PC simulation.
  • Let your PC GUI program connect to the real display module hardware.
  • Optionally interface to other GUI related hardware like: touch screens, keyboard, and other simple I/O hardware
  • Test GUI "look and feel" experiences on the GUI related hardware before the target hardware selection and design.

More information about IOTester tool here.

The IOTester hardware tool is purchased separately.

All GUI display driver library packages includes ready-to-run IOTester examples as Getting Started examples.

Graphic and Fonts

The IconEdit tool can create fonts and graphic symbols as C source code for easy compile-in with an embedded application.

More information about IconEdit here

Handling of large fonts or large graphic symbols in a small embedded system

If the GUI design style you choose uses a lot of graphic images or large fonts, you may risk to run out of processor ROM memory in your embedded processor system.    A solution to this is use of the Virtual Font concept.

Goal with Virtual Fonts:

  • Place all memory consuming constant objects (here fonts and code-pages) outside the processor ROM.
  • Still access font data directly when needed for rendering, without RAM buffering requirements.
  • Easy to use. No special considerations required during GUI application programming
  • Maintain full source code portability to the target system
  • Still full testable in PC simulation mode.

Requirement for use of Virtual fonts:

Extra external memory for storage of constant data outside the processor chip.

If not already done then you may consider adding a storage device for constant data, for instance a small 8 pin serial flash chip, to your processor hardware design.

This simple design precaution may save a lot of development time in the long run. And it may increase market flexibility, for instance enable your application to add new fonts and support for new language areas in a dynamical way, without touching existing GUI application code.