Skip navigation

Cross-platform development has taken on a whole new level of importance.  The impetus is staggering. Developing and publishing new embedded software is a huge undertaking, one which software publishers would like to minimize. For low-cost widgets, controlling costs is vital.


The holy grail of nearly every development team is to develop and maintain one code base that does not require modifications to operate on a processor or hardware platform architecture.  Recently, Intel Embedded Innovator newsletter and magazine featured two relatively new offerings in this area: Adobe’s AIR and Nokia’s QT products.


Although a substantial number of my Software and Tools blogs have focused on Real Time Embedded Systems, not all embedded software is realtime. Adobe AIR and Nokia QT focus on embedded applications development, primarily for mobile devices. Naturally, most mobile devices today include a cellular telephone as part of the package, but that is quickly becoming just a part of the offering and not the entire reason for choosing a compatible mobile device. Some of the newer mobile devices sell not because they are phones, but because of everything else they can do.


The Adobe AIR application runtime is free for most uses. The downloadable Adobe AIR Software Development Kit (SDK) is also free. There is no specific development tool for building Adobe AIR applications, but web developers can use the IDE of their choice, including Adobe tools such as Eclipse™ based Flash Builder, Flash, Dreamweaver, and Javascript, to build Adobe AIR-based applications. The native language of AIR is Javascript, which is one of the ways that true cross-platform development can happen. While Javascript requires a web browser to be installed in order to execute code, Javascript can be used to develop applications that simply use the browser for required services like screen I/O and keyboard input. The Adobe AIR’s SDK provides a set of command line tools for packaging Adobe AIR applications. This can be used with any text editor to build and deploy an AIR application, underlining the actual nature of the product: it’s a runtime environment first and foremost with a collection of Javascript APIs. On the other hand, AIR enables the publication of applications built using a number of Adobe-based development suite applications. Think of AIR as a platform which enables delivery of applications independent of the underlying hardware.


Nokia’s Qt (pronounced cute) product stands in contrast with AIR. Qt is also a free cross-platform standard. But the two products diverge quickly: Qt provides an application and User Interface (UI) framework based on C++Qt applications can run on a variety of platforms including Microsoft (1) Windows and Linux.

Qt documentation shows programmers how to:



One of the significant differences between AIR and Qt is hinted at by the last item in the above list. Where AIR does not require modification to application source code for each new platform, Qt does require modification.


Let’s look at some examples of Qt code from :

MoviePlayer::MoviePlayer(QWidget *parent)



     movieLabel = new QLabel(tr("No movie loaded"));


     movieLabel->setSizePolicy(QSizePolicy::Ignored, QSizePolicy::Ignored);





     connect(movie, SIGNAL(frameChanged(int)), this,


     connect(movie, SIGNAL(stateChanged(QMovie::MovieState)),

             this, SLOT(updateButtons()));

     connect(fitCheckBox, SIGNAL(clicked()), this, SLOT(fitToWindow()));

     connect(frameSlider, SIGNAL(valueChanged(int)), this,


     connect(speedSpinBox, SIGNAL(valueChanged(int)),

             movie, SLOT(setSpeed(int)));





This code is straight forward – once you know what the classes do. Qlabel is a Qt class, as are Qwidget and Qmovie. For example, Qmovie is a class for playing a movie with QImageReader. Movies in this case are simple animations without sound. There are other classes for playing movies with sound. Qt has hundreds of classes serving a myriad of useful tasks. But with completeness comes complexity. The list of classes is staggering; becoming proficient in the use of all these classes is a significant undertaking. Programmers are not limited to the predefined classes. As with any C++ program, custom classes may be defined and used in the usual manner.


Qt does not create a single unified interface that homologates all different platforms. Instead, programmers must use a macro processing facility to select between different platform code bases. By comparison, AIR does unify the underlying platform hardware definitions so that one code works on all supported hardware platforms.


AIR and Qt offer two different paradigms to cross-platform development.  AIR relies on the Javascript environment to homologate operating platforms. Qt places the burden of code configuration on the programmers.  Applications developed with many Adobe tools may be directly targeted to the AIR environment while Qt employs C++ as a development tool base, and requires more configuration management. Both are free to use for most applications.


Do you prefer developing in C++ or Javascript? The language defines which product may be right for you.



Henry Davis

Roving Reporter (Intel Contractor)

Intel® Embedded Alliance

Companies like ADI Engineering (1) offer a service to create customized Single Chip solutions for customers. But once you have a custom version of an Intel® Atom™ E6xx board, without an Input/Output Hub IOH chip, how do you develop software?


According to Steve Yates, President of ADI Engineering, using their management chip design means that both hardware and software developers can continue with their design with minimal disruption. Previous generations of Intel® Atom™ processors relied on a proprietary, closed interface between the CPU functions and the System Control Hub (SCH). The SCH provided essential functions for CPU functionality including the system memory controller and boot flash controller. By moving the Atom E6xx’s IOH from the Front Side Bus (FSB) to the open PCIe bus, Intel effectively opened access for engineers to implement functions of the IOH in different ways and chips – eliminating the IOH from end-product design.


For the remainder of this discussion we’ll divide the systems software into software that relies on APIs at or above the BIOS services level, and directly BIOS/BIOS-dependent software. Applications code that operates with at most calls to BIOS services via the standard APIs may be developed independent of the underlying BIOS.


Software development for the embedded application will be done via cross-platform techniques. This means that the editors, compilers, and debuggers will operate on the development machine, usually a desktop computer. For most embedded applications, the target hardware and software is not fully compatible with the development hardware. Intel offers a complete tool suite for Atom™ embedded software development.  The “Embedded Tool Suite for Intel Atom Processor” and “Intel Application Software Development Tool Suite for Intel Atom Processor” are fully capable tools that address software development and performance requirements of Atom-powered Embedded and Consumer Electronic products. The Tool Suites cover the entire cycle of software development: coding, compiling, debugging, and performance analysis. Both of these tool suites are Linux-hosted and are compatible with GNU tools. Thus, there are a great many third party software tools of all types available to supplement the Intel offerings. These Linux-based tools then interface to a target platform via a serial communications port such as USB, RS-232, or JTAG.




Green Hills Software (2) and Wind River Systems (3) both offer cross-platform development tools. The Green Hills Software offering includes the INTEGRITY® real-time operating system, INTEGRITY Secure Virtualization technology,® Integrated Development Environment (IDE), optimizing C/C++ compilers, and DoubleCheck™ static analyzer. Wind River provides an embedded development kit that includes a hardware board as part of the kit. Developers can begin application development immediately using the kit. Each embedded development kit includes a bootable USB flash drive that turns any host computer into an integrated development environment. Each board also comes with a pre-flashed, 30-day run-time trial version of Wind River's VxWorks real-time operating system or Wind River Linux. Wind River offers C/C++ compilers and a full suite of development software tools.


Both Wind River and Green Hills’ general development tools are the subject of my blog on development tools. <url>

Software development at the BIOS level is where complications may arise. Compared to applications software developers, engineers who are conversant with BIOS are a select group. Taking on a full BIOS development may be more than what your development team is organized to implement. It may also be more capability that your application requires. Fortunately there are members of the Intel Embedded Alliance who offer alternatives.


Insyde® Software (4) (figure below) provides system firmware and software engineering consulting services for companies in the embedded systems and other businesses. InsydeH2O provides a firmware product designed to replace the traditional PC BIOS. It is an implementation of the Intel Platform Innovation Framework for Unified Extensible Firmware Interface (UEFI). Unlike traditional 16-bit real mode BIOS technology, InsydeH2O BIOS Replacement Drivers run in 32-bit mode. The InsydeH2O Compatibility Support Module (CSM) provides backwards compatibility - including the run-time BIOS interface. InsydeH2O's CSM supports continued use of standard legacy operating systems and tools. As with all implementations of the Intel UEFI, InsydeH2O is intended to simplify a gradual transition from legacy software to UEFI.




American Megatrends, Inc.(5) Aptio is a next-generation BIOS firmware based on the UEFI Specifications and the Intel Platform Innovation Framework for EFI. With the availability of UEFI, the days of hand editing and modifying BIOS by hex editors are gone. Aptio can be expanded using drivers, development tools, support utilities and pre-boot application solutions, including:


  • Visual eBIOS (VeB)
  • AMI Debug for UEFI
  • AMI Flash Utility (AFU)      Suite
  • Change Logo Utility -      OEM splash logo management
  • AMI BIOS Configuration      Program (AMIBCP) - Change setup paramaters and strings in Aptio ROM images
  • MMTool - manage modules,      drivers and Option ROMs in Aptio ROM images
  • DMIEdit - SMBIOS data      management


In a very real sense, tools for American Megatrends’ UEFI take the previously ad hoc development methodology used  when modifying previous generations of BIOS and brings UEFI to new levels of software and configuration management. Nanjing Bysoft Co., Ltd (6) and Phoenix Technologies, Ltd (7) also offer BIOS replacement firmware for Atom E6xx-based systems based on the Intel Platform Innovation Framework for Unified Extensible Firmware Interface.


From the applications developer’s viewpoint for systems using a BIOS compatible solution, software development may use standard available development tools providing lower level access is maintained using standard BIOS APIs. Systems that do not include a BIOS rely on a bootloader mechanism to load the system code onto the hardware. This is one area that is different for a customized E6xx design. Since the Atom bootloader process on earlier generation processors was built into the SCH, there was a standard mechanism defined to load the execution image. With the E6xx single-chip approach to systems hardware development, there are a number of ways that an execution image could be loaded. Perhaps the easiest way to implement the loading process is through the use of Intel’s Boot Loader Development Kit (BLDK). For these “naked board” approaches to the low level software, all services are up to the developers to implement for their specific system. All JTAG–based development tools used to control the E6xx processor and interrogate its states will continue to work for these systems.


Supporting standard operating systems with a customized E6xx design is really a matter of electing to implement standard BIOS, or a UEFI replacement. Regardless of which approach is selected, developers must implement the essential services expected by the OS of choice. For the most part, this can be accomplished by using the Intel BLDK to create a loader to work with the customized loading mechanism. UEFI vendors can provide a near off-the-shelf solution for BIOS replacement for systems using a custom management chip.




Testing and validating software is best and most cost-effectively achieved using the cross development paradigm. For example, Wind River Systems employs Eclipse-based JTAG support for Atom processors. By using Eclipse based services, Wind River improves user functionality and indirectly supports third party additions to the Eclipse environment. For software developers using the Wind River tools, Eclipse can become an entire project by itself. According to current large scale users of Eclipse, the Eclipse API can overwhelm developers new to the technology. But with that complexity comes the ability to make the system do anything that you can imagine. The issue is the amount of effort required to extend Eclipse in your own unique direction. Fortunately Wind River has already provided toolset extensions to permit scripting of JTAG functions for test and validation purposes.


The range of options available to developers of embedded Atom-based products is greater than ever before. Through the use of Intel’s BLDK, developers can create just the right low levels services for their application. Or, choosing to employ an UEFI alternative is always an option.


What path will you take for your next single-chip E6xx-based design?



  1. ADI Engineering is an Associate member of  the Intel Embedded Alliance
  2. Green Hills Software is an Affiliate member of the Intel Embedded Alliance
  3. Wind River Systems is an Associate member of the Intel Embedded Alliance
  4. Insyde Software is an Affiliate member of the Intel Embedded Alliance
  5. American Megatrends, Inc. is an Affiliate member of the Intel Embedded Alliance
  6. Nanjing Bysoft Co., Ltd is a General member of the Intel Embedded Alliance
  7. Phoenix Technologies, Ltd is an Affiliate member of the Intel Embedded Alliance


Henry Davis

Roving Reporter (Intel Contractor)

Intel® Embedded Alliance

Consolidation of hardware platforms, or “boxes,” is a goal for many companies needing to update one or both pieces of hardware. Consolidation without massive change to legacy software can be a tricky job. Intel’s Virtualization Technology can ease the migration process.


“Time and tides wait for no man”(1) – and neither does concrete.


Making concrete is one of those amazing chemical reactions that we often take for granted. That is, unless your job is to work with concrete, then organized chaos results. Pourable concrete is a perishable commodity that starts its limited life as soon as water is added to make the mixture. Not only does an individual batch of concrete “spoil” if it’s left in the cement mixer too long, but concrete pours often must be completed in a single, multi-truck pour - that also has a limited life span.


In comparison to realtime control of higher frequency rate processes like controlling the ignition of an automotive engine, concrete seems like a slow process to manage. But the entire process from concrete production, quality control, and delivery is deceptively complex with control of critical mixing valves just one part of the process.




Command Alkon, a redimix concrete systems supplier , uses a proprietary system to manage its software and materials handling products, including entire integrated concrete system. Subsystems of the software manage a wide variety of services, including disparate functions:


  • Common Master Files
  • User Definable Forms
  • Comprehensive Scheduling and Tracking Tools
  • Order Modeling
  • Windows-style Order Tree
  • Concrete Mix Design Interface
  • Field Level Security
  • Dual Units of Measure
  • Time Analysis Capabilities
  • Driver Utilization Management
  • Comprehensive Executive, Operational, and Financial Reporting Capabilities
  • Customizable Pricing Levels
  • Price Change Utilities
  • Cement Content Pricing
  • Accounting functions
  • Language Translation
  • Batch Panel Interfaces
  • Geographic Mapping Interfaces
  • Signaling Interfaces including complete Autostatusing
  • Color Dispensing Interfaces
  • Quality Control System Interface
  • Caller ID Interface 



As is often the case involving legacy code in large scale systems, changing the software operating environment can be a huge undertaking. The complexity and difficulty explodes when the system is split across multiple non-homogeneous hardware platforms. In the case of  Command Alkon, the proprietary software system was partitioned between two hardware boxes – one to manage the realtime control aspects of a concrete plant automation and another to deal with the non-realtime aspects of the system including the User Interface and management functions. These two systems communicated through an ethernet link connecting the two boxes.


At first glance, upgrading either one of the hardware platforms seems like a straightforward task. But the decision of what to do was complicated by the thousands of plant installations around the world.


Maintenance and provisioning spares in general argues in favor of implementing systems with the minimal number of pieces of hardware necessary. There are examples where adding redundant hardware improves systems reliability <link to my blog post> and availability, but that isn’t the case with a system made up of disparate entire hardware boxes and operating software.  Command Alkon’s concrete management system relies on Microsoft® Windows (2) for management and accounting functions. A separate hardware and software system operates the realtime aspects of the system.  Both systems function well, but many computer systems have a limited lifespan. Thus there is a future date when today’s hardware is no longer available.


Ideally, both the realtime subsystem and the Windows-based User Interface and management functions would run on a single platform.


Intel’s virtualization technology provides the base for companies like TenAsys (3) to field combined Microsoft Windows and a realtime operating system.




The TenAsys approach employs Intel virtualization to simultaneously host two operating systems on a single hardware platform. TenAsys’ eVM for Windows embedded virtualization platform creates a virtual machine environment that hosts an embedded or real-time operating system alongside Windows. eVM partitions the input and output interfaces to the right virtual machine partition to ensure that critical hardware interfaces are given first priority to the most critical operating system kernel. Doing so guarantees deterministic response to real-time events.


What makes TenAsys approach different is the ability to simultaneously host a wide variety of realtime operating systems (RTOS) alongside Windows on a single platform. eVM permits a guest RTOS to be configured and controlled by a user interface running on the Windows operating system. TenAsys’ approach permits an RTOS of choice to be selected as the guest OS. eVM can manage guest OS configurations for Wind River Systems (4) vxWorks RTOS, QNX Software Solutions Ltd (5) QNX, Microsoft Windows CE, Linux, and legacy RTOSes.


Using the virtualization approach protects one of the most valuable assets in large legacy systems – the proprietary software.  But if both the Windows and RTOS systems have been merged into a single hardware platform, how do you communicate between the two logically separate systems without modifying the legacy link that previously connected the two hardware platforms?


eVM creates a virtualization environment to allow both a Windows system and an RTOS to operate in the same physical hardware. It accomplishes this by removing one hardware thread from Windows control during installation. This hardware thread is dedicated to the guest RTOS. Windows employs its standard configuration mechanism to perform this piece of systems configuration – for a multi-core processor this is accomplished by dedicating one core to Windows and another to the guest RTOS. eVM relies on Intel VT-x support to perform realtime memory mapping between each OS’s logical memory map and the physical memory map. Competing use of the memory mapping hardware is one area that developers must pay close attention to since competition between Windows and guest OSes may limit systems performance.




During systems installation, a fixed partition is established to contain the eVM software and the room needed for the guest OS. This locks the dedicated memory from control by Windows and is one of the basic mechanisms used to ensure deterministic RTOS behavior. The next critical configuration task is to separate interrupt serving into two categories: those that are required to be served by the guest OS and those that may be served by Windows. This is accomplished by establishing eVM as the interrupt service for interrupts associated with the realtime devices. eVM then passes control to the guest OS. By maintaining control over critical resources, eVM ensures that realtime functions do not become entangled in Windows non-realtime operation.


There are other classes of “realtime” devices such as a realtime clock, disc controller, PCI bus, bridge on the PCI bus, and interrupt controller. All of these signals are generated by eVM as virtual devices that are resident in the guest OS space.




In this architecture, device A is a PCI device driver that supports MSI, device B is handled by a normal Windows driver, device C and D share an interrupt but eVM routes a virtual interrupt for device D that may be polled by the guest OS while device C functions a normal Windows device,  device E is handled by eVM and a virtual IRQ is delivered to the guest OS, lastly device F is an MSI device that is handled by eVM and passed a virtual IRQ to the guest OS.


With control over the interrupt structure established, eVM can create a virtual Ethernet link between the Windows operations and the guest OS operations. This is accomplished by Windows using its standard NDIS drivers  and the guest OS employing an NE2000 interface. Thus eVM creates a virtual Ethernet link using shared memory that can be accessed by both Windows and the guest OS as if the virtual link were physical. Consequently, the Command Alkon Windows software and the RTOS hosted-software behave in the same manner as they did when operating on two separate boxes without modification.


TenAsys’ eVM provides an elegant way to marry two previously separate hardware platforms to achieve lower hardware complexity on a single piece of hardware. It does this through an elegant use of Windows installation techniques, eVM-based interrupt handlers, and Intel Virtualization Technology.


What’s in your future platform?


1.    1. Cesar Chavez

2.    2. Microsoft® Corporation is an Associate member of the Intel Embedded Alliance

3.    3. TenAsys is an Affiliate  Member of the Intel Embedded Alliance

4.    4. Wind River Systems is an Associate member of the Intel Embedded Alliance

5.    5. QNX Software Solutions Ltd is an Associate member of the Intel Embedded Alliance