# IDE - Linux Embedded systems

Integrated Development Environments (IDEs) are nothing new. Several embedded vendors tout that they have a set of tools wrapped in an IDE that’s been created with the embedded developer in mind. In reality, most of these tools become shelfware when you find that the tools available in open source are just as good, if not better, for embedded development chores.

This section covers several different approaches for getting the tools in place for an IDE that’s productive for embedded engineers. These projects are all mature and ready for use in a production environment. Like any tool, each of these has limitations that you should consider before making your selection as well as great functionality that reduces the drudgework involved with embedded development.

Your Editor + Make + Shell
This is the most popular IDE by far. Using these tools gives you the most control over the development environment in exchange for more work on your part. You create and maintain make files for the project and interact with the code librarian on the command line. Using the shell has the very tangible benefit of a ready-to-use set of scripts for building the software in a separate build system, as long as the engineers have been disciplined enough to put all the settings in make files or shell scripts.

You can choose from hundreds of editors. If you’re new to Linux, we advise you to try a few to see which ones you’re comfortable with. Table below lists some popular editors, in no particular order.

Using Make
Make is a tool that looks at a target and dependencies and figures out what steps are necessary to create the target if it’s out of date with its dependencies. The notion of out of date means the file system has a date on a dependency that’s newer than the target file. Make then looks to see if there’s a rule to rebuild the dependency, first by name then by file extension.

A make rule looks like this:
output-file: input1.o input2.o input3.o
$(CC)$^ -o $@ This line is read, “output-file is made from input1.o input2.o and input3.o” and means that make attempts to be sure that on the file system, the dependencies are up to date before running this rule. To help you be more productive, make has a large number of predefined rules; the author of a make file doesn’t need to write much in the make file to get something built. This has disadvantages in that a make file seems to work by magic, because you haven’t specified much of anything but make still seems to have enough information to build something. One of the most confusing aspects of make files is the usage of environment variables and how those affect make. When make starts, all environment variables become make variables. Make sets defaults for some variables so that the predefined rules work on most targets. Make’s rules then use these variables to execute tools to build dependencies. In the previous example, the tool$(CC) defaults to the value of cc, which is a symlink to GCC on most systems.

For embedded projects, you can still use the standard make file rules, but some make variables need to be changed so that they point to the cross-compiler and not the native tools on the system. Table below lists the most frequently reset variables.

Each of these variables has a corresponding FLAGS variable in the format <variable name>FLAGS that’s used to pass parameters in for that tool. The FLAGS variable makes it so that you don’t need to alter the built-in rules to change how the programs work.

In most projects, the LDFLAGS (flags for the linker) are updated to include references to additional libraries and link instructions, such as when you want to build without shared libraries.

When you’re cross-building, you should set these in the environment or in the make file so that the right tools are invoked. The kernel’s make file appends the default value to a prefix to the tools that you supply for example, from the kernel make file:

When you run the make file, the value of $(CROSS_COMPILE) is passed via the environments: export CROSS_COMPILE=armv4l-linuxmake zImage Or it can be passed in the value CROSS_COMPILE when make is run: make CROSS_COMPILE=armv4l-linux- No matter which way make is invoked, the result is the same. When you’re working on embedded projects, all you need to do is use the built-in make variables and tools. The rest of the software adjusts to the project. Eclipse Eclipse has quickly become the IDE of choice, and not just for embedded engineers. This project was released by Object Technologies (a unit of IBM) more than 5 years ago as a general-purpose coding platform with very strong support for Java.5 Shortly after the introduction of the Java-oriented Eclipse release, the C Development Toolkit (CDT; the Java IDE was called the JDK early on) was released; it provided rudimentary C support. Over the years, the CDT has become much more robust and featurecomplete. Installing Eclipse and Plug-ins Eclipse is designed to be highly extensible. Its extensions are known as plug-ins, and the CDT is such a plug-in. To use Eclipse, the easiest thing to do is get the version from the package manager:$ sudo apt-get install eclipse

Here’s the command for RPM systems:
\$ sudo yum install eclipse

And then you wait. An Eclipse installation is about 350MB and takes at least 15 minutes to download with a reasonably fast Internet connection. After you download it, run Eclipse and install the CDT by pointing Eclipse at the CDT plug-in update site. To do so, select Help ➤ Software Updates ➤ Find and Install.

Doing so displays the dialog shown in Figure. Choose “Search for new features to install.” This is a misnomer because it doesn’t search for the features: you need to tell it a URL that contains the binaries for the plug-in that the wizard should download and install into the current Eclipse configuration.

On the next page, shown in Figure below, click the New Remote Site button and enter the following the name can be any value.Then, click OK. The name appears in the list with a check mark to the left of the value. Click the Finish button to start the update process.

A list of mirrors appears. Select the mirror closest to you, or navigate to the bottom of the list and select the canonical site, CDT. The software churns for a few seconds and then displays the dialog shown in Figure below.

Clicking Finish begins the installation process. The Update Manager displays a dialog that shows the progress of the download. Depending on the proximity of the mirror, the number of users doing an upgrade, and how many of your kids are watching streaming videos while downloading new kernel source tarballs, this process could take up to 30 minutes. You’re asked to restart Eclipse for changes to take effect.

Along with the CDT project, the next set of plug-ins that are essential to embedded development are in the Device Software Development Platform project, specifically the Target Management and Device Debugging plug-ins. The Target Management plug-in makes downloading files to a remote target, such as a board running embedded Linux, very simple. The Device Debugging plug-in is designed to make remote debugging in Eclipse as easy as debugging a program locally. Installing these additional plug-ins is left as an exercise for you.

Using Eclipse
In Eclipse, the organizing entity is a project. To start development, first create a project by selecting FileNew and selecting Managed Make C project. A Managed Make project is one where Eclipse populates the make file based on the contents of the project. In the next panel, fill in the name of the project and click Next. In the next panel, the wizard asks what sort of project to create. For this example, select the Executable (Gnu) project type, and click Next.

A configuration is a set of compiler settings used to build the source code. The Debug configuration builds the code with no optimizations and debugging symbols turned on, whereas the Release configuration builds with the highest optimization level and no debugging symbols. Click Finish to create the project.The default project settings are appropriate for the native compiler and not for cross-compilation.

Only a few changes are necessary to make the project invoke a different compiler in the project’s property page. Open the property page by selecting the project and pressing Alt+Enter. The dialog in Figure below appears.

In the Tool Settings panel, change the GCC C Compiler and Linker command to the cross-compiler, and the assembler command to the cross-assembler. In this example, the compiler is /home/gene/xtools/ powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-gcc and /home/gene/xtools/ powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-as, respectively.

Next, add a file to the project by selecting File ➤ New ➤ File and creating a file with the extension .c for example, test.c. The software adds this file to the make file and attempts to build the project, resulting in an error. Automatic project builds are great for Java but irritating for C or C++ projects.

Disable this feature by choosing Window ➤ Preferences and then choosing General Workspace on the menu at left. In the panel on the right, unselect Build Automatically.

For each build configuration, Eclipse creates a directory of the same name to contain the project make files generated by the project. To allow for maximum flexibility, the make file optionally includes three make files that you can further customize:

1. makefile.init: Use this file to add initialization instructions to the make file. This file is included first, before anything else.
2. makefile.defs: This is the best place to define any variables used later in the file.
3. makefile.targets: In this file, add any additional targets, where targets are the things that the build creates.

That’s all you need to do to create a working environment in Eclipse. As new files are added to the project, the make file automatically adjusts.