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.
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 has 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 constrains.
Teamwork and early prototyping
- The PC simulation mode also enables multiple 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 include the PC simulator tool free of extra charge
All GUI display driver library packages include ready-to-run PC-mode examples as fast Getting Started solution.
Use of IOTester
- Same development and debug advantages 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 include 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 running 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.
- Use of Virtual Fonts can be added late in the development process, without impact on existing application source codes.
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.