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