Comtrol eCos - Manual (Page 780)

Writing New Devices - host
...
}
synth::tdf_get_option returns a list of all the arguments for a given option. For example, if the target definition
file contains an entry:
synth_device console {
appearance -foreground white -background black
filter trace {^TRACE:.*} -foreground HotPink1 -hide 1
filter xyzzy {.*xyzzy.*} -foreground PapayaWhip
}
A call synth::tdf_get_option console appearance will return the list {-foreground white -background
black} . This list can be manipulated using standard Tcl routines such as llength and lindex. Some options can
occur multiple times in one entry, for example filter in the console entry. synth::tdf_get_options returns a
list of lists, with one entry for each option occurrence. synth::tdf_get_all_options returns a list of lists of all
options. This time each entry will include the option name as well.
The I/O auxiliary will not issue warnings about entries in the target definition file for devices which were not
loaded, unless the
-v or --verbose command line argument was used. This makes it easier to use a single target
definition file for different applications. However the auxiliary will issue warnings about options within an entry
that were ignored, because often these indicate a typing mistake of some sort. Hence a script should always call
synth::tdf_has_option, synth:;tdf_get_option or synth::tdf_get_options for all valid options, even if some of
the options preclude the use of others.
Hooks
Some scripts may want to take action when particular events occur, for example when the eCos application has
exited and there is no need for further I/O. This is supported using hooks:
namespace eval my_device {
...
proc handle_ecos_exit { arg_list } {
...
}
synth::hook_add "ecos_exit" my_device::handle_ecos_exit
}
It is possible for device scripts to add their own hooks and call all functions registered for those hooks. A typical
use for this is by user initialization scripts that want to monitor some types of I/O. The available Tcl procedures for
manipulating hooks are:
synth::hook_define < name >
synth::hook_defined < name >
synth::hook_add < name > < function >
synth::hook_call < name > < args >
synth::hook_define creates a new hook with the specified name. This hook must not already exist.
synth::hook_defined can be used to check for the existence of a hook. synth::hook_add allows other scripts
to register a callback function for this hook, and synth::hook_call allows the owner script to invoke all such
callback functions. A hook must already be defined before a callback can be attached. Therefore typically device
scripts will only use standard hooks and their own hooks, not hooks created by some other device, because the
676