eBPF动手实践系列一:解构内核源码eBPF样例编译过程

Linux阅码场 2023-04-17 11:52

1

他山之石

了解和掌握纯c语言的ebpf编译和使用,有助于我们加深对于eBPF技术原理的进一步掌握,也有助于开发符合自己业务需求的高性能的ebpf程序。
目前常见和主流的纯c语言的ebpf编译使用方法,主要是两种。一种是内核源码中原生提供的编译方式。另外一种是libbpf-bootstrap项目中提供的skeleton编译方式。libbpf-bootstrap方式和社区5.x以上内核结合的比较好,以后再做介绍,今天我们选择基于4.18内核的基于内核源码的原生编译方式做介绍。

在国内学习ebpf技术,就不得不提到《Linux内核观测技术BPF》书籍译者狄卫华老师。狄老师还有一个网站《深入浅出 eBPF》。在网站里,他专门用一篇文章介绍了基于内核源码方式编译ebpf的方式,文章内容叫《【BPF入门系列-3】BPF 环境搭建》,网址:

 https://www.ebpf.top/post/ebpf_c_env/

我们今天将参考这篇文章内容,对基于内核源码方式的纯c语言的ebpf编译方式做进一步分析。

2

获取内核源码

目前主流的服务器的操作系统环境还是以8u + 4.18内核为主。因此,本文以4.18版本内核为主要分析对象。我们提供如下操作系统环境的获取建议:

2.1  获取操作系统环境

如果你自己有centos8u兼容环境操作系统,则可以使用已有的环境。如果没有,可以通过阿里云官网购买阿里云主机,选择选择centos8或者anolis8操作系统环境。
$  cat /etc/centos-releaseCentOS Linux release 8.5.2111$  uname -r4.18.0-348.7.1.el8_5.x86_64

2.2  获取开源的内核源码

可以使用wget,从aliyun官网镜像,获取开源的4.18内核源码。
$  cd /tmp/$  wget https://mirrors.aliyun.com/linux-kernel/v4.x/linux-4.18.tar.gz$  tar -zxvf linux-4.18.tar.gz$  cd linux-4.18
下载内核源码一定要确保内核版本与操作系统的一致。原因是ebpf会用到VERSION、PATCHLEVEL和SUBLEVEL这3个宏的值与内核做内核版本校验。如果版本传的不对,ebpf校验会失败。
$  cat Makefile  | grep -P '^VERSION|^PATCHLEVEL|^SUBLEVEL'   VERSION = 4PATCHLEVEL = 18SUBLEVEL = 0

3

初始化基础环境

需要安装ebpf编译时依赖的llvm和clang等rpm包。此外内核编译还需要依赖openssl-devel等rpm包。
$  sudo yum install bison flex openssl-devel$  sudo yum install clang llvm elfutils-libelf-devel

具体每个实验机器的环境可能略有差别,需要根据自己的情况做细节调整。

4

编译内核源码中ebpf程序样例

4.1  编译环境初始化

狄老师的文章中这里执行的是make scripts,在内核源码编译时此步骤前通常还需要执行make prepare。而make init正好包含这两步make prepare && make scripts。因此,我们将命令按照如下方式优化,基本能够一遍跑过:
$  cd /tmp/linux-4.18$  make oldconfig && make init  # make oldconfig && make prepare && make scripts$  make headers_install

4.2  编译内核源码样例

终于执行到了内核源码中提供的ebpf程序样例的编译。
$  make M=samples/bpf

4.3  执行样例程序

我们可以通过对样例程序的执行,对编译效果进行验证。结果显示执行成功,狄老师文章中的步骤验证通过,有点小激动。
$  sudo ./samples/bpf/trace_outputrecv 1766352 events per sec

5

内核源码的ebpf编译关键过程提取

接下去就是本文最重点的部分,对ebpf编译过程的分析。我们主要分分析headers_install和对samples/bpf目录的make这2个步骤。

5.1  头文件安装 make headers_install

重新获取一个干净的内核源码,再次执行上面的编译步骤。这次我们对编译过程增加一些观察步骤。
$  cd  /tmp/$  rm -fr /tmp/linux-4.18$  tar -zxvf linux-4.18.tar.gz $  cd /tmp/linux-4.18$  make oldconfig && make init$  ls usr/include/ls: cannot access usr/include/: No such file or directory      # 此时include目录不存在$  make headers_install$  ls usr/include/ -R  | grep -v -P ':$' | grep -v -P '^$' | wc -l931                                                      #  此时include目录下有931个文件$  diff -rs usr/include/ /usr/include/|grep -P '^Files .+ and .+ are identical$'|wc -l677
这说明内核源码目录下,headers_install步骤生成的usr/include/目录下功能900多个文件,其中大多数(677个)文件都能在操作系统环境的/usr/include/下找到完全一摸一样的同名文件,并且内容也完全相同。
$  rpm -ql kernel-headers | wc -l964  $  rpm -ql kernel-headers | head /usr/include/asm/usr/include/asm-generic/usr/include/asm-generic/bpf_perf_event.h
而操作系统环境的/usr/include/目录正好是kernel-headers包的安装目录。所以编译过程中headers_install步骤就是在内核源码目录生成了kernel-headers包作用一样的内容。

5.2  eBPF样例编译 make M=samples/bpf

ebpf样例的编译过程,我们做一下改进,通过SHELL选项打开shell的调试选项。具体命令如下:
$  make M=samples/bpf --debug=v,m SHELL="bash -x" > make.log 2>&1
通过分析make.log,再结合其他一些黑科技,可以大概找出内核源码样例中trace_output命令的编译脉络。其中用户态编译脉络如下。为了表述上更加突出主题,此处只显示编译命令的关键信息,下一节会给出完整编译命令。
$  gcc -g -fPIC -c -o libbpf.o libbpf.c$  gcc -g -fPIC -c -o bpf.o bpf.c$  gcc -g -fPIC -c -o btf.o btf.c$  gcc -g -fPIC -c -o nlattr.o nlattr.c$  ld -r -o libbpf-in.o libbpf.o bpf.o nlattr.o btf.o$  ar rcs libbpf.a libbpf-in.o$  gcc -O2 -std=gnu89 -c -o bpf_load.o bpf_load.c$  gcc -O2 -std=gnu89 -c -o trace_output_user.o trace_output_user.c$  gcc -O2 -std=gnu89 -c -o trace_helpers.o trace_helpers.c$  gcc -o trace_output bpf_load.o trace_output_user.o trace_helpers.o libbpf.a -lelf -lrt
其中内核态编译脉络如下:
$  clang -O2 -emit-llvm -c trace_output_kern.c -o - $  llc -march=bpf -filetype=obj -o trace_output_kern.o
其中前一行最后的横线 - 表示 这里是输出给shell管道,所以这两行实际是可以通过shell管道拼接成一个命令来执行的。

6

手工编译内核源码中的eBPF样例分析

通过上一节对关键步骤make M=samples/bpf的实践,我们已经可以编译出内核源码中提供的ebpf样例。但这还不够我们充分地理解这个编译过程,我们将这编译过程继续拆解一下,拆解成可以一步步执行的那种,为了方便大家理解,我将这个过程分解为 A-H 6大手工步骤,里面还会包含一些细分的小步骤:
$  cd  /tmp/$  rm -fr /tmp/linux-4.18$  tar -zxvf linux-4.18.tar.gz $  cd /tmp/linux-4.18$  make oldconfig && make init$  make headers_install$  cd tools/lib/bpf/

6.1  手工步骤A过程解析

手工步骤A1:
$  # gcc -g -fPIC -c -o libbpf.o libbpf.c$  gcc -g -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -fPIC -I. -I/tmp/linux-4.18/tools/include -I/tmp/linux-4.18/tools/arch/x86/include/uapi -I/tmp/linux-4.18/tools/include/uapi -I/tmp/linux-4.18/tools/perf -D"BUILD_STR(s)=#s" -c -o libbpf.o libbpf.c
手工步骤A2:
$ # gcc -g -fPIC -c -o bpf.o bpf.c$  gcc -g -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -fPIC -I. -I/tmp/linux-4.18/tools/include -I/tmp/linux-4.18/tools/arch/x86/include/uapi -I/tmp/linux-4.18/tools/include/uapi -I/tmp/linux-4.18/tools/perf -D"BUILD_STR(s)=#s" -c -o bpf.o bpf.c
手工步骤A3:
$ # gcc -g -fPIC -c -o btf.o btf.c$  gcc -g -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -fPIC -I. -I/tmp/linux-4.18/tools/include -I/tmp/linux-4.18/tools/arch/x86/include/uapi -I/tmp/linux-4.18/tools/include/uapi -I/tmp/linux-4.18/tools/perf -D"BUILD_STR(s)=#s" -c -o btf.o btf.c
手工步骤A4:
$ # gcc -g -fPIC -c -o nlattr.o nlattr.c$  gcc -g -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -fPIC -I. -I/tmp/linux-4.18/tools/include -I/tmp/linux-4.18/tools/arch/x86/include/uapi -I/tmp/linux-4.18/tools/include/uapi -I/tmp/linux-4.18/tools/perf -D"BUILD_STR(s)=#s" -c -o nlattr.o nlattr.c
针对手工步骤A1到A4的关键编译选项做一些介绍。

● -fPIC,告诉编译器输出位置无关目标,为后面生成共享库埋下伏笔。

● -I. 表示需要包含当前目录下的头文件。

● -I/tmp/linux-4.18/tools/include -I/tmp/linux-4.18/tools/arch/x86/include/uapi -I/tmp/linux-4.18/tools/include/uapi -I/tmp/linux-4.18/tools/perf,这4个头文件,是用户态ebpf程序所依赖tool目录下的头文件位置。

6.2  手工步骤B过程解析

$  ld -r -o libbpf-in.o  libbpf.o bpf.o nlattr.o btf.o
手工步骤B是将步骤A中产生4个.o文件进行链接。

6.3  手工步骤C过程解析

$  ar rcs libbpf.a libbpf-in.o
手工步骤C是从链接后的文件中提取静态库文件。

6.4  手工步骤D/E/F过程解析

手工步骤D:
$  # gcc -O2 -std=gnu89 -c -o bpf_load.o bpf_load.c$  gcc -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ -I./tools/lib/ -I./tools/include -I./tools/perf -I./usr/include -Wno-unused-variable -c -o samples/bpf/bpf_load.o samples/bpf/bpf_load.c
手工步骤E:
$  # gcc -O2 -std=gnu89 -c -o trace_output_user.o trace_output_user.c$  gcc -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ -I./tools/lib/ -I./tools/include -I./tools/perf -I./tools/lib/bpf/ -c -o samples/bpf/trace_output_user.o samples/bpf/trace_output_user.c
手工步骤F:
$  # gcc -O2 -std=gnu89 -c -o trace_helpers.o trace_helpers.c$  gcc -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ -I./tools/lib/ -I./tools/include -I./tools/perf -I./tools/lib/bpf/ -c -o samples/bpf/../../tools/testing/selftests/bpf/trace_helpers.o samples/bpf/../../tools/testing/selftests/bpf/trace_helpers.c
针对手工步骤E的关键编译选项做一些介绍。手工步骤D和手工步骤F与此类似。

● -O2 和 -std=gnu89 是两个核心选项。

● include选项,一共有6个,我们将其分为3组。第一组是-I./usr/include ,这表示包含等同于kernel-headers的内容。
● 第二组是-I./tools/lib/, -I./tools/include,-I./tools/perf,-I./tools/lib/bpf/
● 第三组是-I./tools/testing/selftests/bpf/。之所以把这一组单独独立出来,是因为它和样例代码处于同样的路径。

6.5  手工步骤G过程解析

$  # gcc -o trace_output bpf_load.o trace_output_user.o trace_helpers.o libbpf.a -lelf -lrt$  gcc -o samples/bpf/trace_output samples/bpf/bpf_load.o samples/bpf/trace_output_user.o samples/bpf/../../tools/testing/selftests/bpf/trace_helpers.o /tmp/linux-4.18/samples/bpf/../../tools/lib/bpf/libbpf.a -lelf -lrt
针对手工步骤G的关键编译选项做一些介绍。

● -lelf -lrt链接两个类库

● libbpf.a表示以静态链接库的方式链接libbpf的类库。
● 最关键的是,没有添加-static选项,没有添加-static选项,没有添加-static选项,重要的事情说三遍。

6.6  手工步骤H过程解析

$  clang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/8/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -Isamples/bpf -I./tools/testing/selftests/bpf/ -D__KERNEL__ -D__BPF_TRACING__ -D__TARGET_ARCH_x86 -O2 -emit-llvm -c samples/bpf/trace_output_kern.c -o - | llc -march=bpf -filetype=obj -o samples/bpf/trace_output_kern.o
针对手工步骤H的关键编译选项做一些介绍。

● -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/8/include,这2个选项是一组。nostdinc表示屏蔽掉系统默认的include环境,替换成当前gcc编译器自带的include头文件环境。

●-I./arch/x86/include,-I./arch/x86/include/generated,-I./include,-I./arch/x86/include/uapi,-I./arch/x86/include/generated/uapi,-I./include/uapi,-I./include/generated/uapi。这7个头文件很关键,是内核态ebpf程序所依赖的绝大多数头文件的位置。
● -include ./include/linux/kconfig.h,这个头文件也很关键,是让上面7个头文件生效的前提条件。
● -I samples/bpf 和 -I ./tools/testing/selftests/bpf/,这2个头文件是和ebpf样例所处位置相同,单独独立出来看。
● llc是llvm的连接器。内核是将clang的编译和llc的链接独立成两步完成,在llc步骤才指定-march=bpf。
对编译结果进行验证,完美验证通过,第二次有点小激动。
$  sudo ./samples/bpf/trace_outputrecv 1760674 events per sec
关键步骤抽取不是最终目的,根本目的是能让我们实现脱离内核源码进行独立的纯C语言编译。我们将在后续的文章中进一步阐述。

7

关于4.9版本内核

按照内核的原生步骤,对4.9内核进行一次编译,我们会发现对应手工步骤E的这一步,编译代码有点不一样,具体代码如下。
$  gcc -o samples/bpf/trace_output samples/bpf/bpf_load.o samples/bpf/libbpf.o samples/bpf/trace_output_user.o -lelf -lrt
其中没有了对libbpf.a静态库的链接,但却多了一个libbpf.o文件的链接。
$  cd /tmp/linux-4.9/$  find . -name libbpf.c./samples/bpf/libbpf.c./tools/lib/bpf/libbpf.c
查询内核源码,可以发现,在4.9内核下,有2个libbpf.c文件,分别处于./tools/lib/bpf/目录和./samples/bpf/目录。而内核ebpf样例暂时使用的还是老的./samples/bpf/libbpf.c文件。

8

进一步探索

本文为eBPF动手实践系列的第一篇,我们实现了基于内核源码框架的一步一步的纯C语言编译,下一篇我们会对这个编译过程继续深入探索,实现脱离内核源码后的纯C语言编译。
欢迎有想法或者有问题的同学,加群交流eBPF技术以及工程实践。
SREWorks数智运维工程群(钉钉群号:35853026)

附录: eBPF手工纯C编译完整命令清单

cd  /tmp/rm -fr /tmp/linux-4.18tar -zxvf linux-4.18.tar.gz cd /tmp/linux-4.18make oldconfig && make initmake headers_installcd tools/lib/bpf/
# 步骤A1# gcc -g -fPIC -c -o libbpf.o libbpf.cgcc -g -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -fPIC -I. -I/tmp/linux-4.18/tools/include -I/tmp/linux-4.18/tools/arch/x86/include/uapi -I/tmp/linux-4.18/tools/include/uapi -I/tmp/linux-4.18/tools/perf -D"BUILD_STR(s)=#s" -c -o libbpf.o libbpf.c
# 步骤A2# gcc -g -fPIC -c -o bpf.o bpf.cgcc -g -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -fPIC -I. -I/tmp/linux-4.18/tools/include -I/tmp/linux-4.18/tools/arch/x86/include/uapi -I/tmp/linux-4.18/tools/include/uapi -I/tmp/linux-4.18/tools/perf -D"BUILD_STR(s)=#s" -c -o bpf.o bpf.c
# 步骤A3# gcc -g -fPIC -c -o btf.o btf.cgcc -g -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -fPIC -I. -I/tmp/linux-4.18/tools/include -I/tmp/linux-4.18/tools/arch/x86/include/uapi -I/tmp/linux-4.18/tools/include/uapi -I/tmp/linux-4.18/tools/perf -D"BUILD_STR(s)=#s" -c -o btf.o btf.c
# 步骤A4# gcc -g -fPIC -c -o nlattr.o nlattr.cgcc -g -DHAVE_LIBELF_MMAP_SUPPORT -DCOMPAT_NEED_REALLOCARRAY -fPIC -I. -I/tmp/linux-4.18/tools/include -I/tmp/linux-4.18/tools/arch/x86/include/uapi -I/tmp/linux-4.18/tools/include/uapi -I/tmp/linux-4.18/tools/perf -D"BUILD_STR(s)=#s" -c -o nlattr.o nlattr.c
# 步骤Bld -r -o libbpf-in.o libbpf.o bpf.o nlattr.o btf.o
# 步骤Car rcs libbpf.a libbpf-in.o
cd /tmp/linux-4.18/
# 步骤D# gcc -O2 -std=gnu89 -c -o bpf_load.o bpf_load.cgcc -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ -I./tools/lib/ -I./tools/include -I./tools/perf -I./usr/include -Wno-unused-variable -c -o samples/bpf/bpf_load.o samples/bpf/bpf_load.c
# 步骤E# gcc -O2 -std=gnu89 -c -o trace_output_user.o trace_output_user.cgcc -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ -I./tools/lib/ -I./tools/include -I./tools/perf -I./tools/lib/bpf/ -c -o samples/bpf/trace_output_user.o samples/bpf/trace_output_user.c
# 步骤F# gcc -O2 -std=gnu89 -c -o trace_helpers.o trace_helpers.cgcc -O2 -fomit-frame-pointer -std=gnu89 -I./usr/include -I./tools/lib/ -I./tools/testing/selftests/bpf/ -I./tools/lib/ -I./tools/include -I./tools/perf -I./tools/lib/bpf/ -c -o samples/bpf/../../tools/testing/selftests/bpf/trace_helpers.o samples/bpf/../../tools/testing/selftests/bpf/trace_helpers.c
# 步骤G# gcc -o trace_output bpf_load.o trace_output_user.o trace_helpers.o libbpf.a -lelf -lrtgcc -o samples/bpf/trace_output samples/bpf/bpf_load.o samples/bpf/trace_output_user.o samples/bpf/../../tools/testing/selftests/bpf/trace_helpers.o /tmp/linux-4.18/samples/bpf/../../tools/lib/bpf/libbpf.a -lelf -lrt
# 步骤Hclang -nostdinc -isystem /usr/lib/gcc/x86_64-redhat-linux/8/include -I./arch/x86/include -I./arch/x86/include/generated -I./include -I./arch/x86/include/uapi -I./arch/x86/include/generated/uapi -I./include/uapi -I./include/generated/uapi -include ./include/linux/kconfig.h -Isamples/bpf -I./tools/testing/selftests/bpf/ -D__KERNEL__ -D__BPF_TRACING__ -D__TARGET_ARCH_x86 -O2 -emit-llvm -c samples/bpf/trace_output_kern.c -o - | llc -march=bpf -filetype=obj -o samples/bpf/trace_output_kern.o
/ END /

阅码场服务微信号:小月@阅码场(linuxer2016)


如有疑问和相关需求,点击阅读原文,联系我们。

Linux阅码场 专业的Linux技术社区和Linux操作系统学习平台,内容涉及Linux内核,Linux内存管理,Linux进程管理,Linux文件系统和IO,Linux性能调优,Linux设备驱动以及Linux虚拟化和云计算等各方各面.
评论
  • 习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习笔记&记录学习习笔记&记学习学习笔记&记录学习学习笔记&记录学习习笔记&记录学习学习笔记&记录学习学习笔记记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习习笔记&记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&学习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&记录学习学习笔记&记
    youyeye 2024-12-10 16:13 105浏览
  • 概述 通过前面的研究学习,已经可以在CycloneVGX器件中成功实现完整的TDC(或者说完整的TDL,即延时线),测试结果也比较满足,解决了超大BIN尺寸以及大量0尺寸BIN的问题,但是还是存在一些之前系列器件还未遇到的问题,这些问题将在本文中进行详细描述介绍。 在五代Cyclone器件内部系统时钟受限的情况下,意味着大量逻辑资源将被浪费在于实现较大长度的TDL上面。是否可以找到方法可以对此前TDL的长度进行优化呢?本文还将探讨这个问题。TDC前段BIN颗粒堵塞问题分析 将延时链在逻辑中实现后
    coyoo 2024-12-10 13:28 101浏览
  • 时源芯微——RE超标整机定位与解决详细流程一、 初步测量与问题确认使用专业的电磁辐射测量设备,对整机的辐射发射进行精确测量。确认是否存在RE超标问题,并记录超标频段和幅度。二、电缆检查与处理若存在信号电缆:步骤一:拔掉所有信号电缆,仅保留电源线,再次测量整机的辐射发射。若测量合格:判定问题出在信号电缆上,可能是电缆的共模电流导致。逐一连接信号电缆,每次连接后测量,定位具体哪根电缆或接口导致超标。对问题电缆进行处理,如加共模扼流圈、滤波器,或优化电缆布局和屏蔽。重新连接所有电缆,再次测量
    时源芯微 2024-12-11 17:11 70浏览
  • 近日,搭载紫光展锐W517芯片平台的INMO GO2由影目科技正式推出。作为全球首款专为商务场景设计的智能翻译眼镜,INMO GO2 以“快、准、稳”三大核心优势,突破传统翻译产品局限,为全球商务人士带来高效、自然、稳定的跨语言交流体验。 INMO GO2内置的W517芯片,是紫光展锐4G旗舰级智能穿戴平台,采用四核处理器,具有高性能、低功耗的优势,内置超微高集成技术,采用先进工艺,计算能力相比同档位竞品提升4倍,强大的性能提供更加多样化的应用场景。【视频见P盘链接】 依托“
    紫光展锐 2024-12-11 11:50 44浏览
  •         在有电流流过的导线周围会感生出磁场,再用霍尔器件检测由电流感生的磁场,即可测出产生这个磁场的电流的量值。由此就可以构成霍尔电流、电压传感器。因为霍尔器件的输出电压与加在它上面的磁感应强度以及流过其中的工作电流的乘积成比例,是一个具有乘法器功能的器件,并且可与各种逻辑电路直接接口,还可以直接驱动各种性质的负载。因为霍尔器件的应用原理简单,信号处理方便,器件本身又具有一系列的du特优点,所以在变频器中也发挥了非常重要的作用。  &nb
    锦正茂科技 2024-12-10 12:57 76浏览
  • 全球知名半导体制造商ROHM Co., Ltd.(以下简称“罗姆”)宣布与Taiwan Semiconductor Manufacturing Company Limited(以下简称“台积公司”)就车载氮化镓功率器件的开发和量产事宜建立战略合作伙伴关系。通过该合作关系,双方将致力于将罗姆的氮化镓器件开发技术与台积公司业界先进的GaN-on-Silicon工艺技术优势结合起来,满足市场对高耐压和高频特性优异的功率元器件日益增长的需求。氮化镓功率器件目前主要被用于AC适配器和服务器电源等消费电子和
    电子资讯报 2024-12-10 17:09 84浏览
  • RK3506 是瑞芯微推出的MPU产品,芯片制程为22nm,定位于轻量级、低成本解决方案。该MPU具有低功耗、外设接口丰富、实时性高的特点,适合用多种工商业场景。本文将基于RK3506的设计特点,为大家分析其应用场景。RK3506核心板主要分为三个型号,各型号间的区别如下图:​图 1  RK3506核心板处理器型号场景1:显示HMIRK3506核心板显示接口支持RGB、MIPI、QSPI输出,且支持2D图形加速,轻松运行QT、LVGL等GUI,最快3S内开
    万象奥科 2024-12-11 15:42 66浏览
  • 肖特基具有很多的应用场景, 可以做同步整流,防止电流倒灌和电源反接等,但是随着电源电流的增大,肖特基导通正向压降0.3~0.7v的劣势也越发明显,产生了很多的热,对于工程师的散热设计是个考验,增加了工程师的设计难度和产品成本,目前一种新的理想二极管及其控制器,目前正在得到越来越广泛的应用- BMS,无人机,PLC,安防,家电,电动工具,汽车等都在快速普及理想二极管有三种架构,内置电荷泵的类似无锡明芯微MX5050T这种,驱动能力会弱点,静态功耗200uA,外置电荷泵MX74700T的这种驱动能力
    王萌 2024-12-10 08:51 85浏览
  • 智能汽车可替换LED前照灯控制运行的原理涉及多个方面,包括自适应前照灯系统(AFS)的工作原理、传感器的应用、步进电机的控制以及模糊控制策略等。当下时代的智能汽车灯光控制系统通过车载网关控制单元集中控制,表现特殊点的有特斯拉,仅通过前车身控制器,整个系统就包括了灯光旋转开关、车灯变光开关、左LED前照灯总成、右LED前照灯总成、转向柱电子控制单元、CAN数据总线接口、组合仪表控制单元、车载网关控制单元等器件。变光开关、转向开关和辅助操作系统一般连为一体,开关之间通过内部线束和转向柱装置连接为多,
    lauguo2013 2024-12-10 15:53 78浏览
  •         霍尔传感器是根据霍尔效应制作的一种磁场传感器。霍尔效应是磁电效应的一种,这一现象是霍尔(A.H.Hall,1855—1938)于1879年在研究金属的导电机构时发现的。后来发现半导体、导电流体等也有这种效应,而半导体的霍尔效应比金属强得多,利用这现象制成的各种霍尔元件,广泛地应用于工业自动化技术、检测技术及信息处理等方面。霍尔效应是研究半导体材料性能的基本方法。通过霍尔效应实验测定的霍尔系数,能够判断半导体材料的导电类型、载流子浓度及载流子
    锦正茂科技 2024-12-10 11:07 64浏览
  • 一、SAE J1939协议概述SAE J1939协议是由美国汽车工程师协会(SAE,Society of Automotive Engineers)定义的一种用于重型车辆和工业设备中的通信协议,主要应用于车辆和设备之间的实时数据交换。J1939基于CAN(Controller Area Network)总线技术,使用29bit的扩展标识符和扩展数据帧,CAN通信速率为250Kbps,用于车载电子控制单元(ECU)之间的通信和控制。小北同学在之前也对J1939协议做过扫盲科普【科普系列】SAE J
    北汇信息 2024-12-11 15:45 73浏览
  • 天问Block和Mixly是两个不同的编程工具,分别在单片机开发和教育编程领域有各自的应用。以下是对它们的详细比较: 基本定义 天问Block:天问Block是一个基于区块链技术的数字身份验证和数据交换平台。它的目标是为用户提供一个安全、去中心化、可信任的数字身份验证和数据交换解决方案。 Mixly:Mixly是一款由北京师范大学教育学部创客教育实验室开发的图形化编程软件,旨在为初学者提供一个易于学习和使用的Arduino编程环境。 主要功能 天问Block:支持STC全系列8位单片机,32位
    丙丁先生 2024-12-11 13:15 45浏览
  • 【萤火工场CEM5826-M11测评】OLED显示雷达数据本文结合之前关于串口打印雷达监测数据的研究,进一步扩展至 OLED 屏幕显示。该项目整体分为两部分: 一、框架显示; 二、数据采集与填充显示。为了减小 MCU 负担,采用 局部刷新 的方案。1. 显示框架所需库函数 Wire.h 、Adafruit_GFX.h 、Adafruit_SSD1306.h . 代码#include #include #include #include "logo_128x64.h"#include "logo_
    无垠的广袤 2024-12-10 14:03 69浏览
  • 我的一台很多年前人家不要了的九十年代SONY台式组合音响,接手时只有CD功能不行了,因为不需要,也就没修,只使用收音机、磁带机和外接信号功能就够了。最近五年在外地,就断电闲置,没使用了。今年9月回到家里,就一个劲儿地忙着收拾家当,忙了一个多月,太多事啦!修了电气,清理了闲置不用了的电器和电子,就是一个劲儿地扔扔扔!几十年的“工匠式”收留收藏,只能断舍离,拆解不过来的了。一天,忽然感觉室内有股臭味,用鼻子的嗅觉功能朝着臭味重的方向寻找,觉得应该就是这台组合音响?怎么会呢?这无机物的东西不会腐臭吧?
    自做自受 2024-12-10 16:34 136浏览
  • 本文介绍Linux系统(Ubuntu/Debian通用)挂载exfat格式U盘的方法,触觉智能RK3562开发板演示,搭载4核A53处理器,主频高达2.0GHz;内置独立1Tops算力NPU,可应用于物联网网关、平板电脑、智能家居、教育电子、工业显示与控制等行业。修改对应的内核配置文件# 进入sdk目录cdrk3562_linux# 编辑内核配置文件vi./kernel-5.10/arch/arm64/configs/rockchip_linux_defconfig注:不清楚内核使用哪个defc
    Industio_触觉智能 2024-12-10 09:44 90浏览
我要评论
0
点击右上角,分享到朋友圈 我知道啦
请使用浏览器分享功能 我知道啦