RTT的设备驱动模型

驱动框架

RTT里把驱动分为了三层：I/O 设备管理层、设备驱动框架层、设备驱动层。

更直观的讲是这三层：用户接口层、抽象驱动层、具体驱动层。

用户接口层里提供了用户使用具体硬件的接口。

为何要把驱动分为抽象驱动和具体驱动呢？

任意一款芯片，抽象驱动层的使用的是同一个源文件，同一套代码。单纯的抽象驱动无法真正的去“驱动”设备，需要对接具体驱动，具体驱动实现了对硬件的操作。因此在拿到一个新的芯片时，只需开发具体驱动即可，抽象驱动和用户接口都写好了。

具体驱动对接抽象驱动这个过程就是注册，注册时除了对接，还要提供设备名。应用程序使用设备时，也是根据设备名来使用的。

具体到代码实现来看

这种层次结构横向看是分层思想，分为三层。

纵向看是类的派生继承关系。从下到上不断抽象、屏蔽下层差异，体现了面向对象的抽象的思想。子类受到父类的接口约束，子类各自实现父类提供的统一接口，又体现了面向接口编程的思想。

比如从具体驱动到抽象驱动的实现：不同厂商相同硬件模块的对象对接到同一个父类接口上。多对一，体现面向对象的抽象的威力。

以串口设备为例，不管下层是 STM32、GD32 还是别的平台的，只要都是串口设备，都对接到 RT-Thread 的串口设备类——如图所绘，多个硬件对象对接同一个父类对象接口。同理，从设备驱动框架层到IO设备管理接口层，又是多对一，又是再一次的屏蔽差异，再一次的抽象。——面向对象的思想贯穿其中。

具体代码

对象 rt_object 是 rt-thread 内核里的祖宗类。

这个基类其实只有 4 个属性，用来描述一个东西需要有的基本信息：

struct rt_object
{
     /* 对象名称     */
     char        name[RT_NAME_MAX];
     /* 对象类型     */
     rt_uint8_t  type;
     /* 对象的参数   */
     rt_uint8_t  flag;
     /* 对象管理链表 */
     rt_list_t   list;
};

设备类，设备是个东西，但是还没到具体设备这一步，这也是个抽象类：

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 */

    /* 数据收发回调函数 */
    rt_err_t (*rx_indicate)(rt_device_t dev, rt_size_t size);
    rt_err_t (*tx_complete)(rt_device_t dev, void *buffer);

    const struct rt_device_ops *ops;    /* 设备操作方法 */

    /* 设备的私有数据 */
    void *user_data;
};
typedef struct rt_device *rt_device_t;

到这里为止都是说的框架，