📄 c-overview5.html
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN"><html><head><link rel="STYLESHEET" type="text/css" href="wrs.css"><title> Overview </title></head><body bgcolor="FFFFFF"><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="GuideIX.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-overview.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-overview4.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-overview6.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p><font face="Helvetica, sans-serif" class="sans"><h3 class="H2"><i><a name="84215">1.5 Host-Target Interface </a></i></h3></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85618"> </a>The elements of Tornado described in this section provide the link between the host and target development environments: </p></dl><dl class="margin"><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85878"> </a>The target agent is a scalable component of VxWorks that communicates with the target server on the host system. </li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85882"> </a>The target server connects Tornado tools such as the shell and debugger with the target agent. </li></ul></p><p class="listspace"><ul class="Bullet" type="disc"><li><a name="85883"> </a>The Tornado registry provides access to target servers, and may run on any host on a network. </li></ul></p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="85558">Target Agent</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="85560"> </a>On the target, all Tornado tools are represented by the target agent. The target agent is a compact implementation of the core services necessary to respond to requests from the Tornado tools. The agent responds to requests transmitted by the target server, and replies with the results. These requests include memory transactions, notification services for breakpoints and other target events, virtual I/O support, and task control.</p><dd><p class="Body"><a name="84222"> </a>The agent synthesizes two modes of target control: <i class="term">task mode</i> (addressing the target at application level) and <i class="term">system mode</i> (system-wide control, including ISR debugging). The agent can execute in either mode and switches between them on demand. This greatly simplifies debugging of any aspect of an embedded application, whether it be a task, an interrupt service routine, or the kernel itself.</p><dd><p class="Body"><a name="84223"> </a>The agent is independent of the run-time operating system, interfacing with run-time services indirectly so that it can take advantage of kernel features when they are present, but without requiring them. The agent's driver interface is also independent of the run-time, because it avoids the VxWorks I/O system. Drivers for the agent are raw drivers that can operate in either a polling or an interrupt-driven mode. A polling driver is required to support system-level breakpoints.</p><dd><p class="Body"><a name="84224"> </a>This run-time independence means that the target agent can execute before the kernel is running. This feature is valuable for the early stages of porting VxWorks to a new target platform.</p><dd><p class="Body"><a name="84225"> </a>A key function of the agent is to service the requests of the host-resident object-module loader. Given the incremental loading capabilities of Tornado, it is quite common to configure the target with the agent linked into the run-time and stored in ROM. When started, the target server automatically initializes the symbol table from the host-resident image of the target run-time system. From this point on, all downloads are incremental in nature, greatly reducing download time. </p><dd><p class="Body"><a name="84227"> </a>The agent itself is scalable; you can choose what features to include or exclude. This permits the creation of final-production configurations that still allow field testing, even when very little memory can be dedicated to activities beyond the application's purpose.</p></dl></dl><dl class="margin"><dd><p class="table" callout><table border="0" cellpadding="0" cellspacing="0"><tr valign="top"><td valign="top" width="40"><br><img border="0" alt="*" src="icons/note.gif"></td><td><hr><div class="CalloutCell"><a name="86507"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">NOTE: </font></b></a>The target agent is not required. A target server can also connect to an ICE back end, which requires less target memory, but does not support task mode debugging.</div></td></tr><tr valign="top"><td></td><td><hr></td></tr><tr valign="middle"><td colspan="20"></td></tr></table></p callout></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84229">Tornado Target Server</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84231"> </a>The target server runs on the host, and connects the Tornado tools to the target agent. There is one server for each target; all host tools access the target through this server, whose function is to satisfy the tool requests by breaking each request into the necessary transactions with the target agent. The target server manages the details of whatever connection method to the target is required, so that each tool need not be concerned with host-to-target transport mechanisms.</p><dd><p class="Body"><a name="84232"> </a>In some cases, the server passes a tool's service request directly to the target agent. In other cases, requests can be fulfilled entirely within the target server on the host. For example, when a target-memory read hits a memory region already cached in the target server, no actual host-to-target transaction is needed. </p><dd><p class="Body"><a name="84233"> </a>The target server also allocates target memory from a pool dedicated to the host tools, and manages the target's symbol table on the host. This permits the server to do most of the work of dynamic linking--address resolution--on the host system, before downloading a new module to the target.</p><dd><p class="Body"><a name="84234"> </a>A target server need not be on the same host as the Tornado tools, as long as the tools have network access to the host where the target server is running. </p><dd><p class="Body"><a name="85547"> </a>For information about how to configure, start, and manage target servers see <a href="c-tools.html#83918"><i class="title">5. Target Server</i></a> and the <b class="command">tgtsvr</b> reference entry in <a href="x-toolman.html#83918"><i class="title">C. Tornado Tools Reference</i></a>.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84263">Tornado Registry</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84265"> </a>Tornado provides a central target server registry that allows you to select a target server by a convenient name. The registry associates a target server's name with the network address needed to connect with that target server. You can see the registry indirectly through the list of available targets. The Tornado registry need not run on the same host as your tools, as long as it is accessible on the network.</p><dd><p class="Body"><a name="84266"> </a>To help keep server names unique over a network of interacting hosts, target-server names have the form <i class="textVariable">targetName</i><b class="operator">@</b><i class="textVariable">host</i>, where <i class="textVariable">targetName</i> is a target-server name selected by the user who launches a server (with the network name of the target as a default). The registry rejects registration attempts for names that are already in use.</p><dd><p class="Body"><a name="84271"> </a>It is recommended that a single registry be used at a development site, to allow access to all targets on the network. A registry should never be killed; without a registry, target servers cannot be named, and no Tornado tool can connect to a target.</p><dd><p class="Body"><a name="85812"> </a>For information about the Tornado registry, see <a href="c-start2.html#91837"><i class="title">2.2 Host Setup: Tornado Registry</i></a>.</p></dl></dl><font face="Helvetica, sans-serif" class="sans"><h4 class="H4"><i><a name="84294">Virtual I/O</a></i></h4></font><dl class="margin"><dl class="margin"><dd><p class="Body"><a name="84296"> </a><i class="term">Virtual I/O</i> is a service provided jointly by the target agent and target server. It consists of an arbitrary number of logical devices (on the VxWorks end) that convey application input or output through standard C-language I/O calls, using the same communication link as other agent-server transactions.</p><dd><p class="Body"><a name="84297"> </a>This mechanism allows developers to use standard C routines for I/O even in environments where the only communication channel is already in use to connect the target with the Tornado development tools. </p><dd><p class="Body"><a name="84298"> </a>From the point of view of a VxWorks application, a standard I/O channel is an ordinary character device with a name like <b class="file">/vio/0</b>, <b class="file">/vio/1</b>, and so on. It is managed using the same VxWorks calls that apply to other character devices, as described in the <i class="title">VxWorks Programmer's Guide: I/O System</i>. This is also the developer's point of view while working in the Tornado shell.</p><dd><p class="Body"><a name="84299"> </a>On the host side, virtual I/O is connected to the shell or to the target server console, which is a window on the host where the target server is running. See <a href="c-tools2.html#90945"><i class="title">Console and Redirection</i></a> for information about how to configure a target server with a virtual console. </p></dl></dl><a name="foot"><hr></a><p class="navbar" align="right"><a href="index.html"><img border="0" alt="[Contents]" src="icons/contents.gif"></a><a href="GuideIX.html"><img border="0" alt="[Index]" src="icons/index.gif"></a><a href="c-overview.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="c-overview4.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="c-overview6.html"><img border="0" alt="[Next]" src="icons/next.gif"></a></p></body></html><!---by WRS Documentation (), Wind River Systems, Inc. conversion tool: Quadralay WebWorks Publisher 4.0.11 template: CSS Template, Jan 1998 - Jefro --->⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -