从hello.c到进程回收：C程序编译链接装载全链路拆解-北京尧图网络

简介面向计算机系统课程学习者与备考 CSAPP深入理解计算机系统大作业的学生这份哈工大课程报告以经典 hello 程序为主线串联程序从源码到运行的完整生命周期可帮助你理清课程大作业的写作框架与知识脉络适合正在完成同类报告或复习底层机制的人群参考。压缩包共 1 个 doc 文件约 6.44MB正文按章节组织涵盖计算机系统概述、预处理、编译、汇编、链接以及进程管理、信号与异常、内存管理、I/O 管理等模块并配有 Ubuntu 下的命令示例与中间结果解析如 hello.i 展开行数、头文件与宏替换过程等便于对照实验环境复现验证。该资源已有 358 人学习可作为课程报告的参考范文与知识点索引帮助读者理解各阶段工具链的作用及相互衔接提升对程序加载、执行与系统资源管理的整体认识。1. 从一行 C 语句到进程被回收这份 Hello 生命周期报告能补上哪块底层拼图很多人学完 CSAPP 的链接和异常控制流概念能背真要把hello.c从磁盘上的 ASCII 文本一路追到进程被 shell 回收脑子里还是糊的。这份某高校计算机学院的《程序人生》大作业干的就是这件事它以 hello 的 P2PFrom Program to Process和 020From Zero-0 to Zero-0两条主线把预处理、编译、汇编、链接、进程、存储、IO 七个阶段串成一条能动手复现的链路每一环都配了命令、中间文件和逐行解读。刚学完 CSAPP、想找一份完整观察记录照着跑一遍的人适合看带课的助教也能拿它当验收清单对着目录一条条问学生「这步产物在哪、里面长什么样」。2. 环境基线与中间产物链五份文件把整条复现路径固定下来2.1 虚拟机与工具链的最小组合这份报告的实验环境门槛很低一台四核 x64 的笔记本、8G 内存、256G 磁盘就够Windows 上装个虚拟机跑 64 位 Linux 发行版编译工具链用系统自带的 gcc 和 binutils编辑器 vim、gedit、VS Code 都行。真正需要留意的不是硬件而是工具链版本hello.i展开成多少行、hello.o里重定位条目叫什么名字、main里某个变量落在%rbp偏移多少全都跟 gcc 和 binutils 的版本强相关。原文那份记录里hello.i是 3065 行、自己的代码从 3046 行开始你换一台机器跑出来大概率是两千多行或者四千多行这不是你错了是头文件版本不同。我在动手前会先把版本信息落一份档后面写报告、对差异都用得上# 记录工具链版本后面所有行数对不上重定位类型不一样都要回来查这里 gcc --version | head -1 ld --version | head -1 uname -a # 确认调试与观察工具齐全 which gcc readelf objdump nm ldd strace gdbreadelf和objdump都来自 binutils跟 gcc 是两套东西前者读 ELF 结构后者反汇编两个都要有。strace用来观察系统调用gdb用来在execve前后打点缺一个后面就会卡在「看得见结果但说不清过程」。2.2 中间产物清单与每份文件对应的验证点这份报告最有价值的地方是把「每一步产出什么文件、这个文件用来验证什么」列成了一张表。整理成下面这样更好用因为写报告时你会反复回来查「我这一步该拿什么去证明」产物生成阶段格式主要验证点hello.i预处理ASCII 文本头文件展开、宏替换、条件编译裁剪、注释消失hello.s编译ASCII 汇编数据段布局、寄存器传参、控制转移、PLT 调用hello.o汇编可重定位 ELF节区结构、符号表、.rela.text重定位条目hello.asm反汇编文本未重定位的地址全是 0 占位hello.elfELF 转储文本.symtab、.rela.text、.debug_*全量信息hello链接可执行 ELF入口地址、LOAD段、动态链接依赖hello_elf/hello_asm链接后观察文本重定位后的真实地址、PLT桩代码表里hello.asm和hello_asm是最容易被忽略的一对前者是未链接的反汇编call后面跟的偏移是00 00 00 00后者是链接后的反汇编同样的call后面已经是真实目标。这两份文件放在一起对比重定位这件事就不用再靠想象了。原文里的 hello.c 没有完整贴出来但根据汇编章节的描述可以还原出大致结构带argc ! 3的判断、一段getchar()循环、一次sleep、两次格式化输出。照着写一份功能等价的就能跑通全流程#include stdio.h #include unistd.h #include stdlib.h int sleepsecs 2.5; /* 隐式强转实际存 2编译会有 warning是故意的 */ int main(int argc, char *argv[]) { int i; if (argc ! 3) { printf(Usage: Hello student_id name!\n); exit(1); } for (i 0; i 10; i) /* 循环体里只调 getchar用来观察控制转移 */ getchar(); sleep(sleepsecs); printf(Hello %s %s\n, argv[1], argv[2]); return 0; }int sleepsecs 2.5;这行是报告里刻意保留的2.5被截断成2正好用来讲浮点到整型的隐式转换在汇编里是什么样——你在.data段里看到的是.long 2浮点那部分根本没进目标文件。自己写的时候如果开了-Wall会报一条 warning别急着改这条 warning 本身就是观察素材。2.3 一次性跑通全流程的命令序列把这五步连起来敲一遍整条链路就活了。命令本身很简单关键是每次只做一件事产物分开命名别用gcc hello.c一把梭那样中间过程全被临时文件吃掉了mkdir -p ~/hello-p2p cd ~/hello-p2p # 把上面的 hello.c 放进来 # 1) 预处理只做文本级替换不做任何语法检查 gcc -E hello.c -o hello.i # 2) 编译C 源码 - 汇编文本 gcc -S hello.i -o hello.s # 3) 汇编汇编文本 - 可重定位目标文件二进制 gcc -c hello.s -o hello.o # 4) 链接可重定位目标文件 - 可执行文件 gcc hello.o -o hello # 5) 观察ELF 结构与反汇编全部落成文本方便 diff readelf -a hello.o hello.elf objdump -d hello.o hello.asm readelf -a hello hello_elf objdump -d hello hello_asm参数含义值得逐个说清-E表示「只预处理」-S表示「只编译到汇编」-c表示「编译汇编但不链接」三个开关刚好卡在三个阶段的分界线上-o指定输出文件名不写的话 gcc 会按阶段给默认名a.out或者hello.o容易覆盖。objdump -d只反汇编有代码的节-s是把所有节的内容按十六进制打出来看.rodata里的字符串用-s更方便。第 5 步把结果全导成文本是血泪经验调汇编的时候你会反复在hello.o和hello之间跳落成文件之后直接diff hello.asm hello_asm就能看出链接改了什么。3. 预处理到汇编3065 行的 hello.i 怎么变成 hello.o3.1 预处理头文件搬运、宏替换与条件编译预处理的核心就三件事把#include的头文件原样复制进来、把#define的宏换成实际值、按#if的条件裁剪代码顺便把注释全部吃掉。报告里那组数字很直观——原来几十行的hello.c预处理之后膨胀到 3065 行自己的代码被挤到 3046 行之后前面三千行全是stdio.h、unistd.h、stdlib.h三个头文件带进来的类型声明、函数原型和一堆条件编译分支。# 两种写法等价cpp 是独立的预处理器gcc -E 是驱动它 cpp hello.c hello.i gcc -E hello.c -o hello.i # 看一下膨胀了多少以及自己的代码从哪一行开始 wc -l hello.i grep -n int main hello.i sed -n 3040,3065p hello.iwc -l给出总行数grep -n int main直接定位自己代码的起点行号sed截取尾部几十行看展开后的样子。这里有个细节hello.i里会出现大量以#开头的行编号标记和文件名标记这是预处理器给编译器留的位置信息用来在报错时把行号映射回原始.c文件。这些标记你在读hello.i的时候可以直接跳过但它们解释了「为什么hello.i里明明没写几行编译器报错却能精确到hello.c第 12 行」。提示gcc -E默认会保留#行标记加-P参数可以去掉。写报告截图的时候加-P更干净但分析行号映射的时候别加。宏替换的观察点更好找。hello.c里只要写了#define N 10hello.i里所有N都会变成10包括循环条件里的那个。报告里提到的「根据#if决定需要编译的代码」在hello.i里表现为整段整段的代码直接消失——不是被注释掉是根本没出现在文件里。这就是为什么预处理阶段不报语法错误它压根不懂语法只认#开头的行。3.2 编译hello.s 里的汇编指示、数据段与寄存器传参从hello.i到hello.s是整条链路里信息密度最高的一步。词法分析、语法分析、语义检查、中间代码生成、优化、目标代码生成六个阶段压在一个gcc -S里输出的是人还能读懂的 x86-64 汇编文本。报告花了最长的一章拆这一步抓的点很准先认汇编指示再看数据类型怎么落段最后看操作和控制转移怎么实现。gcc -S hello.i -o hello.s汇编指示也叫伪操作都以.开头不会被翻译成机器指令只是给汇编器下指令。报告里列了一张表最常用的几个是指示作用.file声明源文件名给调试信息用.text以下内容进代码段.data以下内容进已初始化数据段.section .rodata切换到只读数据段放字符串和常量.globl声明符号为全局链接时别的模块可见.align地址对齐x86-64上常见 4 或 8.long/.string按 4 字节整数 / 字符串写入数据.size/.type声明符号大小、是函数还是对象这些指示直接决定了 ELF 里节的划分。hello.s里能观察到的变量分布大致是这样.file hello.c .section .rodata .LC0: .string Usage: Hello student_id name!\n .LC1: .string Hello %s %s\n .globl sleepsecs .data .align 4 .type sleepsecs, object .size sleepsecs, 4 sleepsecs: .long 2 # 2.5 被截断成 2浮点部分没进目标文件 .text .globl main .type main, function main: pushq %rbp movq %rsp, %rbp subq $32, %rsp # 开栈帧32 字节装 argc/argv/i movl %edi, -20(%rbp) # 第 1 个参数 argc 从 edi 落到栈 movq %rsi, -32(%rbp) # 第 2 个参数 argv 从 rsi 落到栈 cmpl $3, -20(%rbp) # argc 与 3 比较 je .L2 # 相等则跳过 if 块字符串统一进.rodata、已初始化的全局变量进.data、函数体进.text这是 C 语言内存模型在汇编层面的第一次落地。要注意原文正文里写「sleepsecs存在rodata段」但从hello.s实际的.globl、.data、.long三段来看它落在.data段——.rodata只装了两个字符串。这类前后不一致在整理笔记时最好保留判断痕迹别照着抄因为评审或者自己半年后回看认的是汇编不是正文措辞。寄存器传参是另一个必须吃透的点。x86-64 的调用约定里前六个整型参数依次走%rdi、%rsi、%rdx、%rcx、%r8、%r9所以main拿到的是%edi里的argc和%rsi里的argv。函数一进来就把这两个寄存器写进栈帧是因为后面要调用printf、sleep这些寄存器会被被调用者覆盖只能先存起来。局部变量i落在(%rbp-4)argv的首地址落在(%rbp-32)中间那 28 个字节是编译器给对齐和临时值留的余量。这些偏移量就是你后面用gdb打断点看内存时的坐标。控制转移的实现方式也值得单独看一眼。C 里的if和for到汇编层被压成「比较条件跳转」两件事cmpl $3, -20(%rbp)做减法并设置条件码je .L2检查 ZF 标志位相等就跳走。for (i 0; i 10; i)更典型编译器会把i 10优化成i 9于是cmpl $9, -4(%rbp)配jle .L4少做一次比较。这种「源码写的和汇编做的不是一回事」的地方恰恰是读汇编最有收获的地方。函数调用部分main自己是被__libc_start_main调起来的call指令先把下一条指令的地址压栈再跳到目标函数结束时leave一条指令等价于mov %rbp,%rsp加pop %rbp把栈帧还回去ret再从栈顶弹出返回地址写进%rip。这套push/sub/leave/ret的组合在hello.s里每个函数都能看到一模一样的骨架。外部函数的调用形式是PLT后缀putsPLT、printfPLT、sleepPLT、getcharPLT、exitPLT。PLT 是过程链接表动态链接的可执行文件里对共享库函数的调用先跳到 PLT 桩再由桩跳到 GOT 里存的真实地址。这里还有个容易被忽略的优化第一次printf只输出一个不带格式符的固定字符串gcc 会直接把它换成putsPLT因为puts更快。所以你在hello.s里找不到第一次printf别以为自己漏抄了。3.3 汇编readelf 拆开 hello.o 的节区与重定位条目汇编器把hello.s翻译成机器指令打包成可重定位目标文件hello.o。「可重定位」这三个字是关键这时候代码里的地址全是占位的call printf后面跟的是00 00 00 00因为汇编器不知道printf最终会被链接到哪个地址只能先留空等链接器来填。gcc -c hello.s -o hello.o # 全量 ELF 信息重点看节头、符号表、重定位表 readelf -a hello.o hello.elf # 只看重定位条目最常用 readelf -r hello.o # 反汇编对比 call 后面的占位 objdump -d hello.o hello.asmhello.o里你会看到这些节.text放机器指令.data放已初始化的全局变量.bss放未初始化的全局变量在文件里不占空间只记大小.rodata放只读常量.symtab是符号表.rela.text是代码段的重定位表.debug_*一堆调试节。readelf -a会把它们全打出来第一次看会很晕建议按「节头 → 符号表 → 重定位表」的顺序读。.rela.text里的每一条重定位记录有四个字段含义分别是Offset这条重定位要改的位置相对于所在节的偏移Type重定位类型R_X86_64_PC32表示相对寻址R_X86_64_PLT32表示要跳 PLTSym. Name要引用的符号比如printf、.rodataAddend加数跟符号地址相加后写回目标位置。对照objdump -d hello.o看call指令后面那 4 个字节正好对应Offset指向的位置。这时候的hello.o是一块「半成品」能看结构不能运行./hello.o会直接报格式错误——因为它没有入口地址、没有对齐到可加载的段、也没有动态链接器信息。注意新版 binutils 里printf的重定位类型可能显示成R_X86_64_PLT32旧版显示R_X86_64_PC32。写报告时两个都提一句比只写一个更稳妥因为不同发行版差异很大。4. 链接、装载与运行从 hello 的虚拟地址空间到 fork/execve4.1 链接重定位表如何把符号填成真实地址链接器干两件事符号解析和重定位。符号解析是把每个.o里的未定义符号跟别的模块或库里的定义对上号printf在hello.o里是UND未定义在标准 C 库里是T代码段中的全局符号重定位是拿着.rela.text里的记录把call后面那 4 个占位字节改成算好的偏移。# 用 gcc 驱动链接它会自动带上 crt 启动文件、libc、动态链接器 gcc hello.o -o hello # 链接后的反汇编对比 hello.asm objdump -d hello hello_asm diff (grep -A2 call hello.asm) (grep -A2 call hello_asm)这里有个几乎所有人都踩过的坑报告摘要里写的是ld hello.o -o hello这条命令直接敲会失败报一堆undefined reference to _start、undefined reference to main之类的错。原因是ld只是个裸链接器不知道启动文件在哪、不知道 C 库在哪、不知道动态链接器路径。gcc是驱动器它在背后帮你补上crt1.o、crti.o、crtbegin.o、-lc、-lgcc、crtend.o、crtn.o这一长串参数。真要看gcc到底做了什么加-v参数它会把完整的ld调用打出来那才是链接的真实样子。链接完成后hello.o里那些00 00 00 00全部变成了真实偏移call后面不再是零jmp也不再是零.rela.text这一节直接消失重定位做完就没用了。objdump -d hello里能看到main的起始地址已经变成0x4011a5这类具体的值而不是hello.o里的0x0。4.2 装载虚拟地址空间布局与动态链接hello这个可执行文件在磁盘上是一堆节被操作系统加载到内存时按「段」组织段是节的集合按访问权限合并。用readelf -l看段表能看到若干个LOAD段每个段记录虚拟地址VirtAddr、文件大小FileSiz、内存大小MemSiz、对齐Align。典型布局大致是区域起始位置内容权限代码段0x400000附近.init.plt.text.rodata只读、可执行数据段紧随代码段.data.bss.got.dynamic可读可写堆数据段之后malloc分配区向高地址增长可读可写共享库映射区0x7f...附近libc.so等共享对象按段设置栈高地址向低地址增长局部变量、返回地址、环境变量可读可写内核区最顶端用户态不可访问—.bss段特殊它在文件里不占空间FileSiz为 0MemSiz不为 0加载时由内核映射一块「请求二进制零」的匿名页读到的全是 0。这就是为什么未初始化的全局变量默认是 0 而不用在文件里写一堆零字节。readelf -l hello # 段表LOAD 段的地址、大小、权限 readelf -S hello # 节表.text .data .bss .got .plt 各在哪 ldd hello # 依赖哪些共享库动态链接器路径是什么 readelf -d hello # .dynamic 节NEEDED、INIT、FINI 条目ldd hello会列出linux-vdso.so.1、libc.so.6、ld-linux-x86-64.so.2这几项。动态链接的核心机制是延迟绑定第一次调用printfPLT时PLT 桩跳到 GOTGOT 里存的还是「解析器入口」而不是printf的真实地址解析器找到printf后把真实地址写回 GOT之后再调用就直接跳了。所以要观察动态链接的过程得在第一次调用之前停下来用gdb在main入口看 GOT 表内容跑一步再看一次能明显看到地址从解析器变成libc里的实际偏移。4.3 运行fork、execve、地址变换与 printf 落盘在 shell 里敲./hello arg1 arg2背后发生的事比想象中长。shell 本身是个进程读到你敲的命令后调用fork()创建子进程子进程调用execve(hello, argv, envp)把自己替换成 hello。execve做四件事删除当前进程虚拟地址的用户部分里已有的区域结构、为新程序的代码/数据/bss/栈创建私有且写时复制的区域、把共享库映射到共享区域、把程序计数器设成代码段入口。做完这四步bash的壳子还在但里面跑的已经是 hello 了。# 观察 fork/execve 与后续 IO strace -f -e traceprocess,read,write ./hello arg1 arg2 # 观察地址空间变化在 execve 前后各打一次 gdb -q ./hello (gdb) start (gdb) info proc mappingsstrace的输出里能清楚看到clonefork在 Linux 上的实际实现、execve、read、write的调用顺序。getchar()循环十次就是十次read(0, ...)每次读一个字节sleep(2)对应的是一次nanosleepprintf(Hello %s %s\n, ...)对应的是一次write(1, Hello ..., N)注意是write不是printf因为printf是库函数它把格式化结果攒在缓冲区里真正落到终端靠的是write系统调用。地址变换这条线也在这一步发生。程序里用的全是虚拟地址CPU 里的 MMU 靠 CR3 寄存器指向的页表做四级遍历PGD → PUD → PMD → PTE每一级取 9 位索引最后拼出物理页框号加上页内偏移得到物理地址。为了不每次都走四级TLB 缓存了最近的页表项为了不每次都访问内存三级 CacheL1/L2/L3缓存了最近的物理内存块。访问一个没映射过的页会触发缺页故障内核的缺页处理程序负责分配物理页、建立映射、再重新执行那条指令。进程结束的时候main返回 0exit被调用进程进入僵尸态shell 通过wait回收它内核把它的页表、文件描述符、信号处理表全部清掉。这就是 020 里的那个「to Zero-0」——从零开始回到零。5. 避坑与排查复现 Hello 全链路时最容易翻车的五处5.1 编译与链接阶段的三处硬伤**现象**照着报告敲ld hello.o -o hello报一堆undefined reference to _start或者链接出来的文件一跑就段错误。原因ld是裸链接器不带启动文件、不带 C 库、不指定动态链接器_start是crt1.o提供的main的调用链也靠启动文件搭起来。 **解决**统一用gcc hello.o -o hello驱动确实想手写ld命令就加-v把gcc的完整调用抄出来照着改路径。现象hello.i的行数跟报告里的 3065 行差了几百上千行怀疑自己预处理漏了东西。 **原因**行数主要由头文件决定不同发行版、不同 gcc 版本、不同glibc版本展开出来的行数完全不同stdio.h里包含的头文件数量都能差出十几个。 **解决**不要拿行数当正确性标准改成校验「自己的代码从第几行开始」「三个头文件的路径出现在哪」「宏有没有被替换」这三条行数只作为参考值记录在报告里并注明工具链版本。**现象**在hello.s里找不到第一次printf的调用只看到putsPLT以为编译器把代码优化坏了。原因printf(Usage: ...\n)不带任何格式符gcc 会把它替换成语义等价但更快的puts这是标准允许的优化不是 bug。 **解决**想强制保留printf编译时加-fno-builtin-printf或者把字符串改成带%s的形式再传一个参数写报告时把这条优化单独拎出来讲比忽略过去更有说服力。5.2 观察与记录阶段的两处误判现象readelf -a hello.o输出里翻不到.rela.text或者重定位类型显示成R_X86_64_PLT32而报告里写的是R_X86_64_PC32对不上。 **原因**重定位节的命名和类型跟 binutils 版本、目标架构、编译器选项都有关新版工具链对函数调用普遍用PLT32旧版用PC32。 **解决**先readelf -S hello.o确认重定位节叫什么名字再用readelf -r单独看报告里两种类型都写并注明版本别只写一种然后说别人错。**现象**报告正文说sleepsecs在.rodata段但hello.s里明明写着.data用objdump -s看.rodata里也只有两个字符串。 **原因**已初始化为非零值的全局变量按 C 语义进.data只有const或者字符串字面量才进.rodata正文那句是笔误。 **解决**以汇编和readelf -S为准正文里保留一句「这里与初稿描述不一致按实际产物修正」这种自我纠错反而是加分项。现象strace抓到一堆read(0, ...)但printf的输出在终端上是一次性出来的怀疑write被吞了。 **原因**标准输出接终端时是行缓冲接管道或文件时是全缓冲printf的内容先进用户态缓冲区缓冲区满或者遇到换行行缓冲模式才真正write。 **解决**用strace -e tracewrite单独看或者在printf后面加fflush(stdout)写报告时把「库函数缓冲」和「系统调用」这两层分开讲别混成一件事。6. 二次开发把这份报告改造成自己的实验脚手架这份材料的骨架很好但它是静态文档而底层观察这件事最怕「一次性」。我的做法是把它变成一个可以反复跑的小脚手架每次改一点代码跑一遍脚本diff 一次产物看汇编和 ELF 哪里变了。第一层是自动化产物。写一个Makefile把五个阶段拆成独立目标make all一次产出全部中间文件make clean全部清掉CC : gcc TARGETS : hello.i hello.s hello.o hello hello.elf hello_elf hello.asm hello_asm all: $(TARGETS) hello.i: hello.c $(CC) -E hello.c -o $ hello.s: hello.i $(CC) -S $ -o $ hello.o: hello.s $(CC) -c $ -o $ hello: hello.o $(CC) $ -o $ # 观察目标只依赖不产出永远执行 hello.elf: hello.o readelf -a $ $ hello_elf: hello readelf -a $ $ hello.asm: hello.o objdump -d $ $ hello_asm: hello objdump -d $ $ clean: rm -f $(TARGETS)第二层是对照实验。源码里每次只改一个变量其余不动然后diff上一次的hello.s。我常做的三组对比改造点改动方式观察目标优化等级-O0换成-O2main的栈帧消失、循环被展开、i不再落栈静态 vs 动态-static与默认对比hello.asm里PLT全变成直接callldd报「not a dynamic executable」多目标文件把printf拆到util.chello.o的.rela.text多出一条跨模块重定位第三层是验证方法。改完之后别只看「能跑」要拿三个指标卡readelf -r hello.o的重定位条目数量变化、objdump -d里main的指令条数变化、strace的系统调用序列变化。三个都对得上才算真正理解了这次改动在机器层面意味着什么。我一般还会在gdb里start之后打一次info registers rbp rsp把栈帧边界记下来跟hello.s里的subq $32, %rsp对一遍——对不上说明我对这段汇编的理解有偏差。这套脚手架跑顺之后再去看别的程序的 ELF思路是一样的先readelf -h看入口再readelf -l看段再objdump -d看代码最后strace看运行。从那以后我每次拆一个二进制都会先把这四步强制走一遍再下结论因为跳过去的那一步往往就是后来返工的那一步。希望帮到你。本文还有配套的精品资源点击获取

从hello.c到进程回收：C程序编译链接装载全链路拆解

相关推荐

GitHub热榜技术趋势：AI工具链与多语言框架解析

RAGFlow Redis连接器性能调优实战指南

Anaconda国内镜像下载与配置优化指南

更多资讯

办公软件实战教学：以真实任务驱动的Word+Excel+PPT协同学习框架

大型汽车4S店维修管理系统：从需求到落地的全流程设计

Kraken简正波仿真：传播损耗与阵元波形从原理到Matlab实现

零基础入门Unity AI Demo：从跑通到改参数的新手避坑指南

VoiceStudio：基于Electron+k2-fsa的离线语音分析工作台

LETKF算法编译指南：从环境配置到性能优化

今日更新

PLFM_RADAR：从被动告警到主动感知的微服务健康监控系统

SPI隔离设计实战：MAX14431BAEE+与STM32F407工业级应用

数字隔离器如何根治SPI通信地环路干扰：MAX14431与TM4C129实战

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？