Trends in Cross–Development for Intelligent Systems with Respect to Intel System Studio

The first decision to be made when defining your build environment is the choice of a cross-build development tools set to base development on. If you are using a proprietary real-time operating system (RTOS), the basic development toolchain will come from the OS vendor. Examples for this are Integrity* from Green Hills Software, VxWorks* from Wind River*, Nucleus from MentorGraphics* or QNX*. All of these come with their defined set of development tools, which can only be augmented by utilities from other vendors.

In the case of Intel System Studio, you would be using a Linux* based target OS either with or without a real-time scheduler, and your choices are considerably varied. You have the option to build your own cross build tool chain, create a full target OS image inside a buildroot/chroot wrapper, or use a variety of pre-defined cross build environments that come with specific Linux* flavors targeted for the embedded market.

Let us start with the roll-your-own approach to highlight what to consider when choosing a cross-development centric GNU* toolchain.

When talking about development tools usage in embedded, one must distinguish three different machines:

  • the build machine, on which the tool set is built
  • the host machine, on which the tool set is executed
  • the target machine, for which the tool set generates code

Very rarely do you actually need 3 systems. In most scenarios the build machine and the host machine will be identical, reducing the setup to a development host machine and a development target machine.

                              

A complete tool suite is made up of the following components:

·         Compiler: This could be a range of different compilers. For Linux* targets the most common compiler to use are the GCC and G++ GNU* Project compilers. Intel System Studio uses the Intel C++ Compiler, and in some cases it is useful to use the Intel C++ Compiler for an entire application build. The main question will be whether this compiler is going to be a native GCC build or a compiler build that is part of a tool suite specifically targeted at cross development.

·         Build Process Backend Components: Looking beyond the compiler itself, there are build backend tools like assembler, linker, and output format conversion utilities. In the Linux* world this is covered by the GNU Binutils.

·         Libraries:

o    The main set of library files required are part of the C library, which implements the traditional POSIX API that can be used to develop userspace applications. It interfaces with the kernel through system calls, and provides higher-level services. GLIBC (http://www.gnu.org/software/libc/) is the C library from the GNU project. Embedded GLIBC (http://eglibc.org) is a variant of the GNU C Library (GLIBC) optimized for embedded systems. Its goals include reduced footprint, support for cross-compiling and cross-testing, while maintaining source and binary compatibility with GLIBC. uClibc (http://uclibc.org) is an alternate C library, which features a much smaller footprint. This library can be an interesting alternative if flash space and/or memory footprint is an issue. The C library has a special relation with the C compiler, so the choice of the C library must be done when the custom tool suite is generated. Once the toolchain has been built, it is usually no longer possible to switch to another library.

o    Additionally, libraries for optimized and simplified implementation of signal processing, media processing and security encryption routines may be of interest such as Intel Integrated Performance Primitives or Intel Math Kernel Library.

·         Performance and Power Analysis Tools: With the typically embedded requirement of getting a maximum amount of performance for a dedicated task combined with reduced power consumption or battery usage out of a given highly integrated chipset, software tuning and analysis tools  become an ever more important part of your cross-development toolset. These tools come in very varied packages and with a wide range of use cases. The performance tool of choice for Intel System Studio is Intel® VTune™ Amplifier for Systems

 ·         Debuggers: The tool whose importance is commonly most underestimated, by those not already used to the extreme reliability requirements of many embedded use cases, is the debugger. These fall into three categories. Memory and code correctness checking tools, high level language application debug tools and system software debuggers. The latter two are focused on real-time debug of software stack components. A forth type of debug tools that has found new life because of the complex interactions in heterogeneous multicore SoC chipsets is the instrumentation based event tracing utility. Intel System Studio offers the GNU Project Debugger for application debugger and the Intel® JTAG Debugger as system debugger. SVEN – ultra-low overhead instrumentation technology for software debug is also included.  

The most straightforward approach that is especially easy in a scenario where the development host architecture as well as OS is closely related to the target architecture and OS is something called buildroot (http://www.buildroot.net). The concept behind this is that you have a complete customized embedded Linux build environment and can create a custom OS image. If you include the build tools in this OS image, you automatically also get the build environment with it. If you then use chroot (http://www.linux.org/article/view/chroot-access-another-linux-from-your-current-linux-) to create a virtualized boot environment for your virtual OS image, you can run your new embedded Linux* build environment in a protective virtual wrapper on top of the standard Linux* host. As in the case of Intel® Architecture targets the development host and target are closely related, this is possible without the overhead of an actual virtual machine.

The alternative approach, which is valid for other architecture targets as well as Intel® architecture is the generation of a custom cross-build binutils and gcc tools set using the –sysroot option to tell the compiler which version of C libraries, headers, start objects and other shared objects to use and where they can be found. All common GNU based cross-build environments use some variation of this approach.

Creating your own cross-build GNU tool set is often tied into creating your own custom Linux* platform. OpenEmbedded (http://www.openembedded.org) with its Bitbake utility is one approach to roll a custom Linux*. Poky Linux (http://pokylinux.org) offers an approach to creating your own cross-build GNU toolchain.

Many complete Embedded Linux* frameworks like OpenEmbedded or Yocto Project rely on these as a foundation.

Instead of creating your own framework it usually makes more sense to rely on the frameworks that already exist. In addition to OpenEmbedded and Yocto Project, there are also a variety of offerings from Code Sourcery, Wind River, MontaVista and Timesys.

For more complete information about compiler optimizations, see our Optimization Notice.