以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文件。
复杂、无冗余代码
