之前我们完成了关于通过查询的方式获取按键键值的驱动程序，可以参考：嵌入式Linux开发——裸板程序之中断控制器。
虽然读取键值没有什么问题，但是测试程序占用CPU过高，一直在不断的查询，资源消耗过大，这个问题非常严重，我们必须要来解决一下。但是在解决这个问题之前，我们先来思考一个问题，除了不断的这样 read，是不是还有其他的方法可以获取按键的键值呢？自然是有的，这个方式就是通过终端的方式来获取键值。 如果举一个例子，小明在家等小华给他送东西，有什么方式不会错过呢？他可以不断的去门口查看，其实这就是我们之前的方式，不断的让应用程序去read，这时候自然小明大量的精力都消耗在了不断的查看过程中，他想做别的事的时间和精力也会被不断的查看而占用。
为了这个解决这个问题，方法很多，我们先来说其中一个普通的，就是小明家安装一个门铃，小华到了，按下门铃，这时候小明去开门就可以了。这时候，小明在家做其他事，也就不会被打扰了，节省了大量的资源。 其实上面的故事很平常，但是实际上，第一种方式就是不断查询的方式，虽然不会错过小华，但是消耗了大量资源，一定是不可以采用的。而第二种方式有点类似于今天要说的——中断模式。 当发生了某件事，这件事作为一个中断，处理完了这个中断后，在恢复去执行另外一件事。 简单总结一下：

• 单片机程序处理中断的过程
  1. 按键按下，中断发生
  2. CPU发生中断，跳转到异常向量入口进行执
     a. 保存被中断的现场（寄存器的值）
     b. 判断中断的来源，执行中断处理函数，清中断
     c. 恢复被中断的现场，继续执行

那么对于Linux嵌入式来说，处理中断是不是相同呢？
对于Linux来说，处理流程也是相同的，肯定需要先设置异常向量，不然都不知道该调用谁来处理。同样也需要分辨 异常的来源，毕竟按下每个键都应该执行不同的任务。同样，不能因为按下按键，恢复以后之前的程序就不继续执行了（reset除外）。所以，裸板程序中处理异常事件的流程在Linux下都是成立的，只是这些代码都是由系统帮我们实现的，不需要我们自己来实现。那么我们就需要使用好。那么，我们可以来思考一下，对于以上流程，哪一个对于系统来说没办法帮我们代劳，必须我们自己来完成呢？那么这个过程对我们来说肯定是需要关注的了。 其实，不难想到，以上的处理流程里面，分析中断源、中断处理函数这些部分一定是系统没办法帮我们代劳的。不但这些内容和硬件相关性比较高，同时，我们想要如何处理，也都不一定相同。 ARM架构下的Linux的异常处理原理如下图：

• 按下按键
• CPU进入异常模式
  b vector_irq + stubs_offset，vector_irq是使用宏来定义的。在这个宏中调用__irq_xxxx的列表，其中会做对现场进行相应的保存的工作
• 最终会调用到asm_do_IRQ
  • 其中调用desc_handle_irq(irq, desc)
  • 调用desc->handle_irq(irq, desc)以中断号为下标取出handle_irq，在其中调用irq_desc[irq] -> handle_irq，irq_desc实际是一个结构体数组
• handle_irq 就等于handle_edge_irq`
  • 其中主要做了desc0>chip->ack(irq)清中断
  • 调用handle_IRQ_event来处理中断，
    • 取出action链表中的成员
    • 执行action->handler

那么如何才能将自己的中断处理加入到终端框架中

1. 注册中断：：request_irq(unsigned int irq, irq_handler_t handler, unsigned long irqflags, const char * devname, void * dev_id)：
   irq为中断号，handler为处理函数，irqflags为上升沿触发、下降沿触发、边缘触发等标志，devname为设备名，dev_id为设备号
   实际背后做了以下工作：
   • 分配irq_action结构，以上成员都指向传入的参数
   • 调用setut_irq(irq, action)，传入中断号和irqaction结构
     • 找到irq_desc[irq]，并在irq_desc[irq] -> action链表中，加入之前构造的action结构体
     • desc->chip->set_type(irq, new->flags & IRQF_TRIGGER_MASK)：将对应的引脚设置为中断引脚
     • desc->chip->startup或desc->chip->enable：使能中断
2. free_irq(irq, dev_id)：来解除中断（出链，禁止中断）

说了这么多，还是老规矩，先来看看一个按键的中断框架是如何，然后我们再来考虑该如区分不同的中断 #include #include #include #include #include #include #include #include #include static const char* dev_name = "first_eint"; static unsigned int major = 0; static struct class* first_class; static struct class_device* first_class_device; //中断的处理函数 static irqreturn_t irq_handler(int irq, void *dev_id) { printk("Interrupted! "); return 0; } static int first_open (struct inode *inode, struct file *file) { //int request_irq(unsigned int irq, irq_handler_t handler, // unsigned long irqflags, const char *devname, void *dev_id) //IRQ_EINT0：中断号，定义在includeasm-armarchirqs.h中 // IRQ_TYPE_EDGE_BOTH：双边缘触发，定义在includelinuxirq.h中 request_irq(IRQ_EINT0, irq_handler, IRQ_TYPE_EDGE_BOTH, dev_name, major); return 0; } static int first_release (struct inode *inode, struct file *file) { printk("release "); //void free_irq(unsigned int irq, void *dev_id) free_irq(IRQ_EINT0, major); return 0; } static struct file_operations first_fops = { .owner = THIS_MODULE, .open = first_open, .release= first_release, }; static int __init first_init(void) { major = register_chrdev(major, dev_name, &first_fops); first_class = class_create(THIS_MODULE, dev_name); first_class_device = class_device_create(first_class, NULL, MKDEV(major, 0), NULL, dev_name); return 0; } static void __exit first_exit(void) { unregister_chrdev(major, dev_name); class_device_unregister(first_class_device); class_destroy(first_class); } module_init(first_init); module_exit(first_exit); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Ethan Lee <4128127@qq.com>"); 这个驱动还是很简单的，主要用到了我们之前讲的驱动框架，在open的时候会注册中断，使用了request_irq，在release中，调用了free_irq来释放了注册的中断。 Makefile KERN_DIR=/code/LinuxDev/Lab/KernelOfLinux/linux-2.6.22.6 #内核目录 all: make -C $(KERN_DIR) M=`pwd` modules #M=`pwd`表示，生成的目标放在pwd命令的目录下 # -C代表使用目录中的Makefile来进行编译 clean: make -C $(KERN_DIR) M=`pwd` modules clean rm -f modules.order obj-m += first.o #加载到module的编译链中，内核会编译生成出来ko文件，作为一个模块 最后就是测试程序了 #include #include #include #include int main() { int cnt = 15; int fd = open("/dev/first_eint", O_RDWR); if(fd < 0) { printf("open error "); return -1; } while(cnt--){ //十五秒后如果自动结束程序 if(!(cnt % 5)) printf("count = %d ", cnt); sleep(1); } printf("time out "); close(fd); return 0; } 执行结果：
执行结果
后台执行，占用资源的情况 以上已经实现了中断程序的框架结构，主要用到的了request_irq和free_irq两个函数。只要设备文件被打开，当按钮被按下，就会触发中断函数的调用。当时对于上面的代码来说，还不够完善，因为它只能够处理一个按键的信息，我们希望开发板上的按键都可以注册在驱动程序中统一管理。并且前端可以通过read函数来获取键值。现在我们的程序来说，虽然资源占用降低了，但是实际测试程序并没有进行read操作，仅仅是sleep。如果测试程序不断的去读取键值，那么，占用资源的情况依然很难得到缓解。 为了解决以上的问题，可以让前端的程序不断的read的驱动程序所提供的键值，那么，这时候可以有这样一个思路来解决。
read函数的大致调用流程如下：
当测试程序调用了read函数->通过sys_read等系统调用->调用驱动函数中的read函数。
我们采用一种阻塞式的方法来讲驱动函数中的read函数进行阻塞处理，如果没有发生中断就让程序睡眠。如果中断发生，那么，一定会调用中断处理函数，在中断处理函数中讲程序唤醒。以此来解决测试程序read的时候占用资源较多的情况。既然测试程序已经可以read数据，那么，多个键值的问题其实也就引刃而解了。 #include #include #include #include #include #include #include #include #include #include #include #include static const char* dev_name = "third_eint"; static volatile unsigned int major = 0; static struct class* third_class; static struct class_device* third_class_device; //定义一个结构体，用来描述引脚的状态，方便讲引脚的值管理起来 struct pin_desc { unsigned int pin; //引脚名称 unsigned int value; //键值 }; static struct pin_desc btn_pins[4] = { {S3C2410_GPF0, 0x1}, //引脚名和预设的键值，未被按下为1，按下位0x81 //引脚名定义在：includeasmarch-s3c2410 egs-gpio.h {S3C2410_GPF2, 0x2}, {S3C2410_GPG3, 0x3}, {S3C2410_GPG11, 0x4}, }; static int eints[4] = {IRQ_EINT0, IRQ_EINT3, IRQ_EINT9, IRQ_EINT11,}; unsigned int status = 0;//用于存放引脚值信息 unsigned int condition = 0; //用于描述是否需要睡眠，如果非零表示可以睡眠了，0表示不需要睡眠 unsigned char value = 0; //记录键值的内容，以便判断是否被按下 static DECLARE_WAIT_QUEUE_HEAD(wait_queue); ／* 这是一个宏，用来生成存放睡眠信息的结构体。定义在：includelinuxwait.h头文件中。传入的参数就是结构体的名称，可以直接使用传入的信息来获取结构体。 睡眠的原理：在内核中维护一个睡眠的数组，需要睡眠的程序就挂在这个数组中；如果需要唤醒，内核会从这个数组里面将对应的结构体取出来，并唤醒 *／ /* 在中断函数的框架中，有一个非常重要的参数，就是void* dev_id 这个实际上是由request_irq时传入的变量，最终传递给注册的中断处理函数 方便传递任何类型的信息。 在这里我们传递的是关于引脚描述的信息 */ static irqreturn_t irq_handler(int irq, void *dev_id) { struct pin_desc* desc = (struct pin_desc*) dev_id; //强制类型转换 status = s3c2410_gpio_getpin(desc->pin); //根据我们发送的引脚名称，从中获取到引脚值，和我们之前按位获取没有什么区别，只是一个系统封装好的函数 if(status) //如果被按下了，那么将value变量改为0x8x，比如第一个按键未被按下就是0x81，被按下则是0x01。以此来判断到底是哪个按键被按下了。 value = desc->value | 0x80; else value = desc->value; wake_up_interruptible(&wait_queue); //从睡眠的队列中唤醒 condition = 1; //中断处理完毕，表示可以进入睡眠状态，再次，read的时候，会将此变量传递给系统 return 0; } static ssize_t third_read (struct file *file, char __user *buff, size_t size, loff_t *ppos) { printk(".........read "); wait_event_interruptible(wait_queue, condition);//进入睡眠状态，阻塞于此 condition = 0;//此时值为0，表示不需要再进入睡眠了 printk("read......... "); copy_to_user(buff, &value, 1);//将按键数据发送给用户空间 return 0; } static int third_open (struct inode *inode, struct file *file) { int i = 0;//循环将所有的按键引脚都请求设置为中断 for(; i < EINT_PIN_COUNT; ++i){ request_irq(eints[i], irq_handler, IRQT_BOTHEDGE, dev_name, &btn_pins[i]); } return 0; } static int third_release (struct inode *inode, struct file *file) { //void free_irq(unsigned int irq, void *dev_id) int i = 0; for(;i < EINT_PIN_COUNT; ++i){ free_irq(eints[i], &btn_pins[i]); } printk("button released "); return 0; } struct file_operations third_fops = { .owner = THIS_MODULE, .open = third_open, .read = third_read, .poll = third_poll, .release = third_release, }; static int __init third_init(void) { major = register_chrdev(major, dev_name, &third_fops); third_class = class_create(THIS_MODULE, dev_name); third_class_device = class_device_create(third_class, NULL, MKDEV(major, 0), NULL, dev_name); printk("init "); return 0; } static void __exit third_exit(void) { unregister_chrdev(major, dev_name); class_device_unregister(third_class_device); class_destroy(third_class); printk("exit "); } module_init(third_init); module_exit(third_exit); MODULE_AUTHOR("Ethan Lee <4128127@qq.com>"); MODULE_LICENSE("GPL"); 测试代码： #include #include #include #include int main() { int fd = open("/dev/third_eint", O_RDWR); if(fd < 0) { printf("open error "); return -1; } while(1){ unsigned char value = 0; read(fd, &value, 1); printf("0x%02x ", value); } return 0; } 测试结果：
测试结果
后台运行，资源占用情况 根据以上的测试结果可以看出，可以通过中断来正确的识别不同按键的键值。同时genuine打印信息可以看出wait_event_interruptible(wait_queue, condition);实际的阻塞点位于此处。
目前，测试程序为死循环read，但实际资源占用率并不高，解决了我们之前所提出的问题。 但是是不是就完美解决了呢？实际并没有，比如，测试程序不希望被阻塞在这里，而有其他的逻辑需要执行，那么，这里通过阻塞的方式来获取按键值，显然不是我们希望所看到的。想要知道如何解决，那么且听下回分解。