前言:苦串口驱动久矣!
现状
串口驱动三种工作模式:轮询、中断、DMA。
轮询模式占用 CPU 最高,但是实现也是最简单的;DMA 占用 CPU 最少,实现也是最麻烦的;中断模式居中。
原串口驱动有以下几个问题:
1、中断模式,接收有缓存,发送没缓存
2、中断模式,读操作是非阻塞的,没有阻塞读;写操作因为没有缓存,只能阻塞写,没有非阻塞写。
3、中断接收过程,每往发送寄存器填充一个字符,就使用完成量等待发送完成中断,通过完成量进行进程调度次数和发送数据量同样多!
4、DMA 模式比较复杂,在实现上更复杂。
首先,接收有两种缓存方案,一种没有缓存,借用应用层的内存直接做 DMA 接收缓存;一种有缓存,用的和中断模式下相同的 fifo 数据结构。发送只有一种缓存方式,把应用层内存放到数据队列里做发送缓存。
无论哪种缓存方案,都没有考虑阻塞的问题。而是抛给串口驱动一个内存地址,就返回到应用层了。应用层要么动用
rt_device_set_rx_indicate
rt_device_set_tx_complete
做同步——退化成 poll 模式,失去了 DMA 的优势;要么继续干其它工作——抛给串口驱动的内存可能引入隐患为了防止 DMA 工作的时候又有新的读写需求,
对串口驱动的期望
轮询模式不在今天讨论计划内。下面所有的讨论都只涉及中断和 DMA 两种模式。
无论哪种工作模式,都应该有至少一级缓存机制。
无论哪种工作模式,都应该可以设置成阻塞或者非阻塞。
默认是阻塞 io 模式;如果想用非阻塞工作模式,可以通过 open 或者 control 修改。
读写阻塞特性是同步的,不存在阻塞写非阻塞读或者非阻塞写阻塞读两种模式。
阻塞读的过程是,没有数据永久阻塞;有数据无论多少(小于等于期望数据量),返回读取的数据量。
阻塞写的过程是,缓存空间为 0 阻塞等待缓存被释放;缓存空间不足先填满缓存,继续等待缓存被释放;缓存空间足够,把应用层数据拷贝到驱动缓存。最后返回搬到缓存的数据量。
非阻塞读的过程是,没有数据返回 0;有数据,从 fifo 拷贝数据到应用层提供的内存,返回拷贝的数据量。
非阻塞写的过程是,缓存为 0 ,返回 0;缓存不足返回写成功了多少数据;缓存足够,把数据搬移完,返回写成功的数据量。
无论是轮询、中断、DMA 哪种模式,都应该可以实现 STREAM 特性。
中断模式下的理论实践
注:以下实现是在 NUC970 上完成的,有些特性可能不是通用的。例如,串口外设自带硬件 fifo ,uart1 是高速 uart 设备,fifo 有 64 字节。uart3 的 fifo 就只有 16 字节。
定义缓存数据结构
为实现上述需求,接收和发送都需要有如下一个 fifo
1struct rt_serial_fifo
2{
3 rt_uint32_t buf_sz;
4 /* software fifo buffer */
5 rt_uint8_t *buffer;
6
7 rt_uint16_t put_index, get_index;
8
9 rt_bool_t is_full;
10};
注:别问我为啥不用 ringbuffer
大部分还是借用 struct rt_serial_rx_fifo
的实现的。增加了个 buf_sz
由 fifo 自己维护自己的缓存容量
针对 fifo 特意定义了三个函数,