An Embedded Software Primer

An Embedded Software Primer David E. Simon

Chapter 9: Embedded Software Development Tools • Host and Target Machines • Linker/Locators for Embedded Software • Getting Embedded Software into the Target System

Host and Target Machines • For embedded systems, programming is usually done on a host, a computer where the programming tools run. • After the program is written, compiled, assembled and linked, it is transferred to the target (system where it will eventually run) • Done because target might not have a screen, keyboard, sufficient memory or peripherals necessary for programming. Cross-Compilers • Compilers, assemblers and linkers are designed to run on the host. • However, target is different than the host. Hence compiler has to produce binary instructions that will be understood by target and not by host i.e. a cross compiler • Certain problems – code that compiles correctly on native compiler might not do so on cross-compiler • Problem normally when using functions without declaring, old style of declaring etc. and not in the common statements like if, switch or while. • Even code that compiles cleanly on cross-compiler might not work on target • Size for int might be different on the host and the target, structures might be packed differently etc. • Cross-compiler should be able to notice potential errors – void pointer cast to an int might not give a warning on a native compiler but it should on the cross-compiler as ints and void pointers might not be same size on target

Host and Target Machines (contd.) Cross-Assemblers and Tool Chains • Cross-Assembler – runs on host, produces binary instructions for target • Input should be assembly instructions appropriate for target. • Fig. 9.1 shows process for creating instructions that are built on host but meant for the target • Tools are compatible with each other and form a tool chain.

Host and Target Machines (contd.)

Linker/Locators for Embedded Software • Linkers in embedded systems different from native linkers. • Often called locaters (as well as cross-linkers) Address Resolution • Native Linker – creates a file to be run on the host by a loader. Loader loads file into system memory during run-time. • Locater – creates a file that will be copied onto target. Output on target has to run on its own (not through loader) • Difference between the two lies in file format as well as information they should contain • Fig. 9.2 shows a tool chain to build an EXE file. • As seen, the MOVE instruction for loading idunno into R1 and the CALL to whosonfirst must contain the corresponding addresses of idunno and whosonfirst. • The solution to this problem is address resolution • Compiler leaves flags in ABBOTT.OBJ indicating to the linker to patch the addresses for idunno and whosonfirst • Also leaves a flag on COSTELLO.OBJ showing their location within the OBJ file • Linker finds out the addresses relative to the start of the EXE file while combining the two OBJ files • Finally on loading onto the memory, loader knows the exact memory locations of the addresses

Linker/Locators for Embedded Software (contd.)

Linker/Locators for Embedded Software (contd.) • Most embedded systems don’t have a loader. • The locator directly copies the program onto target memory. Hence it needs the exact addresses beforehand • Locators can load several file formats to the ROM, most simple being a binary image. • Others include the Intel HEX File Format and the Motorola S-Record Format (not shown here, if needed refer Simon Fig. 9.3 and 9.4) Locating Program Components Properly • Certain parts of program need to be in ROM and some in RAM • E.g. subroutine whosonfirst would be in ROM since it remains unchanged, however variable idunno would be stored in RAM since its value is variable • Tool chains normally resolve this by dividing program in independent segments (e.g. code for RAM goes into segment 1 and for ROM into segment 2) • Most cross-compilers normally segment the program as follows: • Instructions (some cross-compilers put functions in different segments others put entire code in one segment) • Uninitialized data • Initialized data • Constant strings • Several cross-compiler options can be customized through the command-line or C #pragmas

Linker/Locators for Embedded Software (contd.) • Locator to be told where in memory to place segments • Fig. 9.6 shows 2 command-line instructions showing this • –Z indicates line is a list of segments • Operands (IDATA, UDATA) are the segments • Address at end of line (0 and 8000) • Can specify ROM and RAM address ranges to locator (will return error if program exceeds them) • Can specify ending address for segment (useful for stacks) • Can group similar segments (CODE, DATA etc.) Initialized Data and Constant Strings • Initialized data introduces a problem in embedded systems • Consider following code #define FREQ_DEFAULT 44100 . . static int Freq = FREQ_DEFAULT; void SetFreq (int NewFreq) { Freq = NewFreq; }

Linker/Locators for Embedded Software (contd.) • Initial value of variable Freq should be in ROM however its value is changed by function SetFreq so it should be in RAM • Solution – store variable in RAM, initial value in ROM, copy the value at startup. • Works fine if there is a loader, however embedded systems don’t have one • Locator might automatically insert code into program to do the copying, but it still might need some tweaking • Many locators create a “shadow” segment in ROM containing all initial values • This is copied to initialized-data segment at startup • Another problem – constant strings • Consider following code char *sMsg = “Reactor is melting!”; • If sMsg is not changed but is only printed onto the screen it can be stored in ROM, however if it is changed it needs to be in RAM • Problem handled in several ways and depends on the cross-compiler Locator Maps • Locators normally create an output file called a map (fig. 9.7) • Shows location of each segment in memory • Useful for debugging

Linker/Locators for Embedded Software (contd.) Executing Out of RAM • RAM typically faster than ROM • Code as a result copied to RAM during startup • Start-up code runs directly from ROM (hence slow) copies remaining code to RAM and jumps to an entry point in the RAM • Code sometimes needed to be decompressed before copying to RAM • Entire process places new requirement on locator as it must execute both from ROM and later from the RAM

Getting Embedded Software into the Target System Several ways to transfer software to target PROM Programmers • Classic way – use output file to build a ROM or PROM (if software still needs some changes) • Drawback – tooling cost to build ROM quite high • Use PROM instead of ROM only if – changes still required in software, production volumes not high enough or if debugging still left • Better to keep PROM in a socket instead of soldering directly to circuit (PROM can then be reprogrammed or replaced if needed) • PROM programmer should be compatible with the locator output file format. ROM Emulators • ROM emulators replace (emulate) ROM in the target system. • Looks like a ROM with a serial port or network connection to talk to host • Will behave just like ROM that has been programmed with user code In-Circuit Emulators • Use overlay-memory to get software to target • Discussed in Chapter 10

Getting Embedded Software into the Target System (contd.) Flash • Can be programmed by most PROM programmers and can be treated just like an EPROM. • If network or serial communication possible, software can be directly downloaded to flash. No need to remove chip • Advantages • Software loaded without removing chip – no risk of bending pins, damaging chip etc. • Faster • Allows new versions of software to be loaded in-field • Some issues • Flash-programming software needs to be copied in RAM (can’t fetch instructions from flash while it’s being programmed). Changed address on RAM from the original address location in flash memory needs to be resolved by locator • Programming start-up software should never get corrupted. Should be able to program even if it crashed earlier • Normally resolved by downloading start-up software directly from host to RAM and then copying to flash • Feasible to have flash-programming software in a separate independent segment, all stored in one block of addresses within flash

Getting Embedded Software into the Target System (contd.) • When debugging flash-programming software use one of the other methods for downloading it to target Monitors • They are programs on target ROM that know how to load new programs to the system. • Stores the user software sent from a host through a communications link (serial) to target RAM and runs it • Might also perform some locator and debugger functions (setting breakpoints, checking register values) etc. also • Available from several RTOS vendors • Only useful when attached to the host (communication link present)

An Embedded Software Primer