Skip to main content
aboutsummaryrefslogtreecommitdiffstats
blob: 0071e96fc15132f42156b5f4c5ff853720d85763 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3c.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML lang=en-us>
<HEAD>
<TITLE>Target Communication Framework</TITLE>
</HEAD>

<BODY>

<H1>Target Communication Framework project</H1>

<P>
<H2><A name=Index></A>Index</H2>

<UL>
  <LI><A href="#Summary">Summary</A> 
  <LI><A href="#Goals">Goals</A> 
  <LI><A href="#Features">Features</A> 
  <LI><A href="#Agent">Reference implementation of a target agent</A>
  <LI><A href="#Debugger">Prototype of a debugger based on Eclipse Debug Framework and TCF</A>
  <LI><A href="#RSE">Prototype of a system monitor and remote file access based on Remote System Explorer and TCF</A>
</UL>

<P>
<H2><A name=Summary></A>Summary </H2>

<P>Today almost every device software development tool on the market has its own 
method of communication with target system. Communication methods often conflict 
with each other, require individual setup, configuration and maintenance, impose 
all kinds of unnecessary limitations. Target Communication Framework is designed 
to establish common ground in the area of communication protocols between 
development tools and embedded devices. 

<P>
<H2><A name=Goals></A>Goals </H2>
<P>
<UL>
  <LI>Universal, extensible, simple, lightweight, vendor agnostic framework for 
  tools and targets to communicate for purpose of debugging, profiling, code 
  patching and other device software development needs. 
  <LI>Single configuration per target (not per tool per target as today in most 
  cases), or no configuration when possible. 
  <LI>Small overhead and footprint on target side. </LI></UL>
<P>

<H2><A name=Features></A>Features </H2>
<P><A href="TCF Specification.html">Target Communication Framework Specification</A> is a document 
describing design goals, requirements and format of TCF communication protocol, 
as well as framework API and software design considerations. 
<P>TCF communication model is based on the idea of services. A service is a group 
of related commands, events and semantics. A service can be discovered, 
added or removed as a group at communication endpoint. Service definitions are 
not part of the framework specification, and new services are expected to be 
defined by developers of tools and target agents. However, standardization of 
common services is needed to achieve certain level of compatibility of 
tools/targets, see <A href="TCF Services.html">TCF Services Specification</A>
as starting point of this work. 

<H2><A name=Agent></A>Reference implementation of a target agent</H2>

<P>Current reference implementation of TCF target agents is fully functional, 
can run on Windows, Linux and VxWorks, and provides the following services: 
<UL>
    <LI>Run Control - provides threads and processes run control functionality 
    sufficient for debugging of user space programs. On Linux it is implemented 
    using PTRACE, on VxWorks is uses vxdbgLib, on Windows it is not currently supported. 

    <LI>Breakpoints - provides basic breakpoints support. On Linux it is 
    implemented using PTRACE, on VxWorks is uses vxdbgLib,
    on Windows it is not currently supported. 

    <LI>Registers - allows inspection and modification of CPU registers.
    Implemented for Linux and VxWorks, on Windows it is not currently supported.

    <LI>Stack Trace - execution thread stack back-tracing.
    Implemented for Linux and VxWorks, on Windows it is not currently supported.

    <LI>Memory - program memory access.
    Implemented for Linux and VxWorks, on Windows it is not currently supported.

    <LI>Processes - provides access to the target OS's process 
    information, allows starting new and terminating existing processes,
    and allows attaching and detaching processes for debugging.
    Implemented for Linux and VxWorks, on Windows it is not currently supported.

    <LI>Line Numbers - provides mapping between locations in the source files
    and corresponding machine instruction addresses in the executable object.
    Implemented for Linux only.

    <LI>Sys Monitor - provides list of processes, process attributes and 
    CPU/memory utilization data. On Linux it is implemented using /proc file 
    system, on Windows and VxWorks it is not currently supported. 

    <LI>File System - provides access to remote file system. 

    <LI>Diagnostics - allows testing of communication channel and agent 
    functionality.
</UL>

<P>The agent code is designed to be easily extensible by adding new command 
handler implementations. The code separates machine dependences, common TCF 
logic and service implementations, which allows easy porting to a new OS or a 
target and reconfiguring of the agent for specific needs. The code is written in 
ANSI C. See <A href="TCF Linux Agent Prototype.html">TCF Linux Agent Prototype</A>
for more details about the agent code. 

<H2><A name=Debugger></A>Prototype of a debugger based on Eclipse Debug Framework and TCF</H2>

<P>The prototype 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. Since current 
reference implementation of target agent does not support line number 
information access, source level debugging is not supported. 
<P>The prototype launch configuration autodetects TCF targets on a local network 
and allows a user to connect to a target by simply selecting it from a list 
without a need for any further configuration or setup. TCF launch configuration 
dialog also offers controls to run a built-in diagnostics on a selecting target, 
which perform stress testing of communication channel, agent and target itself: 
<P><IMG alt="TCF launch configuration dialog" src="TCF_Launch_Dialog.jpg"> 

<P>The prototype makes use of flexible debug model element hierarchy support, 
which is available in Eclipse debug framework since Eclipse 3.2. The flexible 
hierarchy allows debugger views to be "data driven" or, in other words, dynamically 
adapt to a given targets capabilities and structure, without a need to modify 
debugger code to support a new target.
 
<H2><A name=RSE></A>Prototype of a system monitor and remote file access based on Remote System Explorer and TCF</H2>

<P>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. 
<P>The prototype 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:
<P><IMG alt="Remote System Explorer: Files subsystem over TCF" src="TCF_RSE_Files.jpg"> 
<P><IMG alt="Remote System Explorer: Processes subsystem over TCF" src="TCF_RSE_Processes.jpg"> 

</BODY>
</HTML>

Back to the top