从需求的角度去理解Linux之一:总线、设备和驱动

这是一篇有关如何学习嵌入式Linux系统的方法论文章,也是从需求的角度去理解Linux系统软件的开篇,相信此系列文章日后会是学习嵌入式Linux的标杆!

这是作者精心撰写的经验总结,希望嵌入式Linux的学习者仔细领会,多读几遍也无妨。

转载请务必保留我们的公众号:嵌入式企鹅圈

一、软件、面向对象、软件框架

软件是为了解决现实问题而产生的,面向对象的软件思维是解决普遍现实问题的一种有效的抽象方法,而软件框架指的是用面向对象的思维去解决某种特定领域的问题而专门设计的一套行之有效的解决方案。

一般地,JAVA/C++编程反映面向对象的软件思维,而像Android
Framework、Windows
MFC和Linux的QT则代表应用层的软件框架。前述应用框架要解决的问题包括应用消息处理、UI控件显示和处理、资源管理等等。软件框架带来的好处就是对于解决某个领域问题,框架会帮你完成80%的开发工作量,而你只需要完成20%的开发工作量。

Linux平台上的各个子系统,如设备驱动模型、input子系统、I2C总线、frame
buffer驱动等等都属于软件框架,它是针对特定的硬件体系需求以面向对象的思维去设计的一种软件解决方案,而且已经经过长时间的多平台验证。严格意义上,将子系统归入软件抽象组件会更加贴切,而软件框架表现为一组抽象组件及其组件实例之间的交互。软件框架和软件组件的特点都是解决特点领域问题,可以高度重用设计。

Linux系统以C语言开发为主,C语言在教科书上会被认为是过程语言。事实上,面向对象只是一种软件思维,并不局限于某种语言,只不过C++/JAVA在娘胎(编译器)里就已经得到支持,而C语言通过struct数据结构和函数指针一样可以出色地完成面向对象抽象的工作。Linux系统绝对是利用C语言进行面向对象编程的开山鼻祖,处处洋溢着软件艺术的光辉!

二、理解好软件需求是学习好软件框架的前提

对于学习着来说,软件需求(即软件要解决的问题)和软件框架都已经存在。但学习者往往只关注软件框架,因为学习的终极目标也是为了掌握软件框架并使用它来解决自己的问题。对于一般的知识传播者来说(例如学校老师、机构培训师;教科书或者网络文献),往往也是着重于解读软件框架的组成和原理。

事实上,对于一个代码量有几万甚至几十万行代码量的软件框架,一开始接触就学习原理和代码并不是好事。这种做法很像是试图从软件框架的学习理解中得出软件需求,有太多的未知就接触源码,那理解过程会非常痛苦,往往会感到非常迷惑。

我认为,深入地理解好需求,再去理解软件框架会事半功倍。

甚至,当达到一定的水平后,知道了需求,完全可以去猜测软件框架的实现。

三、Linux系统的软件需求

对于软件需求,最容易让人联想到的是一种具体的业务需求,如12306购票业务等等。Linux是一种操作系统,操作系统的软件需求是什么?操作系统是为了给应用层提供良好的接口而进行总线设备驱动管理、内存管理、文件管理、进程管理等等。总线设备驱动管理就是我们今天要谈的主题。Linux平台有各种子系统、各种总线、各种驱动,Linux系统对它们的管理就是软件框架的组成。我们要理解好Linux已有的框架,就要清晰地知晓其解决的问题,也就是其管理了哪些硬件设备,这些硬件设备的特点是什么,这些设备的访问方式是什么。

可以说,深入地理解硬件体系是理解好Linux总线设备驱动框架的前提!从面向对象的角度,我们要弄清楚,物理意义上的硬件是什么,而对应的软件对象是如何表述的。

以下阐述会重点讲述软件需求,作为以后分析框架的基础。

四、总线、驱动、设备

1.
总线

总线代表着同类设备需要共同遵守的工作时序,不同的总线对于物理电平的要求是不一样的,对于每个比特的电平维持宽度也是不一样,而总线上传递的命令也会有自己的格式约束。如I2C总线、USB总线、PCI总线等等。以I2C总线为例,在同一组I2C总线上连接着不同的I2C设备。

2.设备

设备代表真实的、具体的物理器件,在软件上用器件的独特的参数属性来代表该器件。如I2C总线上连接的I2C从设备都有一个标识自己的设备地址,由这个设备地址来确定主设备发过来的命令是否该由它来响应。

3.驱动

驱动代表着操作设备的方式和流程。对于应用来说,应用程序open打开设备后,接着就read访问这个设备,驱动就是如何实现这个访问的具体的过程。驱动主要包括两部分,第一是通过对SOC的控制寄存器进行编程,按总线要求输出时序和命令,成功地与外围设备进行交互;第二是对第一步中得到的数据进行处理,并向应用层提供特定格式的数据。

a.不同总线的设备的驱动过程是不一样的,这个很容易理解,USB鼠标的驱动和I2C
EEPROM的读时序肯定是不一样的,访问时序的产生和控制也是驱动的一部分。

b.同种总线不同设备类型的设备驱动也是不一样的。如I2C电容屏设备,对于读read来说就是在datasheet规定的地址上去读触摸点的X和Y坐标,而I2C
EEPROM的读操作是读取存储的内容,两种设备的datasheet是不一样的,驱动自然是不一样的。

c.同种总线的同类设备的设备驱动也可能是不一样的。例如对于触摸屏,TSC2003只支持单点触控,而FT5X06支持多点触摸。在获取触控坐标时,前者只需要获得一个点的数据就返回,而后者则需要先获得当前有几个点的数据,然后再把所有点的坐标都读出来。

在驱动的操作中,一般都会用到GPIO和中断等硬件资源,如上图的SDA和SCL会连接到SOC芯片的具体的两个GPIO引脚,而I2C读写时一般都采用中断控制的方式(查询读写是否完成比较低效,浪费CPU)。如果我们在驱动中直接针对具体的引脚来编程,那这个驱动的平台可移植性就比较差,因为不同的产品设计可能引脚不一样。所以,为了提高驱动的可移植性,Linux把驱动要用到的GPIO和中断等资源剥离给设备去管理。即在设备里面包含其自己的设备属性,还包括了其连接到SOC所用到的资源。而驱动重点关注操作的流程和方法。

4.再谈总线

第1点中谈到的总线只是物理意义上的表述,总线就是在行业中制定出标准,明确规定时序的格式。我们在第3点中谈到,在软件层面上,时序的产生和控制由驱动负责。那我们要思考在软件层面上,总线的职责是什么?

总线在软件层面主要是负责管理设备和驱动。

a.设备要让系统感知自己的存在,设备需要向总线注册自己;同样地,驱动要让系统感知自己的存在,也需要向总线注册自己。设备和总线在初始化时必须要明确自己是哪种总线的,I2C设备和驱动不能向USB总线注册吧。

b.多个设备和多个驱动都注册到同一个总线上,那设备怎么找到最适合自己的驱动呢,或者说驱动怎么找到其所支持的设备呢?这个也是由总线负责,总线就像是一个红娘,负责在设备和驱动中牵线。设备会向总线提出自己对驱动的条件(最简单的也是最精确的就是指定对方的名字了),而驱动也会向总线告知自己能够支持的设备的条件(一般是型号ID等,最简单的也可以是设备的名字)。那设备在注册的时候,总线就会遍历注册在它上面的驱动,找到最适合这个设备的驱动,然后填入设备的结构成员中;驱动注册的时候,总线也会遍历注册在其之上的设备,找到其支持的设备(可以是多个,驱动和设备的关系是1:N),并将设备填入驱动的支持列表中。我们称总线这个牵线的行为是match。牵好线之后,设备和驱动之间的交互红娘可不管了。

c.总线在匹配设备和驱动之后驱动要考虑一个这样的问题,设备对应的软件数据结构代表着静态的信息,真实的物理设备此时是否正常还不一定,因此驱动需要探测这个设备是否正常。我们称这个行为为probe,至于如何探测,那是驱动才知道干的事情,总线只管吩咐得了。所以我们可以猜测在总线的管理代码中会有这样的逻辑:

if(match(device, driver) == OK)

driver->probe();

5.
再谈驱动

假设设备正常,探测成功,这时就代表应用程序可以通过驱动来访问操作这个设备了。事实上是这样吗?仔细想想还少了什么东西。应用层通过什么来访问操作这个设备?想起来吗?我们公众号“嵌入式企鹅圈”的第一篇文章《Linux字符设备驱动剖析》中曾清晰地分析了Linux字符设备驱动的开发和访问过程,在开篇即提到应用程序如何访问设备:

int
fd = open(“设备文件名”);

read(fd, buf, len);

write(fd, buf, len);

在这个应用程序中会涉及驱动两个问题,一是设备文件名从何而来,二是应用层的open、read和write对应驱动哪些接口,是如何对应的。这些都是驱动要解决的问题。

a.总线匹配设备和驱动之后,驱动探测到设备正常,这时驱动是处于做好准备让应用层来差遣了,但是设备文件名如果没有创建,应用程序也不知从何入手。所以在驱动的probe探测成功之后,立即创建设备文件是最合适的时机。其通过sysfs文件系统、uevent事件通知机制和后台应用服务mdev程序配合能够成功地在/dev目录创建对应的设备文件。

b.驱动要提供应用层open、read、write、ioctl等操作的对应接口,而且这些接口要向系统报备(注册)自己,否则系统也不知道怎么调用驱动,因为在上面的描述中从始至终都是设备、驱动和总线三个东西在唱戏,它们跟系统,严格意义是跟Linux的虚拟文件系统和设备文件系统还没建立起关系来。即驱动要包括以下步骤:

B1.设备要提供struct
file_operation结构定义的接口:

struct file_operations {

int (*open) (struct inode *, struct file
*);

int (*ioctl) (struct inode *, struct file
*, ...);

ssize_t (*read) (struct file *, char __user
*,...);

ssize_t (*write) (struct file *, const
char __user *, ...);

…}

这些接口将会对应到应用层的设备访问操作。在这些接口中,其会根据第3点中提到的需求去完成自己的操作任务。

B2.应用层正常的访问流程是:应用层操作->虚拟文件系统操作->具体文件系统操作->具体设备驱动的操作。虚拟文件系统VFS系统已经存在,具体文件系统操作对于字符设备来说非常简单,我们姑且认为是字符设备文件系统devfs,此时字符设备驱动要做的是将自己的struct
file_operations向devfs注册,对应字符设备驱动是cdev_add函数。详细的分析过程可以参考《Linux字符设备驱动剖析》。

所以我们可以想象在驱动driver的结构体中有一个probe接口,驱动要实现这个接口,而这个probe接口要完成的工作包括:

Driver->probe()

I.探测设备是否正常

II.cdev_add(struct
file_operations)注册操作接口

III.
device_create()创建设备文件

6.
继续谈驱动

做好以上准备即已万事俱备的时候,等着应用程序来访问操作了。通过《Linux字符设备驱动剖析》中open的整个过程,到最后会调用到具体驱动的open,接下来我们就要阐述一下设备驱动的struct
file_operations中的接口都要做什么。我们挑几个主要的来讲讲,其余可以自己想象。

a.open一般会进行驱动的初始化,可能包括硬件的初始化和软件的初始化。我们在第3点谈驱动的时候,曾说明为了让驱动更具移植性,会将驱动driver过程中使用到的具体GPIO和IRQ中断等资源列入设备device的属性内容。这时device数据结构中断的GPIO和IRQ的标识都来源于SOC
datasheet的物理地址定义。我们都知道Linux在运行过程中会使用到SOC的MMU内存管理单元来管理自己的内存,会将内存分为两部分,内核空间(3G-4G)和用户空间(0-3G),这两块地址空间都是虚拟线性地址空间,即程序编译链接之后对应的地址空间,虚拟地址空间需要通过MMU和页表来映射到实际的物理内存空间才能最终访问到物理内存和物理IO等资源。而驱动操作硬件都处在内核空间,在open函数中主要包括以下操作:

a1.通过系统提供的资源获取接口获取到GPIO和IRQ等资源

a2.通过ioremap接口将GPIO和IRQ从物理地址空间映射到3G-4G中的虚拟地址空间

a3.根据具体的控制规格设置GPIO和IRQ相关的寄存器。

以上初始化的动作可能会出现在驱动probe探测的代码中,那open的接口可以什么都不做。

b.
read:驱动的open如果成功,那整个访问流程已经成功一大半了,因为open的流程足够漫长和复杂。而read只是从用户空间的fd文件句柄找到所属进程的file文件结构,然后即可找出file_operations->read,其即是驱动的read接口。那就按着外网设备的规格和总线的时候进行操作,达到read设备的目的。Write也一样。

c.
ioctl一般是对设备进行参数设置。

微信公众号:嵌入式企鹅圈

我们追求:

1.忠于Linux源码,百分百原创。

2.从上电第一行代码、系统第一行代码、模块第一行代码、应用第一行代码,深入讲解嵌入式软件生命周期。

3 深刻理解硬件体系,
聚焦软件层次设计、模块设计和框架设计。

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-11-09 16:36:21

从需求的角度去理解Linux之一:总线、设备和驱动的相关文章

从需求的角度去理解Linux系列:总线、设备和驱动

笔者成为博客专家后整理以前原创的嵌入式Linux系列博文,现推出以让更多的读者受益. <从需求的角度去理解linux系列:总线.设备和驱动>是一篇有关如何学习嵌入式Linux系统的方法论文章,也是从需求的角度去理解Linux系统软件的开篇,期待此系列文章日后会是学习嵌入式Linux的标杆! 这是作者精心撰写的经验总结,希望嵌入式Linux的学习者仔细领会,多读几遍也无妨. 一.软件.面向对象.软件框架 软件是为了解决现实问题而产生的,面向对象的软件思维是解决普遍现实问题的一种有效的抽象方法,而

从汇编角度来理解linux下多层函数调用堆栈执行状态

注:在linux下开发经常使用的辅助小工具: readelf .hexdump.od.objdump.nm.telnet.nc 等,详细能够man一下. 我们用以下的C代码来研究函数调用的过程. C++ Code 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 int bar(int c, int d) { int e = c + d; return e; } int foo(int a, int b) { return bar(a, b); } int main(

从逆向的角度去理解C++虚函数表

很久没有写过文章了,自己一直是做C/C++开发的,我一直认为,作为一个C/C++程序员,如果能够好好学一下汇编和逆向分析,那么对于我们去理解C/C++将会有很大的帮助,因为程序中所有的奥秘都藏在汇编中,很多问题我们从表面上无法看出到底是为什么,只要用逆向工具一分析,很快就能知道其中的所以然来.我们都知道虚函数表是放在类对象的最前面,但是很多人并不知道虚函数表的第一项存放的是什么,下面我用IDA分析一下C++的虚函数调用,从汇编的角度去理解虚函数.此文只适合具有逆向分析基础的读者,如果没有逆向分析

从认知角度去理解设计

设计并不是一味只求美感或者感觉,设计同样是一门建立在多学科基础上的科学,从认知角度来理解设计能帮助我们设计出更多尊重用户的作品,这样的设计才能经得起时间的考验,让更多用户所喜爱. 下面是我对<认知与设计——理解ui设计准则>这本书的概要与理解. 一.影响我们感知的因素     a. 经验影响感知: 我们根据经验对事物的预想:先入为主的主观印象往往影响感知,当我们带有    不同的主观感受去观察同一张图片时会看到不同的东西 我们的认知框架:认知框架即是不断置身的各种环境在我们心智中建立起开模式,

从有限状态机的角度去理解Knuth-Morris-Pratt Algorithm(又叫KMP算法,”看毛片“算法)

转载请加上:http://www.cnblogs.com/courtier/p/4273193.html 在开始讲这个文章前的唠叨话: 1:首先,在阅读此篇文章之前,你至少要了解过,什么是有限状态机,什么是KMP算法,因为,本文是从KMP的源头,有限状态 机来讲起的,因为,KMP就是DFA(Deterministic Finite Automaton)上简化的. 2:很多KMP的文章(有限自动机去解释的很少),写得在我看来不够好,你如果,没有良好的数学基础就很难去理解他们(比如下图), 因为,你

以吃货的角度去理解云计算中On-Premise、IaaS、PaaS和SaaS

了解云计算的一定都听过四个“高大上”的概念:On-Premise(本地部署),IaaS(基础设施及服务).PaaS(平台即服务)和SaaS(软件即服务),这几个术语并不好理解.不过,如果你是个吃货,还喜欢汉堡,那这个问题就好解决了! 如果我想吃汉堡,有几种方法呢? 1.自己买材料自己做 准备烤箱,准备火腿,准备面粉,准备青菜,然后自己和面,加材料,加热等等.其要求动手能力比较强,比较难做,但是,您可以根据自己的口味,做出符合自己味道的汉堡.这就是On-Premise(本地部署). 典型代表:物理

从信息熵角度去理解问题

信息是个很抽象的概念.人们常常说信息很多,或者信息较少,但却很难说清楚信息到底有多少.比如一本五十万字的中文书到底有多少信息量.直到1948年,香农提出了“信息熵”的概念,才解决了对信息的量化度量问题.三国真人娱乐城 一条信息的信息量大小和它的不确定性有直接的关系.比如说,我们要搞清楚一件非常非常不确定的事,或是我们一无所知的事情,就需要了解大量的信息.相反,如果我们对某件事已经有了较多的了解,我们不需要太多的信息就能把它搞清楚.所以,从这个角度,我们可以认为,信息量的度量就等于不确定性的多少.

文章标题 带你从源码的角度去理解Handler

一.概述 Handler . Looper .Message 这三者都与Android异步消息处理线程相关的概念.那么什么叫异步消息处理线程呢? 异步消息处理线程启动后会进入一个无限的循环体之中,每循环一次,从其内部的消息队列中取出一个消息,然后回调相应的消息处理函数,执行完成一个消息后则继续循环.若消息队列为空,线程则会阻塞等待. 说了这一堆,那么和Handler . Looper .Message有啥关系?其实Looper负责的就是创建一个MessageQueue,然后进入一个无限循环体不断

从汇编角度来理解linux下多层函数调用堆栈运行状态

我们用下面的C代码来研究函数调用的过程. C++ Code 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16   int bar(int c, int d) { int e = c + d; return e; } int foo(int a, int b) { return bar(a, b); } int main(void) { foo(2, 3); return 0; } 如果在编译时加上-g选项,那么用objdump反汇编时可以把C代码和汇编代码穿插起来显示