To get the full functionality of the synthetic target, users must build and install the I/O auxiliary ecosynth and various support files. It is possible to develop applications for the synthetic target without the auxiliary, but only limited I/O facilities will be available. The relevant code resides in the host subdirectory of the synthetic target architectural HAL package, and building it involves the standard configure, make, and make install steps.
There are two main ways of building the host-side software. It is possible to build both the generic host-side software and all package-specific host-side software, including the I/O auxiliary. in a single build tree. This involves using the configure script at the toplevel of the eCos repository, which will automatically search the packages hierarchy for host-side software. For more information on this, see the README.host file at the top of the repository. Note that if you have an existing build tree which does not include the synthetic target architectural HAL package then it will be necessary to rerun the toplevel configure script: the search for appropriate packages happens at configure time.
The alternative is to build just the host-side for this package. This involves creating a suitable build directory and running the configure script. Note that building directly in the source tree is not allowed.
$ cd <somewhere suitable> $ mkdir synth_build $ cd synth_build $ <repo<>/packages/hal/synth/arch/<version>/host/configure <options> $ make $ make install |
The code makes extensive use of Tcl/TK and requires version 8.3 or
later. This is checked by the configure script. By
default it will use the system's Tcl installation in /usr. If a different, more recent Tcl
installation should be used then its location can be specified using
the options --with-tcl=<path>,
--with-tcl-header=<path> and
--with-tcl-lib=<path>. For more information on these options
see the README.host file at the toplevel of the
eCos repository.
Some users may also want to specify the install location using a
--prefix=<path> option. The default install
location is /usr/local. It is
essential that the bin
subdirectory of the install location is on the user's search
PATH, otherwise the eCos application will be unable to
locate and execute the I/O auxiliary ecosynth.
Because ecosynth is run automatically by an eCos application rather
than explicitly by the user, it is not installed in the bin subdirectory itself. Instead it is
installed below libexec,
together with various support files such as images. At configure time
it is usually possible to specify an alternative location for
libexec using
--exec-prefix=<path> or
--libexecdir=<path>. These options should not
be used for this package because the eCos application is built
completely separately and does not know how the host-side was
configured.
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.
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.