[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Watchdog device driver
- Date: Thu, 22 May 2008 14:12:55 +1000
- From: chrisj at rtems.org (Chris Johns)
- Subject: Watchdog device driver
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