字符设备驱动程序led驱动

以led驱动为例，讲解如何写一个字符设备驱动程序。

1）看原理图

a.确定引脚

b.看芯片手册，确定如何操作引脚

2）写驱动程序

3）写测试程序

最简单的字符设备驱动程序的框架：

App：     open           read          write            ioctl

---------------------------------------------------------------

驱动：  drv_open   drv_read    drv_write      drv_ioctl

----------------------------------------------------------------

硬件：

以面向对象的思想构造一个结构体，在这个结构体中填充drv_open、drv_write等这些函数。

a  分配一个file_operations结构体体；

b  设置它：

　　.open = led_open

　　.write  = led_write

c  注册：告诉内核，就是把file_operations这个结构体放入某个数组里面。可以简单的这样认为，内核中有一个数组，这个数组存放一个又一个的驱动程序，file_operations这个结构体想放在数组哪一项中，就是通过主设备号指定的。这个主设备号可以写0，如果写0的话，会从头开始遍历这个数组，找到一项空的，就把file_operations这个结构体放入。

d  入口函数:   register_chrdev

e  出口函数:   unregister_chrdev

我们提供的这些函数要实现什么样的功能？比如说led_open、led_write等函数实现的功能是什么？

led_open: 把led引脚配置为输出引脚

led_write: 根据app传入的值，设置引脚状态

问：在驱动中如何指定引脚，看原理图可以确定引脚是哪一个，但我如何告诉驱动程序呢？有三种方法可供选择。

1）传统写法。

在驱动代码中写死

2）总线设备驱动模型

把驱动一分为二。led_drv.c    led_dev.c

3)使用设备树指明引脚。

此时驱动程序也是分为两部分，一部分是led_drv.c   另一部分是设备树，比如说jz2440.dts。

注意：无论是传统方法、总线设备驱动模型法、设备树法驱动的核心都是一样的，都是分配、设置、注册一个file_operations结构体，唯一的差别就是在于如何指定这些引脚。

驱动写法核心不变，差别在于如何指定硬件资源。

以上三种驱动写法有什么优缺点呢？

假设有这样的一个场景：

公司里使用同一款芯片做了两个产品，一个是tv，一个是camera。

如何写驱动程序？

1）传统写法：

led_drv.c

分配一个file_opreation结构体

设置

　　.open = led_open------配置pin1为输出引脚

　　.write =led_write------根据app传入的值，设置pin1状态

注册

入口

出口

现在在第二块板子上写驱动程序，可以将led_drv.c的驱动程序复制过来，然后在此基础上修改。把原来的pin1改成pin2.

优点：简单

缺点：不易扩展，大量重复的代码

对于这种现象有没有办法改进呢？答案是肯定的。在我们这个场景里面，这两个设备使用同一个主芯片，引脚的操作是类似的。可以将这些引脚抽出来，通过其他方法来指定。由此引入总线设备驱动模型

2）总线设备驱动模型

将驱动分为两部分。一部分是led_dev.c, 一部分是led_drv.c

一部分是led_dev.c（指定资源）-------------------------对应tv

　　----分配、设置、注册一个platform_device。里面会有各种资源指定引脚，比如说：

　　　　.resource 指明引脚  pin1

               .name 

一部分是led_dev.c（指定资源）-------------------------对应camera

　　----分配、设置、注册一个platform_device。里面会有各种资源指定引脚，比如说：

　　　　.resource 指明引脚  pin2

　　　　.name

tv的led_dev.c和camera的led_dev.c对应同一个led_drv.c

 一部分是led_drv.c（分配、设置、注册一个platform_drv结构体，这个结构体中有probe、.driver{  .name }） 。

当内核发现有一个平台device和平台driver的名字相同时，probe函数就会被调用。probe函数里面会做什么事情呢？

分配一个file_opreation结构体

设置

　　.open = led_open------在这个地方不会将引脚写死了，配置平台设备中指定的引脚

　　.write =led_write------根据app传入的值，设置平台设备指定的引脚状态

注册

入口

出口

对于tv和camera，他们的led_drv.c保持不变，唯一需要修改的是led_dev.c中的资源。在TV中资源指定是pin1，在camera中资源指定是pin2。这样的驱动程序很容易扩展，只需要修改资源即可。那么缺点是什么呢？现在有两个版本的硬件，就需要有两个platform_device,如果继续增加的话，就需要更多的platform_device,里面就会存在很多冗余的代码，并且这些代码是以.c文件存在的，充斥着大量的污染，linux创始人说这样的代码存在就是垃圾。继续改进，从而设备树就登场了。

3）设备树

总线设备驱动模型的缺点在于通过这些.c文件来指定这些资源，使用的话需要重新编译。

使用设备树写程序的时候，仍然分为两部分：

led_drv.c

　分配、设置、注册一个platform_driver结构体（同总线设备驱动模型的platform_driver）

通过dts文件来指定资源，内核会根据这个dts文件构造platform_device, 当需要更改单板时，只需重新定义dts文件就可以了。这个文件最终会被编译成一个dtb文件。启动单板时，既要启动内核，也要传入dtb文件。

复杂、无冗余代码