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

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

3. 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.

4. 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.

5. 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.

6. 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.

8. 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.

9. 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.

10. 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.

11. 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.

12. 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.

14. 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.

15. 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.

16. 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.

17. 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.

18. 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

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

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

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