URL
https://opencores.org/ocsvn/openrisc/openrisc/trunk
Subversion Repositories openrisc
[/] [openrisc/] [trunk/] [rtos/] [ecos-2.0/] [doc/] [html/] [ref/] [synth-running.html] - Rev 510
Go to most recent revision | Compare with Previous | Blame | View Log
<!-- Copyright (C) 2003 Red Hat, Inc. -->
<!-- This material may be distributed only subject to the terms -->
<!-- and conditions set forth in the Open Publication License, v1.0 -->
<!-- or later (the latest version is presently available at -->
<!-- http://www.opencontent.org/openpub/). -->
<!-- Distribution of the work or derivative of the work in any -->
<!-- standard (paper) book form is prohibited unless prior -->
<!-- permission is obtained from the copyright holder. -->
<HTML
><HEAD
><TITLE
>Running a Synthetic Target Application</TITLE
><meta name="MSSmartTagsPreventParsing" content="TRUE">
<META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.76b+
"><LINK
REL="HOME"
TITLE="eCos Reference Manual"
HREF="ecos-ref.html"><LINK
REL="UP"
TITLE="eCos Synthetic Target"
HREF="hal-synth-arch.html"><LINK
REL="PREVIOUS"
TITLE="Installation"
HREF="synth-install.html"><LINK
REL="NEXT"
TITLE="The I/O Auxiliary's User Interface"
HREF="synth-gui.html"></HEAD
><BODY
CLASS="REFENTRY"
BGCOLOR="#FFFFFF"
TEXT="#000000"
LINK="#0000FF"
VLINK="#840084"
ALINK="#0000FF"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="3"
ALIGN="center"
>eCos Reference Manual</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="bottom"
><A
HREF="synth-install.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="80%"
ALIGN="center"
VALIGN="bottom"
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="bottom"
><A
HREF="synth-gui.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><H1
><A
NAME="SYNTH-RUNNING">Running a Synthetic Target Application</H1
><DIV
CLASS="REFNAMEDIV"
><A
NAME="AEN17751"
></A
><H2
>Name</H2
>Execution -- Arguments and configuration files</DIV
><DIV
CLASS="REFSECT1"
><A
NAME="SYNTH-RUNNING-DESCRIPTION"
></A
><H2
>Description</H2
><P
>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,
</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>$ ecos_hello <options></PRE
></TD
></TR
></TABLE
><P
>or using gdb:
</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>$ gdb --nw --quiet --args ecos_hello <options>
(gdb) run
Starting program: ecos_hello <options></PRE
></TD
></TR
></TABLE
><P
>By default use of the I/O auxiliary is disabled. If its I/O facilities
are required then the option <TT
CLASS="OPTION"
>--io</TT
> must be used.
</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
>In future the default behaviour may change, with the I/O auxiliary
being started by default. The option <TT
CLASS="OPTION"
>--nio</TT
> can be
used to prevent the auxiliary from being run.
</P
></BLOCKQUOTE
></DIV
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="SYNTH-RUNNING-ARGUMENTS"
></A
><H2
>Command-line Arguments</H2
><P
>The syntax for running a synthetic target application is:
</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>$ <ecos_app> [options] [-- [app_options]]</PRE
></TD
></TR
></TABLE
><P
>Command line options up to the <TT
CLASS="OPTION"
>--</TT
> 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
<TT
CLASS="VARNAME"
>cyg_hal_sys_argc</TT
> and
<TT
CLASS="VARNAME"
>cyg_hal_sys_argv</TT
>.
</P
><P
>The following options are accepted as standard:
</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><TT
CLASS="OPTION"
>--io</TT
></DT
><DD
><P
>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.
</P
></DD
><DT
><TT
CLASS="OPTION"
>--nio</TT
></DT
><DD
><P
>This option prevents the eCos application from spawning the I/O
auxiliary. In the current version of the software this is the default.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-nw</TT
>, <TT
CLASS="OPTION"
>--no-windows</TT
></DT
><DD
><P
>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 <TT
CLASS="OPTION"
>-nw</TT
>.
Emulation of some devices, for example buttons connected to digital
inputs, requires the graphical interface.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-w</TT
>, <TT
CLASS="OPTION"
>--windows</TT
></DT
><DD
><P
>The <TT
CLASS="OPTION"
>-w</TT
> causes the I/O auxiliary to provide a
graphical user interface. This is the default.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-v</TT
>, <TT
CLASS="OPTION"
>--version</TT
></DT
><DD
><P
>The <TT
CLASS="OPTION"
>-v</TT
> 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.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-h</TT
>, <TT
CLASS="OPTION"
>--help</TT
></DT
><DD
><P
><TT
CLASS="OPTION"
>-h</TT
> 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
<TT
CLASS="OPTION"
>-nw</TT
>.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-k</TT
>, <TT
CLASS="OPTION"
>--keep-going</TT
></DT
><DD
><P
>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 <TT
CLASS="OPTION"
>-k</TT
>
option can be used to make the auxiliary continue in spite of errors,
although obviously it may not be fully functional.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-nr</TT
>, <TT
CLASS="OPTION"
>--no-rc</TT
></DT
><DD
><P
>Normally the auxiliary processes two <A
HREF="synth-running.html#SYNTH-RUNNING-USER-CONFIG"
>user configuration files</A
>
during startup: <TT
CLASS="FILENAME"
>initrc.tcl</TT
> and
<TT
CLASS="FILENAME"
>mainrc.tcl</TT
>. This can be suppressed using the
<TT
CLASS="OPTION"
>-nr</TT
> option.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-x</TT
>, <TT
CLASS="OPTION"
>--exit</TT
></DT
><DD
><P
>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 <TT
CLASS="OPTION"
>-x</TT
> then
the auxiliary will exit as soon the application exits.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-nx</TT
>, <TT
CLASS="OPTION"
>--no-exit</TT
></DT
><DD
><P
>When the graphical user interface is disabled with
<TT
CLASS="OPTION"
>-nw</TT
> 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
<TT
CLASS="OPTION"
>-nx</TT
> option causes the auxiliary to continue running
even after the application has exited.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-V</TT
>, <TT
CLASS="OPTION"
>--verbose</TT
></DT
><DD
><P
>This option causes the I/O auxiliary to output some additional
information, especially during initialization.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-l <file></TT
>, <TT
CLASS="OPTION"
>--logfile <file></TT
></DT
><DD
><P
>Much of the output of the eCos application and the I/O auxiliary is
simple text, for example resulting from eCos
<TT
CLASS="FUNCTION"
>printf</TT
> or <TT
CLASS="FUNCTION"
>diag_printf</TT
> 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
<TT
CLASS="OPTION"
>-l</TT
> 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 <TT
CLASS="OPTION"
>-l</TT
> 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.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-t <file></TT
>, <TT
CLASS="OPTION"
>--target <file></TT
></DT
><DD
><P
>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 <TT
CLASS="OPTION"
>-t</TT
>
option can be used to specify which target definition should be used
for the current run, defaulting to <TT
CLASS="FILENAME"
>default.tdf</TT
>.
It is not necessary to include the <TT
CLASS="FILENAME"
>.tdf</TT
> suffix,
this will be appended automatically if necessary.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-geometry <geometry></TT
></DT
><DD
><P
>This option can be used to control the size and position of the main
window, as per X conventions.
</P
></DD
></DL
></DIV
><P
>The I/O auxiliary loads support for the various devices dynamically
and some devices may accept additional command line arguments. Details
of these can be obtained using the <TT
CLASS="OPTION"
>-h</TT
> option or by
consulting the device-specific documentation. If an unrecognised
command line argument is used then a warning will be issued.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="SYNTH-RUNNING-TDF"
></A
><H2
>The Target Definition File</H2
><P
>The eCos application will want to access devices such as
<TT
CLASS="VARNAME"
>eth0</TT
> or <TT
CLASS="VARNAME"
>/dev/ser0</TT
>. These need to
be mapped on to Linux devices. For example some users may all traffic
on the eCos <TT
CLASS="VARNAME"
>/dev/ser0</TT
> serial device to go via the
Linux serial device <TT
CLASS="VARNAME"
>/dev/ttyS1</TT
>, while ethernet I/O
for the eCos <TT
CLASS="VARNAME"
>eth0</TT
> device should be mapped to the
Linux ethertap device <TT
CLASS="VARNAME"
>tap3</TT
>. Some devices may need
additional configuration information, for example to limit the
number of packets that should be buffered within the I/O auxiliary.
The target definition file provides all this information.
</P
><P
>By default the I/O auxiliary will look for a file
<TT
CLASS="FILENAME"
>default.tdf</TT
>. An alternative target definition can
be specified on the command line using <TT
CLASS="OPTION"
>-t</TT
>, for
example:
</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="SCREEN"
>$ bridge_app --io -t twineth</PRE
></TD
></TR
></TABLE
><P
>A <TT
CLASS="FILENAME"
>.tdf</TT
> suffix will be appended automatically if
necessary. If a relative pathname is used then the I/O auxiliary will
search for the target definition file in the current directory, then
in <TT
CLASS="FILENAME"
>~/.ecos/synth/</TT
>, and finally
in its install location.
</P
><P
>A typical target definition file might look like this:
</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>synth_device console {
# appearance -foreground white -background black
filter trace {^TRACE:.*} -foreground HotPink1 -hide 1
}
synth_device ethernet {
eth0 real eth1
eth1 ethertap tap4 00:01:02:03:FE:06
## Maximum number of packets that should be buffered per interface.
## Default 16
#max_buffer 32
## Filters for the various recognised protocols.
## By default all filters are visible and use standard colours.
filter ether -hide 0
#filter arp -hide 1
#filter ipv4 -hide 1
#filter ipv6 -hide 1
}</PRE
></TD
></TR
></TABLE
><P
>A target definition file is actually a Tcl script that gets run in the
main interpreter of the I/O auxiliary during initialization. This
provides a lot of flexibility if necessary. For example the script
could open a socket to a resource management server of some sort to
determine which hardware facilities are already in use and adapt
accordingly. Another possibility is to adapt based on <A
HREF="synth-new-host.html#SYNTH-NEW-HOST-ARGS"
>command line arguments</A
>. Users who
are not familiar with Tcl programming should still be able to edit a
simple target definition file without too much difficulty, using a
mixture of cut'n'paste, commenting or uncommenting various lines, and
making small edits such as changing <TT
CLASS="LITERAL"
>tap4</TT
> to
<TT
CLASS="LITERAL"
>eth2</TT
>.
</P
><P
>Each type of device will have its own entry in the target definition
file, taking the form:
</P
><TABLE
BORDER="5"
BGCOLOR="#E0E0F0"
WIDTH="70%"
><TR
><TD
><PRE
CLASS="PROGRAMLISTING"
>synth_device <device type> {
<options>
}</PRE
></TD
></TR
></TABLE
><P
>The documentaton for each synthetic target device should provide
details of the options available for that device, and often a suitable
fragment that can be pasted into a target definition file and edited.
There is no specific set of options that a given device will always
provide. However in practice many devices will use common code
exported by the main I/O auxiliary, or their implementation will
involve some re-use of code for an existing device. Hence certain
types of option are common to many devices.
</P
><P
>A good example of this is filters, which control the appearance of
text output. The above target definition file defines a filter
<TT
CLASS="VARNAME"
>trace</TT
> for output from the eCos application. The
regular expression will match output from the infrastructure package's
tracing facilities when <TT
CLASS="VARNAME"
>CYGDBG_USE_TRACING</TT
> and
<TT
CLASS="VARNAME"
>CYGDBG_INFRA_DEBUG_TRACE_ASSERT_SIMPLE</TT
> are enabled.
With the current settings this output will not be visible by default,
but can be made visible using the menu item <SPAN
CLASS="GUIMENUITEM"
>System
Filters</SPAN
>. If made visible the trace output will appear in
an unusual colour, so users can easily distinguish the trace output
from other text. All filters accept the following options:
</P
><P
></P
><DIV
CLASS="VARIABLELIST"
><DL
><DT
><TT
CLASS="OPTION"
>-hide [0|1]</TT
></DT
><DD
><P
>This controls whether or not text matching this filter should be
invisible by default or not. At run-time the visibility of each filter
can be controlled using the <SPAN
CLASS="GUIMENUITEM"
>System Filters</SPAN
>
menu item.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-foreground <colour></TT
></DT
><DD
><P
>This specifies the foreground colour for all text matching this
filter. The colour can be specified using an RGB value such as
<TT
CLASS="LITERAL"
>#F08010</TT
>, or a symbolic name such as
<TT
CLASS="LITERAL"
>"light steel blue"</TT
>. The X11 utility
<SPAN
CLASS="APPLICATION"
>showrgb</SPAN
> can be used to find out
about the available colours.
</P
></DD
><DT
><TT
CLASS="OPTION"
>-background <colour></TT
></DT
><DD
><P
>This specifies the background colour for all text matching the filter.
As with <TT
CLASS="OPTION"
>-foreground</TT
> the colour can be specified using
a symbolic name or an RGB value.
</P
></DD
></DL
></DIV
><P
>Some devices may create their own subwindows, for example to monitor
ethernet traffic or to provide additional I/O facilities such as
emulated LED's or buttons. Usually the target definition file can be
used to control the <A
HREF="synth-gui.html#SYNTH-GUI-LAYOUT"
>layout</A
> of
these windows.
</P
><P
>The I/O auxiliary will not normally warn about
<B
CLASS="COMMAND"
>synth_device</B
> entries in the target definition file
for devices that are not actually needed by the current eCos
application. This makes it easier to use a single file for several
different applications. However it can lead to confusion if an entry
is spelled incorrectly and hence does not actually get used. The
<TT
CLASS="OPTION"
>-V</TT
> command line option can be used to get warnings
about unused device entries in the target definition file.
</P
><P
>If the body of a <B
CLASS="COMMAND"
>synth_device</B
> command contains an
unrecognised option and the relevant device is in use, the I/O
auxiliary will always issue a warning about such options.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="SYNTH-RUNNING-USER-CONFIG"
></A
><H2
>User Configuration Files</H2
><P
>During initialization the I/O auxiliary will execute two user
configuration files, <TT
CLASS="FILENAME"
>initrc.tcl</TT
> and
<TT
CLASS="FILENAME"
>mainrc.tcl</TT
>. It will look for these files in the
directory <TT
CLASS="FILENAME"
>~/.ecos/synth/</TT
>. If
that directory does not yet exist it will be created and populated
with initial dummy files.
</P
><P
>Both of these configuration files are Tcl scripts and will be run in
the main interpreter used by the I/O auxiliary itself. This means that
they have full access to the internals of the auxiliary including the
various Tk widgets, and they can perform file or socket I/O if
desired. The section <A
HREF="synth-new-host.html"
>Writing New Devices - host</A
> contains
information about the facilities available on the host-side for
writing new device drivers, and these can also be used in the
initialization scripts.
</P
><P
>The <TT
CLASS="FILENAME"
>initrc.tcl</TT
> script is run before the auxiliary
has processed any requests from the eCos application, and hence before
any devices have been instantiated. At this point the generic
command-line arguments has been processed, the target definition file
has been read in, and the hooks functionality has been initialized. If
running in graphical mode the main window will have been created, but
has been withdrawn from the screen to allow new widgets to be added
without annoying screen flicker. A typical
<TT
CLASS="FILENAME"
>initrc.tcl</TT
> script could add some menu or toolbar
options, or install a hook function that will be run when the
eCos application exits.
</P
><P
>The <TT
CLASS="FILENAME"
>mainrc.tcl</TT
> script is run after eCos has
performed all its device initialization and after C++ static
constructors have run, and just before the call to
<TT
CLASS="FUNCTION"
>cyg_start</TT
> which will end up transferring control
to the application itself. A typical <TT
CLASS="FILENAME"
>mainrc.tcl</TT
>
script could look at what interrupt vectors have been allocated to
which devices and create a little monitor window that shows interrupt
activity.
</P
></DIV
><DIV
CLASS="REFSECT1"
><A
NAME="SYNTH-RUNNING-SESSION"
></A
><H2
>Session Information</H2
><P
>When running in graphical mode, the I/O auxiliary will read in a file
<TT
CLASS="FILENAME"
>~/.ecos/synth/guisession</TT
> containing session
information. This file should not normally be edited manually, instead
it gets updated automatically when the auxiliary exits. The purpose of
this file is to hold configuration options that are manipulated via
the graphical interface, for example which browser should be used to
display online help.
</P
><DIV
CLASS="WARNING"
><P
></P
><TABLE
CLASS="WARNING"
BORDER="1"
WIDTH="100%"
><TR
><TD
ALIGN="CENTER"
><B
>Warning</B
></TD
></TR
><TR
><TD
ALIGN="LEFT"
><P
>GUI session functionality is not yet available in the current release.
When that functionality is fully implemented it is possible that some
target definition file options may be removed, to be replaced by
graphical editing via a suitable preferences dialog, with the
current settings saved in the session file.
</P
></TD
></TR
></TABLE
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="synth-install.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="ecos-ref.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="synth-gui.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Installation</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="hal-synth-arch.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>The I/O Auxiliary's User Interface</TD
></TR
></TABLE
></DIV
></BODY
></HTML
> Go to most recent revision | Compare with Previous | Blame | View Log