1.看门狗设备基类
/ components / drivers / include / drivers /下的watchdog.h 定义了如下看门狗设备基类
struct rt_watchdog_device
{
struct rt_device parent;
const struct rt_watchdog_ops *ops;
};
看门狗设备基类的方法定义如下
struct rt_watchdog_ops
{
rt_err_t (*init)(rt_watchdog_t *wdt);
rt_err_t (*control)(rt_watchdog_t *wdt, int cmd, void *arg);
};
一个是对看门狗进行初始化，另一个是对看门狗进行控制/配置，比如喂狗呀关闭看门狗呀等等操作。
这是所有看门狗的共性，抽象出来成为看门狗基类。
2.看门狗设备基类的子类
各个看门狗基类的子类已经是在bsp的驱动层来实现了，例如
/ bsp / stm32 / libraries / HAL_Drivers / drivers 下的drv_wdt.h和drv_wdt.c定义了stm32_wdt_obj类，这些都是可以实例化的终类。其他芯片厂家如此这般一样。
3.初始化化/构造流程
以stm32为例，从设备驱动层、设备驱动框架层到设备io管理层从下到上的构造/初始化流程如下
3.1设备驱动层
此层是bsp层，也是具体对象所在。
在/ bsp / stm32 / libraries / HAL_Drivers / drivers 下的drv_wdt.h定义并实例化了stm32的看门狗设备类:
struct stm32_wdt_obj
{
rt_watchdog_t watchdog;
IWDG_HandleTypeDef hiwdg;
rt_uint16_t is_start;
};
static struct stm32_wdt_obj stm32_wdt;
可以看到stm32看门狗设备类继承自看门狗基类rt_watchdog_t，剩下的hiwdg和is_start都是stm32看门狗的私有属性了。
在drv_wdt.c的rt_wdt_init中开启stm32看门狗设备的初始化/构造流程——重写了看门狗设备基类的ops方法:
ops.init = &wdt_init;
ops.control = &wdt_control;
stm32_wdt.watchdog.ops = &ops;
最终调用/ components / drivers / watchdog /下的watchdog.c中rt_hw_watchdog_register函数来初始化stm32看门狗的父类——看门狗基类。
3.2 设备驱动框架层
rt_hw_watchdog_register是看门狗设备驱动框架层的入口，开启看门狗设备基类的构造/初始化流程。
其主要是重写父类——设备基类的方法，如下
#ifdef RT_USING_DEVICE_OPS
device->ops = &wdt_ops;
#else
device->init = rt_watchdog_init;
device->open = rt_watchdog_open;
device->close = rt_watchdog_close;
device->read = RT_NULL;
device->write = RT_NULL;
device->control = rt_watchdog_control;
#endif
并最终调用设备基类的初始化/构造函数rt_device_register。
3.3 设备io管理层
rt_device_register是看门狗设备io管理层的入口。从框架章节可以知道所有设备类都继承自设备基类rt_device，自然都要实现设备基类rt_device的约束方法。
在/ components / drivers / core 下的device.c中实现了rt_device_register，由它将看门狗设备放到容器里管理。
4.总结
整个设备对象的构造/初始化流程其实是对具体设备对象也就是结构体进行初始化赋值，按照先调用子类构造/初始化函数，再调用父类的构造/初始化函数方式——其实也是子类构造/初始化函数调用父类构造/初始化函数的流程，来完成设备对象的初始化/构造。最终放到对象容器里来管理。