Printer Friendly

Automotive electronics: building automotive GUIs "in a Flash".

According to Adobe Systems, more than 300 million mobile devices have graphical user interfaces (GUIs) based on Adobe Flash technology--a number that may exceed a billion by 2010. Developers of in-car navigation and infotainment systems are also beginning to embrace Flash, for a simple reason: it can reduce the time to build a GUI by up to 50 percent. In the past, software teams had to translate their GUI prototypes into C, C++, or Java code, a labor-intensive process that can take many months. Now, teams can prototype their GUIs with high-level Flash tools and run those GUIs directly on embedded Flash players, without having to write graphics code.

Flash is gaining momentum in the automotive embedded market for several reasons:

* A million graphics designers worldwide use Flash authoring tools, providing automotive teams with an immense pool of expertise to draw upon.

* Compared to desktop Flash players, new embedded Flash players (for example, Flash Lite 3) use less memory and provide faster rendering with less CPU overhead.

* Automotive-grade CPUs and graphics chips now support the frame rates needed for a pleasing Flash experience on VGA and larger displays.

Flash provides a domain-specific environment for graphics and multimedia that offers almost endless possibilities for building user experiences. As a result, automotive developers can quickly implement animations and special effects. Also, Adobe certification of Flash players ensures that Flash-based applications look and work the same across hardware platforms, allowing developers to create GUI components once and then deploy them across a family of products.


Nonetheless, to satisfy the requirements of automotive developers, an implementation of Flash must address several issues, including:

* How do you combine Flash content with other graphics programs, such as web browsers and 3D navigation applications?

* How do you make the Flash-based user interface perform consistently under all CPU load conditions?

* How can you keep the Flash-based user interface reliable? Can you monitor for failures and gracefully recover from them?

* How do you control how the Flash content interacts with operating system services, such as multimedia and video playback?

Integrating Flash with non-Flash Graphical Applications

Traditionally, a Flash player runs within a web browser or is launched from a windowing system. However, GUI development can be greatly simplified by turning this model on its head and making Flash the main environment that launches all other graphical applications, including web browsers, 3D navigation programs, and even other Flash applications. Flash excels as a screen manager, allowing the graphics designer to intimately control menu transitions and audio effects; it also simplifies customization by allowing designers and developers to freely position, resize, and configure graphical components.


Figure 1 shows an example of using Flash as a screen manager. The program on the left draws 3D maps in OpenGL ES, a standards-based 3D API for embedded systems. The program has loaded three components directly into its application space: a 2D graphics library, the OpenGL ES 3D library, and a graphics driver that controls the graphics hardware. Loading the driver in this way allows the program to control the graphics chip directly and thereby increase performance. The program on the right is a Flash player. Like the OpenGL ES program, it also directly controls the graphics hardware, ensuring high performance.

Many graphics chips for automotive systems now support multi-layering. Developers can take advantage of this feature to seamlessly blend Flash and non-Flash programs on the same display. In Figure 1, the Flash player draws on a foreground layer and controls the drawing of the 3D map on a background layer. To make the 3D map visible, the developer used a chroma key technique on the foreground layer. Since the 3D rendering and the Flash rendering take place on independent layers, the graphics controller can refresh the moving 3D map without having to redraw the Flash content--this eliminates flicker and reduces the load on the CPU.

Ensuring Predictable Response Times and Managing Failure Conditions

An automotive GUI should always respond promptly to user commands, even when the system is running a variety of CPU-intensive tasks, including multiple graphics programs. One solution is to create a central display manager that uses thread priorities to determine when each graphics program gets control of the CPU.

In this approach, a program (for instance, a DVD player) that wants to join the graphics environment sends a request to the display manager. The manager responds with a yes or a no, depending on whether the program has sufficient permissions to join. Upon joining, the program gains access to a mutual exclusion lock (mutex). When the program wants to draw something to the screen, it will wait on the mutex, acquire it, draw directly to the graphics chip, and then release the mutex. Every graphical program competes for this mutex based on its individual priority. Because the highest-priority graphics program will always acquire the mutex first, this approach ensures a level of realtime performance and a consistently fast user experience.

To prevent system downtime, many embedded systems require some level of dynamic fault recovery. Using fault-notification mechanisms provided by the underlying operating system, the display manager described above can learn about graphical applications that fail. If a Flash-based or other graphical program fails while holding the mutex, the display manager can release the mutex and give it to the next program in the priority queue. The manager can also recover any resources that the failed program was using and restart the program.

Interacting with Flash

To integrate Flash successfully, embedded developers need to manage two types of interactions:

1. Using Flash content to launch and control other Flash content

2. Enabling communication between Flash content and OS services

Figure 2 provides an example of how to implement these interactions. An HMI engine allows master Flash applications to manage secondary Flash applications (such as media player, picture viewer), while an HMI server provides a gateway to native OS services.

Consider how this design can work in a DVD player. The user interface in Figure 3 consists of: a viewing area that displays the movie (top half of screen); a DVD player Flash application that provides controls for play, pause, next, previous, etc. (middle of screen); and an HMI engine, written in Flash, that controls the main menu buttons (bottom of screen).


In this example, the HMI engine launches and controls the DVD Flash player (Flash controlling Flash). The DVD Flash player then communicates with the DVD playback OS service through the HMI server (Flash content communicating asynchronously with native OS services).

The above examples show how real time and reliability can be preserved in an embedded system while allowing graphic designers to leverage the power of Adobe Flash. Modular HMI frameworks then become possible that provide a blending of 2D/3D applications, Flash applications, and multimedia.

Randy Martin has been part of the QNX Software Systems team for fifteen years. For more information contact QNX Software Systems, 175 Terence Matthews Crescent, Ottawa, Ontario, Canada, K2M 1W8; (800)676-0566;

by Randy Martin, QNX Software Systems
COPYRIGHT 2008 Advantage Business Media
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2008 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Title Annotation:INDUSTRY FOCUS
Author:Martin, Randy
Publication:ECN-Electronic Component News
Date:Feb 1, 2008
Previous Article:DSPs: networked digital video surveillance--what's the impact?
Next Article:Batteries: charger-circuit designs fulfill consumer needs.

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters