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.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.