1 |
786 |
skrzyp |
synth_device watchdog {
|
2 |
|
|
|
3 |
|
|
## How should the watchdog device decide that the watchdog has
|
4 |
|
|
## triggered, assuming the eCos application has failed to
|
5 |
|
|
## reset the device in time. There are two options: wallclock
|
6 |
|
|
## time, where the watchdog will trigger after a second
|
7 |
|
|
## irrespective of what the eCos application has been doing;
|
8 |
|
|
## or consumed cpu time, where the watchdog will only trigger
|
9 |
|
|
## if the eCos application has actually run for a whole second.
|
10 |
|
|
##
|
11 |
|
|
## Using wallclock time matches most real hardware,
|
12 |
|
|
## but can give spurious results if there are other processes
|
13 |
|
|
## running and consuming cpu cycles. Also, if the user has
|
14 |
|
|
## halted the application in gdb then the watchdog will trigger
|
15 |
|
|
## even though the application has no chance to reset the
|
16 |
|
|
## watchdog.
|
17 |
|
|
##
|
18 |
|
|
## Using consumed cpu cycles avoids these problems.
|
19 |
|
|
## However the default implementation of the idle thread action
|
20 |
|
|
## is to block in a select() system call, so if the eCos
|
21 |
|
|
## application spends most of its time idling but not resetting
|
22 |
|
|
## the watchdog then the device will not trigger. The
|
23 |
|
|
## configuration option CYGIMP_HAL_IDLE_THREAD_SPIN can be used
|
24 |
|
|
## to change the synthetic target HAL's implementation of the
|
25 |
|
|
## idle thread action.
|
26 |
|
|
##
|
27 |
|
|
## The default is to use consumed_cpu_time. Wallclock time can
|
28 |
|
|
## be selected by uncommenting the next line.
|
29 |
|
|
# use wallclock_time
|
30 |
|
|
# use consumed_cpu_time
|
31 |
|
|
|
32 |
|
|
## When running in GUI mode there will be a small window showing
|
33 |
|
|
## the current state of the watchdog: asleep, watching, or giving
|
34 |
|
|
## the alarm. This window can be packed as desired, using one
|
35 |
|
|
## of the container frames .main.nw .main.n .main.ne .main.w
|
36 |
|
|
## .main.e .main.sw .main.s or .main.se, and with a position of
|
37 |
|
|
## left, right, top or bottom. The default is to pack inside the
|
38 |
|
|
## .main.n frame, on the right, thus causing the watchdog to
|
39 |
|
|
## appear above the central text window.
|
40 |
|
|
# watchdog_pack -in .main.n -side right
|
41 |
|
|
|
42 |
|
|
## If running in GUI mode, when the watchdog triggers and resets
|
43 |
|
|
## the eCos application this will be shown in the display.
|
44 |
|
|
## Optionally the watchdog device can also give an audible alert
|
45 |
|
|
## when this happens. This is disabled by default to avoid
|
46 |
|
|
## annoying co-workers, but can be enabled by specifying a suitable
|
47 |
|
|
## sound file. Two such files, sound1.au and sound2.au, are supplied
|
48 |
|
|
## with the watchdog device itself. Alternatively the user can
|
49 |
|
|
## specify a different sound file using a suitable path
|
50 |
|
|
# sound sound1.au
|
51 |
|
|
# sound sound2.au
|
52 |
|
|
# sound ~/sounds/my_watchdog_alert.au
|
53 |
|
|
|
54 |
|
|
## If sound is enabled then the watchdog device needs some way to
|
55 |
|
|
## access the host's sound hardware. Rather than accessing
|
56 |
|
|
## /dev/audio or /dev/dsp directly the watchdog.tcl script will
|
57 |
|
|
## run an external program. This can avoid complications with
|
58 |
|
|
## different sound file formats etc. The default program is
|
59 |
|
|
## "play", a front-end to the sox utility, but a different
|
60 |
|
|
## program or script can be specified if desired. It will be run
|
61 |
|
|
## simply as " &"
|
62 |
|
|
# sound_player play
|
63 |
|
|
}
|