Comtrol eCos - Manual (Page 782)

Writing New Devices - host
Output and Filters
Scripts can use conventional facilities for sending text output to the user, for example calling puts or directly
manipulating the central text widget
.main.centre.text . However in nearly all cases it is better to use output
facilities provided by the I/O auxiliary itself:
synth::report < msg >
synth::report_warning < msg >
synth::report_error < msg >
synth::internal_error < msg >
synth::output < msg > < filter >
synth::report is intended for messages related to the operation of the I/O auxiliary itself, especially additional
output resulting from
-v or --verbose . If running in text mode the output will go to standard output. If running in
graphical mode the output will go to the central text window. In both modes, use of -l or --logfile will modify
the behaviour.
synth::report_warning, synth::report_error and synth::internal_error have the obvious meaning, including
prepending strings such as
Warning: and Error: . When the eCos application informs the I/O auxiliary that all
static constructors have run, if at that point there have been any calls to synth::error then the I/O auxiliary will exit.
This can be suppressed with command line arguments
-k or --keep-going . synth::internal_error will output
some information about the current state of the I/O auxiliary and then exit immediately. Of course it should never
be necessary to call this function.
synth::output is the main routine for outputting text. The second argument identifies a filter. If running in text
mode the filter is ignored, but if running in graphical mode the filter can be used to control the appearance of this
output. A typical use would be:
synth::output $line "console"
This outputs a single line of text using the console filter. If running in graphical mode the default appearance of
this text can be modified with the appearance option in the synth_device console entry of the target definition
file. The System filters menu option can be used to change the appearance at run-time.
Filters should be created before they are used. The procedures available for this are:
synth::filter_exists < name >
synth::filter_get_list
synth::filter_add < name > [options]
synth::filter_parse_options < options > < parsed_options > < message >
synth::filter_add_parsed < name > < parsed_options >
synth::filter_exists can be used to check whether or not a particular filter already exists: creating two filters with
the same name is not allowed. synth::filter_get_list returns a list of the current known filters. synth::filter_add
can be used to create a new filter. The first argument names the new filter, and the remaining arguments control the
initial appearance. A typical use might be:
synth::filter_add "my_device_tx" -foreground yellow -hide 1
It is assumed that the supplied arguments are valid, which typically means that they are hard-wired in the script.
If instead the data comes out of a configuration file and hence may be invalid, the I/O auxiliary provides a parsing
utility. Typical usage would be:
array set parsed_options [list]
678