x-vxsim4.html

this about vxworks operations systems

<tr valign="middle">
<td colspan="20">

</td>
</tr>
</table>
</p callout>



<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/caution.gif">

</td>

<td>
<hr><div class="CalloutCell"><a name="85408"><b class="symbol_UC"><font face="Helvetica, sans-serif" size="-1" class="sans">CAUTION:  </font></b></a>Only <b class="symbol_UC">SIGUSR1</b> (16 on Solaris 2 hosts) and <b class="symbol_UC">SIGUSR2</b> (17 on Solaris 2 hosts) can be used to represent user-defined interrupts.</div>
</td>


</tr>
<tr valign="top">
<td></td>

<td><hr></td>


</tr>

<tr valign="middle">
<td colspan="20">

</td>
</tr>
</table>
</p callout>



<dl class="margin">

<dd><p class="Body"><a name="84695"> </a>If a VxSim task reads from a host device, the task would normally require a blocking read; however, this would stop the VxSim process entirely until data is ready. The alternative is to put the device into asynchronous mode so that a <b class="symbol_UC">SIGIO</b> signal is sent whenever data becomes ready. In this case, an input ISR reads the data, puts it in a buffer, and unblocks some waiting task.</p>
<dd><p class="Body"><a name="84696"> </a>To install an ISR that runs whenever data is ready on some underlying host device, first open the host device (use <b class="routine"><i class="routine">u_open</i></b><b>(&nbsp;)</b>, the underlying host routine, <i class="emphasis">not</i> the VxSim <b class="routine"><i class="routine">open</i></b><b>(&nbsp;)</b> function). Put the file descriptor in asynchronous mode, using the VxSim-specific routine <b class="routine"><i class="routine">s_fdint</i></b><b>(&nbsp;)</b> so that the host sends a <b class="symbol_UC">SIGIO</b> signal when data is ready. Finally, connect the ISR. The following code fragment does this on one of the host serial ports:</p>
<dl class="margin">

<dd><pre class="Code2"><b><a name="84697">... 
fd = u_open ("/dev/ttyb", 2); 
s_fdint (fd, 1); 
intConnect (32 + fd, ISRfunc, 0); 
...</a></b></pre>
</dl>

<dd><p class="Body"><a name="86301"> </a>Since VxSim uses the task's stack when taking interrupts, the task stacks are artificially inflated to compensate. You may notice this if you spawn a task of a certain size and then examine the stack size.</p>
</dl>

</dl>
<dl class="margin">

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="86302">Windows</a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="84700"> </a>Windows messages are used to simulate hardware interrupts. For example, VxSim uses messages 0xc000 - 0xc010 to simulate interrupts from ULIP, the pipe back end, and so forth. The messages are the VxSim equivalent to Interrupt Service Routines (ISRs) on other VxWorks targets. You can install ISRs in VxSim to handle these "interrupts." Not all VxWorks functions can be called from ISRs; see <a href="c-basic.html#83550"><i class="title">2.&nbsp;Basic OS</i></a>. To run ISR code during a future system clock interrupt, use the watchdog timer facilities. To run ISR code during auxiliary clock interrupts, use the <b class="routine"><i class="routine">sysAuxClk</i></b><i class="textVariable">xxx</i><b>(&nbsp;)</b> functions.</p>
<dd><p class="Body"><a name="84724"> </a><a href="x-vxsim4.html#84657">Table&nbsp;H-2</a> shows how the message table is set up.<p class="table">
<h4 class="EntityTitle"><a name="84709"><font face="Helvetica, sans-serif" size="-1" class="sans">Table H-3:&nbsp;&nbsp;Interrupt Assignments</font></a></h4>

<table border="0" cellpadding="0" cellspacing="0">
<tr>
<td colspan="20">
<hr class="tablerule">
</td>
</tr>
<tr valign="middle">
<th rowspan="1" colspan="1">
<div class="CellHeading"><b><a name="84713"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">Interrupts</font></b></div>
</th>

<th rowspan="1" colspan="1">
<div class="CellHeading"><b><a name="84715"> </a><font face="Helvetica, sans-serif" size="-1" class="sans">Assigned To</font></b></div>
</th>


</tr>
<tr>
<td colspan="20">
<hr class="tablerule2">
</td>
</tr>
<tr valign="top">
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84717"> </a>0xc000-0xc010&nbsp;</div>
</td>
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84719"> </a>host messages&nbsp;</div>
</td>

</tr>
<tr valign="top">
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84721"> </a>0xc011 on&nbsp;</div>
</td>
<td colspan=1 rowspan=1>
<div class="CellBody"><a name="84723"> </a>available for user messages &nbsp;</div>
</td>

</tr>

<tr>
<td colspan="20">
<hr class="tablerule">
</td>
</tr>
<tr valign="middle">
<td colspan="20">

</td>
</tr>
</table>
</p>
</p>
<dd><p class="Body"><a name="84725"> </a>Pseudo-drivers can be created to use these interrupts. Interrupt code must be connected with the standard VxWorks <b class="routine"><i class="routine">intConnect</i></b><b>(</b>&nbsp;<b>)</b> mechanism. </p>
<dd><p class="Body"><a name="84726"> </a>For example, to install an ISR that logs a message whenever host message <b class="symbol_UC">WM_TIMER_CLOCK</b><b class="routine"><i class="routine"> </i></b>arrives, execute the following:</p>
<dl class="margin">

<dd><pre class="Code2"><b><a name="84727"></b><tt class="output">-&gt; </tt><b>intConnect (0xc011, logMsg, "Help!\n")</a></b></pre>
</dl>

<dd><p class="Body"><a name="84728"> </a>Then send message 0xc011 to VxSim from a host task. Every time the message is received, the ISR (<b class="routine"><i class="routine">logMsg</i></b><b>(&nbsp;)</b> in this case) runs. </p>
<dd><p class="Body"><a name="84729"> </a>If a VxSim task reads from a host device, the task would normally block while reading; however, this would stop the VxSim process entirely until data is ready. Instead the device is put into asynchronous mode so that a message is sent whenever data becomes ready. In this case, an input ISR reads the data, puts it in a buffer, and unblocks some waiting task.</p>
<dd><p class="Body"><a name="84733"> </a>Since VxSim uses the task's stack when taking interrupts, the task stacks are artificially inflated to compensate. You may notice this if you spawn a task of a certain size and then examine the stack size.</p>
</dl>

</dl>

<font face="Helvetica, sans-serif" class="sans">
<h4 class="H4"><i><a name="84735">Clock and Timing Issues</a></i></h4>
</font>
<dl class="margin">

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="84736">Solaris and HP-UX </a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="84737"> </a>The execution times of VxSim functions are not, in general, the same as on a real target. For example, the VxWorks <b class="routine"><i class="routine">intLock</i></b><b>(&nbsp;)</b> function is normally very fast because it just writes to the processor status register. However, under VxSim, <b class="routine"><i class="routine">intLock</i></b><b>(&nbsp;)</b>is relatively slow because it makes a host system call to mask signals.</p>
<dd><p class="Body"><a name="84738"> </a>The clock facilities are provided by the host routine <b class="routine"><i class="routine">setitimer</i></b><b>(&nbsp;)</b> (<b class="symbol_UC">ITIMER_REAL</b> for the system clock; <b class="symbol_UC">ITIMER_PROF</b> for the auxiliary clock). The problem with using <b class="symbol_UC">ITIMER_REAL</b> for the system clock is that it produces inaccurate timings when VxSim is swapped out as a host process.<sup><a href="#foot"><b class="FootnoteMarker">1</b></a></sup>
 On the other hand, the timing of VxSim is, in general, different than on an actual target, so this is not really a problem.</p>
<dd><p class="Body"><a name="84742"> </a>The BSP system clock can be configured to use the virtual timer (<b class="symbol_UC">ITIMER_VIRTUAL</b>) in addition to <b class="symbol_UC">ITIMER_REAL</b>; see <b class="file">sysLib.c</b>. In this way, when the process is swapped out by the host, VxSim does not count wall-clock elapsed time as part of simulated elapsed time. VxSim still uses <b class="symbol_UC">ITIMER_REAL</b> to keep track of the elapsed time during the <i class="term">wind</i> kernel's idle loop. Although the addition of <b class="symbol_UC">ITIMER_VIRTUAL</b> results in more accurate <i class="emphasis">relative</i> time, the problem is that the host system becomes increasingly loaded (due to the extra signal generation) and as a result connections to the outside world (such as the network) become delayed and can fail.</p>
<dd><p class="Body"><a name="84743"> </a>The <b class="routine"><i class="routine">spy</i></b><b>(</b>&nbsp;<b>)</b> facility is built on top of the auxiliary clock (<b class="symbol_UC">ITIMER_PROF</b>). The task monitoring occurs during each interrupt of the auxiliary clock to see which task is executing or if the kernel is executing. Because the profiling timer includes host system time and user time, discrepancies can occur, especially if intensive host I/O occurs.</p>
</dl>

<dd><font face="Helvetica, sans-serif" size="-1" class="sans">
<h5 class="HU"><i><a name="84744">Windows </a></i></h5>
</font><dl class="margin">

<dd><p class="Body"><a name="84745"> </a>The execution times of VxSim functions are not, in general, the same as on a real target. For example, the VxWorks <b class="routine"><i class="routine">intLock</i></b><b>(&nbsp;)</b> function is normally very fast because it just writes to the processor status register. However, under VxSim, <b class="routine"><i class="routine">intLock</i></b><b>(&nbsp;)</b>is relatively slow because it takes a host semaphore, allowing other processes to run.</p>
<dd><p class="Body"><a name="84746"> </a>The clock facilities are provided by the host routine <b class="routine"><i class="routine">settimer</i></b><b>(&nbsp;)</b> for both the system and auxiliary clocks. The problem with using <b class="routine"><i class="routine">settimer</i></b><b>(&nbsp;)</b> for the target system clock is that it produces inaccurate timings when VxSim is swapped out as a host process.<sup><a href="#foot"><b class="FootnoteMarker">2</b></a></sup>
 On the other hand, the timing of VxSim is, in general, different than on an actual target, so this is not really a problem. </p>
<dd><p class="Body"><a name="84750"> </a>The <b class="routine"><i class="routine">spy</i></b><b>(</b>&nbsp;<b>)</b> facility is built on top of the auxiliary clock. The task monitoring occurs during each interrupt of the auxiliary clock to see which task is executing or if the kernel is executing. Because the profiling timer includes host system time and user time, discrepancies can occur, especially if intensive host I/O occurs.</p>
</dl>

</dl>


<a name="foot"><hr></a>

<p class="FootnoteNumberMarker">1:&nbsp;
<span class="Footnote"><a name="84741"> </a>Because VxSim is a host process, it shares resources with all other processes and is swapped in and out. In addition, the kernel's idle loop has been modified to suspend VxSim until a signal arrives (rather than busy waiting), thus allowing other processes to run.</span>
<p class="FootnoteNumberMarker">2:&nbsp;
<span class="Footnote"><a name="84749"> </a>Because VxSim is a host process, it shares resources with all other processes and is swapped in and out. In addition, the kernel's idle loop has been modified to suspend VxSim until a signal arrives (rather than busy waiting), thus allowing other processes to run.</span>

<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="x-vxsim.html"><img border="0" alt="[Top]" src="icons/top.gif"></a><a href="x-vxsim3.html"><img border="0" alt="[Prev]" src="icons/prev.gif"></a><a href="x-vxsim5.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 --->