![if !IE]> <![endif]>
The role of the development system
An alternative environment for developing software for embedded systems is to use the final operating system as the development environment either on the target system itself or on a similar system. This used to be the traditional way of developing software before the advent of cheap PCs and workstations and integrated cross-compilation.
It still offers distinct advantages over the cross-compila-tion system. Run-time library support is integrated because the compilers are producing native code. Therefore the run-time libraries that produce executable code on the development system will run unmodified on the target system. The final software can even be tested on the development system before moving it to the target. In addition, the full range of functions and tools can be used to debug the software during this testing phase, which may not be available on the final target. For example, if a target simply used the operating system kernel, it would not have the file system and terminal drivers needed to support an onscreen debugger or help download code quickly from disk to memory. Yet a development system running the full version of the operating system could offer this and other features, such as downloading over a network. However, there are some important points to remember.
Floating point and memory management functions
Floating point co-processors and memory management units should be considered as part of the processor environ-ment and need to be considered when creating code on the target. For example, the development system may have a floating point unit and memory management, while the target does not. Code created on the development system may not run on the target because of these differences. Executing float-ing point instructions would cause a processor exception while the location of code and data in the memory may not be compatible.
This means that code created for the development sys-tem may need recompiling and linking to ensure that the correct run-time routines are used for the target and that they are located correctly. This in turn may mean that the target versions may not run on the development system because its resources do not match up. This raises the question of the validity of using a development system in the first place. The answer is that the source code and the bulk of the binary code does not need modifying. Calling up a floating point emulation library instead of using floating point instructions will not affect any integer or I/O routines. Linking modules to a differ-ent address changes the addresses, not the instructions and so the two versions are still extremely similar. If the code works on the development system, it is likely that it will work on the target system.
While the cross-compilation system is probably the most popular method used today to develop software for embedded systems — due to the widespread availability of PCs and workstations and the improving quality of software tools — it is not the only way. Dedicated development systems can offer faster and easier software creation because of the closer rela-tionship between the development environment and the end target.
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.