I/O 设备模型框架
RT-Thread提供了一套简单的I/O设备模型框架，如图所示，它位于硬件和应用程序之间，共分成三层，从上到下分别是I/O设备管理层、设备驱动框架层、设备驱动层。
应用程序通过I/O设备管理接口获得正确的设备驱动，然后通过这个设备驱动与底层I/O硬件设备进行数据交互。
I/O设备管理层实现了对设备驱动程序的封装。应用程序通过图中的“I/O设备管理层”提供的标准接口访问底层设备，设备驱动程序的升级，更替不会对上层应用产生影响。
这种方式使得设备的硬件操作相关的代码能够独立于应用程序而存在，双方只需关注各自的功能实现，从而降低了代码的耦合性、复杂性，提高了系统的可靠性。
设备驱动框架层是对同类硬件设备驱动的抽象，将不同厂家的同类硬件设备驱动中相同的部分抽取出来，将不同部分留出接口，由驱动程序实现。
设备驱动层是一组驱使硬件设备工作的程序，实现访问硬件设备的功能。它负责创建和注册I/O设备，对于操作逻辑简单的设备，可以不经过设备驱动框架层，直接将设备注册到I/O设备管理器中。
- 设备驱动根据设备模型定义，创建出具备硬件访问能力的设备实例，将该设备通过rt_device_register()接口注册到I/O设备管理器中。
- 应用程序通过rt_device_find()接口查找到设备，然后使用I/O设备管理接口来访问硬件。
对于另一些设备，如看门狗等，则会将创建的设备实例先注册到对应的设备驱动框架中，再由设备驱动框架向I/O设备管理器进行注册，主要有以下几点：
- 看门狗设备驱动程序根据看门狗设备模型定义，创建出具备硬件访问能力的看门狗设备实例，并将该看门狗设备通过rt_hw_watchdog_register()接口注册到看门狗设备驱动框架中。
- 看门狗设备驱动框架通过rt_device_register()接口将看门狗设备注册到I/O设备管理器中。
- 应用程序通过I/O设备管理接口来访问看门狗设备硬件。
I/O设备模型
RT-Thread的设备模型是建立在内核对象模型基础之上的，设备被认为是一类对象，被纳入对象管理器的范畴。
每个设备对象都是由基对象派生而来，每个具体设备都可以继承其父类对象的属性，并派生出私有属性。
/**
* Device structure
*/
struct rt_device
{
struct rt_object parent; //内核对象基类
enum rt_device_class_type type; //设备类型
rt_uint16_t flag; //设备参数
rt_uint16_t open_flag; //设备打开标志
rt_uint8_t ref_count; //设备被引用次数
rt_uint8_t device_id; /设备ID，0~255
/* device call back */
rt_err_t (*rx_indicate)(rt_device_t dev, rt_size_t size);
rt_err_t (*tx_complete)(rt_device_t dev, void *buffer);
#ifdef RT_USING_DEVICE_OPS
const struct rt_device_ops *ops;
#else
/* common device interface */
rt_err_t (*init) (rt_device_t dev);
rt_err_t (*open) (rt_device_t dev, rt_uint16_t oflag);
rt_err_t (*close) (rt_device_t dev);
rt_size_t (*read) (rt_device_t dev, rt_off_t pos, void *buffer, rt_size_t size);
rt_size_t (*write) (rt_device_t dev, rt_off_t pos, const void *buffer, rt_size_t size);
rt_err_t (*control)(rt_device_t dev, int cmd, void *args);
#endif
#if defined(RT_USING_POSIX)
const struct dfs_file_ops *fops;
struct rt_wqueue wait_queue;
#endif
void *user_data; //设备私有数据
};
I/O设备类型
/**
* device (I/O) class type
*/
enum rt_device_class_type
{
RT_Device_Class_Char = 0, /**< character device */
RT_Device_Class_Block, /**< block device */
RT_Device_Class_NetIf, /**< net interface */
RT_Device_Class_MTD, /**< memory device */
RT_Device_Class_CAN, /**< CAN device */
RT_Device_Class_RTC, /**< RTC device */
RT_Device_Class_Sound, /**< Sound device */
RT_Device_Class_Graphic, /**< Graphic device */
RT_Device_Class_I2CBUS, /**< I2C bus device */
RT_Device_Class_USBDevice, /**< USB slave device */
RT_Device_Class_USBHost, /**< USB host bus */
RT_Device_Class_SPIBUS, /**< SPI bus device */
RT_Device_Class_SPIDevice, /**< SPI device */
RT_Device_Class_SDIO, /**< SDIO bus device */
RT_Device_Class_PM, /**< PM pseudo device */
RT_Device_Class_Pipe, /**< Pipe device */
RT_Device_Class_Portal, /**< Portal device */
RT_Device_Class_Timer, /**< Timer device */
RT_Device_Class_Miscellaneous, /**< Miscellaneous device */
RT_Device_Class_Sensor, /**< Sensor device */
RT_Device_Class_Touch, /**< Touch device */
RT_Device_Class_Unknown /**< unknown device */
};
其中字符设备、块设备是常用的设备类型，它们的分类依据是设备数据与系统之间的传输处理方式。
字符模式设备允许非结构的数据传输，即通常数据传输采用串行的形式，每次一个字节。字符设备通常是一些简单设备，如串口、按键。
块设备每次传输一个数据块，例如每次传输512个字节数据。这个数据块是硬件强制性的，数据块可能使用某类数据接口或某些强制性的传输协议，否则就可能发生错误。
因此，有时块设备驱动程序对读或写操作必须执行附加的工作，如下图所示：
当系统服务于一个具有大量数据的写操作时，设备驱动程序必须首先将数据划分为多个包，每个包采用设备指定的数据尺寸。而在实际过程中，最后一部分数据尺寸有可能小于正常的设备块尺寸。
每个块使用单独的写请求写入到设备中，头三个直接进行写操作。但最后一个数据块尺寸小于设备块尺寸，设备驱动程序必须使用不同于前3个块的方式处理最后的数据块。
设备驱动程序首先执行相对应的设备块的读操作，然后把写入数据覆盖到读出数据上，然后再把这个“合成”的数据块作为一整个块写回到设备中。
驱动程序需要先把块3所对应的设备块读出来，然后将需要写入的数据覆盖至从设备块读出的数据上，使其合并成一个新的块，最后再写回到块设备中。
