Comtrol eCos - Manual (Page 752)

Installation
Toolchain
When developing eCos applications for a normal embedded target it is necessary to use a suitable cross-compiler
and related tools such as the linker. Developing for the synthetic target is easier because you can just use the
standard GNU tools (gcc, g++, ld, . . . ) which were provided with your Linux distribution, or which you used to
build your own Linux setup. Any reasonably recent version of the tools, for example gcc 2.96(Red Hat) as shipped
with Red Hat Linux 7, should be sufficient.
There is one important limitation when using these tools: current gdb will not support debugging of eCos threads
on the synthetic target. As far as gdb is concerned a synthetic target application is indistinguishable from a normal
Linux application, so it assumes that any threads will be created by calls to the Linux
pthread_create function
provided by the C library. Obviously this is not the case since the application is never linked with that library.
Therefore gdb never notices the eCos thread mechanisms and assumes the application is single-threaded. Fixing
this is possible but would involve non-trivial changes to gdb.
Theoretically it is possible to develop synthetic target applications on, for example, a PC running Windows and
then run the resulting executables on another machine that runs Linux. This is rarely useful: if a Linux machine is
available then usually that machine will also be used for building ecos and the application. However, if for some
reason it is necessary or desirable to build on another machine then this requires a suitable cross-compiler and
related tools. If the application will be running on a typical PC with an x86 processor then a suitable configure triplet
would be
i686-pc-linux-gnu . The installation instructions for the various GNU tools should be consulted
for further information.
Hardware Preparation
Preparing a real embedded target for eCos development can be tricky. Often the first step is to install suitable
firmware, usually RedBoot. This means creating and building a special configuration for eCos with the RedBoot
template, then somehow updating the target’s flash chips with the resulting RedBoot image. Typically it will also
be necessary to get a working serial connection, and possibly set up ethernet as well. Although usually none of
the individual steps are particularly complicated, there are plenty of ways in which things can go wrong and it
can be hard to figure out what is actually happening. Of course some board manufacturers make life easier for
their developers by shipping hardware with RedBoot preinstalled, but even then it is still necessary to set up
communication between host and target.
None of this is applicable to the synthetic target. Instead you can just build a normal eCos configuration, link your
application with the resulting libraries, and you end up with an executable that you can run directly on your Linux
machine or via gdb. A useful side effect of this is that application development can start before any real embedded
hardware is actually available.
Typically the memory map for a synthetic target application will be set up such that there is a read-only ROM
region containing all the code and constant data, and a read-write RAM region for the data. The default locations
and sizes of these regions depend on the specific platform being used for development. Note that the application
always executes out of ROM: on a real embedded target much of the development would involve running RedBoot
firmware there, with application code and data loaded into RAM; usually this would change for the final system; the
firmware would be replaced by the eCos application itself, configured for ROM bootstrap, and it would perform
the appropriate hardware initialization. Therefore the synthetic target actually emulates the behaviour of a final
system, not of a development environment. In practice this is rarely significant, although having the code in read-
only memory can help catch some problems in application code.
648