Watchdog device driver
Chris Johns
chrisj at rtems.org
Thu May 22 04:12:55 UTC 2008
Andrei Chichak wrote:
> At 05:12 PM 5/21/2008, you wrote:
>> This is a good idea. I see the driver as something like:
>>
>> int wd = open ("/dev/wd0", O_WRONLY, 0);
>>
>> ioctl (wd, RTEMS_WDOG_RESET); /* reset the watchdog */
>> ioctl (wd, RTEMS_WDOG_CONFIG, 250); /* set the timeout to be 250msec */
>> ioctl (wd, RTEMS_WDOG_TRIGGER); /* trigger a watchdog reset */
>>
>> close (wd);
>>
>> Regards
>
> I like the interface, in all of the systems that I have written there
> was a two phase strobbing, I suspect that would be the RESET and TRIGGER, yes?
>
The trigger would allow you the ability to reset a board by asking the driver
to trigger the watchdog. This maybe done by lowering the time out to very
short value or it could be disabling interrupts and looping.
I think a single call to RESET or SERVICE the watchdog is all that is needed.
You also need enable and disable. If a watchdog cannot be disabled the driver
should return an error code.
> Where in the BSP would this sort of stuff go? (Being a moderate
> newbie I have to ask. I didn't know there was support for SPI, I'll
> have to look that up)
We need to create a header file that would live in the cpukit and be installed
when RTEMS is build and installed. This would provide the API which is the
RTEMS_WDOG_RESET declarations. Maybe these could go in an existing header. I
will let Joel decide this.
In the BSP the driver can go where it suits the BSP. You have to register the
driver and this could be via confdefs.h (Joel?) or by a call in the BSP. If
the BSP does not provide a watchdog driver the open fails because no device
node exists.
Regards
Chris
More information about the users
mailing list