Embedded System Development Lecture 13 4/11/2007 CS590 Embedded System Development Lecture 13 4/11/2007

Class Notes Homework #3 is out. It is due next week (4/18). Final project report/demo April 25th.

Tool Chains Most programming work for embedded systems is done on a host or workstation, a computer system on which all the programming tools run. Only after the program has been written, compiled, assembled and linked is it moved to the target, the system that is shipped to customers.

Tool Chains Native tools are toolsets that will build software to run on the host. What we need is a compiler that will run on the host but produce the binary instructions that will be understood by our embedded processor. Such a program is called a cross-compiler.

Tool Chains Various compilers and processors may exhibit behavior you might not expect. Variable sizes may vary Structures may be packed differently. Your ability to access 16-bit and 32-bit entities that reside at odd-numbered addresses may be different.

Tools Chains Just like cross-compilers, there are also cross-assemblers. When you are building the software, the output of one tool becomes the input to the next tool. A set of tools that is compatible in this way is called a tool chain.

Linking and Locating Linkers for embedded systems are often called locators or linker/locators because in addition to linking all the code together they also must handle locating the code at specific memory addresses. When a file is compiled, there may be references to specific addresses that hold a data item or are the address of a subroutine. Since the compiler can’t know at compile time what the ultimate addresses will be, it notes all the addresses that need to be filled in.

Linking and Locating The process of resolving all these unknown addresses is called address resolution. The information produced by the compiler that will allow these addresses to be resolved are commonly called fix-ups.

Linking and Locating Another issue that locators must resolve in the embedded environment is that some parts of the program need to end up in ROM and some parts need to end up in RAM. Most tool chains deal with this problem by dividing programs up into segments. Each segment is a piece of the program that the locator can place into memory independently of the other segments.

Linking and Locating Most cross-compilers automatically divide the module they compile into two or more segments: The Instructions Uninitialized Data Initialized Data Constant Strings You must tell the locator where to position the segments in memory.

Linking and Locating Other features that some locators offer: You can specify the ranges of ROM and RAM, and the locator will tell you if the program doesn’t fit. You can specify an address at which a segment is to end, and the locator will place the segment below that address. This is useful for things such as stacks. You can assign each segment to a group, and then tell the locator where the groups go, rather than dealing with the individual segments.

Initialized Data and Strings Initialized data causes special problems in embedded systems. The initial values must be in ROM, but it needs to run in RAM. One common way that locators deal with this is to create a “shadow” segment in ROM that contains all the initial values, and that segment is copied to the real initialized data segment at startup time.

Initialized Data and Strings Although the C standard specifies that any uninitialized variable that is not stored on the stack starts with a value of zero, this may or may not be true on your embedded system. Some tool chains automatically insert code that zeros out this memory area.

Initialized Data and Strings Strings present another potential issue. Should the strings be stored in RAM or ROM? Some compilers will put constant strings into the initialized data segment.

Locator Maps Most locators will create an output file, called a map, that lists where the locator placed each of the segments in memory. Typically, maps also include the addresses of public functions and global data variables.

Executing out of RAM RAM is typically faster than ROM. We may want to copy the code out of RAM and into ROM. We may want to compress the code image. Startup time considerations

Output File Formats Binary Intel Hex File Format Motorola S-Record Format

Getting Software onto the Target PROM Programmers ROM Emulators In-Circuit Emulators Flash Memory On-Chip Debugging

Class Project Any questions from last week? Final Demo/Presentation April 25th. Please email me your source code.