一文搞懂|Linux驱动的来龙去脉

一口Linux 2022-02-06 00:00

驱动相关的学习资料网上很多,但大部分都是碎片化的记录,很少有系统化的总结整理。本文旨在系统化的讲清楚 Linux 驱动的来龙去脉。先从总线,设备,驱动介绍内核对于驱动的模型设计;然后引入设备树的概念,打通设备和驱动的关系;最后手把手和你一起定制自己的开发板。这也是拿到芯片后,如何 bringup 板子的入门工作。详细交流可以加我微信 rrjike,一起学习进步!

Linux 总线、设备、驱动模型的探究

设备驱动模型的需求

总线、设备和驱动模型,如果把它们之间的关系比喻成生活中的例子是比较容易理解的。举个例子,充电墙壁插座安静的嵌入在墙面上,无论设备是电脑还是手机,插座都能依然不动的完成它的使命——充电,没有说为了满足各种设备充电而去更换插座的。其实这就是软件工程强调的高内聚、低耦合概念。

所谓高内聚低耦合是模块内各元素联系越紧密就代表内聚性就越高,模块间联系越不紧密就代表耦合性低。所以高内聚、低耦合强调的就是内部要紧紧抱团。设备和驱动就是基于这种模型去实现彼此隔离不相干的。这里,有的读者就要问了,高内聚、低耦合的软件模型理解,可设备和驱动为什么要采用这种模型呢?没错,好问题。下面进入今天的话题——总线、设备和驱动模型的探究。

设想一个叫 GITCHAT 的网卡,它需要接在 CPU 的内部总线上,需要地址总线、数据总线和控制总线,以及中断 pin 脚等。

那么在 GITCHAT 的驱动里需要定义 GITCHAT 的基地址、中断号等信息。假设 GITCHAT 的地址为0x0001,中断号是 2,那么:

#define GITCHAT_BASE 0x0001
#define GITCHAT_INTERRUPT 2

int gitchat_send()
{
    writel(GITCHAT_BASE + REG, 1);
    ...
}

int gitchat_init()
{
    request_init(GITCHAT_INTERRUPT, ...);
    ...
}

但是世界上的板子千千万,有三星、华为、飞思卡尔……每个板子的信息也都不一样,站在驱动的角度看,当每次重新换板子的时候,GITCHAT_BASE 和 GITCHAT_INTERRUPT 就不再一样,那驱动代码也要随之改变。这样的话一万个开发板要写一万个驱动了,这就是文章刚开始提到的高内聚、低耦合的应用场景。

驱动想以不变应万变的姿态适配各种设备连接的话就要实现设备驱动模型。基本上我们可以认为驱动不会因为 CPU 的改变而改变,所以它应该是跨平台的。自然像 “#define GITCHAT_BASE 0x0001,#define GITCHAT_INTERRUPT 2” 这样描述和 CPU 相关信息的代码不应该出现在驱动里。

设备驱动模型的实现

现在 CPU 板级信息和驱动分开的需求已经刻不容缓。但是基地址、中断号等板级信息始终和驱动是有一定联系的,因为驱动毕竟要取出基地址、中断号等。怎么取?有一种方法是 GITCHAT 驱动满世界去询问各个板子:请问你的基地址是多少?中断号是几?细心的读者会发现这仍然是一个耦合的情况。

对软件工程熟悉的读者肯定立刻想到能不能设计一个类似接口适配器的类(adapter)去适配不同的板级信息,这样板子上的基地址、中断号等信息都在一个 adapter 里去维护,然后驱动通过这个 adapter 不同的 API 去获取对应的硬件信息。没错,Linux 内核里就是运用了这种设计思想去对设备和驱动进行适配隔离的,只不过在内核里我们不叫做适配层,而取名为总线,意为通过这个总线去把驱动和对应的设备绑定一起,如图:

基于这种设计思想,Linux 把设备驱动分为了总线、设备和驱动三个实体,这三个实体在内核里的职责分别如下:

模型设计好后,下面来看一下具体驱动的实践,首先把板子的硬件信息填入设备端,然后让设备向总线注册,这样总线就间接的知道了设备的硬件信息。比如一个板子上有一个 GITCHAT,首先向总线注册:

static struct resource gitchat_resource[] = {
    {
            .start = ...,
            .end = ...,
            .flags = IORESOURCE_MEM
    }...
};

static struct platform_device gitchat_device = {
    .name = "gitchat";
    .id = 0;
    .num_resources = ARRAY_SIZE(gitchat_resource);
    .resource = gitchat_resource,
};

static struct platform_device *ip0x_device __initdata = {
    &gitchat_device,
    ...
};

static ini __init ip0x_init(void)
{
    platform_add_devices(ip0x_device, ARRAY_SIZE(ip0x_device));
}

现在 platform 总线上自然知道了板子上关于 GITCHAT 设备的硬件信息,一旦 GITCHAT 的驱动也被注册的话,总线就会把驱动和设备绑定起来,从而驱动就获得了基地址、中断号等板级信息。总线存在的目的就是把设备和对应的驱动绑定起来,让内核成为该是谁的就是谁的和谐世界,有点像我们生活中红娘的角色,把有缘人通过红线牵在一起。设备注册总线的代码例子看完了,下面看下驱动注册总线的代码示例:

static int gitchat_probe(struct platform_device *pdev)
{
    ...
    db->addr_res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
    db->data_res = platform_get_resource(pdev, IORESOURCE_MEM, 1);
    db->irq_res  = platform_get_resource(pdev, IORESOURCE_IRQ, 2);
    ...
}

从代码中看到驱动是通过总线 API 接口 platform_get_resource 取得板级信息,这样驱动和设备之间就实现了高内聚、低耦合的设计,无论你设备怎么换,我驱动就可以岿然不动。

看到这里,可能有些喜欢探究本质的读者又要问了,设备向总线注册了板级信息,驱动也向总线注册了驱动模块,但总线是怎么做到驱动和设备匹配的呢?接下来就讲下设备和驱动是怎么通过总线进行“联姻”的。

总线里有很多匹配方式,比如:

static int platform_match(struct device *dev, struct device_driver *drv)
{
        struct platform_device *pdev = to_platform_device(dev);
        struct platform_driver *pdrv = to_platform_driver(drv);

        /* When driver_override is set, only bind to the matching driver */
        if (pdev->driver_override) 
                return !strcmp(pdev->driver_override, drv->name);

        /* Attempt an OF style match first */
        if (of_driver_match_device(dev, drv))
                return 1;

        /* Then try ACPI style match */
        if (acpi_driver_match_device(dev, drv))
                return 1;

        /* Then try to match against the id table */
        if (pdrv->id_table)
                return platform_match_id(pdrv->id_table, pdev) != NULL;

        /* fall-back to driver name match */
        return (strcmp(pdev->name, drv->name) == 0);
}

从上面可知 platform 总线下的设备和驱动是通过名字进行匹配的,先去匹配 platform_driver 中的 id_table 表中的各个名字与 platform_device->name 名字是否相同,如果相同则匹配。

设备驱动模型的改善

相信通过上面的学习,相信对于设备、驱动通过总线来匹配的模型已经有所了解。如果写代码的话应该是下面结构图所示:

最底层是不同板子的板级文件代码,中间层是内核的总线,最上层是对应的驱动,现在描述板级的代码已经和驱动解耦了,这也是 Linux 设备驱动模型最早的实现机制,但随着时代的发展,就像是人类的贪婪促进了社会的进步一样,开发人员对这种模型有了更高的要求,虽然驱动和设备解耦了,但是天下设备千千万,每次设备的需求改动都要去修改 board-xxx.c 设备文件的话,这样下去,有太多的板级文件需要维护。完美的 Linux 怎么会允许这样的事情存在,于是乎,设备树(DTS)就登向了历史舞台,下一篇内容将探讨设备树的实现原理和用法。

Linux 设备树(DTS)的深入理解

设备树的出现

上面说过设备树的出现是为了解决内核中大量的板级文件代码,通过 DTS 可以像应用程序里的 XML 语言一样很方便的对硬件信息进行配置。关于设备树的出现其实在 2005 年时候就已经在 PowerPC Linux 里出现了,由于 DTS 的方便性,慢慢地被广泛应用到 ARM、MIPS、X86 等架构上。为了理解设备树的出现的好处,先来看下在使用设备树之前是采用什么方式的。

关于硬件的描述信息之前一般放在一个个类似 arch/xxx/mach-xxx/board-xxx.c 的文件中,如:

static struct resource gitchat_resource[] = {
    {
        .start = 0x20100000 ,
        .end = 0x20100000 +1,
        .flags = IORESOURCE_MEM 
        …
        .start = IRQ_PF IRQ_PF 15 ,
        .end = IRQ_PF IRQ_PF 15 ,
        .flags = IORESOURCE_IRQ | IORESOURCE_IRQ_HIGHEDGE
    }
};

static struct platform_device gitchat_device = {
    .name name ="gitchat",
    .id = 0,
    .num_resources num_resources = ARRAY_SIZE(gitchat_resource),
    .resource = gitchat_resource,
};

static struct platform_device *ip0x_devices[] __initdata ={
    &gitchat_device,
};

static int __init ip0x_init(void)
{
    platform_add_devices(ip0x_devices, ARRAY_SIZE(ip0x_devices)); 
}

一个很少的地址获取,我们就要写大量的类似代码,当年 Linus 看到内核里有大量的类似代码,很是生气并且在 Linux 邮件列表里发了份邮件,才有了现在的设备树概念,至于设备树的出现到底带来了哪些好处,先看一下设备树的文件:

eth:eth@ 4,c00000 {
    compatible ="csdn, gitchat";
    reg =<
        4 0x00c00000 0x2
        4 0x00c00002 0x2
    >;
    interrupt-parent =<&gpio 2>;
    interrupts=<14 IRQ_TYPE_LEVEL_LOW>;
    …
};

从代码中可看到对于 GITCHAT 这个网卡驱动、一些寄存器、中断号和上一层 gpio 节点都很清晰的被描述。比上一图的代码优化了很多,也容易维护了很多。这样就形成了设备在脚本,驱动在 c 文件里的关系图:

从图中可以看出 A、B、C 三个板子里都含有 GITCHAT 设备树文件,这样对于 GITCHAT 驱动写一份就可以在 A、B、C 三个板子里共用。从上幅图里不难看出,其实设备树的出现在软件模型上相对于之前并没有太大的改变,设备树的出现主要在设备维护上有了更上一层楼的提高,此外在内核编译上使内核更精简,镜像更小。

设备树的文件结构和剖析

设备树和设备树之间到底是什么关系,有着哪些依赖和联系,先看下设备树之间的关系图:

除了设备树(DTS)外,还存有 dtsi 文件,就像代码里的头文件一样,是不同设备树共有的设备文件,这不难理解,但是值得注意的是如果 dts 和 dtsi 里都对某个属性进行定义的话,底层覆盖上层的属性定义。这样的好处是什么呢?假如你要做一块电路板,电路板里有很多模块是已经存在的,这样就可以直接像包含头文件一样把共性的 dtsi 文件包含进来,大大减少工作量,后期也可以对类似模块再次利用。

设备树文件的格式是 dts,包含的头文件格式是 dtsi,dts 文件是一种程序员可以看懂的格式,但是 Uboot 和 Linux 只能识别二进制文件,不能直接识别。所以就需要把 dts 文件编译成 dtb 文件。把 dts 编译成 dtb 文件的工具是 dtc,位于内核目录下 scripts/dtc,也可以手动安装:sudo apt-get install device-tree-compiler 工具。具体 dts 是如何转换成机器码并在内存里供 kernel 识别的,请看下图:

设备树的应用

有了理论,在具体的工程里如何做设备树呢?这里介绍三大法宝:文档、脚本、代码。文档是对各种 node 的描述,位于内核 documentation/devicetree/bingdings/arm/ 下,脚本就是设备树 dts,代码就是你要写的设备代码,一般位于 arch/arm/ 下,以后在写设备的时候可以用这种方法,绝对的事半功倍。很多上层应用开发者没有做过内核开发的经验,对内核一直觉得很神秘,其实可以换一种思路来看内核,相信上层应用开发者最熟悉的就是各种 API,工作中可以说就是和 API 打交道,对于内核也可以想象是各种 API,只不过是内核态的 API。这里设备文件就是根据各种内核态的 API 来调用设备树里的板级信息:

  • struct device_node *of_find_node_by_phandle(phandle handle);

  • struct device_node *of_get_parent(const struct device_node_ *node);

  • of_get_child_count()

  • of_property_read_u32_array()

  • of_property_read_u64()

  • of_property_read_string()

  • of_property_read_string_array()

  • of_property_read_bool()

具体的用法这里不做进一步的解释,大家可以查询资料或者看官网解释。

这里对设备树做个总结,设备树可以总结为三大作用:一是平台标识,所谓平台标识就是板级识别,让内核知道当前使用的是哪个开发板,这里识别的方式是根据 root 节点下的 compatible 字段来匹配。二是运行时配置,就是在内核启动的时候 ramdisk 的配置,比如 bootargs 的配置,ramdisk 的起始和结束地址。三是设备信息集合,这也是最重要的信息,集合了各种设备控制器,接下来的实践课会对这一作用重点应用。这里有张图对大家理解设备树作用有一定的帮助:

Linux 设备和驱动的相遇

一个开发板

上面的最后我们讲到设备树的三大作用,其最后一个作用也是最重要的作用:设备信息集合。这一节结合设备信息集合的详细讲解来认识一下设备和驱动是如何绑定的。所谓设备信息集合,就是根据不同的外设寻找各自的外设信息,我们知道一个完整的开发板有 CPU 和各种控制器(如 I2C 控制器、SPI 控制器、DMA 控制器等),CPU 和控制器可以统称为 SOC,除此之外还有各种外设 IP,如 LCD、HDMI、SD、CAMERA 等,如下图:

我们看到一个开发板有很多的设备,这些设备是如何一层一层展开的呢?设备和驱动又是如何绑定的呢?我们带着这些疑问进入本节的主题。

各级设备的展开

内核启动的时候是一层一层展开地去寻找设备,设备树之所以叫设备树也是因为设备在内核中的结构就像树一样,从根部一层一层的向外展开,为了更形象的理解来看一张图:

大的圆圈中就是我们常说的 soc,里面包括 CPU 和各种控制器 A、B、I2C、SPI,soc 外面接了外设 E 和 F。IP 外设有具体的总线,如 I2C 总线、SPI 总线,对应的 I2C 设备和 SPI 设备就挂在各自的总线上,但是在 soc 内部只有系统总线,是没有具体总线的。

第一节中讲了总线、设备和驱动模型的原理,即任何驱动都是通过对应的总线和设备发生联系的,故虽然 soc 内部没有具体的总线,但是内核通过 platform 这条虚拟总线,把控制器一个一个找到,一样遵循了内核高内聚、低耦合的设计理念。下面我们按照 platform 设备、i2c 设备、spi 设备的顺序探究设备是如何一层一层展开的。

1.展开 platform 设备

上图中可以看到红色字体标注的 simple-bus,这些就是连接各类控制器的总线,在内核里即为 platform 总线,挂载的设备为 platform 设备。下面看下 platform 设备是如何展开的。

还记得上一节讲到在内核初始化的时候有一个叫做 init_machine() 的回调函数吗?如果你在板级文件里注册了这个函数,那么在系统启动的时候这个函数会被调用,如果没有定义,则会通过调用 of_platform_populate() 来展开挂在“simple-bus”下的设备,如图(分别位于 kernel/arch/arm/kernel/setup.c,kernel/drivers/of/platform.c):

这样就把 simple-bus 下面的节点一个一个的展开为 platform 设备。

2.展开 i2c 设备

有经验的小伙伴知道在写 i2c 控制器的时候肯定会调用 i2c_register_adapter() 函数,该函数的实现如下(kernel/drivers/i2c/i2c-core.c):

注册函数的最后有一个函数 of_i2c_register_devices(adap),实现如下:

of_i2c_register_devices()函数中会遍历控制器下的节点,然后通过of_i2c_register_device()函数把 i2c 控制器下的设备注册进去。

3.展开 spi 设备

spi 设备的注册和 i2c 设备一样,在 spi 控制器下遍历 spi 节点下的设备,然后通过相应的注册函数进行注册,只是和 i2c 注册的 api 接口不一样,下面看一下具体的代码(kernel/drivers/spi/spi.c):

当通过 spi_register_master 注册 spi 控制器的时候会通过 of_register_spi_devices 来遍历 spi 总线下的设备,从而注册。这样就完成了 spi 设备的注册。

各级设备的展开

学到这里相信应该了解设备的硬件信息是从设备树里获取的,如寄存器地址、中断号、时钟等等。接下来我们一起看下这些信息在设备树里是怎么记录的,为下一节动手定制开发板做好准备。

1.reg 寄存器

我们先看设备树里的 soc 描述信息,红色标注的代表着寄存器地址用几个数据量来表述,绿色标注的代表着寄存器空间大小用几个数据量来表述。图中的含义是中断控制器的基地址是 0xfec00000,空间大小是 0x1000。如果 address-cells 的值是 2 的话表示需要两个数量级来表示基地址,比如寄存器是 64 位的话就需要两个数量级来表示,每个代表着 32 位的数。

2.ranges 取值范围

ranges 代表了 local 地址向 parent 地址的转换,如果 ranges 为空的话代表着与 cpu 是 1:1 的映射关系,如果没有 range 的话表示不是内存区域。

动手定制一个开发板案例

前面通过学习总线、设备、驱动模型知识后,知道了设备和驱动之间都是通过总线进行绑定而匹配的;然后通过设备树的深入探究,知道了设备树的出现大大增加了驱动的通用性;接着我们一起看了 Linux 的启动流程和设备在内核里一层一层的展开。

通过前面的课程学习,相信内核初学者对内核和驱动有了一个大概的感性认识,有内核经验的小伙伴相信也有了系统化的梳理。都说“实践是检验真理的唯一标准”,为了检验前面的理论性,更为了加深理解,这里我们手把手一起从设备树入手,模拟一个电路板,上面有中断控制器、GPIO 控制器、I2C 控制器、SPI 控制器、以太网控制器等,并根据这个电路板从头到尾构建一个 DTS 文件,使内核支持我们自己定制的开发板。

添加一个新的 SOC

我们假设 csdn 是一家芯片厂商,研发了一块叫做 gitchat 的芯片,对应的开发板叫做 evb。需要做什么工作才能定制一套开发板并且使 Linux 支持我们这块电路板呢?

首先我们在 arch/arm 目录下创建一个 mach-gitchat 的目录,然后创建 arch/arm/machgitchat/Kconfig,Makefile,common.c。

其中,Kconfig 里做了一个叫 ARCH_GITCHAT 的假芯片,common.c 是对应的驱动,Makefile 里对这个驱动做了编译。我们来简单的看一下这个驱动

就像前几节课讲的那样,我们是通过 DT_MACHINE_START 来定义一个电路板的,里面有很多回调函数,这里简单的写了 init_late 和 dt_compat,其中 dt_compat 会根据设备树里的字段进行匹配,如果字段一致就说明匹配正确,这里的字段是“csdn, gitchat”。

添加对应的 DTS

现在已经在 Linux 里添加了我们定义的 soc,接下来需要添加 soc 对应的设备树,即具体的板级文件信息。

在 arch/arm/boot/dts 下创建 csdn-gitchat.dtsi 和 csdn-gitchat-evb.dts。csdn-gitchat.dtsi 是对芯片的描述,csdn-gitchat-evb.dts 是针对这个芯片的 evb 板子描述,其内容分别如下:

/*
 * DTS file for demo platform for Dec20,2017 CSDN/Gitchat course
 *
 * Copyright (c) 2017 xxx 
 *
 * Licensed under GPLv2.
 */


/ {
    compatible = "csdn,gitchat";
    #address-cells = <1>;
    #size-cells = <1>;
    interrupt-parent = <&intc>;

    aliases {
        serial0 = &uart0;
    };

    cpus {
        #address-cells = <1>;
        #size-cells = <0>;

        cpu@0 {
            compatible = "arm,cortex-a9";
            device_type = "cpu";
            reg = <0x0>;
        };
        cpu@1 {
            compatible = "arm,cortex-a9";
            device_type = "cpu";
            reg = <0x1>;
        };
    };

    axi@40000000 {
        compatible = "simple-bus";
        #address-cells = <1>;
        #size-cells = <1>;
        ranges = <0x40000000 0x40000000 0x80000000>;

        l2-cache-controller@80040000 {
            compatible = "arm,pl310-cache";
            reg = <0x80040000 0x1000>;
            interrupts = <59>;
            arm,tag-latency = <1 1 1>;
            arm,data-latency = <1 1 1>;
            arm,filter-ranges = <0 0x40000000>;
        };

        intc: interrupt-controller@80020000 {
            #interrupt-cells = <1>;
            interrupt-controller;
            compatible = "csdn,gitchat";
            reg = <0x80020000 0x1000>;
        };

        peri-iobg@b0000000 {
            compatible = "simple-bus";
            #address-cells = <1>;
            #size-cells = <1>;
            ranges = <0x0 0xb0000000 0x180000>;

            ethernet@10000 {
                compatible = "davicom,dm9000";
                reg = <0x10000 0x2 0x10004 0x2>;
                interrupts = <7>;
                davicom,no-eeprom;
            };

            timer@20000 {
                compatible = "csdn,gitchat-tick";
                reg = <0x20000 0x1000>;
                interrupts = <0>;
                clocks = <&clks 11>;
            };

            clks: clock-controller@30000 {
                compatible = "csdn,gitchat-clkc";
                reg = <0x30000 0x1000>;
                #clock-cells = <1>;
            };

            gpio0: goio@40000 {
                #gpio-cells = <2>;
                #interrupt-cells = <2>;
                compatible = "csdn,gitchat-gpio";
                reg = <0x40000 0x200>;
                interrupts = <43>;
                gpio-controller;
                interrupt-controller;
            };

            uart0: uart@50000 {
                cell-index = <0>;
                compatible = "csdn,gitchat-uart";
                reg = <0x50000 0x1000>;
                interrupts = <17>;
                status = "disabled";
            };

            spi0: spi@d0000 {
                cell-index = <0>;
                compatible = "csdn,gitchat-spi";
                reg = <0xd0000 0x10000>;
                interrupts = <15>;
                #address-cells = <1>;
                #size-cells = <0>;
                status = "okay";
            };

            i2c0: i2c@e0000 {
                cell-index = <0>;
                compatible = "csdn,gitchat-i2c";
                reg = <0xe0000 0x10000>;
                interrupts = <24>;
                #address-cells = <1>;
                #size-cells = <0>;
                status = "okay";
            };
        };
    };
};
/dts-v1/;

/include/ "csdn-gitchat.dtsi"

/ {
    model = "Csdn Gitchat EVB Board";
    compatible = "csdn,gitchat-evb""csdn,gitchat";

    memory {
        device_type = "memory";
        reg = <0x00000000 0x20000000>;
    };

    chosen {
        bootargs = "console=ttyS0,115200 root=/dev/mtdblock5 rw rootfstype=ubifs";
    };

    axi@40000000 {
        peri-iobg@b0000000 {
            spi@d0000 {
                status = "disabled";
            };
            i2c@e0000 {
                pixcir_ts@5c {
                    compatible = "pixcir,pixcir_tangoc";
                    reg = <0x5c>;
                    interrupt-parent = <&gpio0>;
                    interrupts = <17 0>;
                    attb-gpio = <&gpio0 22 0>;
                    touchscreen-size-x = <1024>;
                    touchscreen-size-y = <600>;
                };
            };
        };
    };

};

&uart0 {
    status = "okay";
};

由于篇幅限制,这里我们只写了部分代码。

DTS 的编译

在 arch/arm/boot/dts/Makefile 里添加我们的板子:

刚刚平台目录下我们已经对 MACH_GITCHAT 进行了定义,这里就会把设备树编译成 dtb 文件。我们也可以通过命令手动来编译生成 csdn-gitchat-evb.dtb 文件:

$ dtc -I dts -O dtb csdn-gitchat-evb.dts -o csdn-gitchat-evb.dtb

至此,一个自己定制的开发板就已经搞定,这里虚拟了一个开发板,如果定制一个真实的电路板的话需要根据芯片手册把设备树里的信息完善起来。但是通过这个系列学习完全可以理解从零是如何定制一个开发板的。

end



一口Linux 


关注,回复【1024】海量Linux资料赠送

精彩文章合集

文章推荐

【专辑】ARM
【专辑】粉丝问答
【专辑】所有原创
专辑linux入门
专辑计算机网络
专辑Linux驱动
【干货】嵌入式驱动工程师学习路线
【干货】Linux嵌入式所有知识点-思维导图


点击“阅读原文”查看更多分享,欢迎点分享、收藏、点赞、在看


一口Linux 写点代码,写点人生!
评论
  • 随着消费者对汽车驾乘体验的要求不断攀升,汽车照明系统作为确保道路安全、提升驾驶体验以及实现车辆与环境交互的重要组成,日益受到业界的高度重视。近日,2024 DVN(上海)国际汽车照明研讨会圆满落幕。作为照明与传感创新的全球领导者,艾迈斯欧司朗受邀参与主题演讲,并现场展示了其多项前沿技术。本届研讨会汇聚来自全球各地400余名汽车、照明、光源及Tier 2供应商的专业人士及专家共聚一堂。在研讨会第一环节中,艾迈斯欧司朗系统解决方案工程副总裁 Joachim Reill以深厚的专业素养,主持该环节多位
    艾迈斯欧司朗 2025-01-16 20:51 84浏览
  • 全球领先的光学解决方案供应商艾迈斯欧司朗(SIX:AMS)近日宣布,与汽车技术领先者法雷奥合作,采用创新的开放系统协议(OSP)技术,旨在改变汽车内饰照明方式,革新汽车行业座舱照明理念。结合艾迈斯欧司朗开创性的OSIRE® E3731i智能LED和法雷奥的动态环境照明系统,两家公司将为车辆内饰设计和功能设立一套全新标准。汽车内饰照明的作用日益凸显,座舱设计的主流趋势应满足终端用户的需求:即易于使用、个性化,并能提供符合用户生活方式的清晰信息。因此,动态环境照明带来了众多新机遇。智能LED的应用已
    艾迈斯欧司朗 2025-01-15 19:00 71浏览
  • 80,000人到访的国际大展上,艾迈斯欧司朗有哪些亮点?感未来,光无限。近日,在慕尼黑electronica 2024现场,ams OSRAM通过多款创新DEMO展示,以及数场前瞻洞察分享,全面展示自身融合传感器、发射器及集成电路技术,精准捕捉并呈现环境信息的卓越能力。同时,ams OSRAM通过展会期间与客户、用户等行业人士,以及媒体朋友的深度交流,向业界传达其以光电技术为笔、以创新为墨,书写智能未来的深度思考。electronica 2024electronica 2024构建了一个高度国际
    艾迈斯欧司朗 2025-01-16 20:45 91浏览
  • 随着智慧科技的快速发展,智能显示器的生态圈应用变得越来越丰富多元,智能显示器不仅仅是传统的显示设备,透过结合人工智能(AI)和语音助理,它还可以成为家庭、办公室和商业环境中的核心互动接口。提供多元且个性化的服务,如智能家居控制、影音串流拨放、实时信息显示等,极大提升了使用体验。此外,智能家居系统的整合能力也不容小觑,透过智能装置之间的无缝连接,形成了强大的多元应用生态圈。企业也利用智能显示器进行会议展示和多方远程合作,大大提高效率和互动性。Smart Display Ecosystem示意图,作
    百佳泰测试实验室 2025-01-16 15:37 138浏览
  • 晶台光耦KL817和KL3053在小家电产品(如微波炉等)辅助电源中的广泛应用。具备小功率、高性能、高度集成以及低待机功耗的特点,同时支持宽输入电压范围。▲光耦在实物应用中的产品图其一次侧集成了交流电压过零检测与信号输出功能,该功能产生的过零信号可用于精确控制继电器、可控硅等器件的过零开关动作,从而有效减小开关应力,显著提升器件的使用寿命。通过高度的集成化和先进的控制技术,该电源大幅减少了所需的外围器件数量,不仅降低了系统成本和体积,还进一步增强了整体的可靠性。▲电路示意图该电路的过零检测信号由
    晶台光耦 2025-01-16 10:12 84浏览
  • 实用性高值得收藏!! (时源芯微)时源专注于EMC整改与服务,配备完整器件 TVS全称Transient Voltage Suppre,亦称TVS管、瞬态抑制二极管等,有单向和双向之分。单向TVS 一般应用于直流供电电路,双向TVS 应用于电压交变的电路。在直流电路的应用中,TVS被并联接入电路中。在电路处于正常运行状态时,TVS会保持截止状态,从而不对电路的正常工作产生任何影响。然而,一旦电路中出现异常的过电压,并且这个电压达到TVS的击穿阈值时,TVS的状态就会
    时源芯微 2025-01-16 14:23 128浏览
  • 日前,商务部等部门办公厅印发《手机、平板、智能手表(手环)购新补贴实施方案》明确,个人消费者购买手机、平板、智能手表(手环)3类数码产品(单件销售价格不超过6000元),可享受购新补贴。每人每类可补贴1件,每件补贴比例为减去生产、流通环节及移动运营商所有优惠后最终销售价格的15%,每件最高不超过500元。目前,京东已经做好了承接手机、平板等数码产品国补优惠的落地准备工作,未来随着各省市关于手机、平板等品类的国补开启,京东将第一时间率先上线,满足消费者的换新升级需求。为保障国补的真实有效发放,基于
    华尔街科技眼 2025-01-17 10:44 87浏览
  • 一个易用且轻量化的UI可以大大提高用户的使用效率和满意度——通过快速启动、直观操作和及时反馈,帮助用户快速上手并高效完成任务;轻量化设计则可以减少资源占用,提升启动和运行速度,增强产品竞争力。LVGL(Light and Versatile Graphics Library)是一个免费开源的图形库,专为嵌入式系统设计。它以轻量级、高效和易于使用而著称,支持多种屏幕分辨率和硬件配置,并提供了丰富的GUI组件,能够帮助开发者轻松构建出美观且功能强大的用户界面。近期,飞凌嵌入式为基于NXP i.MX9
    飞凌嵌入式 2025-01-16 13:15 137浏览
  • 近期,智能家居领域Matter标准的制定者,全球最具影响力的科技联盟之一,连接标准联盟(Connectivity Standards Alliance,简称CSA)“利好”频出,不仅为智能家居领域的设备制造商们提供了更为快速便捷的Matter认证流程,而且苹果、三星与谷歌等智能家居平台厂商都表示会接纳CSA的Matter认证体系,并计划将其整合至各自的“Works with”项目中。那么,在本轮“利好”背景下,智能家居的设备制造商们该如何捉住机会,“掘金”万亿市场呢?重认证快通道计划,为家居设备
    华普微HOPERF 2025-01-16 10:22 145浏览
  • 百佳泰特为您整理2025年1月各大Logo的最新规格信息,本月有更新信息的logo有HDMI、Wi-Fi、Bluetooth、DisplayHDR、ClearMR、Intel EVO。HDMI®▶ 2025年1月6日,HDMI Forum, Inc. 宣布即将发布HDMI规范2.2版本。新规范将支持更高的分辨率和刷新率,并提供更多高质量选项。更快的96Gbps 带宽可满足数据密集型沉浸式和虚拟应用对传输的要求,如 AR/VR/MR、空间现实和光场显示,以及各种商业应用,如大型数字标牌、医疗成像和
    百佳泰测试实验室 2025-01-16 15:41 134浏览
  • 电竞鼠标应用环境与客户需求电竞行业近年来发展迅速,「鼠标延迟」已成为决定游戏体验与比赛结果的关键因素。从技术角度来看,传统鼠标的延迟大约为20毫秒,入门级电竞鼠标通常为5毫秒,而高阶电竞鼠标的延迟可降低至仅2毫秒。这些差异看似微小,但在竞技激烈的游戏中,尤其在对反应和速度要求极高的场景中,每一毫秒的优化都可能带来致胜的优势。电竞比赛的普及促使玩家更加渴望降低鼠标延迟以提升竞技表现。他们希望通过精确的测试,了解不同操作系统与设定对延迟的具体影响,并寻求最佳配置方案来获得竞技优势。这样的需求推动市场
    百佳泰测试实验室 2025-01-16 15:45 185浏览
我要评论
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦