Comtrol eCos - Manual (Page 775)

Writing New Devices - host
Name
Writing New Devices — extending the synthetic target, host-side
Description
On the host-side adding a new device means writing a Tcl/Tk script that will handle instantiation and subsequent
requests from the target-side. These scripts all run in the same full interpreter, extended with various commands
provided by the main I/O auxiliary code, and running in an overall GUI framework. Some knowledge of program-
ming with Tcl/Tk is required to implement host-side device support.
Some devices can be implemented entirely using a Tcl/Tk script. For example, if the final system will have some
buttons then those can be emulated in the synthetic target using a few Tk widgets. A simple emulation could just
have the right number of buttons in a row. A more advanced emulation could organize the buttons with the right
layout, perhaps even matching the colour scheme, the shapes, and the relative sizes. With other devices it may be
necessary for the Tcl script to interact with an external program, because the required functionality cannot easily be
accessed from a Tcl script. For example interacting with a raw ethernet device involves some
ioctl calls, which is
easier to do in a C program. Therefore the ethernet.tcl script which implements the host-side ethernet support
spawns a separate program rawether , written in C, that performs the low-level I/O. Raw ethernet access usually
also requires root privileges, and running a small program rawether with such privileges is somewhat less of a
security risk than the whole eCos application, the I/O auxiliary, and various dynamically loaded Tcl scripts.
Because all scripts run in a single interpreter, some care has to be taken to avoid accidental sharing of global
variables. The best way to avoid problems is to have each script create its own Tcl namespace, so for example the
ethernet.tcl script creates a namespace ethernet:: and all variables and procedures reside in this namespace.
Similarly the I/O auxiliary itself makes use of a synth:: namespace.
Building and Installation
When an eCos device driver or application code instantiates a device, the I/O auxiliary will attempt to load a
matching Tcl script. The third argument to
synth_auxiliary_instantiate specifies the type of device, for
example ethernet , and the I/O auxiliary will append a .tcl suffix and look for a script ethernet.tcl .
If the device being instantiated is application-specific rather than part of an eCos package, the I/O auxiliary will
look first in the current directory, then in
~/.ecos/synth . If it is part of an eCos package then the auxiliary will
expect to find the Tcl script and any support files below libexec/ecos in the install tree - note that the same
install tree must be used for the I/O auxiliary itself and for any device driver support. The directory hierarchy
below
libexec/ecos matches the structure of the eCos repository, allowing multiple versions of a package to be
installed to allow for incompatible protocol changes.
The preferred way to build host-side software is to use autoconf and automake. Usually this involves little more
than copying the
acinclude.m4 , configure.in and Makefile.am files from an existing package, for example
the synthetic target ethernet driver, and then making minor edits. In acinclude.m4 it may be necessary to ad-
just the path to the root of the repository. configure.in may require a similar change, and the AC_INIT macro
invocation will have to be changed to match one of the files in the new package. A critical macro in this file
is
ECOS_PACKAGE_DIRS which will set up the correct install directory. Makefile.am may require some more
changes, for example to specify the data files that should be installed (including the Tcl script). These files should
671