1）实验平台：正点原子ATK-DLRK3568开发板
2）平台购买地址：https://detail.tmall.com/item.htm?id=731866264428
3）全套实验源码+手册+视频下载地址： http://www.openedv.com/docs/boards/xiaoxitongban
第十六章 Linux阻塞和非阻塞IO实验
阻塞和非阻塞IO是Linux驱动开发里面很常见的两种设备访问模式，在编写驱动的时候一定要考虑到阻塞和非阻塞。本章我们就来学习一下阻塞和非阻塞IO，以及如何在驱动程序中处理阻塞与非阻塞，如何在驱动程序使用等待队列和poll机制。
16.1 阻塞和非阻塞IO
16.1.1 阻塞和非阻塞简介
这里的“IO”并不是我们学习单片机的时候所说的“GPIO”(也就是引脚)。这里的IO指的是Input/Output，也就是输入/输出，是应用程序对驱动设备的输入/输出操作。当应用程序对设备驱动进行操作的时候，如果不能获取到设备资源，那么阻塞式IO就会将应用程序对应的线程挂起，直到设备资源可以获取为止。对于非阻塞IO，应用程序对应的线程不会挂起，它要么一直轮询等待，直到设备资源可以使用，要么就直接放弃。阻塞式IO如图16.1.1.1所示：
图16.1.1.1 阻塞IO访问示意图。
图16.1.1.1中应用程序调用read函数从设备中读取数据，当设备不可用或数据未准备好的时候就会进入到休眠态。等设备可用的时候就会从休眠态唤醒，然后从设备中读取数据返回给应用程序。非阻塞IO如图16.1.2所示：
图16.1.1.2 非阻塞IO访问示意图
从图16.1.1.2可以看出，应用程序使用非阻塞访问方式从设备读取数据，当设备不可用或数据未准备好的时候会立即向内核返回一个错误码，表示数据读取失败。应用程序会再次重新读取数据，这样一直往复循环，直到数据读取成功。
应用程序可以使用如下所示示例代码来实现阻塞访问：
示例代码16.1.1.1 应用程序阻塞读取数据
1 int fd;
2 int data = 0;
3
4 fd = open("/dev/xxx_dev", O_RDWR); /* 阻塞方式打开 */
5 ret = read(fd, &data, sizeof(data)); /* 读取数据 */
从示例代码16.1.1.1可以看出，对于设备驱动文件的默认读取方式就是阻塞式的，所以我们前面所有的例程测试APP都是采用阻塞IO。
如果应用程序要采用非阻塞的方式来访问驱动设备文件，可以使用如下所示代码：
示例代码16.1.1.2 应用程序非阻塞读取数据
1 int fd;
2 int data = 0;
3
4 fd = open("/dev/xxx_dev", O_RDWR | O_NONBLOCK); /* 非阻塞方式打开 */
5 ret = read(fd, &data, sizeof(data)); /* 读取数据 */
第4行使用open函数打开“/dev/xxx_dev”设备文件的时候添加了参数“O_NONBLOCK”，表示以非阻塞方式打开设备，这样从设备中读取数据的时候就是非阻塞方式的了。
16.1.2 等待队列
1、等待队列头
阻塞访问最大的好处就是当设备文件不可操作的时候进程可以进入休眠态，这样可以将CPU资源让出来。但是，当设备文件可以操作的时候就必须唤醒进程，一般在中断函数里面完成唤醒工作。Linux内核提供了等待队列(wait queue)来实现阻塞进程的唤醒工作，如果我们要在驱动中使用等待队列，必须创建并初始化一个等待队列头，等待队列头使用结构体wait_queue_head表示，wait_queue_head结构体定义在文件include/linux/wait.h中，结构体内容如下所示：
示例代码16.1.2.1 wait_queue_head结构体
34 struct wait_queue_head {
35 spinlock_t lock;
36 struct list_head head;
37 };
38 typedef struct wait_queue_head wait_queue_head_t;
有些资料里面用wait_queue_head_t表示等待队列头，从38行可以看出，wait_queue_head_t是wait_queue_head的别名，这么做的目的是为了兼容老版本代码。最新版本的系统都用wait_queue_head表示等待队列头，如果你的代码要考虑移植到老版本linux内核中，那么最好使用wait_queue_head_t表示等待队列头。
定义好等待队列头以后需要初始化，使用init_waitqueue_head函数初始化等待队列头，函数原型如下：
void init_waitqueue_head(struct wait_queue_head *wq_head)
参数wq_head就是要初始化的等待队列头。
也可以使用宏DECLARE_WAIT_QUEUE_HEAD来一次性完成等待队列头的定义的初始化。
2、等待队列项
等待队列头就是一个等待队列的头部，每个访问设备的进程都是一个队列项，当设备不可用的时候就要将这些进程对应的队列项添加到等待队列里面。在以前的linux版本中使用结构体wait_queue_t表示等待队列项，在新版本的linux内核中已经删除了wait_queue_t，取而代之的是wait_queue_entry结构体(其实只是换了个名字，结构体内的成员变量还是一样的)，wait_queue_entry结构体内容如下：
示例代码16.1.2.2 wait_queue_entry结构体
27 struct wait_queue_entry {
28 unsigned int flags;
29 void *private;
30 wait_queue_func_t func;
31 struct list_head entry;
32 };
使用宏DECLARE_WAITQUEUE定义并初始化一个等待队列项，宏的内容如下：
DECLARE_WAITQUEUE(name, tsk)
name就是等待队列项的名字，tsk表示这个等待队列项属于哪个任务(进程)，一般设置为current，在Linux内核中current相当于一个全局变量，表示当前进程。因此宏DECLARE_WAITQUEUE就是给当前正在运行的进程创建并初始化了一个等待队列项。
3、将队列项添加/移除等待队列头
当设备不可访问的时候就需要将进程对应的等待队列项添加到前面创建的等待队列头中，只有添加到等待队列头中以后进程才能进入休眠态。当设备可以访问以后再将进程对应的等待队列项从等待队列头中移除即可，等待队列项添加API函数如下：
void add_wait_queue(struct wait_queue_head *wq_head,
struct wait_queue_entry *wq_entry)
函数参数和返回值含义如下：
wq_head：等待队列项要加入的等待队列头。
wq_entry：要加入的等待队列项。
返回值：无。
等待队列项移除API函数如下：
void remove_wait_queue(struct wait_queue_head *wq_head,
struct wait_queue_entry *wq_entry)
函数参数和返回值含义如下：
wq_head：要删除的等待队列项所处的等待队列头。
wq_entry：要删除的等待队列项。
返回值：无。
4、等待唤醒
当设备可以使用的时候就要唤醒进入休眠态的进程，唤醒可以使用如下两个函数：
void wake_up(struct wait_queue_head *wq_head)
void wake_up_interruptible(struct wait_queue_head *wq_head)
参数wq_head就是要唤醒的等待队列头，这两个函数会将这个等待队列头中的所有进程都唤醒。wake_up函数可以唤醒处于TASK_INTERRUPTIBLE和TASK_UNINTERRUPTIBLE状态的进程，而wake_up_interruptible函数只能唤醒处于TASK_INTERRUPTIBLE状态的进程。
5、等待事件
除了主动唤醒以外，也可以设置等待队列等待某个事件，当这个事件满足以后就自动唤醒等待队列中的进程，和等待事件有关的API函数如表16.1.2.1所示：
表16.1.2.1 等待事件API函数
16.1.3 轮询
如果用户应用程序以非阻塞的方式访问设备，设备驱动程序就要提供非阻塞的处理方式，也就是轮询。poll、epoll和select可以用于处理轮询，应用程序通过select、epoll或poll函数来查询设备是否可以操作，如果可以操作的话就从设备读取或者向设备写入数据。当应用程序调用select、epoll或poll函数的时候设备驱动程序中的poll函数就会执行，因此需要在设备驱动程序中编写poll函数。我们先来看一下应用程序中使用的select、poll和epoll这三个函数。
1、select函数
select函数原型如下：
int select(int nfds,
fd_set *readfds,
fd_set *writefds,
fd_set *exceptfds,
struct timeval *timeout)
函数参数和返回值含义如下：
nfds：所要监视的这三类文件描述集合中，最大文件描述符加1。
readfds、writefds和exceptfds：这三个指针指向描述符集合，这三个参数指明了关心哪些描述符、需要满足哪些条件等等，这三个参数都是fd_set类型的，fd_set类型变量的每一个位都代表了一个文件描述符。readfds用于监视指定描述符集的读变化，也就是监视这些文件是否可以读取，只要这些集合里面有一个文件可以读取那么seclect就会返回一个大于0的值表示文件可以读取。如果没有文件可以读取，那么就会根据timeout参数来判断是否超时。可以将readfs设置为NULL，表示不关心任何文件的读变化。writefds和readfs类似，只是writefs用于监视这些文件是否可以进行写操作。exceptfds用于监视这些文件的异常。
比如我们现在要从一个设备文件中读取数据，那么就可以定义一个fd_set变量，这个变量要传递给参数readfds。当我们定义好一个fd_set变量以后可以使用如下所示几个宏进行操作：
void FD_ZERO(fd_set *set)
void FD_SET(int fd, fd_set *set)
void FD_CLR(int fd, fd_set *set)
int FD_ISSET(int fd, fd_set *set)
FD_ZERO用于将fd_set变量的所有位都清零，FD_SET用于将fd_set变量的某个位置1，也就是向fd_set添加一个文件描述符，参数fd就是要加入的文件描述符。FD_CLR用户将fd_set变量的某个位清零，也就是将一个文件描述符从fd_set中删除，参数fd就是要删除的文件描述符。FD_ISSET用于测试一个文件是否属于某个集合，参数fd就是要判断的文件描述符。
timeout:超时时间，当我们调用select函数等待某些文件描述符可以设置超时时间，超时时间使用结构体timeval表示，结构体定义如下所示：
struct timeval {
long tv_sec; /* 秒 */
long tv_usec; /* 微妙 */
};
当timeout为NULL的时候就表示无限期的等待。
返回值：0，表示的话就表示超时发生，但是没有任何文件描述符可以进行操作；-1，发生错误；其他值，可以进行操作的文件描述符个数。
使用select函数对某个设备驱动文件进行读非阻塞访问的操作示例如下所示：
示例代码16.1.3.1 select函数非阻塞读访问示例
1 void main(void)
2 {
3 int ret, fd; /* 要监视的文件描述符 */
4 fd_set readfds; /* 读操作文件描述符集 */
5 struct timeval timeout; /* 超时结构体 */
6
7 fd = open("dev_xxx", O_RDWR | O_NONBLOCK); /* 非阻塞式访问 */
8
9 FD_ZERO(&readfds); /* 清除readfds */
10 FD_SET(fd, &readfds); /* 将fd添加到readfds里面 */
11
12 /* 构造超时时间 */
13 timeout.tv_sec = 0;
14 timeout.tv_usec = 500000; /* 500ms */
15
16 ret = select(fd + 1, &readfds, NULL, NULL, &timeout);
17 switch (ret) {
18 case 0: /* 超时 */
19 printf("timeout!\r\n");
20 break;
21 case -1: /* 错误 */
22 printf("error!\r\n");
23 break;
24 default: /* 可以读取数据 */
25 if(FD_ISSET(fd, &readfds)) { /* 判断是否为fd文件描述符 */
26 /* 使用read函数读取数据 */
27 }
28 break;
29 }
30 }
2、poll函数
在单个线程中，select函数能够监视的文件描述符数量有最大的限制，一般为1024，可以修改内核将监视的文件描述符数量改大，但是这样会降低效率！这个时候就可以使用poll函数，poll函数本质上和select没有太大的差别，但是poll函数没有最大文件描述符限制，Linux应用程序中poll函数原型如下所示：
int poll(struct pollfd *fds,
nfds_t nfds,
int timeout)
函数参数和返回值含义如下：
fds：要监视的文件描述符集合以及要监视的事件,为一个数组，数组元素都是结构体pollfd类型的，pollfd结构体如下所示：
struct pollfd {
int fd; /* 文件描述符 */
short events; /* 请求的事件 */
short revents; /* 返回的事件 */
};
fd是要监视的文件描述符，如果fd无效的话那么events监视事件也就无效，并且revents返回0。events是要监视的事件，可监视的事件类型如下所示：
POLLIN 有数据可以读取。
POLLPRI 有紧急的数据需要读取。
POLLOUT 可以写数据。
POLLERR 指定的文件描述符发生错误。
POLLHUP 指定的文件描述符挂起。
POLLNVAL 无效的请求。
POLLRDNORM 等同于POLLIN
revents是返回参数，也就是返回的事件，由Linux内核设置具体的返回事件。
nfds：poll函数要监视的文件描述符数量。
timeout：超时时间，单位为ms。
返回值：返回revents域中不为0的pollfd结构体个数，也就是发生事件或错误的文件描述符数量；0，超时；-1，发生错误，并且设置errno为错误类型。
使用poll函数对某个设备驱动文件进行读非阻塞访问的操作示例如下所示：
示例代码16.1.3.2 poll函数读非阻塞访问示例
1 void main(void)
2 {
3 int ret;
4 int fd; /* 要监视的文件描述符 */
5 struct pollfd fds;
6
7 fd = open(filename, O_RDWR | O_NONBLOCK); /* 非阻塞式访问 */
8
9 /* 构造结构体 */
10 fds.fd = fd;
11 fds.events = POLLIN; /* 监视数据是否可以读取 */
12
13 ret = poll(&fds, 1, 500); /* 轮询文件是否可操作，超时500ms */
14 if (ret) { /* 数据有效 */
15 ......
16 /* 读取数据 */
17 ......
18 } else if (ret == 0) { /* 超时 */
19 ......
20 } else if (ret < 0) { /* 错误 */
21 ......
22 }
23 }
3、epoll函数
传统的selcet和poll函数都会随着所监听的fd数量的增加，出现效率低下的问题，而且poll函数每次必须遍历所有的描述符来检查就绪的描述符，这个过程很浪费时间。为此，epoll应运而生，epoll就是为处理大并发而准备的，一般常常在网络编程中使用epoll函数。应用程序需要先使用epoll_create函数创建一个epoll句柄，epoll_create函数原型如下：
int epoll_create(int size)
函数参数和返回值含义如下：
size：从Linux2.6.8开始此参数已经没有意义了，随便填写一个大于0的值就可以。
返回值：epoll句柄，如果为-1的话表示创建失败。
epoll句柄创建成功以后使用epoll_ctl函数向其中添加要监视的文件描述符以及监视的事件，epoll_ctl函数原型如下所示：
int epoll_ctl(int epfd,
int op,
int fd,
struct epoll_event *event)
函数参数和返回值含义如下：
epfd：要操作的epoll句柄，也就是使用epoll_create函数创建的epoll句柄。
op：表示要对epfd(epoll句柄)进行的操作，可以设置为：
EPOLL_CTL_ADD 向epfd添加文件参数fd表示的描述符。
EPOLL_CTL_MOD 修改参数fd的event事件。
EPOLL_CTL_DEL 从epfd中删除fd描述符。
fd：要监视的文件描述符。
event：要监视的事件类型，为epoll_event结构体类型指针，epoll_event结构体类型如下所示：
struct epoll_event {
uint32_t events; /* epoll事件 */
epoll_data_t data; /* 用户数据 */
};
结构体epoll_event的events成员变量表示要监视的事件，可选的事件如下所示：
EPOLLIN 有数据可以读取。
EPOLLOUT 可以写数据。
EPOLLPRI 有紧急的数据需要读取。
EPOLLERR 指定的文件描述符发生错误。
EPOLLHUP 指定的文件描述符挂起。
EPOLLET 设置epoll为边沿触发，默认触发模式为水平触发。
EPOLLONESHOT 一次性的监视，当监视完成以后还需要再次监视某个fd，那么就需要将fd重新添加到epoll里面。
上面这些事件可以进行“或”操作，也就是说可以设置监视多个事件。
返回值：0，成功；-1，失败，并且设置errno的值为相应的错误码。
一切都设置好以后应用程序就可以通过epoll_wait函数来等待事件的发生，类似select函数。epoll_wait函数原型如下所示：
int epoll_wait(int epfd,
struct epoll_event *events,
int maxevents,
int timeout)
函数参数和返回值含义如下：
epfd：要等待的epoll。
events：指向epoll_event结构体的数组，当有事件发生的时候Linux内核会填写events，调用者可以根据events判断发生了哪些事件。
maxevents：events数组大小，必须大于0。
timeout：超时时间，单位为ms。
返回值：0，超时；-1，错误；其他值，准备就绪的文件描述符数量。
epoll更多的是用在大规模的并发服务器上，因为在这种场合下select和poll并不适合。当设计到的文件描述符(fd)比较少的时候就适合用selcet和poll，本章我们就使用sellect和poll这两个函数。
16.1.4 Linux驱动下的poll操作函数
当应用程序调用select或poll函数来对驱动程序进行非阻塞访问的时候，驱动程序file_operations操作集中的poll函数就会执行。所以驱动程序的编写者需要提供对应的poll函数，poll函数原型如下所示：
unsigned int (*poll) (struct file *filp, struct poll_table_struct *wait)
函数参数和返回值含义如下：
filp：要打开的设备文件(文件描述符)。
wait：结构体poll_table_struct类型指针，由应用程序传递进来的。一般将此参数传递给poll_wait函数。
返回值:向应用程序返回设备或者资源状态，可以返回的资源状态如下：
POLLIN 有数据可以读取。
POLLPRI 有紧急的数据需要读取。
POLLOUT 可以写数据。
POLLERR 指定的文件描述符发生错误。
POLLHUP 指定的文件描述符挂起。
POLLNVAL 无效的请求。
POLLRDNORM 等同于POLLIN，普通数据可读
我们需要在驱动程序的poll函数中调用poll_wait函数，poll_wait函数不会引起阻塞，只是将应用程序添加到poll_table中，poll_wait函数原型如下：
void poll_wait(struct file * filp, wait_queue_head_t * wait_address, poll_table *p)
参数wait_address是要添加到poll_table中的等待队列头，参数p就是poll_table，就是file_operations中poll函数的wait参数。
16.2 阻塞IO实验
在上一章Linux中断实验中，我们直接在应用程序中通过read函数不断的读取按键状态，当按键有效的时候就打印出按键值。这种方法有个缺点，那就是keyirqApp这个测试应用程序拥有很高的CPU占用率，大家可以在开发板中加载上一章的驱动程序模块keyirq.ko，然后以后台运行模式打开keyirqApp这个测试软件，命令如下：
./keyirqApp /dev/keyirq &
测试驱动是否正常工作，如果驱动工作正常的话输入“top”命令，top命令打开资源界面以后输入大写“P”，按照CPU使用率从高到低排序。可以看到keyirqApp这个应用程序的CPU使用率，结果如图16.2.1所示：
图16.2.1 CPU使用率
从图16.2.1可以看出，keyirqApp这个应用程序的CPU使用率竟然高达100%，这仅仅是一个读取按键值的应用程序，这么高的CPU使用率显然是有问题的！原因就在于我们是直接在while循环中通过read函数读取按键值，因此keyirqApp这个软件会一直运行，一直读取按键值，CPU使用率肯定就会很高。最好的方法就是在没有有效的按键事件发生的时候，keyirqApp这个应用程序应该处于休眠状态，当有按键事件发生以后keyirqApp这个应用程序才运行，打印出按键值，这样就会降低CPU使用率，本小节我们就使用阻塞IO来实现此能。
16.2.1 硬件原理图分析
本章实验硬件原理图参考13.2小节即可。
16.2.2 实验程序编写
1、驱动程序编写
本实验对应的例程路径为：开发板光盘01、程序源码Linux驱动例程13_blockio。
本章实验我们在上一章的“12_irq”实验的基础上完成，主要是对其添加阻塞访问相关的代码。新建名为“13_blockio”的文件夹，然后在13_blockio文件夹里面创建vscode工程，工作区命名为“blockio”。将“12_irq”实验中的keyirq.c复制到13_blockio文件夹中，并重命名为blockio.c。接下来我们就修改blockio.c这个文件，在其中添加阻塞相关的代码，完成以后的blockio.c内容如下所示(因为是在上一章实验的keyirq.c文件的基础上修改的，为了减少篇幅，下面的代码有省略)：
示例代码 16.2.2.1 blockio.c 文件代码(有省略)
41 /* key设备结构体 */
42 struct key_dev{
43 dev_t devid; /* 设备号 */
44 struct cdev cdev; /* cdev */
45 struct class *class; /* 类 */
46 struct device *device; /* 设备 */
47 struct device_node *nd; /* 设备节点 */
48 int key_gpio; /* key所使用的GPIO编号 */
49 struct timer_list timer; /* 按键值 */
50 int irq_num; /* 中断号 */
51
52 atomic_t status; /* 按键状态 */
53 wait_queue_head_t r_wait; /* 读等待队列头 */
54 };
......
150 static void key_timer_function(struct timer_list *arg)
151 {
152 static int last_val = 0;
153 int current_val;
154
155 /* 读取按键值并判断按键当前状态 */
156 current_val = gpio_get_value(key.key_gpio);
157 if (1 == current_val && !last_val){
158 atomic_set(&key.status, KEY_PRESS); /* 按下 */
159 wake_up_interruptible(&key.r_wait);
160 }
161 else if (0 == current_val && last_val) {
162 atomic_set(&key.status, KEY_RELEASE); /* 松开 */
163 wake_up_interruptible(&key.r_wait);
164 }
165 else
166 atomic_set(&key.status, KEY_KEEP); /* 状态保持 */
167
168 last_val = current_val;
169 }
170
171 /*
172 * @description : 打开设备
173 * @param – inode : 传递给驱动的inode
174 * @param - filp : 设备文件，file结构体有个叫做private_data的成员变量
175 * 一般在open的时候将private_data指向设备结构体。
176 * @return : 0 成功;其他 失败
177 */
178 static int key_open(struct inode *inode, struct file *filp)
179 {
180 return 0;
181 }
182
183 /*
184 * @description : 从设备读取数据
185 * @param – filp : 要打开的设备文件(文件描述符)
186 * @param – buf : 返回给用户空间的数据缓冲区
187 * @param – cnt : 要读取的数据长度
188 * @param – offt : 相对于文件首地址的偏移
189 * @return : 读取的字节数，如果为负值，表示读取失败
190 */
191 static ssize_t key_read(struct file *filp, char __user *buf,
192 size_t cnt, loff_t *offt)
193 {
194 int ret;
195
196 /* 加入等待队列，当有按键按下或松开动作发生时，才会被唤醒 */
197 ret = wait_event_interruptible(key.r_wait, KEY_KEEP !=
atomic_read(&key.status));
198 if(ret)
199 return ret;
200
201 /* 将按键状态信息发送给应用程序 */
202 ret = copy_to_user(buf, &key.status, sizeof(int));
203
204 /* 状态重置 */
205 atomic_set(&key.status, KEY_KEEP);
206
207 return ret;
208 }
......
242 /*
243 * @description : 驱动入口函数
244 * @param : 无
245 * @return : 无
246 */
247 static int __init mykey_init(void)
248 {
249 int ret;
250
251 /* 初始化等待队列头 */
252 init_waitqueue_head(&key.r_wait);
253
254 /* 初始化timer，设置定时器处理函数,还未设置周期，所有不会激活定时器 */
255 timer_setup(&key.timer, key_timer_function, 0);
256
257 /* 初始化按键状态 */
258 atomic_set(&key.status, KEY_KEEP);
......
311 }
......
第42~54行，我们删除了设备结构体struct key_dev中的自旋锁变量，本章驱动代码我们不用自旋锁，而改成第52行的原子变量来实现对相应变量的保护操作。第53行添加了一个等待队列头r_wait，因为在Linux驱动中处理阻塞IO需要用到等待队列，而等待队列会使进程进入休眠状态，所以不能使用自旋锁！
第150~169行，定时器定时处理函数key_timer_function，对按键状态进行判断，如果是按下动作或是松开动作则会使用wake_up_interruptible函数唤醒等待队列，并且将status变量设置为KEY_PRESS或KEY_RELEASE；这样在key_read函数中阻塞的进程就会解除阻塞继续进行下面的操作。
第191~208行，key_read函数，在这个函数中我们会判断按键是否有按下或松开动作发生时，如果没有则调用wait_event_interruptible把它加入等待队列当中，进行阻塞。如果等待队列被唤醒并且条件“KEY_KEEP != atomic_read(&status)”成立，则解除阻塞，继续下面的操作，也就是读取按键状态数据将其发送给应用程序。因为采用了wait_event_interruptible函数，因此进入休眠态的进程可以被信号打断。在该函数中我们读取status原子变量必须要使用atomic_read函数进行操作。
第252行，在驱动入口函数中我们会调用init_waitqueue_head初始化等待队列头；第258行使用原子操作atomic_set设置按键的初始状态status为KEY_KEEP。
使用等待队列实现阻塞访问重点注意两点：
①、将任务或者进程加入到等待队列头，
②、在合适的点唤醒等待队列，一般是中断处理函数里面。
2、编写测试APP
本节实验的测试APP直接使用12_irq实验目录下的keyirqApp.c测试程序，将keyirqApp.c复制到本实验目录13_blockio中，重命名为blockApp.c，不需要修改任何内容。
16.2.3 运行测试
1、编译驱动程序和测试APP
①、编译驱动程序
编写Makefile文件，本章实验的Makefile文件和第五章实验基本一样，只是将obj-m变量的值改为blockio.o，Makefile内容如下所示：
示例代码16.2.3.1 Makefile文件
1 KERNELDIR := /home/alientek/rk3568_linux_sdk/kernel
......
4 obj-m := blockio.o
......
11 clean:
12 $(MAKE) -C $(KERNELDIR) M=$(CURRENT_PATH) clean
第4行，设置obj-m变量的值为blockio.o。
输入如下命令编译出驱动模块文件：
make ARCH=arm64 //ARCH=arm64必须指定，否则编译会失败
编译成功以后就会生成一个名为“blockio.ko”的驱动模块文件。
②、编译测试APP
输入如下命令编译测试blockioApp.c这个测试程序：
/opt/atk-dlrk356x-toolchain/bin/aarch64-buildroot-linux-gnu-gcc blockioApp.c -o blockioApp
编译成功以后就会生成blcokioApp这个应用程序。
2、运行测试
在Ubuntu中将上一小节编译出来的blockio.ko和blockioApp这两个文件通过adb命令发送到开发板的/lib/modules/4.19.232目录下，命令如下：
adb push blockio.ko blockioApp /lib/modules/4.19.232
发送成功以后进入到开发板目录lib/modules/4.19.232中，输入如下命令加载blockio.ko驱动模块：
depmod //第一次加载驱动的时候需要运行此命令
modprobe blockio //加载驱动
驱动加载成功以后使用如下命令打开blockioApp这个测试APP，并且以后台模式运行：
./blockioApp /dev/key &
使用杜邦线将图13.2.1中GPIO3_C5这个IO接到开发板的3.3V电压上，模拟按键被按下，结果如图16.2.3.1所示：
图16.2.3.1 测试APP运行测试
首先输入“ps -aux”命令查看blockioApp这个进程的PID，比如在我的开饭上如图16.2.3.2 所示：
图16.2.3.2 图16.2.3.2 blockioApp的PID
从图16.2.3.2可以看出，blockioApp的PID为972，我们可以输入：
top -p 867 //查看PID为867的进程资源信息
上面就是使用top命令只查看PID为972这个进程的资源消耗情况，如图16.2.3.3所示：
图16.2.3.3 应用程序CPU使用率
从图16.2.3.3可以看出，当我们在按键驱动程序里面加入阻塞访问以后，blockioApp这个应用程序的CPU使用率从图16.2.1中的100%降低到了0%。大家注意，这里的0%并不是说blockioApp这个应用程序不使用CPU了，只是因为使用率太小了，CPU使用率可能为0.00001%，但是图16.2.3.3是没有小数点显示的，因此就显示成了0%。
我们可以使用“kill”命令关闭后台运行的应用程序，比如我们关闭掉blockioApp这个后台运行的应用程序。首先输出“Ctrl+C”关闭top命令界面，进入到命令行模式。然后使用“ps -aux”命令查看一下blockioApp这个应用程序的PID，这个前面已经做了，也就是图16.2.3.2中的972。
使用“kill -9 PID”即可“杀死”指定PID的进程，比如我们现在要“杀死”PID为972的blockioApp应用程序，可是使用如下命令：
kill -9 867
输入上述命令以后终端显示如图16.2.3.4所示：
图16.2.3.4 kill命令输出结果
从图16.2.3.4可以看出，“./blockioApp /dev/key”这个应用程序已经被“杀掉”了，在此输入“ps”命令查看当前系统运行的进程，会发现blockioApp已经不见了。这个就是使用kill命令“杀掉”指定进程的方法。
16.3 非阻塞IO实验
16.3.1 硬件原理图分析
本章实验硬件原理图参考13.2小节即可。
16.3.2 实验程序编写
1、驱动程序编写
本实验对应的例程路径为：开发板光盘01、程序源码Linux驱动例程14_noblockio。
本章实验我们在16.2小节中的“13_blockio”实验的基础上完成，上一小节实验我们已经在驱动中添加了阻塞IO的代码，本小节我们继续完善驱动，加入非阻塞IO驱动代码。新建名为“14_noblockio”的文件夹，然后在14_noblockio文件夹里面创建vscode工程，工作区命名为“noblockio”。将“13_blockio”实验中的blockio.c复制到14_noblockio文件夹中，并重命名为noblockio.c。接下来我们就修改noblockio.c这个文件，在其中添加非阻塞相关的代码，完成以后的noblockio.c内容如下所示(因为是在上一小节实验的blockio.c文件的基础上修改的，为了减少篇幅，下面的代码有省略)：
示例代码16.3.3.1 noblockio.c文件(有省略)
......
27 #include <linux/wait.h>
28 #include <linux/poll.h>
29 //#include <asm/mach/map.h>
30 #include <asm/uaccess.h>
31 #include <asm/io.h>
32
......
185 /*
186 * @description : 从设备读取数据
187 * @param – filp : 要打开的设备文件(文件描述符)
188 * @param – buf : 返回给用户空间的数据缓冲区
189 * @param – cnt : 要读取的数据长度
190 * @param – offt : 相对于文件首地址的偏移
191 * @return : 读取的字节数，如果为负值，表示读取失败
192 */
193 static ssize_t key_read(struct file *filp, char __user *buf,
194 size_t cnt, loff_t *offt)
195 {
196 int ret;
197
198 if (filp->f_flags & O_NONBLOCK) { /*非阻塞方式访问 */
199 if(KEY_KEEP == atomic_read(&key.status))
200 return -EAGAIN;
201 } else { /* 阻塞方式访问 */
202 /* 加入等待队列，当有按键按下或松开动作发生时，才会被唤醒 */
203 ret = wait_event_interruptible(key.r_wait, KEY_KEEP !=
atomic_read(&key.status));
204 if(ret)
205 return ret;
206 }
207 /* 将按键状态信息发送给应用程序 */
208 ret = copy_to_user(buf, &key.status, sizeof(int));
209
210 /* 状态重置 */
211 atomic_set(&key.status, KEY_KEEP);
212
213 return ret;
214 }
......
239 /*
240 * @description : poll函数，用于处理非阻塞访问
241 * @param – filp : 要打开的设备文件(文件描述符)
242 * @param - wait : 等待列表(poll_table)
243 * @return : 设备或者资源状态，
244 */
245 static unsigned int key_poll(struct file *filp,
struct poll_table_struct *wait)
246 {
247 unsigned int mask = 0;
248
249 poll_wait(filp, &key.r_wait, wait);
250
251 if(KEY_KEEP != atomic_read(&key.status))/* 按键按下或松开动作发生 */
252 mask = POLLIN | POLLRDNORM; /* 返回PLLIN */
253
254 return mask;
255 }
256
257 /* 设备操作函数 */
258 static struct file_operations key_fops = {
259 .owner = THIS_MODULE,
260 .open = key_open,
261 .read = key_read,
262 .write = key_write,
263 .release = key_release,
264 .poll = key_poll,
265 };
......
第28行，使用include将内核源码目录include/linux/poll.h头文件包含进来。
第193~214行，key_read函数中判断是否为非阻塞式读取访问，如果是的话就判断按键状态是否有效，也就是判断是否产生了按下或松开这样的动作，如果没有的话就返回-EAGAIN。
第245255行，key_poll函数就是file_operations驱动操作集中的poll函数，当应用程序调用select或者poll函数的时候key_poll函数就会执行。第249行调用poll_wait函数将等待队列头添加到poll_table中，第251252行判断按键是否有效，如果按键有效的话就向应用程序返回POLLIN这个事件，表示有数据可以读取。
第264行，设置file_operations的poll成员变量为key_poll。
2、编写测试APP
新建名为noblockioApp.c测试APP文件，然后在其中输入如下所示内容：
示例代码16.3.3.2 noblockioApp.c文件代码
12 #include <stdio.h>
13 #include <unistd.h>
14 #include <sys/types.h>
15 #include <sys/stat.h>
16 #include <fcntl.h>
17 #include <stdlib.h>
18 #include <string.h>
19 #include <poll.h>
20
21 /*
22 * @description : main主程序
23 * @param – argc : argv数组元素个数
24 * @param – argv : 具体参数
25 * @return : 0 成功;其他 失败
26 */
27 int main(int argc, char *argv[])
28 {
29 fd_set readfds;
30 int key_val;
31 int fd;
32 int ret;
33
34 /* 判断传参个数是否正确 */
35 if(2 != argc) {
36 printf("Usage:\n"
37 "\t./keyApp /dev/key\n"
38 );
39 return -1;
40 }
41
42 /* 打开设备 */
43 fd = open(argv[1], O_RDONLY | O_NONBLOCK);
44 if(0 > fd) {
45 printf("ERROR: %s file open failed!\n", argv[1]);
46 return -1;
47 }
48
49 FD_ZERO(&readfds);
50 FD_SET(fd, &readfds);
51
52 /* 循环轮训读取按键数据 */
53 for ( ; ; ) {
54
55 ret = select(fd + 1, &readfds, NULL, NULL, NULL);
56 switch (ret) {
57
58 case 0: /* 超时 */
59 /* 用户自定义超时处理 */
60 break;
61
62 case -1: /* 错误 */
63 /* 用户自定义错误处理 */
64 break;
65
66 default:
67 if(FD_ISSET(fd, &readfds)) {
68 read(fd, &key_val, sizeof(int));
69 if (0 == key_val)
70 printf("Key Press\n");
71 else if (1 == key_val)
72 printf("Key Release\n");
73 }
74
75 break;
76 }
77 }
78
79 /* 关闭设备 */
80 close(fd);
81 return 0;
82 }
第53~77行，在本测试程序中我们使用select函数来实现非阻塞访问，在for循环中使用select函数不断的轮询，检查驱动程序是否有数据可以读取，如果可以读取的话就调用read函数读取按键数据。大家也可以试试使用poll函数来实现！
16.3.3 运行测试
1、编译驱动程序和测试APP
①、编译驱动程序
编写Makefile文件，本章实验的Makefile文件和第五章实验基本一样，只是将obj-m变量的值改为noblockio.o，Makefile内容如下所示：
示例代码16.3.3.1 Makefile文件
1KERNELDIR := /home/alientek/rk3568_linux_sdk/kernel
......
4 obj-m := noblockio.o
......
11 clean:
12 $(MAKE) -C $(KERNELDIR) M=$(CURRENT_PATH) clean
第4行，设置obj-m变量的值为noblockio.o。
输入如下命令编译出驱动模块文件：
make ARCH=arm64 //ARCH=arm64必须指定，否则编译会失败
编译成功以后就会生成一个名为“noblockio.ko”的驱动模块文件。
②、编译测试APP
输入如下命令编译测试noblockioApp.c这个测试程序：
/opt/atk-dlrk356x-toolchain/bin/aarch64-buildroot-linux-gnu-gcc noblockioApp.c -o noblockioApp
编译成功以后就会生成noblcokioApp这个应用程序。
2、运行测试
在Ubuntu中将上一小节编译出来的noblockio.ko和noblockioApp这两个文件通过adb命令发送到开发板的/lib/modules/4.19.232目录下，命令如下：
adb push noblockio.ko noblockioApp /lib/modules/4.19.232
发送成功以后进入到开发板目录lib/modules/4.19.232中，输入如下命令加载noblockio.ko驱动模块：
depmod //第一次加载驱动的时候需要运行此命令
modprobe noblockio //加载驱动
驱动加载成功以后使用如下命令打开noblockioApp这个测试APP，并且以后台模式运行：
./noblockioApp /dev/key &
使用杜邦线将图13.2.1中GPIO3_C5这个IO接到开发板的3.3V电压上，模拟按键被按下，结果如图16.3.3.1所示：
图16.3.3.1 测试APP运行测试
当GPIO3_C5接到3.3V以后，模拟按键按下，noblockioApp这个测试APP就会打印出按键信息。使用top命令查看noblockioAPP这个应用APP的CPU使用率，如图16.3.3.2所示：
图16.3.3.2 应用程序CPU使用率
从图16.3.3.2可以看出，采用非阻塞方式读处理以后，noblockioApp的CPU占用率也低至0%，和图16.2.3.3中的blockioApp一样，这里的0%并不是说noblockioApp这个应用程序不使用CPU了，只是因为使用率太小了。
如果要“杀掉”处于后台运行模式的noblockioApp这个应用程序，可以参考16.2.3小节讲解的方法。
扫一扫
457
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
