Chapter 2: Getting Started

Overview

The last chapter presented hardware design options for a typical embedded system. This chapter concentrates on how to write and build a program destined for an embedded device.

Because you will be working in a cross-development environment on potentially untested hardware, the first programs are very small, very limited test programs. Even though the first test may be trivial programs, getting them into the target is not trivial. Before you can hope to begin testing your firmware, you must:

• understand the hardware environment;

• make sure you have the necessary programming and debugging tools;

• make sure your programming and debugging tools are compatible with the hardware environment;

• perform some simple tests to verify that the hardware is working.

Youll learn more about these considerations later in this chapter. First, Ill begin with a look at the cross-platform compilation process and how the embedded systems environment differs from the conventional PC environment.

Before going any further, you should be aware that the build procedure discussed in this book does not involve any fancy graphical user interface (GUI) interface nor does it require any expensive tools. The development environment used throughout this text is the Microcross GNU X-Tools, a fully functional set of the X-Tools suite is provided on the book CD. Supplying the completed tool set should eliminate the headaches typically associated with build environment incompatibilities. The examples in this chapter use tools like gcc , objcopy , objdump , and make . You can pick your own editor. I use elvis , a vi clone, that allows me to edit binary files in a convenient way. (You will see later that this is very handy.) If you are accustomed to working with a modern desktop application development environment, these tools may seem primitive, at first. Their sparseness, though, is their strength. Using a GUI development environment for this stage of firmware development is like working in the rain with an umbrella. You spend more time figuring out how to hold the umbrella than you do working on the project. Its much better to just get wet. The point is that you dont want anything sheltering you from the bare metal. Working with simple command-line tools may seem a little cold at first, but, in order to understand the firmware development process, you need to put down the umbrella.