Generic Card Debugger

June 15, 1994

While I don't doubt that there are good reasons for ignoring most of Ward's suggestions, I don't understand why - in all the discussions of GUIs and debuggers, etc. - everyone is ignoring Ward's valuable contribution in bringing Tcl and Tk into the light of Code 521's day.

The card debuggers, in particular, are good candidates for using Tcl, an embedded command language. I'm not familiar with Code 521's debuggers, but I envision a debugging system consisting of:

• Generic Debugging Server is a relatively simple task that is based on Tcl extended with basic hardware manipulation commands. I assume only a few commands are needed: read an address (memory or register), write to an address, etc. Command options would allow specifying the type of data being accessed; e.g., bit, byte, 2- or 4-byte integer, etc.
  
  ASCII lines of input would be accepted from a network connection (socket or RPC) or from standard input. (The Tcl servers I have written have a -tty command line option that enables the latter.) Lines of output would be written back to the input source (i.e., the network or standard output).
  
  Note that this task is (i) simple, (ii) small, and (iii) can be run from a bare-bones command line - no TPCE, no OPMAN, nothing. (You would need the network to load the debugger.)


• Tcl Initialization Files are card-specific. When invoked to debug a particular card, the generic debugger reads that card's initialization file. The primary purpose of this file is to define new card-specific Tcl commands. These commands are implemented as Tcl procedures using the generic hardware manipulation commands. The card-specific commands could range from simple load-register commands that save you the trouble of supplying register addresses all the way up to "first order" commands (in Chuck's terminology) that perform end-to-end tests. Basic Tcl is easy enough for even hardware engineers to "program" their own commands.


• The (G)UI need only be able (1) to send an ASCII command to a card debugger and (2) to receive an ASCII message from the debugger. These requirements could be fulfilled by a bare-bones command line, an OPMAN-like interface, or a GUI running on a remote host. (OPMAN itself could be used if the generic debugger supported the MEDS interface as an I/O option.)
  
  Some thought must be given to the output of the generic debugger so that the user interface can interpret - if it is able - any responses received from the debugger. On TPOCC, for example, each line of output from the TSTOL command language server had a 2-character type prefix that allowed the GUI to distinguish between normal output messages, prompts for more information, screen debugging control messages, etc. The common interface to TSTOL allowed the operator to run TSTOL from the command line, from a curses(1)-based display, and from several Motif-based GUIs.

An advantage of the ASCII I/O interface is that it loosens the coupling between the user interface and the debugger. New commands can be added to the debugger and existing commands can be enhanced without having to recompile, let alone write new code for, the GUI. For example, my Motif- and Tcl-based wimp GUI could be programmed in Tcl to talk to a debugger as follows:

    wmp_net call frame_sync_dbgr@host -input process_response

    wmp_button button1 -label "Read Status"         -command {frame_sync_dbgr write "dbg_read register0"}

(wimp with extensions for the TPOCC/GenSAA widgets, was, of course, called twerp!) The first line establishes a network connection to the frame sync debugger; input received from the debugger is passed to a process_response procedure. The second line creates a Motif button, "Read Status", on the screen; when the button is pressed, the command "dbg_read register0" is sent to the frame sync debugger. Any messages returned by the debugger are interpreted by process_response.

New debugger commands can be incorporated into the GUI by simply defining new buttons with different labels and different on-button-click commands. (I'm using buttons in my example, but the debugger commands can also be generated via menus, etc.) The "ASCII advantage" is not lost on non-Tcl-based GUIs like TPCE. Such GUIs could register a callback procedure with the Motif Resource Manager that sends a command to the debugger. That procedure (a C function) could then be bound to a widget's callback in the display's UIL file:

    ...
    callbacks {
        XmNactivateCallback = procedures {
            send_debugger ("frame_sync dbg_read register0") ;
        } ;
    } ;
    ...

(You should also be able to specify the callback binding in your GUI builder.) When the widget is "activated" (e.g., via a button click), send_debugger() would be called to send "dbg_read register0" to the frame sync debugger. send_debugger() would have to be smart enough to know how to connect to the specified debugger, if not already connected, and to send the command.

Ideally, of course, TPCE would be a programmable GUI having its own embedded Tcl interpreter, complete with MEDS extensions.