一、设备驱动的作用?
任何一个计算机系统的运行都是系统中软硬件协作的结果,没有硬件的软件是空中楼阁,而没有软件的硬件则只是一堆废品。硬件是底层基础,是所有软件得以运行的平台,代码最终会落实为硬件上的组合逻辑与时序逻辑;软件则实现了具体应用,它根据各类不同的业务需求而设计,满足了用户的需求。硬件较固定,软件则很灵活,可以适应各类复杂多变的应用。可以说,计算机系统的软硬件相互成就了对方。
然而,软硬件之间同样存在着悖论,那就是软件和硬件不应当相互渗透到对方的领地。为了尽可能快速地完成设计,应用软件工程师不想也毋须关心硬件,而硬件工程师也难有足够的消遣和能力来顾及软件。诸如,应用软件工程师在调用套接字发送和接收数据包的时侯,他毋须关心网卡上的中断、寄存器、存储空间、I/O端口、片选以及其他任何硬件词汇;在使用printf()函数输出信息的时侯,他不用晓得底层到底是如何把相应的信息输出到屏幕或并口。
也就是说,应用软件工程师须要见到一个没有硬件的纯粹的软件世界,硬件必须被透明地呈现给她们。谁来实现硬件对应用软件工程师的隐型?这个繁重的任务就落在了驱动工程师的头顶。
对设备驱动最浅显的解释就是“驱使硬件设备行动”。设备驱动与底层硬件直接打交道,根据硬件设备的具体工作方法读写设备寄存器,完成设备的寻址、中断处理、DMA通讯,进行化学显存向虚拟显存的映射,最终使通讯设备才能收发数据,使显示设备才能显示文字和画面,使储存设备才能记录文件和数据。
由此可见,设备驱动充当了硬件和应用软件之间的纽带,它促使应用软件只须要调用系统软件的应用编程插口(API)就可让硬件去完成要求的工作。在系统中没有操作系统的情况下,工程师可以按照硬件设备的特性自行定义插口,如对并口定义SerialSend()、SerialRecv();对LED定义LightOn()、LightOff();以及对Flash定义FlashWrite()、FlashRead()等。而在有操作系统的情况下,设备驱动的构架则由相应的操作系统定义,驱动工程师必须根据相应的构架设计设备驱动,这样,设备驱动能够良好地整合到操作系统的内核中。
驱动程序沟通着硬件和应用软件,而驱动工程师则沟通着硬件工程师和应用软件工程师。随着通讯、电子行业的迅速发展,全世界每天都会有大量的新芯片被生产,大量的新电路板被设计,因而,也会有大量设备驱动须要开发。这种设备驱动,或运行在简单的单任务环境中,或运行在VxWorks、Linux、Windows等多任务操作系统环境中,发挥着不可取代的作用。
二、裸机设备驱动和linux系统中的设备驱动有哪些区别?
1、裸机(无操作系统)设备驱动
并不是任何一个计算机系统都一定要运行操作系统linux设备驱动程序第三版 下载,在许多情况下操作系统是不要的。对于功能比较单一、控制并不复杂的系统,如公汽车刷卡机、电冰柜、微波、简单的手机和小灵通等,并不须要多任务调度、文件系统、内存管理等复杂功能,单任务构架完全可以挺好地支持它们的工作。一个无限循环中参杂对设备中断的测量或则对设备的寻址是此类系统中软件的典型构架。裸机的实现就有点类似单片机(MCU),虽然单片机的寄存器没有这么的多。
在这样的系统中,即使不存在操作系统,并且设备驱动是必须存在的。通常情况下,对每一种设备驱动就会定义为一个软件模块,包含.h文件和.c文件,后者定义该设备驱动的数据结构并申明外部函数,前者进行设备驱动的具体实现。例如一个并口驱动,主要是配置GPIO,并口控制寄存器linux设备驱动程序第三版 下载,以及并口的收发(读写)寄存器,而这几个配置都是自定义函数实现的,例如并口的写(发)SerialSend函数等。
其他模块须要使用这个设备的时侯,只须要包含设备驱动的头文件serial.h,之后调用其中的外部插口函数即可。如我们要从并口上发送字符串“HelloWorld”,使用函数SerialSend("HelloWorld")即可。
由此可见,在没有操作系统的情况下,设备驱动的插口被直接递交给了应用软件工程师,应用软件没有跨越任何层次就直接访问了设备驱动的插口。设备驱动包含的插口函数也与硬件的功能直接吻合,没有任何附加功能。
有的工程师把单任务系统设计成设备驱动和具体的应用软件模块处于同一层次(即应用程序也在诸如serial.c中实现),这也许是不合理的,不符合软件设计中高内聚低耦合的要求。另一种不合理的设计是直接在应用程序中操作硬件的寄存器(单独一个main.c,所有功能都在这一个函数中实现,不采用其他任何插口/函数),而不单独设计驱动模块,这些设计意味着系统中不存在或无法充分借助可被重用的驱动代码。
2、Linux系统(有操作系统)中的设备驱动
无操作系统时的设备驱动中的设备驱动直接运行在硬件之上,不与任何操作系统关联。当系统中包含操作系统后,设备驱动会显得如何?
首先,有操作系统时设备驱动的硬件操作工作一直是必不可少的,没有这一部份,我们不可能与硬件打交道。其次,我们还须要将设备驱动融入内核。为了实现这些融合,必须在所有的设备驱动中设计面向操作系统内核的插口,这样的插口由操作系统规定,对一类设备而言结构一致,独立于具体的设备。
由此可见,当系统中存在操作系统的时侯,设备驱动弄成了联接硬件和内核的桥梁。操作系统的存在势必要求设备驱动附加更多的代码和功能(以我看,主要是提供了好多结构),把单一的“驱使硬件设备行动”变成了操作系统内核与硬件交互的模块linux系统iso下载,它对外呈现为操作系统的API(这儿的操作系统可以理解为内核,内核可以被应用程序通过系统调用来访问),不再给应用软件工程师直接提供插口(并且在裸机中,驱动程序的插口是直接提供给应用程序的)。由于应用程序在用户空间,驱动程序在内核空间,所以就必须先由应用程序进行系统调用步入内核,之后再调用驱动程序中和该系统调用相对应的API。
下边以字符设备驱动为例,看下边的几张流程图,其实你能够明白上述所说是哪些意思:
其中关于C库以及怎样通过系统调用“陷入”到内核空间这个我们不用去管,我们重点关注的是应用程序和具体的驱动linux操作系统怎么样,应用程序使用到的函数在具体驱动程序中都有与之对应的函数,例如应用程序中调用了open这个函数,这么在驱动程序中必将有一个和open函数对应的一个函数,这个函数名我们是可以自定义的,例如char_open。每一个系统调用,在驱动中都有与之对应的一个驱动函数,在Linux内核文件include/linux/fs.h中有个称作file_operations的结构体,此结构体就是Linux内核驱动操作函数集合,内容如下所示:
1588 struct file_operations {
1589 struct module *owner;
1590 loff_t (*llseek) (struct file *, loff_t, int);
1591 ssize_t (*read) (struct file *, char __user *, size_t, loff_t *);
1592 ssize_t (*write) (struct file *, const char __user *, size_t,loff_t *);
1593 ssize_t (*read_iter) (struct kiocb *, struct iov_iter *);
1594 ssize_t (*write_iter) (struct kiocb *, struct iov_iter *);
1595 int (*iterate) (struct file *, struct dir_context *);
1596 unsigned int (*poll) (struct file *, struct poll_table_struct *);
1597 long (*unlocked_ioctl) (struct file *, unsigned int, unsigned long);
1598 long (*compat_ioctl) (struct file *, unsigned int, unsigned long);
1599 int (*mmap) (struct file *, struct vm_area_struct *);
1600 int (*mremap)(struct file *, struct vm_area_struct *);
1601 int (*open) (struct inode *, struct file *);
1602 int (*flush) (struct file *, fl_owner_t id);
1603 int (*release) (struct inode *, struct file *);
1604 int (*fsync) (struct file *, loff_t, loff_t, int datasync);
1605 int (*aio_fsync) (struct kiocb *, int datasync);
1606 int (*fasync) (int, struct file *, int);
1607 int (*lock) (struct file *, int, struct file_lock *);
1608 ssize_t (*sendpage) (struct file *, struct page *, int, size_t, loff_t *, int);
1609 unsigned long (*get_unmapped_area)(struct file *,
unsigned long,unsigned long,
unsigned long, unsigned long);
1610 int (*check_flags)(int);
1611 int (*flock) (struct file *, int, struct file_lock *);
1612 ssize_t (*splice_write)(struct pipe_inode_info *, struct file *,
loff_t *, size_t, unsigned int);
1613 ssize_t (*splice_read)(struct file *, loff_t *,
struct pipe_inode_info *,
size_t, unsigned int);
1614 int (*setlease)(struct file *, long, struct file_lock **, void **);
1615 long (*fallocate)(struct file *file, int mode, loff_t offset,loff_t len);
1616 void (*show_fdinfo)(struct seq_file *m, struct file *f);
1617 #ifndef CONFIG_MMU
1618 unsigned (*mmap_capabilities)(struct file *);
1619 #endif
1620 };
简单介绍一下file_operation结构体中比较重要的、常用的函数:
在字符设备驱动开发中最常用的就是前面那些函数,关于其他的函数你们可以查阅相关文档。我们在字符设备驱动开发中最主要的工作就是实现里面那些函数,不一定全部都要实现,并且像open、release、write、read等都是须要实现的,其实了,具体须要实现什么函数还是要看具体的驱动要求。
最后,须要指出的一点是,这儿只是以字符设备驱动为例来讲解应用程序是怎样访问到设备驱动程序的,以上所说的结构体以及其中定义的函数都是针对的字符设备驱动,但是它也不限于那些函数,肯定还有好多其他的函数须要实现。我们晓得设备驱动分为三大类,分别是字符设备,块设备和网路设备,由于不同的设备驱动类别都有对应的各自不同的框架,也即不同的结构体和函数等一些东西,因而我们须要实现的是该类别设备驱动对应的函数。至于这三种类别的设备驱动程的框架以及程序怎样编撰,等到前面到这一部份的时侯再总结。
有了操作系统以后,设备驱动反倒显得复杂,那要操作系统干哪些?首先,一个复杂的软件系统须要处理多个并发的任务,没有操作系统,想完成多任务并发是很困难的。其次,操作系统给我们提供显存管理机制。一个典型的事例是,对于多数含MMU的处理器而言,Windows、Linux等操作系统可以让每位进程都独立地访问4GB的显存空间。
上述优点其实并没有彰显在设备驱动头上,操作系统的存在给设备驱动到底带来了哪些益处呢?简而言之,操作系统通过给设备驱动制造麻烦来达到给下层应用提供便利的目的。假如设备驱动都依照操作系统给出的独立于设备的插口而设计,应用程序将可使用统一的系统调用插口来访问各种设备。对于类UNIX的VxWorks、Linux等操作系统而言,应用程序通过write()、read()等函数读写文件就可以访问各类字符设备和块设备,而不用管设备的具体类型和工作方法,是十分便捷的。
参考文章:
本人小白,是从零开始学习linux驱动开发的,这是自己在学习过程中写的博客,所以肯定会有不正确的地方,假如有还请诸位强调来!!!