Making Embedded Processing Development Easy - part 5 -

Making Embedded Processing Development Easy – part 5


Welcome to a six-part series on 'Making Embedded Processing Development Easy.' We’re on the fifth installment in a sequence created to introduce you to the fundamentals of embedded software design and considerations to aid with embedded processor design.  This series is derived from the expertise of embedded processor software experts from Texas Instruments and is meant to provide an objective view of easing software design.  

This week’s edition is brought to you by Nick Lethaby, a manager in TI’s Software Development Organization.

Q:  There seem to be increasing expectations for embedded devices to have state-of-the-art Human Machine Interfaces (HMIs).  How can embedded software offerings make this easier and which are the best options for my application?

A:  To develop an HMI, you’ll need at a minimum a basic graphics library and some fonts, but for any level of sophistication, you need to use a Graphical User Interface (GUI) framework. The good news is that there is a plethora of both open source and commercial GUI development solutions available for embedded developers. Many of these come with tools that enable “what you see is what you get” (WYSIWYG) prototyping of the HMI on a desktop machine before you download it to the embedded target. This greatly simplifies the development process as different HMI ‘looks and feels’ can be evaluated without spending time building and downloading to an embedded target. As a result, developing an HMI for an embedded application can be little different from developing one for a desktop application.

However, there is one important caveat. Graphics software has the potential to consume copious amounts of memory and processing resources. As a result, it is unwise to select a processor and a GUI framework independently of each other. In reality decisions about the GUI framework will drive the choice of hardware or vice versa. Therefore before attempting to select an embedded graphics software environment, you need to step back and consider four key questions:

  1. How critical is the HMI in differentiating your application?
  2. Will the embedded software team develop the HMI, or is it desired to use professional user interface (UI) designers?
  3. How much memory will the system have available?
  4. How much processing power will your application have available, and will there be any dedicated graphics accelerators in the systems?

If the answer to the first question is likely to be ‘absolutely vital,’ such as for a consumer electronics device like an iPhone, the hardware specification will need to meet the requirements of a sophisticated GUI framework. If other factors are more or equally important for the end product differentiation than the HMI, you’ll need to study the cost implications of supporting various graphics and display options and identify the appropriate combination that best fits your system cost, functionality and performance goals.

As an initial rule of thumb, any GUI framework that originates from the desktop or smartphone world will require at least a 300 MHz processor with a good external memory interface, since in most configurations they require at least a few megabtyes, if not tens of megabtyes, of RAM for execution. Most of these environments will have much better performance if you choose a significantly faster processor that has a dedicated graphics accelerator. Specialist embedded GUI frameworks, such as Prism from Bluewater Embedded can range in code size from 60-200 Kbytes and are a good option for applications looking to minimize memory cost. Basic graphics libraries, which support primitives such as lines and rectangles, require even less memory but are obviously not appropriate for developing more sophisticated HMIs.

A preference to use specialist UI designers rather than software developers to implement the HMI will also have a major impact on the graphics software environment. For example, a GUI framework such as Qt/Embedded requires the developer to write programs for implementation. An environment like Adobe Flash, which is widely used in the Internet space and well supported with tools familiar to specialist GUI designers, does not require software developers for the actual HMI implementation. With Flash running on your device, the UI can be created using the advanced tooling, eliminating the need to write programs.

It should be obvious from the above issues that MCUs with dedicated on-chip memory may be limited in their options for supporting a rich HMI. However higher-end processors will have a number of choices. If you want to make best leverage of professional UI designers, Adobe Flash is an excellent choice. If you will be developing the UI yourself, pure open source options include Android and the various Linux GUI frameworks and graphics software libraries. For developers who want a well-integrated and well- supported GUI framework, Android is an excellent choice because the GUI framework and tooling is pre-integrated and pre-tested as part of the OS.  

Android also has good touch screen support, which is a plus for many embedded applications. Linux offers numerous options, such as Qt, X-11, GTK, and DirectFB that enable more implementation choices and different levels of abstraction from the hardware. However, it should be stressed that the Linux kernel itself does not contain any of these, and getting Linux user space components to build and execute for an embedded processor, can be time-consuming for inexperienced developers.

In addition to open source software, there are several commercial embedded operating systems, such as Microsoft Windows Compact Embedded, Wind River VxWorks and QNX that have configurations including GUI frameworks.  There are also OS-independent GUI frameworks like Mentor Graphics Inflexion that can run on both open source and proprietary operating systems.

When selecting a GUI framework for a particular processor, it is important to understand what underlying acceleration, if any, is available and whether the graphics framework takes advantage of it. The default mode of most GUI frameworks is to use the CPU for processing.

Standard 2D graphics composition operations, such copying large windows to the frame buffer or blending (making one object transparent over another), can entirely consume CPU bandwidth if large display sizes or excessive blending is required. 3D graphics are generally not viable in real-time without a dedicated accelerator. Therefore while most GUI frameworks will work on any processor, they may not be very efficient. The choice of ‘efficient GUI frameworks’ for a particular processor will likely be more limited. Again Linux has a number of options, listed above, for graphics software development.  

The TI Linux SDK includes Qt/Embedded that is accelerated (on appropriate devices) by both an OpenGL ES graphics accelerator and a 2D acceleration library, making Qt/Embedded a very efficient Linux GUI framework for these TI devices. In addition, TI also separately provides an accelerated version of X-11 for developers who prefer that windowing system. A developer who prefers to use GTK would benefit from acceleration if they used GTK/X but not if they used gtkFB as DirectFB currently is not accelerated.

For most developers, the best approach is to determine which GUI frameworks have been accelerated for the chosen device and select from these. If there is a significant existing code base dependent on a particular GUI framework or graphics software package, then you can narrow your search by only considering devices that have accelerated ports of the GUI framework you need to use. Making the most prudent choice will free up your main CPU for the rest of the application.

Next week, for the final edition of “Making Embedded Processing Development Easy,” we’ll discuss enabling security with software.

Read other parts here: Making Embedded Processing Development Easy

About the author:
Nick Lethaby is a manager in Texas Instruments’s (TI) Software Development Organization working with Linux, Android and real-time operating system (RTOS) technology and providers. Previously, he worked for nine years as the product manager for TI’s DSP/BIOS RTOS and xDAIS/codec engine multimedia stack. Prior to joining TI, Nick spent 15 years working with embedded software companies in product marketing and applications roles. He received a bachelor of science in computer science from London University in Great Britain.

If you found this article to be of interest, visit the Micocontroller Designline where you will find links to relevant technical articles, blogs, new products and news.

You can also get a weekly newsletter highlighting the latest developments in this sector – just Click Here to request this newsletter using the Manage Newsletters tab – if you aren't already a member you'll be asked to register.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.