synth.sgml

eCos操作系统源码

subdirectory of the install location is on the user's search
<envar>PATH</envar>, otherwise the eCos application will be unable to
locate and execute the I/O auxiliary ecosynth.
    </para>
    <para>
Because ecosynth is run automatically by an eCos application rather
than explicitly by the user, it is not installed in the <filename
class="directory">bin</filename> subdirectory itself. Instead it is
installed below <filename class="directory">libexec</filename>,
together with various support files such as images. At configure time
it is usually possible to specify an alternative location for
<filename class="directory">libexec</filename> using
<option>--exec-prefix=&lt;path&gt;</option> or
<option>--libexecdir=&lt;path&gt;</option>. 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. 
    </para>
  </refsect1>

  <refsect1 id="synth-tools"><title>Toolchain</title>
    <para>
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, &hellip;) 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.
    </para>
    <para>
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
<function>pthread_create</function> 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.
    </para>
    <para>
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
<userinput>i686-pc-linux-gnu</userinput>. The installation
instructions for the various GNU tools should be consulted for further
information. 
    </para>
  </refsect1>

  <refsect1 id="synth-hardware"><title>Hardware Preparation</title>
    <para>
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.
    </para>
    <para>
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.
    </para>
    <para>
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.
    </para>
  </refsect1>

</refentry>

<!-- }}} -->
<!-- {{{ Running the application        -->

<refentry id="synth-running">
  <refmeta>
    <refentrytitle>Running a Synthetic Target Application</refentrytitle>
  </refmeta>
  <refnamediv>
    <refname>Execution</refname>
    <refpurpose>Arguments and configuration files</refpurpose>
  </refnamediv>

  <refsect1 id="synth-running-description"><title>Description</title>
    <para>
The procedure for configuring and building eCos and an application for
the synthetic target is the same as for any other eCos target. Once an
executable has been built it can be run like any Linux program, for
example from a shell prompt,
    </para>
    <screen>
$ ecos_hello &lt;options&gt;
</screen>
    <para>
or using gdb:
    </para>
    <screen>
$ gdb --nw --quiet --args ecos_hello &lt;options&gt;
(gdb) run
Starting program: ecos_hello &lt;options&gt;
</screen>
    <para>
By default use of the I/O auxiliary is disabled. If its I/O facilities
are required then the option <option>--io</option> must be used.
    </para>
    <note><para>
In future the default behaviour may change, with the I/O auxiliary
being started by default. The option <option>--nio</option> can be
used to prevent the auxiliary from being run.
    </para></note>
  </refsect1>

  <refsect1 id="synth-running-arguments"><title>Command-line Arguments</title>
    <para>
The syntax for running a synthetic target application is:
    </para>
    <screen>
$ &lt;ecos_app&gt; [options] [-- [app_options]]
</screen>
    <para>
Command line options up to the <option>--</option> are passed on to
the I/O auxiliary. Subsequent arguments are not passed on to the
auxiliary, and hence can be used by the eCos application itself. The
full set of arguments can be accessed through the variables
<varname>cyg_hal_sys_argc</varname> and
<varname>cyg_hal_sys_argv</varname>. 
    </para>
    <para>
The following options are accepted as standard:
    </para>
    <variablelist>
      <varlistentry>
        <term><option>--io</option></term>
         <listitem><para>
This option causes the eCos application to spawn the I/O auxiliary
during HAL initialization. Without this option only limited I/O will
be available.
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>--nio</option></term>
         <listitem><para>
This option prevents the eCos application from spawning the I/O
auxiliary. In the current version of the software this is the default.
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-nw</option>, <option>--no-windows</option></term>
         <listitem><para>
The I/O auxiliary can either provide a graphical user interface, or it
can run in a text-only mode. The default is to provide the graphical
interface, but this can be disabled with <option>-nw</option>.
Emulation of some devices, for example buttons connected to digital
inputs, requires the graphical interface.
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-w</option>, <option>--windows</option></term>
         <listitem><para>
The <option>-w</option> causes the I/O auxiliary to provide a
graphical user interface. This is the default.
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-v</option>, <option>--version</option></term>
         <listitem><para>
The <option>-v</option> option can be used to determine the version of
the I/O auxiliary being used and where it has been installed. Both the
auxiliary and the eCos application will exit immediately.
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-h</option>, <option>--help</option></term>
         <listitem><para>
<option>-h</option> causes the I/O auxiliary to list all accepted
command-line arguments. This happens after all devices have been
initialized, since the host-side support for some of the devices may
extend the list of recognised options. After this both the auxiliary
and the eCos application will exit immediately. This option implies
<option>-nw</option>. 
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-k</option>, <option>--keep-going</option></term>
         <listitem><para>
If an error occurs in the I/O auxiliary while reading in any of the
configuration files or initializing devices, by default both the 
auxiliary and the eCos application will exit. The <option>-k</option>
option can be used to make the auxiliary continue in spite of errors,
although obviously it may not be fully functional.
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-nr</option>, <option>--no-rc</option></term>
         <listitem><para>
Normally the auxiliary processes two <link
linkend="synth-running-user-config">user configuration files</link>
during startup: <filename>initrc.tcl</filename> and
<filename>mainrc.tcl</filename>. This can be suppressed using the
<option>-nr</option> option.
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-x</option>, <option>--exit</option></term>
         <listitem><para>
When providing a graphical user interface the I/O auxiliary will
normally continue running even after the eCos application has exited.
This allows the user to take actions such as saving the current
contents of the main text window. If run with <option>-x</option> then
the auxiliary will exit as soon the application exits.
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-nx</option>, <option>--no-exit</option></term>
         <listitem><para>
When the graphical user interface is disabled with
<option>-nw</option> the I/O auxiliary will normally exit immediately
when the eCos application exits. Without the graphical frontend there
is usually no way for the user to interact directly with the
auxiliary, so there is no point in continuing to run once the eCos
application will no longer request any I/O operations. Specifying the
<option>-nx</option> option causes the auxiliary to continue running
even after the application has exited.
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-V</option>, <option>--verbose</option></term>
         <listitem><para>
This option causes the I/O auxiliary to output some additional
information, especially during initialization.
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-l &lt;file&gt;</option>, <option>--logfile &lt;file&gt;</option></term>
         <listitem><para>
Much of the output of the eCos application and the I/O auxiliary is
simple text, for example resulting from eCos
<function>printf</function> or <function>diag_printf</function> calls.
When running in graphical mode this output goes to a central text
window, and can be saved to a file or edited via menus. The
<option>-l</option> can be used to automatically generate an
additional logfile containing all the text. If graphical
mode is disabled then by default all the text just goes to the current
standard output. Specifying <option>-l</option> causes most of the
text to go into a logfile instead, although some messages such as
errors generated by the auxiliary itself will still go to stdout as
well. 
         </para></listitem>
      </varlistentry>
      <varlistentry>
        <term><option>-t &lt;file&gt;</option>, <option>--target &lt;file&gt;</option></term>
         <listitem><para>
During initialization the I/O auxiliary reads in a target definition
file. This file holds information such as which Linux devices should
be used to emulate the various eCos devices. The <option>-t</option>
option can be used to specify which target definition should be used
for the current run, defaulting to <filename>default.tdf</filename>.