Target Communication Framework: Getting Started

Copyright (c) 2007, 2008 Wind River Systems, Inc. Made available under the EPL v1.0

Direct comments, questions to the mailing list

Table of Contents

Creating Eclipse Workspace

Eclipse can be used for developing clients for TCF in Java. TCF host side code is organized into several Eclipse plug-in projects, below are steps to create and populate Eclipse workspace with TCF projects:

TCF Plugins

TCF plugins source code is stored in <TCF Root>\plugins directory.
Examples source code is stored in <TCF Root>\examples directory.
This is the main TCF plugin. It contains Eclipse integration code for the framework. It is the only TCF plugin, which (together with its fragments) should be required by a TCF client. The rest of TCF plugins are clients developed as a reference implementation or for demonstration purposes.
This is a fragment of plugin. It contains the framework itself and interfaces for standard services. The Java code in the fragment does not have any Eclipse dependencies and can be used outside Eclipse.,
This code connects Eclipse Debug Framework and Target Communication Framework. It allows to launch Eclipse debug session by connecting to a target running TCF agent, and then perform basic debugging tasks, like resuming, suspending, single-stepping, setting/removing breakpoints, etc. The code can be used as a reference for developing new TCF clients.
This optional plugin allows Remote System Explorer (RSE) to connect to remote machines using TCF as communication protocol. It includes implementation of RSE services as TCF clients.
This optional plugin improves integration between CDT and TCF debugger. It helps to search for CDT projects and executable files when creating TCF launch configuration.
This is an example plugin. The Example shows how TCF/Java binding can be extended for a new, user defined service. The plugin provides Java binding for DayTime service. Also, see directory <TCF Root>/examples/ for example code of a customized TCF agent, which implements DayTime service.

Building TCF Agent

CDT can be used to build TCF agent. CDT .project file is located in <TCF Root>/agent directory.

Linux: To build the agent:

Windows: For building the agent, there are two possibilities:

On VxWorks, line number mapping and the SysMonitor service (needed for RSE Processes Demo) are not yet implemented.
To build the agent: Use Wind River Workbench 3.0 or 3.1, and VxWorks 6.6 or 6.7 to create a Kernel Module project out of source code in <TCF Root>/agent directory. Use Workbench commands to build and run the agent. To run the agent on VxWorks Simulator you will need to setup a simulated network - see Networking with the VxWorks Simulator chapter in Wind River VxWorks Simulator user's guide for details.

TCF Integration with Lua

The TCF integration with Lua allows writing TCF client and server programs in the Lua programming lanugage. The integration is done so the main loop is the TCF event dispatch loop. At startup a Lua program is invoked to allow an initial setup after which it should return to enter the TCF dispatch loop.

TCF functions are accessible from the Lua table named "tcf". Accessible functions are:

Function Callback Description
read_command(read_command_callback) read_command_callback(string) Reads one line from stdin or if the -s command line option is specified from the specified file.
peer = peer_server_find(peer_name) NA Looks up peer object with the specified name. Returns nil if not found.
peers = peer_server_list() NA Returns a table of discovered peer objects.
peer = peer_server_from_url(peer_url) NA Creates a peer object from the specified URL.
protocol = protocol_alloc() NA Created a new protocol object.
channel_connect(peer, protocol, connect_callback) connect_callback(channel, errorString) Creates connection to specified peer.
event = post_event(post_event_callback, micro_seconds) post_event_callback() The micro_seconds argument is optional. Then not present the callback function will be invoked after currently pending event have been processed.

Protocol object functions:

Function Callback Description
command_handler(protocol, service, name, command_callback) command_callback(token, data) Register command handler for service and name with protocol. The command_callback function will be called each time a command of the specified name and service is received on a channel associated with the protocol object.

Channel object functions:

Function Callback Description
close(channel) NA Disconnects the specified channel.
connecting_handler(channel, connecting_callback) connecting_callback() Register callback function which is called when the channel enters connecting state.
connected_handler(channel, connected_callback) connected_callback() Register callback function which is called when the channel enters connected state.
receive_handler(channel, receive_callback) receive_callback() Register callback function which is called when the channel receives a message.
disconnected_handler(channel, disconnected_callback) disconnected_callback() Register callback function which is called when the channel is disconnected.
event_handler(channel, service, name, event_callback) event_callback(data) Register callback function which is called when an event for service and name is received.
start(channel) NA Starts communication on channel.
send_command(channel, service, name, data, replay_callback) replay_callback(data, error) Send a command to channel and register callback when reply is received.
services = get_services(channel) NA Create a table of service names supported by remote peer.

Peer object functions:

Function Callback Description
id = getid(peer) NA Return ID of peer.
getnames(peer) NA Return table of peer propery names.
getvalue(peer, name) NA Return value of propery name.
setvalue(peer, name, value) NA Set value of propery name.
getflags(peer) NA Return table of flags for peer.
setflags(peer, flags) NA Set flags for peer.

Event object functions:

Function Callback Description
cancel(event) NA Cancel event created by post_event().

Download and Build

The integration has only been tested on Linux at this point.

cd <luadir>
curl -O
tar zxf lua-5.1.4.tar.gz
cd lua-5.1.4
make linux
make local
cd <tcfdir>/agent
make LUADIR=<luadir>/lua-5.1.4

./obj/GNU/Linux/i686/Debug/tcflua tcf_example.lua

Browsing Agent Source Code in CDT

On Linux, the default configuration from the CDT .project file included in TCF should be fine for correctly browsing the agent source code.

On Windows, open Project Properties of the agent project, and under C/C++ General > Indexer switch the configuration to "Win32 - Cygwin" or "Win32 - DevStudio" as needed.

For VxWorks, browsing should be configured automatically through the WR Workbench Kernel Module Project.

Using TCF With Remote System Explorer

Remote System Explorer is an Eclipse based component that allows users to create connections to remote machines and explore their file systems, see list of processes and access some other resources, like remote shells. Remote System Explorer has been designed as a flexible, extensible framework to which Eclipse plug-in developers can contribute their own system definitions, actions, etc.

Plugin enables use of Processes and Files subsystems of Remote System Explorer over TCF. It also extends Processes subsystem to include CPU utilization data and some other process attributes in RSE views.

To connect a remote machine over TCF:

RSE features supported by TCF connection:

Using TCF With Eclipse Debugger

Plugins and allow to start a debug session by connecting to a machine runnning TCF agent.

To start a debug session over TCF:

In TCF debug session "Debug", "Breakpoints", "Registers", "Variables" and "Expressions" views are populated. Source level debugging is fully supported.