Name
User Interface — Controlling the I/O Auxiliary
Description
The synthetic target auxiliary is designed to support both extensions and user customization. Support for the desired devices is dynamically loaded, and each device can extend the user interface. For example it is possible for a device to add menu options, place new buttons on the toolbar, create its own sub-window within the overall layout, or even create entire new toplevel windows. These subwindows or toplevels could show graphs of activity such as interrupts or packets being transferred. They could also allow users to interact with the eCos application, for example by showing a number of buttons which will be mapped on to digital inputs in the eCos application. Different applications will have their own I/O requirements, changing the host-side support files that get loaded and that may modify the user interface. The I/O auxiliary also reads in user configuration scripts which can enhance the interface in the same way. Therefore the exact user interface will depend on the user and on the eCos application being run. However the overall layout is likely to remain the same.
The title bar identifies the window as belonging to an eCos synthetic target application and lists both the application name and its process id. The latter is especially useful if the application was started directly from a shell prompt and the user now wants to attach a gdb session. The window has a conventional menu bar with the usual entries, plus a toolbar with buttons for common operations such as cut and paste. Balloon help is supported.
There is a central text window, possibly surrounded by various sub-windows for various devices. For example there could be a row of emulated LED's above the text window, and monitors of ethernet traffic and interrupt activity on the right. At the bottom of the window is a status line, including a small animation that shows whether or not the eCos application is still running.
The Main Text Window
The central text window holds the console output from the eCos
application: the screen shot above shows DHCP initialization data from
the TCP/IP stack, and some output from the main
thread at the bottom. Some devices can insert text of their own, for
example the ethernet device support can be configured to show details
of incoming and outgoing packets. Mixing the output from the eCos
application and the various devices can make it easier to understand
the order in which events occur.
The appearance of text from different sources can be controlled by means of filters, and it is also possible to hide some of the text. For example, if tracing is enabled in the eCos configuration then the trace output can be given its own colour scheme, making it stand out from the rest of the output. In addition the trace output is generally voluminous so it can be hidden by default, made visible only to find out more about what was happening when a particular problem occurred. Similarly the ethernet device support can output details of the various packets being transferred, and using a different background colour for this output again makes it easier to distinguish from console output.
The default appearance for most filters is controlled via the target definition file. An example entry might be:
filter trace {^TRACE:.*} -foreground HotPink1 -hide 1
The various colours and the hide flag for each filter can be changed at run-time, using the
item on the menu. This will bring up a dialog like the following:It should be noted that the text window is line-oriented, not character-oriented. If an eCos application sends a partial line of text then that will remain buffered until a newline character is received, rather than being displayed immediately. This avoids confusion when there is concurrent output from several sources.
By default the text window is read-only. This means it will not allow cut, paste and clear operations, and keyboard input will be ignored. The
menu has a checkbutton which can be toggled to allow write operations. For example, a user could type in a reminder of what was happening at this time, or paste in part of a gdb session. Such keyboard input does not get forwarded to the eCos application: if the latter requires keyboard input then that should happen via a separate keyboard device.Positioning Optional Windows
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 layout of these windows. This requires an understanding of the overall layout of the display.
Subwindows are generally packed in one of eight frames surrounding the
central text window: .main.nw
,
.main.n
, .main.ne
,
.main.w
, .main.e
,
.main.sw
, .main.s
, and
.main.se
. To position a row of LED's above the text
window and towards the left, a target definition file could contain an
entry such as:
synth_device led { pack -in .main.n -side left … }
Similarly, to put a traffic monitor window on the right of the text window would involve something like:
… monitor_pack -in .main.e -side bottom …
Often it will be sufficient to specify a container frame and one of
left
, right
,
top
or bottom
. Full control
over the positioning requires an understanding of Tcl/Tk and in
particular the packing algorithm, and an appropriate reference work
should be consulted.
Global Settings
Note | |
---|---|
This section still to be written - it should document the interaction between X resources and ecosynth, and how users can control settings such as the main foreground and background colours. |
2024-03-18 | Open Publication License |