|
Article ghostwritten for Wind River Systems. GUIs for embedded applicationsEmbedded
computers (ECs) are showing up everywhere: medical equipment and machines,
test instruments, office equipment, industrial process controls, PDAs,
vehicle navigation and monitoring devices, set-top boxes, and home
appliances. These embedded
software-based devices are becoming ubiquitous across vertical markets.
However, despite the vertical market, graphical user interfaces (GUIs), once
the domain of PC users only, are increasingly in demand for these smart
devices. The
movement towards greater use of GUIs in embedded devices is based in part on
user demand that these applications provide intuitive interfaces that make
every feature easy to use. This
must be combined with a zero learning curve for people with no prior
experience with the device. In addition, the phenomenal increase in
net-centric computing has made it possible, and therefore an end-user
expectation, to remotely access any kind of information.
New features and services can be added to an embedded device simply
by downloading data over an information network, but GUIs must make this
process painless for the user. To accomplish this, embedded GUIs have
special requirements. Embedded vs. DesktopUnlike
desktop computers, embedded devices are designed for specific and
narrowly-defined purposes. They are also made of completely custom hardware
and software integrations. Manufacturers of ECs select the microprocessor, peripherals,
memory, and supporting hardware that best serve the requirements of their
product. Then, they choose the appropriate system software, including
graphics toolkits for generating a device’s UI.
There can be no mass standardization because each EC is created to
perform a unique function. Thus,
the one-size-fits-all desktop GUIs that serve all users equally well (in
theory, at least) cannot satisfy the extremely diverse graphics requirements
of embedded and net-centric applications.
Any graphics solution for embedded applications must allow developers
to design custom GUIs for any number of particular devices. Another
distinguishing factor between desktop GUIs and embedded GUIs is the
difference in the end user learning curve required for each.
A desktop GUI such as Windows has pull-down menus that in turn may
have sub-menu. But, at first glance, the meaning of the items on these menus
may not be immediately apparent. A
user who had never seen a PC desktop previously would have to go through a
complex learning process before he or she was able to use the desktop
efficiently. For
most embedded applications, however, the developer cannot assume the user
has any existing knowledge of or time to learn the user interface.
GUIs need to provide an interface that is so intuitive that a user
with no prior experience with the device can leverage its capabilities
immediately, with virtually no learning curve.
Technical IssuesThere
are other critical requirements to consider before undertaking the design of
a graphics solution for an embedded application.
If the right design parameters are included from the outset, a
successful product can be assured and costly modifications late in the
design process can be avoided. Embedded
environments involve custom hardware, so one of the most important
requirements in embedded GUI design is that any GUI solution needs to be
easily adaptable to non-standard hardware.
This is important because succeeding generations of a device might
have processors, graphics controllers, or board layouts that differ from the
original. To make sure the GUI can be ported easily to the new
architecture, software architecture should allow developers to write a new
graphics driver for the GUI without impacting the rest of the software. While
the technology used to build a GUI is very important, it is ineffective
without a graphics layer that glues a GUI's components to its hardware
controller. This requires a 2-D stack for hardware abstraction that allows
quick implementation of support for custom configurations or new graphics
hardware. The
2-D stack needs to provide the flexibility for a variety of optimization
(acceleration) requirements. In
order to incorporate the different acceleration features of a graphics chip,
developers need to be able to optimize driver software one step at a time in
a logical and efficient manner. One
tool that addresses this need is Wind River's Universal Graphics Library™ (UGL),
a 2-D graphics stack for hardware abstractions that provides open application
programming interfaces (APIs) for chip, input, and frame buffer
specifics. Typically,
writing a driver for a graphics controller requires a great deal of
customization before it can provide the best performance for a particular
application because different applications might have very different
optimization requirements. For example, one application might heavily rely
on drawing clipped rectangles whereas a different application needs to draw
many ellipses. The large number of specialized graphics chips and the many
different possible variations and optimizations for a driver make it
unlikely that a given driver will be available as an off-the-shelf product.
The designer should plan to create a customized driver for each
project. This will require
appropriate tool support and should be a consideration when choosing
graphics libraries for embedded applications.
Obviously,
a GUI needs to be able to communicate with its underlying application, but
in embedded devices the communications link must also shield the application
so that the GUI won’t interfere with real-time performance.
For example, the interactive GUI on a TV set-top box must be able to
order programming from a remote source without disrupting the TV signal. To
create GUI applications for use across a range of processors and
applications, graphics products must be based on cross-platform standards
and should be portable between different operating systems.
A manufacturer may use a GUI based on a C++ GUI library in an
embedded application. He or she might also want to use the same interface,
or components of it, in a non-embedded product using a different OS.
Designers will not want to write the same UI twice for two different
operating systems. Take
future uses into account Another
primary consideration is scalability, since one of the most challenging
elements in embedded design is extremely limited memory.
If there are portions of the software stack that are not required in
the context of a specific application, the device designer should be able to
scale those portions out of the stack to minimize the amount of RAM or ROM
needed. Conservation
of resources is equally important. Desktop
technologies are too resource-hungry to import into embedded applications.
They require too much processing power as well as having large RAM and ROM
requirements. Developers need
to use a suite of tools – such as Zinc™ – for the embedded environment
that deals very carefully with system resources.
Internationalization
is particularly important for GUIs. Often
an embedded device is sold overseas as well as in the U.S.
A graphics solution must be easily adaptable to display dates, time,
measurements, currency, and language in forms appropriate for the country
where the device will be marketed. The
localization must be handled independently of the core application, however.
Most of the software will be the same no matter where the device is
used, so it is not logical to have a separate version of the entire software
package for each country where the device will be marketed.
The software that will stay the same will be the core application.
For localization a separate software module should be provided that can be
called from the core application. Localization
for Asian countries presents a special problem. A normal 8-bit representation can handle 256 characters,
which is enough for the Latin alphabet, but Asian languages have a very
different constitution, where characters cannot be represented with an 8-bit
value. A 16-bit value will reference about 65,000 characters, which is
enough for all characters used throughout the world. A software stack needs
to be able to deal with this different representation of characters. Choose
the right language
Before
choosing a language to implement a GUI, it is important to analyze the
specific requirements for the application. The principal choices are between
Java and C++. Although the two
languages share certain attributes, they differ in significant ways that
make one or the other more suitable for a given application, depending on
the performance you need and the jobs the device must do. C++
GUI libraries are an extension of the classic embedded-systems programming
approach, with system libraries compiled for a specific target processor and
linked with the real-time operating system.
This provides the highest performance and maximum scalability with a
minimal memory footprint. The Zinc API is completely portable, allowing
applications to be reused on a wide range of applications.
As a result, user interface developers can build and test a GUI on
their preferred development platforms and later deploy it on the VxWorks® real
time operating system (RTOS). The
Java™ programming language, especially the PersonalJava™ technology,
offers standards-based API portability and efficiency for embedded
applications with an economical memory footprint.
And because of its modular, object-oriented approach, Java is
well-suited for writing GUIs. Because of Java's widespread use and its
standardized APIs, there is a wide range of excellent commercial development
tools available to help developers create user interfaces.
However, Java is slower than C++ due to its interpretative execution,
so if performance is the ultimate criterion for an application, Java might
not be the best approach. Also, Java requires more memory than C++.
If a minimum memory footprint of two Mbytes or less is critical
application, Java is not the best option.
The memory footprint for Zinc is less than one Mbyte, for Java it is
two Mbytes plus. If
an embedded design requires the ability to download additional applications
or upgrade a GUI once the device is in the field, Java is the best approach
because it allows dynamic download so additional applications can be
downloaded and existing applications can be upgraded.
There are also an increasing numbers of home appliances that offer
services and/or upgrades via the Internet.
In the C++ approach everything is burned into ROM or built into the
device, so it is suitable only for devices where upgrades and downloads are
not required. Another
consideration is available programming expertise.
Building GUIs is still fairly new to many embedded developers.
There are plenty of people with C++ experience, but the API for
embedded applications is relatively new one, so the learning curve may be
significant when a developer new to embedded tries to get a product to
market fast. People with Java
development experience may be more available.
However, the requirements of the application must be the
developer’s first consideration. Wind
River addresses all of the requirements listed above with two products:
Personal Jworks™ for developing GUIs in Java, and Zinc for GUIs
implemented in C++. Both
products include Wind River’s Universal Graphics Library, a 2-D stack for
hardware abstraction that allows developers to optimize driver software one
step at a time, as described above. ###
Back to Word Sculptors main page
|