目录
一. 设备树
把这个词分开其实就是"设备"和"树"， 树的主干就是系统总线，分支则是IIC,SPI等各硬件。而之前没有设备树的时候，linux是如何描述板级信息的？
通过硬编码在内核源代码中描述板级信息，直接写在内核源码中。
而dts用于描述板级信息，如设备节点，属性及配置；dtsi用于描述SOC信息，
设备树的语法结构：
主要的语法元素包含：节点和属性
节点的定义：
每个节点以一个标签和花括号开始，如
cpus {
cpu@0 {
compatible = "arm,cortex-a53";
reg = <0>;
clock-frequency = <1200000000>; /* 1.2 GHz */
};
cpu@1 {
compatible = "arm,cortex-a53";
reg = <1>;
clock-frequency = <1200000000>; /* 1.2 GHz */
};
};
在这个例子中，cpus 是一个节点，cpu@0 和 cpu@1 是它的子节点
设备树的标准属性：
compatible
指定设备的兼容性字符串，帮助操作系统或驱动程序确定如何处理该设备。
reg
描述设备寄存器的地址和大小，通常用于内存映射的设备。
interrupts
定义设备的中断信息，包括中断号和中断触发方式。
那么我们驱动到底是怎么使用设备树的呢？
那么我们驱动到底是怎么使用设备树的呢？
那么我们驱动到底是怎么使用设备树的呢？
比如，我们有在设备树中有下面的定义：
led_device: led@0
{
compatible = "my_led";
reg = <0x0 0x0 0x4>
led-color = "red"
}1.1 驱动的设备树匹配
驱动需要在'of_match_table'中指定设备树节点的兼容性信息，以便内核可以将设备树中的节点与驱动匹配起来
#include <linux/module.h>
#include <linux/platform_device.h>
#include <linux/of.h>
#include <linux/io.h>
struct led_device {
void __iomem *base_addr;
const char *color;
};
static const struct of_device_id led_of_match[] = {
{ .compatible = "my_led", },
{ /* sentinel */ }
};
// 一个用于定义设备树的匹配表，以便内核可以根据设备树中的信息识别和加载驱动
MODULE_DEVICE_TABLE(of, led_of_match);
1.2 驱动的Probe函数
在'probe'函数中，驱动通过设备树API获取设备的配置信息。
static int led_probe(struct platform_device *pdev)
{
//定义一个指向'led_device'结构体的指针，用于保存LED设备的相关信息
struct led_device *led;
//用于获取设备的内存资源
struct resource *res;
//从 platform_device 结构体中获取设备树节点信息，用于访问设备树中定义的属性。
struct device_node *node = pdev->dev.of_node;
// 分配内存给 led_device 结构体，并初始化为零。devm_kzalloc 函数确保在设备释放时自动释放内存。
led = devm_kzalloc(&pdev->dev, sizeof(*led), GFP_KERNEL);
// 检查内存分配是否成功。如果失败，返回 -ENOMEM 表示内存不足。
if (!led)
return -ENOMEM;
// 获取寄存器的资源
res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
if (!res)
return -ENODEV;
// 映射寄存器地址
led->base_addr = devm_ioremap_resource(&pdev->dev, res);
if (IS_ERR(led->base_addr))
return PTR_ERR(led->base_addr);
// 从设备树中获取 LED 颜色信息
if (of_property_read_string(node, "led-color", &led->color)) {
dev_err(&pdev->dev, "Failed to get led-color from device tree\n");
return -EINVAL;
}
dev_info(&pdev->dev, "LED color is %s\n", led->color);
// 其他初始化代码...
platform_set_drvdata(pdev, led);
return 0;
}
1.3 驱动的Remove函数
在'remove'函数中，你可以执行清理操作，例如取消映射的内存
static int led_remove(struct platform_device *pdev)
{
struct led_device *led = platform_get_drvdata(pdev);
// 释放资源等操作...
return 0;
}
1.4 驱动结构体
最后，将'probe'和'remove'函数与设备树匹配表一起定义，并注册驱动
static struct platform_driver led_driver = {
// 指定当平台设备匹配驱动时调用的'probe'函数，在这里它指向'ledn_porbe'函数
// 该函数负责初始化和配置设备
.probe = led_probe,
.remove = led_remove,
.driver = {
.name = "led_driver",
.of_match_table = led_of_match,
},
};
module_platform_driver(led_driver);
MODULE_AUTHOR("Author");
MODULE_DESCRIPTION("LED Driver");
MODULE_LICENSE("GPL");
二. 老版字符设备驱动框架
主要指的就是传统的设备驱动模型，通常包含文件操作函数如open、read、write和close。他们通过设备号和设备文件进行交互，实现数据的读写和设备控制。
2.1 文件操作函数的实现
static int my_open(struct inode *inode, struct file *file) {
printk(KERN_INFO "mychardev: Device opened\n");
return 0;
}
static int my_release(struct inode *inode, struct file *file) {
printk(KERN_INFO "mychardev: Device closed\n");
return 0;
}
static ssize_t my_read(struct file *file, char __user *buf, size_t len, loff_t *offset) {
ssize_t ret = 0;
if (*offset >= BUFFER_SIZE)
return 0;
if (len > BUFFER_SIZE - *offset)
len = BUFFER_SIZE - *offset;
if (copy_to_user(buf, device_buffer + *offset, len) != 0)
return -EFAULT;
*offset += len;
ret = len;
printk(KERN_INFO "mychardev: Read %zu bytes\n", len);
return ret;
}
static ssize_t my_write(struct file *file, const char __user *buf, size_t len, loff_t *offset) {
ssize_t ret = 0;
if (*offset >= BUFFER_SIZE)
return 0;
if (len > BUFFER_SIZE - *offset)
len = BUFFER_SIZE - *offset;
if (copy_from_user(device_buffer + *offset, buf, len) != 0)
return -EFAULT;
*offset += len;
ret = len;
printk(KERN_INFO "mychardev: Wrote %zu bytes\n", len);
return ret;
}
三. 新字符设备驱动框架
新添加的关键特性有：
3.1 设备模型
struct device 和 struct device_driver::新版内核引入了设备模型，提供了一种统一的方式来管理设备和驱动程序，这些结构体提供了设备和驱动程序之间的关联和通信机制
3.2 设备树
设备树用于描述硬件设备的结构，内核通过设备树来初始化和配置设备，而不是通过硬编码的方式
3.3 kobject 和 sysfs
kobject是一个内核对象，用于管理内核中的对象；sysfs是一个文件系统，通过它可以在用户空间中暴露内核对象的信息
可以通过sysfs创建和管理设备的属性，从而使用户空间能够访问和修改设备的状态
3.4 fasync 和 poll
这两个机制提供了异步事件通知的能力，可以用来处理字符设备的事件驱动操作
3.5 file_operations的改进
新版本内核在file_operations结构体中添加了一些新的方法，如unlocked_ioctl，支持无锁的IO控制操作。
四. plateform驱动框架
平台驱动（Platform Driver）框架在Linux内核中是一种专门用于处理平台设备的机制。平台设备通常指的是那些直接与系统硬件紧密耦合的设备，例如嵌入式系统中的设备，或那些通过设备树（Device Tree）描述的设备。
五. SPI驱动框架和编写流程
5.1 定义服务接口
创建一个接口或抽象类，定义服务的标准方法和功能
public interface MyService {
void execute();
}
5.2 实现服务提供者
编写一个或多个服务实现类，实现服务接口
public class MyServiceImpl implements MyService {
@Override
public void execute() {
System.out.println("Service Executed!");
}
}
5.3 配置服务提供者
- 创建一个描述服务提供者的配置文件，通常放在
META-INF/services目录下，文件名为服务接口的完全限定名。 - 文件内容是服务提供者的实现类的完全限定名
com.example.MyServiceImpl
5.4 加载服务
使用ServiceLoader类动态加载并使用服务提供者。
ServiceLoader<MyService> loader = ServiceLoader.load(MyService.class);
for (MyService service : loader) {
service.execute();
}
5.5 部署和测试
- 打包应用程序，确保配置文件正确放置在
META-INF/services目录中。 - 测试服务加载和执行是否符合预期。
六. SPI 总线接口
SPI主要包括以下4条信号线：MOSI，MISO，SS/CS，SCK
通信模式主要是4种，由时钟极性和时钟相位决定
它是一种全双工，串行总线，时钟同步
七. IIC总线接口
主要包括两条信号线：SCL，SDA
时序主要包括：开始信号，应答信号，地址信号，停止信号
它是一种半双工，串行总线，时钟同步，但它支持多主机
八. UART
起始位：标识数据传输的开始，起始位通常是逻辑低电平，在数据传输开始时，数据线会从高电平(空闲状态)变为低电平
数据位：通常是5到9位，通常是8位
奇偶校验位：用于错误检测。奇偶校验位用于检测数据传输过程中是否发生了错误。
停止位：止位的数量可以是1位、1.5位或2位，具体取决于通信协议的配置。
20万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
