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 article 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 Linux development.
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. Sometimes, an editor is almost a religious preference, and this article makes no effort to pick one over another. If you're new to Linux, I advise you to try a few to see which ones you're comfortable with.
This article looks at make through the lens of a user who is already a little familiar with the tool. 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 programmer 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. 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 Linux kernel's make file appends the default value to a prefix to the tools that you supply-for example, from the kernel make file:
AS = $(CROSS_COMPILE)as LD = $(CROSS_COMPILE)ld CC = $(CROSS_COMPILE)gcc CPP = $(CC) -E AR = $(CROSS_COMPILE)ar NM = $(CROSS_COMPILE)nm STRIP = $(CROSS_COMPILE)strip OBJCOPY = $(CROSS_COMPILE)objcopy OBJDUMP = $(CROSS_COMPILE)objdump
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 Linux projects, all you need to do is use the built-in make variables and tools. The rest of the software adjusts to the project.
Our website is not responsible for the information contained by this article. Articleinput.com is a free articles resource thus practically any visitor can submit an article. However if you notice any copyrighted material, please contact us and we will remove the article(s) in discussion right away.
Note: This article was sent to us by: Maddox Zinger at 02012010
1. Embedded Linux is used for some very good commercial reasons
All articles are property of their respective authors. Please read our Privacy Policy!
© 2009 ArticleInput.com.