synth_watchdog.sgml

开放源码实时操作系统源码.

watchdog device has no effect until started.
    </para>
  </refsect1>

  <refsect1 id="synth-watchdog-wallclock-elapsed"><title>Wallclock versus Elapsed Time</title>
    <para>
On real hardware the watchdog device uses wallclock time: if the
device does not receive a reset signal within a set period of time
then the watchdog will trigger. When developing for the synthetic
target this is not always appropriate. There may be other processes
running, using up some or most of the cpu time. For example, the
application may be written such that it will issue a reset after some
calculations which are known to complete within half a second, well
within the one-second resolution of the watchdog device. However if
other Linux processes are running then the synthetic target
application may get timesliced, and half a second of computation may
take several seconds of wallclock time.
    </para>
    <para>
Another problem with using wallclock time is that it interferes with
debugging: if the application hits a breakpoint then it is unlikely
that the user will manage to restart it in less than a second, and the
watchdog will not get reset in time.
    </para>
    <para>
To avoid these problems the synthetic target watchdog normally uses
consumed cpu time rather than wallclock time. If the application is
timesliced or if it is halted inside gdb then it does not consume any
cpu time. The application actually has to spend a whole second's worth
of cpu cycles without issuing a reset before the watchdog triggers.
    </para>
    <para>
However using consumed cpu time is not a perfect solution either. If
the application makes blocking system calls then it is not using cpu
time. Interaction with the I/O auxiliary involves system calls, but
these should take only a short amount of time so their effects can be
ignored. If the application makes direct system calls such as
<function>cyg_hal_sys_read</function> then the system behaviour
becomes undefined. In addition by default the idle thread will make
blocking <function>select</function> system calls, effectively waiting
until an interrupt occurs. If an application spends much of its time
idle then the watchdog device may take much longer to trigger than
expected. It may be desirable to enable the synthetic target HAL
configuration option <varname>CYGIMP_HAL_IDLE_THREAD_SPIN</varname>,
causing the idle thread to spin rather than block, at the cost of
wasted cpu cycles.
    </para>
    <para>
The default is to use consumed cpu time, but this can be changed in
the target definition file:
    </para>
    <programlisting>
synth_device watchdog {
    use wallclock_time
    &hellip;
}
</programlisting>
  </refsect1>

  <refsect1 id="synth-watchdog-gui"><title>User Interface</title>
    <para>
When the synthetic target is run in graphical mode the watchdog device
extends the user interface in two ways. The <guimenu>Help</guimenu>
menu is extended with an entry for the watchdog-specific
documentation. There is also a graphical display of the current state
of the watchdog. Initially the watchdog is asleep:
    </para>
    <informalfigure PgWide=1>
      <mediaobject>
        <imageobject>
          <imagedata fileref="asleep.png" Scalefit=1 Align="Center">
        </imageobject>
      </mediaobject>
    </informalfigure>
    <para>
When application code starts the device the watchdog will begin to
keep an eye on things (or occasionally both eyes).
    </para>
    <informalfigure PgWide=1>
      <mediaobject>
        <imageobject>
          <imagedata fileref="awake.png" Scalefit=1 Align="Center">
        </imageobject>
      </mediaobject>
    </informalfigure>
    <para>
If the watchdog triggers the display will change again, and optionally
the user can receive an audible alert. The location of the watchdog
display within the I/O auxiliary's window can be controlled via
a <command>watchdog_pack</command> entry in the target definition
file. For example the following can be used to put the watchdog
display to the right of the central text window:
    </para>
    <programlisting>
synth_device watchdog {
    watchdog_pack -in .main.e -side top
    &hellip;
}
</programlisting>
    <para>
The user interface section of the generic synthetic target HAL
documentation can be consulted for more information on window packing.
    </para>
    <para>
By default the watchdog support will not generate an audible alert
when the watchdog triggers, to avoid annoying colleagues. Sound can be
enabled in the target definition file, and two suitable files
<filename>sound1.au</filename> and <filename>sound2.au</filename> are
supplied as standard:
    </para>
    <programlisting>
synth_device watchdog {
    sound sound1.au
    &hellip;
}
</programlisting>
    <para>
An absolute path can be specified if desired:
    </para>
    <programlisting>
synth_device watchdog {
    sound /usr/share/emacs/site-lisp/emacspeak/sounds/default-8k/alarm.au
    &hellip;
}
</programlisting>
    <para>
Sound facilities are not built into the I/O auxiliary itself, instead
an external program is used. The default player is
<command>play</command>, a front-end to the
<application>sox</application> application shipped with some Linux
distributions. If another player should be used then this can be
specified in the target definition file:
    </para>
    <programlisting>
synth_device watchdog {
    &hellip;
    sound_player my_sound_player
</programlisting>
    <para>
The specified program will be run in the background with a single
argument, the sound file.
    </para>
  </refsect1>

  <refsect1 id="devs-watchdog-synth-args"><title>Command Line Arguments</title>
    <para>
The watchdog support does not use any command line arguments. All
configuration is handled through the target definition file.
    </para>
  </refsect1>

  <refsect1 id="devs-watchdog-synth-hooks"><title>Hooks</title>
    <para>
The watchdog support does not provide any hooks for use by other
scripts. There is rarely any need for customizing the system's
behaviour when a watchdog triggers because those should be rare
events, even during application development.
    </para>
  </refsect1>

  <refsect1 id="devs-watchdog-synth-tcl"><title>Additional Tcl Procedures</title>
    <para>
The watchdog support does not provide any additional Tcl procedures or
variables for use by other scripts.
    </para>
  </refsect1>

</refentry>
</part>
<!-- /reference -->