With fourteen currently available members of the Atom family, there is a variety of choices to meet hardware needs. But, choice sometimes can complicate software development. In the case of Atom processors, there are differences not only in execution performance, but also in the native support for some functions like full motion video. Properly structured and conceived software can make porting to a new Atom environment quick and easy. With forethought and following some simple rules you can save development costs and time, speeding new products to market.


Structuring software to make porting code across the Atom family can be simplified by choosing the right development environment. One solution is based on supported, commercial software tools such as the Eclipse environment which provides the ability to customize your software development environment.  Software development tools from Intel, Wind River Systems(1), and Green Hills Software(2) use the Eclipse framework to permit third party tools and user customization of the environment.

The Eclipse framework includes a Concurrent Versions System (CVS) repository. This is a persistent information store used to “manage” multi-user access to projects and their contents. Different software versions are maintained by the use of branches which spring off the major development line. Projects in a repository can be of two forms: immutable (a project version) or modifiable (a project in a branch). Since CVS is not a rigidly defined system, it’s possible to manipulate how the tool gets used – creating unique strengths and weaknesses.




The Eclipse Foundation documentation defines an ideal work flow:


1.   Start fresh. Before starting work, update the resources in the workspace with the current branch state. If you are sure that you have no local work that you care about, the fastest way to get caught up is to select the projects you are interested in from the branch (or HEAD) and select Checkout (or Replace with > Latest from Repository if the projects already exist locally). This will overwrite your local resources with those from the branch.

2.   Make changes. Work locally in your Workbench, creating new resources, modifying existing ones, saving locally as you go.

3.   Synchronize. When you are ready to commit your work, synchronize with the repository.

a.   Update. Examine incoming changes and add them to your local Workbench. This allows you to determine if there are changes which might affect the integrity of what you are about to commit. Resolve conflicts. Test again, run integrity checkers (for example, check for broken hypertext links, ensure your code compiles, and so on).

b.   Commit. Now that you are confident that your changes are well integrated with the latest branch contents, commit your changes to the branch. To be prudent, you may repeat the previous step if there are new incoming changes.


This ideal workflow can be compromised by accident or on purpose. Or, a different approach can be defined by the development team. Usually the integrity of development software is assured through company-wide or development team programming standards and practices. These standards are also where the specifics of how to use CVS are kept, although there is not a guarantee of automatic checking for adherence to the standard.


Some companies do not allow embedded applications-specific software to change the development environment as a way to control uniformity of development. In these cases more traditional tools are still available: programming language macro pre-processors and source configuration and control software.


C and C++ both include standardly defined macro preprocessors as part of the pre-compilation process. The standard C preprocessor (CPP) has basic symbol-based processing that can control compilation:


#ifdef _WIN32 // _WIN32 is defined by all Windows 32 and 64 bit compilers

#include <windows.h>


#include <linux.h>



In this case we are selectively choosing between header information specific to an operating environment depending on whether or not the environment is a version of Microsoft® (3) Windows™ or something else. In this case the software definition either selects the Windows header, or the Linux header if WIN32 is false. It’s important to recognize that this structure really selects between the true value of WIN32 and the false value. If there were more than two choices for operating environment possible, we would need to have additional conditional compilation steps or use a different form of conditional compilation.


The two feature-set options of critical importance for products using E6xx Atom processors are: the use of the standard IOH and the presence of integrated graphics support including full motion video. We could define two different boot mechanisms based on the presence or absence of the standard IOH:


#ifdef std_hub_type

#include <stdboot.c>


#include <bldk_boot.c>




Configuring software for the presence (or absence) of processor-based capabilities is similar to selecting between two different boot mechanisms. However, for processors that include full motion video capabilities and versions that have a limited set of graphics support, there are some other considerations. Members of the Atom family are supported by two different drivers for graphics: The Intel Embedded Graphics Drivers (IEGD) and Intel Embedded Media and Graphics Driver (EMGD).  Assuming that your development can use these drivers, the primary issue is selecting which one to compile as part of your application. This may be accomplished using the same compile time if-then-else structure used to select between a Windows environment and a Linux environment.


Another approach to managing different versions of software for different processors is to add third party tools to the Eclipse environment. Subclipse is a pre-configured Subversion plug-in for the Eclipse workbench.  Subversion is a relational database model of configuration control that adheres strictly to the “all or nothing” philosophy of updating source files. By doing so, there is little danger of some part of an application remaining uncompiled without your knowledge due to conflicts. Installing Subversion is a simple process on an Eclipse workbench, requiring a small number of mouse clicks.


Each of the commercial software development packages includes a software project management “wizard” that can also be used to configure software. As an example, Green Hills’ MULTI Project Builder uses a template that defines a specific hardware system (board) so that necessary software modules are automatically included in the compilation process.




Project management facilities can provide some control over what software is included in a specific build.  Selecting between which capabilities a specific member of the Atom family supports can be achieved through the Board Support Package, or template. One template may be defined for Atom-based systems that include full motion video, and another version for Atom processors that do not have full hardware acceleration.


Developing software that can work on all Atom processors is easy, but care must be taken when choosing algorithms to simplify the porting task. Porting issues within the Atom family are related to the presence or absence of hardware acceleration on the processor. The generic software porting issues are eliminated for software that remains targeted to Atom-based processors. Some guidelines for developing software to span multiple members of a single processor family include:


  1. Manage software configuration at the highest level that your tools support. By keeping as many of the implementation alternatives out of the code proper you minimize the chances of an incompatibility sneaking past undetected.
  2. Create a single Application Programming Interface specification for different processor hardware capabilities. Special function hardware homologation should be kept compartmentalized behind the defined interface.
  3. Establish minimum performance requirements for key algorithms and define systems level variables to control the configuration management to generate a warning when trying to configure the application to a processor that has too      little performance.
  4. Clearly document performance-oriented programming techniques that are key to an algorithm’s performance or function – it’s amazing how often the original author forgets why a particular technique was used. This is especially important for programming techniques or styles that are processor-specific.
  5. Use the performance analysis tools provided by the software tool chain to explore alternative algorithms and implementations. Despite the natural tendency to peephole optimize software, the best performance is often found by large scale algorithmic choices. 


The Atom processor family offers alternatives for many embedded applications. Anticipating the future choices that will exist can be made easier by reviewing the Intel Atom family roadmap.


How will future Atom processors affect your software development process?



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

2. Green Hills Software is an Affiliate member of the Intel Embedded Alliance

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


Henry Davis

Roving Reporter (Intel Contractor)

Intel® Embedded Alliance