目录

前言：

一、驱动设计

（1）面向对象：

（2）分层：

（3）分离：

二、驱动框架

（1）传统框架 

（2）总线设备驱动框架：

（3）设备树

---

前言：

经典环节：我一直深信，带着问题思考和实践，能够更容易理解并学习到。

（1）驱动设计的核心思想

• 面向对象
• 分层
• 分离

（2）驱动框架有哪些？

• 传统框架
• 总线设备驱动框架
• 设备树

写作不易，如果有所帮助，多多支持，大家一同进步呀！前人的思想真的巧妙！！！

一、驱动设计

9.驱动设计的思想_面向对象_分层_分离_哔哩哔哩_bilibili

现如今大部分的驱动开发工作，是基于前人的工作上进行修改和完善，所以他所运用的驱动设计思想（前人的想法是真的巧妙），我们需要去学习和理解，之后就可以知道在什么地方完成相应的改进和完善。 

驱动的学习，是要认知到驱动的作用，在Linux系统上的驱动程序相较于裸机单片机上的驱动程序有什么区别，为什么要需要驱动框架之类的东西？可以参照阅读以下的博文：

【Linux】设备驱动简述，快速认知_希希雾里的博客-CSDN博客

经过前面的应用开发的学习，我们可以非常清晰的认知到，Linux系统需要处理非常多的设备，那么如何管理控制以及处理数据，就是一个比较大的问题。并且尤其是进一步的开发过程中，设备改动以及程序版本更迭，如何快速的开发以及兼容，就又是一个大的问题。

每一个设备都有相关的特点和属性，它就是一个个对象，之后就是将这个对象进行分层（类比，皮肤肌肉），最后就是对其更深层次的分解分离（同一类的共性和特性）。

驱动设计的思想，就如上述的，面向对象、分层以及分离。

（1）面向对象：

字符设备驱动程序就是要抽象出一个file_operations结构体，面向对象（设备），提供具体实现的函数（open/read/write）。

（2）分层：

上下分层，举个例子，字符设备驱动程序

• 上层实现硬件无关的操作，比如注册字符设备驱动
• 下层实现硬件相关的操作，

（3）分离：

以LED驱动程序为例，如果更换一个引脚来控制LED。这里涉及到引脚初始化和设置，某一款芯片每一个GPIO操作都是类似的，这里就可以写出比较通用的硬件操作代码（chipY_gpio.c）。

对上图进行总结，board_A.c和board_B.c定义资源，chipY_gpio.c为硬件通用的代码，实现分离。

二、驱动框架

10.驱动进化之路_总线设备驱动模型_哔哩哔哩_bilibili

（1）传统框架 

这里使用到哪个引脚，怎么操作引脚，都写在代码中。

这里的框架，就不考虑拓展性，可以快速实现功能，但是涉及到引脚的修改时，就需要重新编译。

（2）总线设备驱动框架：

如果有一个设备（led）就要建立一个结构体（led_resource）来管理的话，会非常的麻烦

应用分离思想，进行进一步的拓展，引入platform_device/platform_driver，将资源（devise）与“驱动”（driver）分离开来。

按照上述分离之后，我们会发现还是会出现以下多个设备类型的定义，是否可以统一管理呢？这里就引入了总线（bus）的概念，对分离思想更好的实现。

对上述模型进行简化之后就如下图：设备驱动模型视频讲解-Linux笔记

Linux的设备驱动管理将运用对象思想对各式各样的设备、总线以及驱动进行管理。 

总线（bus）：负责管理挂载对应总线的设备以及驱动；

设备（device）：挂载在某个总线的物理设备。

驱动（driver）：与特定设备相关的软件，负责初始化该设备以及提供一些操作该设备的操作方式。

类（class）：对于具有相同功能的设备，归结到一种类别，进行分类管理。

（3）设备树

实际开发中，会有不同单板的.c资源文件，如果都放入Linux内核中，会导致内核臃肿不堪。

这里引入了dts配置文件来管理。dts文件会编译出dtb文件，之后传给内核，内核会解析dtb，产生一系列的platform_device/platform_driver文件。

 这里我们可以看到dtb文件和dts文件都是在内核外的，这样可以使得内核精简优雅。