串口

/DeviceDrivers/serial.c
该文件是串口的驱动框架，和底层驱动没有关系。
/Drivers/usart.c
该文件就和芯片紧密相关，是串口的底层驱动，在board.c中被初始化。初始化中通过serial.c中注册的方式，让系统知道串口设备的存在，它也就仅仅需要留出一个init的函数，然后写入rt_hw_board_init函数中。
还可以使用INIT_BOARD_EXPORT实现自动初始化，例如

INIT_BOARD_EXPORT(rt_hw_usart_init);

/Kernel/device.c
该文件就是驱动操作接口，对于系统本身而言，无论是串口、IIC、SPI都是一样的，应用层仅仅通过和该文件交互就能控制底层的任意设备。
/Applications/xxx
用户串口使用，通过调用device.c中的函数进行串口使用。例如使用下列api可以打开一个设备，其中的name则表示设备名字，如果我填写uart1，则打开的是串口1，如果我写spi，则就换成另外一种，当然前提是这些名字，在board初始化中被注册过。

//eg api
/* 查找系统中的串口设备,返回设备句柄 */
uart_device = rt_device_find(name); 
/* 注册接收回调 */
res = rt_device_set_rx_indicate(uart_device, uart_intput);
/* 打开设备，以可读写、中断方式 */
res = rt_device_open(uart_device, RT_DEVICE_OFLAG_RDWR|RT_DEVICE_FLAG_INT_RX );
/* 初始化事件对象 */
rt_event_init(&event, "event", RT_IPC_FLAG_FIFO);

交互无非就是读和写，对于IIC、SPI、UART都是相同的，这里调用的读函数也就是在device.c中被定义的

/** 写函数
 * @param 使用设备的句柄
 * @param 数据偏移
 * @param 待发送数据池的地址
 * @param 发送长度
 * @return 如果发送了实际大小则返回成功
 */
rt_size_t rt_device_write(rt_device_t dev,
                          rt_off_t    pos,
                          const void *buffer,
                          rt_size_t   size)

数据发送流程如下图所示

1.png

数据接收根据配置知道是采用中断方式，通过调用rt_device_set_rx_indicate已经注册了一个数据接收的回调，也就是当通过该设备接收到数据时，会触发该回调，然后通过下列读函数获取数据。

/**
 * 从设备中读取数据.
 * @param 读取设备的句柄
 * @param 读取是否偏移
 * @param 读取数据保存的buf
 * @param 读取的长度
 * @return 返回是否成功
 */
rt_size_t rt_device_read(rt_device_t dev,
                         rt_off_t    pos,
                         void       *buffer,
                         rt_size_t   size)

整体结构如下图所示:

2.png

按照这种层级编写，作为用户编写应用程序时，实际上除了用于被选中设备的设备名外，其余任何代码都是通用的，极大的提高了代码的复用性和便利性，例如编写了一个传感器驱动，无论它是使用IIC还是uart，在通信部分的代码是完全一样的，而唯一不同的仅仅是选择使用的设备的设备名称。

补充:
（本该是这样，但不知道官网上I2C设备应用笔记一章写的什么鬼，传感器设备直接调用了IIC。目前能够确保可靠的仅仅使用属于RT-Thread的设备驱动管理框架，至于硬件驱动并不属于操作系统，不能保证其代码合理性以及功能，第一步先看懂设备管理框架中的串口、IIC、SPI，然后检查硬件驱动原本的文件，对其增删改，再这个阶段没有问题的情况下进行应用层开发）