讲解嵌入式 Linux 驱动开发的方方面面（深度好文）

点击下方【一起学嵌入式】关注，一起学习，一起成长

01

纯软学习的是一门语言，例如C,C++,java,甚至Python，语言说到底只是一门工具，就像学会英语法语日语一样。

但嵌入式学习的是软件+硬件，通俗的讲，它学的是做系统做产品，讲究的是除了具体的语言工具，更多的是如何将一个产品分解为具体可实施的软件和硬件，以及更小的单元。

想速成的人，先跨过内核的学习，直接学习怎么写驱动。
想成为高手，内核必须深刻了解。注意，是了解，要对里面的调度机制、内存管理机制、文件管理机制等等有所了解。

03

驱动程序设计的5个方法

1.使用设计模式

设计模式是一个用来处理那些在软件中会重复出现的问题的解决方案。开发人员可以选择浪费宝贵的时间和预算从无到有地重新发明一个解决方案，也可以从他的解决方案工具箱中选择一个最适合解决这个问题的方案。在微处理器出现之初，底层驱动已经很成熟了，那么，为什么不利用现有的成熟的解决方案呢?

驱动程序设计模式大致分属以下4个类别：Bit bang、轮询、中断驱动和直接存储器访问(DMA)。

Bit bang模式：当微控制器没有内外设去执行功能的时候，或者当所有的内外设都已经被使用了，而此时又有一个新的请求，那么开发者就应该选择Bit bang设计模式。Bit bang模式的解决方案很有效率，但通常需要大量的软件开销来确保其实施的能力。Bit bang模式可以让开发者手动完成通信协议或外部行为。

轮询模式用于简单地监视一个轮询调度方式中的事件。轮询模式适用于非常简单的系统，但许多现代应用程序都需要中断。

中断可以让开发者在事件发生时进行处理，而不用等代码手动检查。

DMA(直接存储器访问)模式允许其它外围设备来处理数据传输的需求，而不需要驱动的干预。

2.了解实时行为

一个实时系统是否能满足实时需求取决于它的驱动程序。写入能力差的驱动是低效的，并可能使不知情的开发者放弃系统的性能。设计者需要考虑驱动的两个特点：阻塞和非阻塞。一个阻塞的驱动程序在其完成工作之前会阻止其他任何软件执行操作。例如，一个USART驱动程序可以把一个字符装入传输缓冲区，然后一直等到接收到传输结束标志符才继续执行下一步操作。

另一方面，非阻塞驱动则是一般利用中断来实现它的功能。中断的使用可以防止驱动程序在等待一个事件发生时拦截其他软件的执行操作。USART 的驱动程序可以将一个字符装入传输缓冲区然后等主程序发布下一个指令。传输结束标志符的设置会导致中断结束，让驱动进行下一步操作。

无论哪种类型，为了保持实时性能，并防止系统中的故障，开发人员必须了解驱动的平均执行时间和最坏情况下的执行时间。一个完整的系统可能会因为一个潜在的风险而造成更大的安全问题。

在时间和预算都很紧张的情况下为什么还要再造轮子呢?在驱动程序开发中，重用、便携性和可维护性都是驱动设计的关键要求。这里面的许多特征可以通过硬件抽象层的设计和使用来说明。

硬件抽象层(HAL)为开发人员提供一种方式来创建一个标准接口去控制微控制器的外设。抽象隐藏实现细节，取而代之的是提供了可视化功能，如 Usart_Init和 Usart_Transmit。这个方法就是让任何 USART、SPI、PWM 或其他外设具备所有微控制器都支持的共同特点。使用  HAL 隐藏底层、特定设备的细节，让应用程序开发人员专注于应用的需求，而不是关注底层的硬件是如何工作的。同时 HAL 提供了一个重用的容器。

4.参考数据手册

微控制器在过去的几年里变得越来越复杂。以前想要完全了解一个微控制器需要掌握由一个大约包含500页组成的单一数据手册。而如今，一个32位微控制器通常包含由部分的数据手册、整个微控制器系列的资料表、每个外设数以百计的资料以及所有的勘误表组成的数据手册。开发人员如果想要完全掌握这部分的内容需要了解几千页的文件。

不幸的是，所有这些数据手册都是一个驱动程序能真正合理实现所需要的。开发人员在一开始就要对每个数据手册中包含的信息进行收集和排序。通常它们中的每一个都需要被访问以使外设启动和运行。关键信息被分散(或隐藏)在每种类型的数据手册中。

5.谨防外设故障

最近我刚好有机会把一系列的微控制器驱动移植到其他的微处理器上。制造商和数据手册都表明PWM外设在这两个系列的微控制器之间是相同的。然而，实际情况却是在运行PWM驱动器的时候两者之间有很大的不同。该驱动程序只能在原来的微控制器工作，而在新系列的微控制器上却无效。

在反复翻看数据手册之后，我在数据手册中一个完全不相关的注脚里发现了PWM外设上电时会处于故障状态，需要将一个隐藏在寄存器中的标志位清零。在驱动程序实现的开始，确认外设可能出现的故障并查看其他看似无关的寄存器错误。

大牛对于嵌入式驱动开发的建议

嵌入式驱动自学者的感受

可能是小时候被老师教导不要做书呆子的教育有关，小时候，听话孩子，认真，长辈的教育对孩子的影响真的是非常的大，很多影响如果你不细心的观察自己，你根本不能察觉这些进入了你骨子的观念，在我成长过程中，这些长辈的教育除了某些让我自己经历到并彻底认识到某个观念并不正确时，我才会形成自己的观点，自己的观念，但这些自己的观念在所有的价值观中，犹如沧海一粟。 

这种讨厌一知半解的性格，在现在这个社会来说，可以说是极端的，因为现在你学习使用的很多东西，他都不是从零开始的，就好比，你编程使用的是高级语言而不是低级语言不是机器码，所以我的整个学习过程是非常缓慢缓慢地进行着，这么说吧，前面说我经过了半年多的学习，但是到现在为止，我接触嵌入式已经有两个年头了，也就是说，学习期间，我有一年多是在停滞着。 

学习嵌入式，或者说学习现代的计算机编程，如果你想学好，有一个比较要求，那就是你能接受它的设定、它的模式。反过来说，当你真正接受它的设定、它的模式，并记住它们时，我认为，你已经学好了。 

昨天，我又置之死地而后生了一次。最近一直在搞驱动，一个LCD驱动搞得我几乎要放弃继续走嵌入式这条路。昨夜，睡不觉，打开嵌入学习视频，躺在已关灯很久的房间的床上，大概凌晨3，4点吧。之前我一直都是学习着驱动自编源码的教学，是那种几乎和裸板程序没多大区别的编程方式，只是多使用了一些向内核注册的接口函数。 

而最近我想换一下，因为很多设备驱动，内核都是自带的，而且是各种平台的设备驱动都有，我想如果能熟悉掌握内核自带驱动的编程，那以后要做某个设备的驱动时，我只需要在自带驱动中修改一下便好了，通过学习LCD平台设备的驱动，我了解了其编程想法，同时也认同这种想法，甚至让我疑惑，学习资料中教自编驱动的意义，为何不直接教如果修改内核源码驱动？ 

于是，继续按着书去修改内核驱动源码，但问题是，书中说他们这种修改，代码成功运行了，但我这，无论怎么调试都失败，我反复检测，我的修改是否与书中一致，检测了很多遍依然没发现哪一步不同，不过，有一点发现是，书中的内核源码和我内核使用的源码有一点点区别（当然书里并没有把所有的源码都贴上，只是修改部分附近会联带着一些，这就是发现，这些联带的没需要修改的源码和我的源码有点区别，比如，我的源码中多了一些设置（看似无关紧要的设置））。 

与书核对无误但失败后，我又与成功运行的自编驱动核对，我陆续发现我修改的内涵源码中，没有去启动设备，也更没有去点亮背光，而在显存分配后的寄存器设置似乎也有问题，因为这里的地址使用各种宏定义不同的累加或计算，最后算得地址和我的寄存器地址也不知是否吻合，因为驱动源码中最后计算得到的是虚拟地址。于是我对比自编驱动，一点点修改尝试，到睡觉前都没成功。 

我是想学得理直气壮一点的，最后是能一眼就能找到问题，并迅速轻松解决问题的，我也承认自己确实是有些浮躁。但是经过了昨晚床上的一点绝望的思考挣扎后，我好像想通了：为什么嵌入式学习视频老师要教自编驱动。 

下面我说下自编驱动与内核驱动源码各自的问题：

自编驱动：

程序简单简洁，它只能驱动特定的某个设备。如果设备换了需要支持另一款设备，那么你需要重新修改该驱动；如果需要系统同时支持两种LCD，那么它就会变成复杂并且对于内核驱动的简洁优势会削弱不少；如果你想驱动支持多种设备，那自编驱动，相对于内核驱动源码的简洁优势会变成了劣势，因为编程思想的适用范围不同而产生的结果。

内核自带驱动源码： 

①从系统层次去考量，变量、宏定义使用多，甚至有些宏定义的值为了方便能让各种在不同的阶段需要不同的值调用，把简单的一个赋值调用变成了需要进行多次运算才能检测到该值是否满足使用要求，因为我们不是该驱动的编码者，不清楚这样做的好处，也或许是内核驱动源码的开发者从整个系统的编程简洁性去考量，这样做或许也是为了让整个系统代码更少，简洁的一种做法，因为每个设备你都给它赋具体的值的话，整个系统中有几百种驱动设备源码，给所有设备的这个位置参数都赋一个值的话，那各设备关于这个值的代码就要多了几百行了，所以还不如，让各设备根据各种平台去对某个宏进行各自的计算来得到合适的值，但某些计算中相同的算法的也整合在一起，这样就减少了系统不少行代码。所以系统中驱动源码是系统开发者对系统源码的整合，是基于系统层的整合。因此，对于我这种对单个设备驱动编码的人，就会觉得系统源码有好多不人性化的地方，会觉得简单的地方也被弄得很复杂。 

②内核自带驱动还有一些代码是为了兼容以前的版本而添加了，比如以前硬件内存资源稀少，需要使用调色板的方法来减少程序运行时的内存使用量，这也会真假代码的复杂性，这一步虽不是必要的，但如果没弄好，那LCD驱动也不能正常使用。 

③程序复杂，为了适用在多种设备型号，更简单地添加不同型号的设备驱动，内核对驱动抽象分离，把驱动分为平台管理部分，驱动代码部分（与硬件无关码），和设备代码部分（硬件相关代码）。用户添加新型号设备驱动时，只需要在平台管理部分检查添加设备的匹配信息，和提供一个硬件设备相关的代码（有格式）文件即可。 

现在，站在驱动开发者而非系统开发者的角度去衡量。 

①自编的驱动，简洁，要点明确。这个对于驱动开发者的用处就是：无论你使用的是哪个版本的内核，哪个芯片平台，你可以通过自编码比较简单方便地就可以确认硬件设备的情况，是否正常。如果自编码通过，那可以试用自编码上使用的参数去与内核进行核对、修改，然后再去测试。如果不成功，对于内核中多余的设置（这些大多可能是提供内核用做基本判断的变量）可以先屏蔽，编译出错了，根据提示，找到出错的位置修改添加。因为这些多余的设置，设置对了还行，设置错了，你又不好去定位错在哪。 

自编的驱动在此处的用处，调试时，可以让你排除多余的失败可能性问题，在较少的代码去查出错误位置，如果你确定你的设置满足了该设备的必需设置，还是失败，你可以比较放心地去怀疑是硬件问题了。如果自编码成功，那个又可以当做你修改内核驱动的一个标准。 

②内核驱动源码支持管理多种型号的设备的优势，是我用使用它的原因。先了解本版本平台的设备驱动结构，如果是添加型号支持，那就根据自编驱动的参数与设置即可，如果是第一次启动这类设备，你就还需要检测结构是完整性，如果结构完整，参数无误依旧错误，那就把内核驱动源码精简到自编码的简单粗暴设置吧。最终就变成了在基于内核驱动架构下的自编驱动。如果还不行，那无疑是结构性问题了。 

如何编写嵌入式Linux设备驱动程序？

一、Linux device driver 的概念

系统调用是操作系统内核和应用程序之间的接口，设备驱动程序是操作系统内核和机器硬件之间的接口。设备驱动程序为应用程序屏蔽了硬件的细节，这样在应用程序看来，硬件设备只是一个设备文件，应用程序可以象操作普通文件一样对硬件设备进行操作。设备驱动程序是内核的一部分，它完成以下的功能:

4、检测和处理设备出现的错误。

在linux操作系统下有三类主要的设备文件类型，一是字符设备，二是块设备，三是网络设备。字符设备和块设备的主要区别是:在对字符设备发出读/写请求时，实际的硬件I/O一般就紧接着发生了，块设备则不然，它利用一块系统内存作缓冲区，当用户进程对设备请求能满足用户的要求，就返回请求的数据，如果不能，就调用请求函数来进行实际的I/O操作。块设备是主要针对磁盘等慢速设备设计的，以免耗费过多的CPU时间来等待。

已经提到，用户进程是通过设备文件来与实际的硬件打交道。每个设备文件都都有其文件属性(c/b)，表示是字符设备还是块设备?另外每个文件都有两个设备号，第一个是主设备号，标识驱动程序，第二个是从设备号，标识使用同一个设备驱动程序的不同的硬件设备，比如有两个软盘，就可以用从设备号来区分他们。设备文件的的主设备号必须与设备驱动程序在登记时申请的主设备号一致，否则用户进程将无法访问到驱动程序。

最后必须提到的是，在用户进程调用驱动程序时，系统进入核心态，这时不再是抢先式调度。也就是说，系统必须在你的驱动程序的子函数返回后才能进行其他的工作。如果你的驱动程序陷入死循环，不幸的是你只有重新启动机器了，然后就是漫长的fsck。

我们来写一个最简单的字符设备驱动程序。虽然它什么也不做，但是通过它可以了解Linux的设备驱动程序的工作原理。把下面的C代码输入机器，你就会获得一个真正的设备驱动程序。

由于用户进程是通过设备文件同硬件打交道，对设备文件的操作方式不外乎就是一些系统调用，如 open，read，write，close…， 注意，不是fopen， fread，但是如何把系统调用和驱动程序关联起来呢?这需要了解一个非常关键的数据结构：

struct file_operations {int (*seek) (struct inode * ，struct file *， off_t ，int); int (*read) (struct inode * ，struct file *， char ，int); int (*write) (struct inode * ，struct file *， off_t ，int); int (*readdir) (struct inode * ，struct file *， struct dirent * ，int); int (*select) (struct inode * ，struct file *， int ，select_table *); int (*ioctl) (struct inode * ，struct file *， unsined int ，unsigned long); int (*mmap) (struct inode * ，struct file *， struct vm_area_struct *); int (*open) (struct inode * ，struct file *); int (*release) (struct inode * ，struct file *); int (*fsync) (struct inode * ，struct file *); int (*fasync) (struct inode * ，struct file *，int); int (*check_media_change) (struct inode * ，struct file *); int (*revalidate) (dev_t dev); }

这个结构的每一个成员的名字都对应着一个系统调用。用户进程利用系统调用在对设备文件进行诸如 read/write 操作时，系统调用通过设备文件的主设备号找到相应的设备驱动程序，然后读取这个数据结构相应的函数指针，接着把控制权交给该函数。这是 linux 的设备驱动程序工作的基本原理。既然是这样，则编写设备驱动程序的主要工作就是编写子函数，并填充 file_operations 的各个域。

下面就开始写子程序。

#include <linux/types.h> 基本的类型定义#include <linux/fs.h> 文件系统使用相关的头文件#include <linux/mm.h> #include <linux/errno.h> #include <asm/segment.h> unsigned int test_major = 0; static int read_test(struct inode *inode，struct file *file，char *buf，int count){ int left; 用户空间和内核空间if (verify_area(VERIFY_WRITE，buf，count) == -EFAULT ) return -EFAULT; for(left = count ; left > 0 ; left--) { __put_user(1，buf，1); buf++; } return count; }

这个函数是为read调用准备的。当调用read时，read_test()被调用，它把用户的缓冲区全部写1。buf 是read调用的一个参数。它是用户进程空间的一个地址。但是在read_test被调用时，系统进入核心态。所以不能使用buf这个地址，必须用__put_user()，这是kernel提供的一个函数，用于向用户传送数据。另外还有很多类似功能的函数。请参考，在向用户空间拷贝数据之前，必须验证buf是否可用。这就用到函数verify_area。为了验证BUF是否可以用。

static int write_test(struct inode *inode，struct file *file，const char *buf，int count){ return count; } static int open_test(struct inode *inode，struct file *file ){MOD_INC_USE_COUNT; 模块计数加以，表示当前内核有个设备加载内核当中去return 0; } static void release_test(struct inode *inode，struct file *file ){ MOD_DEC_USE_COUNT; }

struct file_operations test_fops = {  read_test，  write_test，  open_test，  release_test，};

设备驱动程序的主体可以说是写好了。现在要把驱动程序嵌入内核。驱动程序可以按照两种方式编译。一种是编译进kernel，另一种是编译成模块(modules)，如果编译进内核的话，会增加内核的大小，还要改动内核的源文件，而且不能动态的卸载，不利于调试，所以推荐使用模块方式。

int init_module(void){ int result; result = register_chrdev(0， "test"， &test_fops); 对设备操作的整个接口if (result < 0) { printk(KERN_INFO "test: can't get major number\n"); return result; } if (test_major == 0) test_major = result; /* dynamic */return 0; }

void cleanup_module(void){ unregister_chrdev(test_major，"test"); }

一个极其简单的字符设备可以说写好了，文件名就叫test.c吧。

下面编译 :

$ gcc -O2 -DMODULE -D__KERNEL__ -c test.c 

–c 表示输出制定名，自动生成.o文件。

得到文件test.o就是一个设备驱动程序。

如果设备驱动程序有多个文件，把每个文件按上面的命令行编译，然后

ld -r file1.o file2.o -o modulename

驱动程序已经编译好了，现在把它安装到系统中去。

$ insmod –f test.o

如果安装成功，在/proc/devices文件中就可以看到设备test，并可以看到它的主设备号。要卸载的话，运行 :

$ rmmod test

下一步要创建设备文件。

mknod /dev/test c major minor

c 是指字符设备，major是主设备号，就是在/proc/devices里看到的。

用shell命令

$ cat /proc/devices

就可以获得主设备号，可以把上面的命令行加入你的 shell script 中去。

minor是从设备号，设置成 0 就可以了。

#include <stdio.h> #include <sys/types.h> #include <sys/stat.h> #include <fcntl.h> main() {     int testdev;     int i;     char buf[10];     testdev = open("/dev/test"，O_RDWR);    if ( testdev == -1 )     {         printf("Cann't open file \n");         exit(0);     }    read(testdev，buf，10);     for (i = 0; i < 10;i++)         printf("%d\n"，buf[i]);     close(testdev); }

以上只是一个简单的演示。真正实用的驱动程序要复杂的多，要处理如中断，DMA，I/O port等问题。这些才是真正的难点。上述给出了一个简单的字符设备驱动编写的框架和原理，更为复杂的编写需要去认真研究LINUX内核的运行机制和具体的设备运行的机制等等。希望大家好好掌握LINUX设备驱动程序编写的方法。

嵌入式驱动的结构分析

其实对于上面介绍的结构体，里面的元素的作用基本可以见名思意了，所以不用赘述了。其实写一个驱动模块就是填充上述的结构体，根据设备的功能和用途写相应的函数，然后对应到结构体中的指针，然后再写一个入口一个出口（就是模块编程中的init和exit）就可以了，一般情况下入口程序就是在注册platform_device和platform_driver（当然，这样说是针对以platform模式编写驱动程序）。

08

嵌入式书籍推荐

微机原理、数字电路，高校里的教材。

2. Linux方面的书：

<ARM体系架构与编程>
<嵌入式Linux应用开发完全手册>
<Linux设备驱动>，老外写的那本
<linux设备驱动开发详解>
<linux内核完全注释>
<Linux内核情景分析>

在做驱动的时候，肯定会用到与内核相关的东西，或者需要和内核中的某些模块配合，这样你也要理解内核的某些部分是如何实现的，最后，你应该可以很好的掌握linux的内核整体框架是什么。

这些都是进步，都是在你一次又一次的开发中需要总结的东西，如果你不总结，永远都是从头开始（或者说永远都是还没看懂别人代码为什么这么做的时候，就去改它，然后可以工作了），就完事了，这样你永远也不可能提高，最后你就有了现在的这种感觉，觉得自己什么都不是，什么都不懂。

还有一点要说明的，现在有许多人搞linux开发，却不去用linux系统做为自己工作的平台，在这种情况下，你很难理解linux内核的实现机制，以及为什么要采用这种方式实现。

你都没用过linux系统，就想去实现一个与linux运行机理相符合的项目，这是不可能的。就是你这个项目成功了，它也肯定不是最优的，或者是不符合linux的使用习惯的（包括内核的扩展和应用程序的实现）。

所以，最后想说的是，你一定要定期总结，总结你这段时间做了什么，你从中得到了什么，为了你以后可以更好的做好类似的工作，你应该去看些其它的什么东西；二是你一定至少要在工作的开发环境中使用 linux 作为你的平时工作平台，而不要使用虚拟机和服务器，因为你只有完全了解了linux的使用，你才可以为它开发符合它规则的项目。

关注我【一起学嵌入式】，一起学习，一起成长。

觉得文章不错，点击“分享”、“赞”、“在看” 呗！