大疆嵌入式招聘信号：BSP与Linux驱动开发核心能力全解析

1. 从一场新春派对聊起：大疆研发岗到底在找什么样的人

年前那阵子，朋友圈里刷到一条挺有意思的消息，大疆上海研发中心搞了个“新春派对”式的招聘专场，放出来的岗位集中在嵌入式、Linux、BSP、驱动开发、C/C++这几个方向。乍一看像是个节日营销活动，但仔细琢磨岗位列表，你会发现这其实是一份相当典型的“嵌入式底层研发能力清单”。我自己在嵌入式圈子里摸爬滚打十来年，带过团队也面过不少人，看到这种岗位组合的第一反应就是：这不是随便撒网，而是精准地在找能啃硬骨头的人。

为什么这么说？因为嵌入式、Linux、BSP、驱动、C/C++这几个词放在一起，指向的是一个非常明确的技术栈——你要能跟硬件打交道，能在资源受限的环境里写出稳定的代码，能看懂芯片手册，能调试那些“跑不起来”的板子。这跟纯互联网后端或者纯应用层开发完全是两码事。应用层出bug，大不了重启服务；底层驱动出问题，可能就是整块板子变砖，或者产线上千台设备集体返工。所以这类岗位对基本功的要求特别扎实，面试官往往不会问你“用过什么框架”，而是直接甩一道内存对齐、中断上下文、设备树匹配的问题过来。

这篇文章我想聊的不是“怎么投简历”或者“大疆面试流程”，而是借这个招聘信号，把嵌入式Linux驱动开发这条技术路线拆开讲透。从BSP到底在做什么，到驱动开发的核心难点，再到C/C++在嵌入式场景下的特殊写法，以及面试里那些高频但容易答砸的问题。如果你正在准备嵌入式方向的求职，或者刚入行想搞清楚BSP和驱动的边界，再或者你是个应用层开发者想往下沉一沉，这篇内容应该能给你一些实在的参考。我会尽量用一线踩坑的经验来讲，少讲教科书上的定义，多讲实际项目里怎么干活、怎么排错、怎么避坑。

2. 嵌入式Linux岗位的能力地图：BSP、驱动、C/C++到底怎么分工

2.1 BSP工程师不是“装系统的”，而是板级生态的搭建者

很多人对BSP的理解停留在“给板子装个Linux系统”，这个认知偏差挺大的。BSP全称Board Support Package，直译是板级支持包，但它的实际工作范围远比“装系统”宽。一个完整的BSP要解决的是：这块板子上的CPU、内存、存储、外设、电源管理、时钟树、引脚复用，怎么让Linux内核认识它们并且正确驱动起来。

我拿一个实际场景举例。假设你拿到一块新的ARM开发板，SoC是某国产芯片，DDR是LPDDR4，存储是eMMC，还有一堆GPIO接的按键和LED。BSP工程师要做的第一件事不是写驱动，而是让板子能启动到串口打印。这个过程涉及：BootROM怎么配置启动介质、SPL（二级程序加载器）怎么初始化DDR、U-Boot怎么传递设备树给内核、内核怎么根据设备树去probe各个设备。每一步都可能卡住，而且卡住的时候往往只有串口那几行log能看。

这里有个经验：BSP调试最怕的不是代码写错，而是硬件本身有问题。我遇到过一块板子，DDR初始化参数按手册配的，但就是跑不稳，偶尔启动失败。查了三天，最后发现是PCB走线阻抗不匹配导致信号完整性有问题。所以做BSP的人，最好懂一点硬件，至少能看懂原理图，会用示波器和逻辑分析仪。纯软件思维在这个岗位上会吃亏。

BSP的交付物通常包括：U-Boot移植、内核配置与裁剪、设备树编写、根文件系统构建、启动脚本、以及一份能让产线烧录的镜像。听起来流程清晰，但每个环节都有大量细节。比如内核裁剪，你要知道哪些驱动编进内核、哪些编成模块、哪些直接不要，这直接影响启动速度和内存占用。再比如设备树，现在ARM Linux基本都用设备树描述硬件，但设备树的语法和绑定文档（binding）经常让人头大，一个属性写错，驱动就probe失败，而且报错信息往往很隐晦。

2.2 驱动开发和BSP的边界在哪里

这是面试里经常被问到的问题，也是实际工作中容易扯皮的地方。我的理解是：BSP偏“让系统跑起来”，驱动偏“让外设动起来”。BSP关注的是启动链路、内存映射、时钟电源这些基础设施；驱动关注的是具体外设的功能实现，比如网卡收发数据、LCD显示图像、触摸屏上报坐标。

但边界不是绝对的。比如一个I2C控制器驱动，它既属于BSP范畴（因为要配置控制器寄存器、时钟、引脚），又属于驱动范畴（因为要实现I2C传输算法）。实际项目中，小公司往往一个人全包，大公司会分得细一些。大疆这种规模的研发中心，大概率是BSP团队和驱动团队分开的，但要求彼此能看懂对方的代码。

从技能栈来看，驱动开发对内核子系统的理解要求更深。你要熟悉字符设备、块设备、网络设备的框架，要懂并发控制（自旋锁、互斥锁、原子操作）、中断处理（上半部下半部、中断线程化）、内存管理（kmalloc、vmalloc、DMA）、电源管理（runtime PM、系统休眠）。这些概念在应用层开发里基本用不到，但在驱动里是天天打交道的。

我个人的学习路径建议是：先能把一块板子跑起来（BSP入门），然后挑一个简单外设写驱动（比如GPIO按键），再逐步深入复杂外设（I2C传感器、SPI屏幕、USB设备）。不要一上来就啃USB子系统或者网络协议栈，容易劝退。

2.3 C/C++在嵌入式场景下的特殊要求

嵌入式岗位要求C/C++，但这里的C/C++和互联网公司的C++不是一回事。互联网C++可能大量用STL、智能指针、模板元编程；嵌入式C++往往禁用异常、禁用RTTI、慎用动态内存，STL也用得少，因为代码体积和运行时开销不可控。

C语言在嵌入式里是绝对主力，但写法上有几个关键点：第一，volatile不能乱用也不能不用，寄存器访问必须加volatile，但加了volatile不等于线程安全；第二，位操作要熟练，寄存器配置基本都是按位来的；第三，内存对齐要心里有数，DMA传输对地址对齐有要求，结构体大小可能因为对齐而膨胀；第四，指针运算要小心，嵌入式里经常直接操作物理地址映射后的虚拟地址。

C++在嵌入式里更多用在应用层或者中间件，比如用类封装设备操作、用模板做编译期计算。但要注意，虚函数表、异常处理、动态内存这些特性会增加二进制体积和不确定性，实时性要求高的场景要谨慎。

面试里C语言的高频考点包括：指针与数组的区别、const和volatile的组合含义、字节对齐、大小端、位域、函数指针、内存分区（栈、堆、全局、常量区）。C++则会问虚函数实现、构造析构顺序、RAII、移动语义等。但嵌入式面试更看重你对“底层行为”的理解，比如问你“一个中断处理函数里能不能调用printf”，正确答案是不能，因为printf可能睡眠，而中断上下文不允许睡眠。

3. 驱动开发核心细节：从设备树到中断处理的实操要点

3.1 设备树：驱动和硬件的“婚约”

设备树（Device Tree）是现代ARM Linux驱动开发绕不开的东西。它的作用是把硬件描述从内核代码里剥离出来，让同一个内核镜像能支持不同板子。你可以把它理解成一份“硬件说明书”，内核启动时解析这份说明书，然后匹配对应的驱动。

一个典型的设备树节点长这样：

&i2c1 { status = "okay"; clock-frequency = <100000>; touchscreen@38 { compatible = "focaltech,ft6236"; reg = <0x38>; interrupt-parent = <&gpio1>; interrupts = <5 IRQ_TYPE_EDGE_FALLING>; reset-gpios = <&gpio1 6 GPIO_ACTIVE_LOW>; }; };

这段描述的意思是：I2C1控制器使能，频率100kHz，挂了一个地址为0x38的触摸屏，中断接在GPIO1_5，下降沿触发，复位脚是GPIO1_6低有效。驱动里会定义一个of_device_id表，compatible字段匹配上之后，probe函数就会被调用。

这里有几个实操坑点。第一，compatible字符串必须和驱动里的完全一致，大小写、连字符都不能错，否则probe不触发。第二，reg属性的地址要跟硬件实际地址一致，I2C设备是7位地址，但设备树里写的是8位格式（左移一位），这个容易搞混。第三，中断类型要跟硬件设计匹配，上升沿、下降沿、高电平、低电平，写错了要么中断触发不了，要么触发多次。第四，gpio属性要用gpiod接口获取，老的gpio接口已经废弃了。

调试设备树有个技巧：内核启动后，去/proc/device-tree目录下看实际解析出来的节点，确认属性有没有生效。如果驱动probe失败，先看dmesg里有没有“failed to probe”或者“no matching node”之类的报错，再对照设备树和驱动代码逐项检查。

3.2 字符设备驱动框架：从file_operations到用户空间交互

字符设备是最基础的驱动类型，按键、LED、传感器、串口都可以用字符设备实现。核心是实现file_operations结构体里的open、read、write、ioctl、release等函数，然后注册设备号，创建设备节点。

一个简化的按键驱动流程是这样的：在probe里申请GPIO、注册中断、初始化等待队列；在中断处理函数里记录按键状态并唤醒等待队列；在read函数里等待按键事件并把键值拷贝到用户空间。用户空间通过/dev/button节点来读取按键。

这里的关键点是并发和阻塞。多个进程同时open同一个设备怎么办？read的时候没有按键事件怎么办？中断来了但用户还没read怎么办？这些问题需要用到内核同步机制。等待队列（wait_queue）用来实现阻塞读，自旋锁用来保护中断上下文和进程上下文共享的数据，原子变量用来做简单的计数。

我见过不少新手写的驱动，在中断里直接调用copy_to_user，这是大忌。copy_to_user可能会睡眠，而中断上下文不能睡眠。正确做法是在中断里把数据存到内核缓冲区，然后唤醒等待队列，让read函数在进程上下文里完成拷贝。

另外，ioctl是驱动和用户空间传递控制命令的常用接口。命令号要用_IOR、_IOW、_IOWR宏来定义，保证方向、大小、类型编码正确。用户空间和内核空间的结构体定义要一致，否则数据解析会出错。建议把共享的结构体定义放在一个公共头文件里，两边都include。

3.3 中断处理：上半部和下半部的分工艺术

中断处理是驱动开发里最需要小心的地方。中断处理函数（上半部）要求快进快出，不能做耗时操作，不能睡眠。但实际业务往往需要做一些“重活”，比如网络包处理、数据拷贝、复杂计算。这时候就要用下半部机制，把重活推迟到中断返回后执行。

Linux提供了几种下半部机制：软中断、tasklet、工作队列、线程化中断。软中断和tasklet运行在中断上下文，不能睡眠；工作队列运行在进程上下文，可以睡眠；线程化中断把中断处理函数变成内核线程，也可以睡眠。

选择哪种机制要看具体需求。如果下半部要做I2C读写（可能睡眠），就必须用工作队列或线程化中断。如果只是简单数据处理，tasklet就够了。现在内核社区的趋势是尽量用线程化中断，因为可调试性好，能设置优先级，还能被调度器管理。

中断共享也是个常见问题。多个设备共用一根中断线时，每个中断处理函数都会被调用，所以处理函数里要先判断“这个中断是不是我的设备产生的”，不是就返回IRQ_NONE。判断方法通常是读设备的中断状态寄存器。如果返回IRQ_NONE次数过多，内核会认为中断风暴，可能会禁用这根中断线。

还有一个坑是中断号获取。老代码里常用gpio_to_irq把GPIO号转成中断号，新代码推荐用gpiod_to_irq配合gpio descriptor。设备树里配置了interrupts属性后，驱动里用platform_get_irq或of_irq_get来获取。如果获取失败，先检查设备树里interrupt-parent和interrupts有没有写对。

4. 实操过程：从零搭建一个嵌入式Linux驱动开发环境

4.1 环境准备：交叉编译工具链和内核源码

嵌入式开发的第一步是搭环境。跟应用层开发不同，嵌入式代码要在宿主机上编译，然后放到目标板上运行，所以需要交叉编译工具链。工具链的选择取决于目标板的CPU架构，ARM 32位常用arm-linux-gnueabihf，ARM 64位用aarch64-linux-gnu，RISC-V用riscv64-linux-gnu。

工具链可以从芯片厂商的SDK里拿，也可以用Linaro或者Bootlin提供的通用版本。我一般推荐用厂商SDK里的，因为跟内核版本和库版本匹配，省得折腾。如果自己搭，要注意glibc版本和内核头文件的兼容性。

内核源码从官网或者厂商仓库获取。编译内核的基本流程是：

# 配置交叉编译环境变量 export ARCH=arm64 export CROSS_COMPILE=aarch64-linux-gnu- # 使用默认配置 make defconfig # 或者使用厂商提供的配置 make vendor_defconfig # 编译内核镜像和设备树 make -j$(nproc) Image dtbs modules

编译驱动模块需要先准备好内核头文件，可以用make modules_prepare生成。然后写一个简单的Makefile：

obj-m += my_driver.o KDIR := /path/to/kernel/source PWD := $(shell pwd) all: make -C $(KDIR) M=$(PWD) modules clean: make -C $(KDIR) M=$(PWD) clean

编译出来的.ko文件传到板子上，用insmod加载，rmmod卸载，dmesg看日志。这是驱动开发的基本循环。

4.2 第一个驱动：GPIO按键的完整实现

我拿GPIO按键驱动作为例子，因为它涵盖了驱动开发的大部分核心概念：设备树匹配、GPIO获取、中断注册、等待队列、字符设备注册。

先看设备树部分：

my_button { compatible = "mycompany,my-button"; button-gpios = <&gpio1 12 GPIO_ACTIVE_LOW>; interrupt-parent = <&gpio1>; interrupts = <12 IRQ_TYPE_EDGE_FALLING>; };

驱动代码的核心结构：

#include <linux/module.h> #include <linux/platform_device.h> #include <linux/gpio/consumer.h> #include <linux/interrupt.h> #include <linux/fs.h> #include <linux/uaccess.h> #include <linux/wait.h> #include <linux/cdev.h> struct my_button { struct gpio_desc *gpiod; int irq; struct cdev cdev; dev_t devno; struct wait_queue_head wq; int key_value; bool key_pressed; }; static irqreturn_t button_irq_handler(int irq, void *dev_id) { struct my_button *btn = dev_id; btn->key_pressed = true; btn->key_value = 1; wake_up_interruptible(&btn->wq); return IRQ_HANDLED; } static ssize_t button_read(struct file *filp, char __user *buf, size_t count, loff_t *offset) { struct my_button *btn = filp->private_data; int ret; if (count < sizeof(int)) return -EINVAL; ret = wait_event_interruptible(btn->wq, btn->key_pressed); if (ret) return ret; btn->key_pressed = false; if (copy_to_user(buf, &btn->key_value, sizeof(int))) return -EFAULT; return sizeof(int); } static int button_open(struct inode *inode, struct file *filp) { struct my_button *btn = container_of(inode->i_cdev, struct my_button, cdev); filp->private_data = btn; return 0; } static const struct file_operations button_fops = { .owner = THIS_MODULE, .open = button_open, .read = button_read, }; static int button_probe(struct platform_device *pdev) { struct my_button *btn; int ret; btn = devm_kzalloc(&pdev->dev, sizeof(*btn), GFP_KERNEL); if (!btn) return -ENOMEM; btn->gpiod = devm_gpiod_get(&pdev->dev, "button", GPIOD_IN); if (IS_ERR(btn->gpiod)) return PTR_ERR(btn->gpiod); btn->irq = gpiod_to_irq(btn->gpiod); if (btn->irq < 0) return btn->irq; init_waitqueue_head(&btn->wq); ret = devm_request_irq(&pdev->dev, btn->irq, button_irq_handler, IRQF_TRIGGER_FALLING, "my-button", btn); if (ret) return ret; ret = alloc_chrdev_region(&btn->devno, 0, 1, "my-button"); if (ret) return ret; cdev_init(&btn->cdev, &button_fops); btn->cdev.owner = THIS_MODULE; ret = cdev_add(&btn->cdev, btn->devno, 1); if (ret) goto err_cdev; platform_set_drvdata(pdev, btn); dev_info(&pdev->dev, "button driver probed, irq=%d\n", btn->irq); return 0; err_cdev: unregister_chrdev_region(btn->devno, 1); return ret; } static int button_remove(struct platform_device *pdev) { struct my_button *btn = platform_get_drvdata(pdev); cdev_del(&btn->cdev); unregister_chrdev_region(btn->devno, 1); return 0; } static const struct of_device_id button_of_match[] = { { .compatible = "mycompany,my-button" }, { } }; MODULE_DEVICE_TABLE(of, button_of_match); static struct platform_driver button_driver = { .probe = button_probe, .remove = button_remove, .driver = { .name = "my-button", .of_match_table = button_of_match, }, }; module_platform_driver(button_driver); MODULE_LICENSE("GPL"); MODULE_AUTHOR("Your Name"); MODULE_DESCRIPTION("GPIO Button Driver");

这段代码虽然不长，但把驱动开发的核心要素都包含了。几个关键点：用devm_系列函数申请资源，出错时自动释放，省得写一堆goto；用gpiod接口而不是老的gpio接口；中断处理函数里只做最小必要操作，然后唤醒等待队列；read函数用wait_event_interruptible实现阻塞读。

加载驱动后，需要手动创建设备节点：mknod /dev/my-button c <major> <minor>。major号可以从/proc/devices里查到。然后写个简单的用户程序open、read，按一下按键就能读到数据。

4.3 调试手段：printk、ftrace和动态调试

驱动调试最常用的手段是printk，但printk有日志级别，默认级别低的打印可能看不到。可以用dmesg -n 8打开所有级别，或者用pr_debug配合动态调试。

动态调试（dynamic debug）是个好东西，可以在运行时开关某条打印，不用重新编译内核。用法是在内核配置里打开CONFIG_DYNAMIC_DEBUG，然后通过/sys/kernel/debug/dynamic_debug/control文件控制。比如：

# 打开某个文件里所有pr_debug echo 'file my_driver.c +p' > /sys/kernel/debug/dynamic_debug/control

ftrace用来跟踪函数调用和中断，对分析时序问题特别有用。比如想知道中断处理函数执行了多久，可以用function_graph tracer：

echo function_graph > /sys/kernel/debug/tracing/current_tracer echo button_irq_handler > /sys/kernel/debug/tracing/set_graph_function cat /sys/kernel/debug/tracing/trace

还有内核的oops信息，驱动里空指针或者非法访问会导致内核崩溃，但oops信息里会打印调用栈和寄存器状态，配合addr2line和gdb可以定位到具体代码行。编译内核时记得打开CONFIG_DEBUG_INFO，否则没有符号信息。

5. 常见问题与排查技巧实录

5.1 驱动probe失败的排查思路

probe失败是驱动开发里最高频的问题。现象是insmod成功但设备节点没出现，或者dmesg里有报错。排查顺序我一般是这样：

第一步，确认设备树节点有没有被内核解析。去/proc/device-tree下找对应节点，看compatible、reg、interrupts这些属性在不在。如果节点都没有，说明设备树没编译进去或者被覆盖了。

第二步，确认驱动有没有匹配上。看/sys/bus/platform/drivers/下对应驱动目录里有没有设备链接。如果没有，说明compatible不匹配或者驱动没注册。

第三步，看probe函数里哪一步失败了。在probe里加printk，或者用dev_err打印错误码。常见失败点包括：GPIO申请失败（引脚被其他驱动占用）、中断申请失败（中断号无效或冲突）、内存申请失败、时钟获取失败。

第四步，如果是依赖其他驱动（比如I2C控制器），确认依赖驱动有没有先加载。Linux驱动模型有probe顺序，依赖的驱动没ready，自己的probe会被推迟（-EPROBE_DEFER）。

5.2 中断不触发的常见原因

中断不触发也是高频问题。先确认硬件层面：用示波器或者逻辑分析仪看中断引脚有没有信号变化。如果硬件没信号，那是电路问题，软件怎么调都没用。

如果硬件有信号但驱动收不到，检查这几点：设备树里interrupt-parent和interrupts有没有写对；GPIO有没有被配置成中断功能（有些引脚复用要设置）；中断触发类型跟硬件信号是否匹配（上升沿/下降沿/电平）；中断有没有被其他驱动占用（cat /proc/interrupts看中断计数）。

还有一种情况是中断触发了但处理函数没执行，可能是中断被disable了。检查/proc/interrupts里对应中断的计数有没有增长，如果没增长说明中断没到CPU。如果增长了但处理函数没打印，可能是处理函数返回了IRQ_NONE被内核忽略了。

5.3 内存泄漏和并发问题的定位

驱动里的内存泄漏不会像应用层那样被valgrind轻易发现，因为内核内存没有自动回收机制。kmalloc的内存必须kfree，devm_kzalloc的不用管（设备卸载时自动释放）。如果发现系统运行一段时间后内存越来越少，可以用/proc/meminfo和slabtop看内核内存分布。

并发问题更隐蔽，典型现象是偶发崩溃或者数据错乱。排查方法是审查所有共享数据的访问路径，确认有没有加锁。中断上下文和进程上下文共享的数据必须用自旋锁保护；可能睡眠的操作不能用自旋锁，要用互斥锁；简单的计数可以用原子变量。

我踩过的一个坑是：在中断处理函数里用mutex_lock，结果系统直接死锁。因为中断上下文不允许睡眠，而mutex_lock可能睡眠。后来改成spin_lock_irqsave，问题解决。这个教训是：中断里只能用不自旋锁和原子操作，其他同步机制一律不能用。

5.4 常见问题速查表

6. 面试高频考点与备考建议

6.1 C语言底层考点：指针、内存、位操作

嵌入式面试的C语言部分，考的不是语法糖，而是对底层行为的理解。高频题包括：指针和数组的区别（数组名不是指针，sizeof结果不同）；const和volatile同时修饰一个变量是什么意思（只读且可能被外部修改，比如状态寄存器）；结构体字节对齐规则（默认按最大成员对齐，可以用#pragma pack或__attribute__((packed))改变）；大小端判断和转换；位域的定义和内存布局。

还有一类题是手写代码，比如“实现一个内存拷贝函数，考虑重叠情况”（memmove）；“用位操作实现一个变量的置位、清零、取反”；“判断一个数是不是2的幂”。这些题不难，但要求写出来的代码没有bug，边界条件要考虑周全。

6.2 Linux内核机制：进程调度、内存管理、文件系统

Linux内核部分的面试范围很广，但嵌入式岗位更关注跟驱动相关的子系统。进程调度会问：进程和线程的区别、调度策略（CFS、实时调度）、上下文切换开销、优先级反转。内存管理会问：虚拟地址到物理地址的映射、页表、TLB、kmalloc和vmalloc的区别、DMA一致性。文件系统会问：VFS框架、字符设备和块设备的区别、proc和sysfs的作用。

我建议备考时不要死记概念，而是结合驱动开发的实际场景去理解。比如问“为什么驱动里不能用printf”，答案要落到“printf可能睡眠，中断上下文不允许睡眠”这个点上。再比如问“copy_to_user为什么可能睡眠”，要能解释“用户空间页面可能被换出，需要缺页中断处理”。

6.3 项目经验怎么讲：从“做了什么”到“解决了什么”

面试里讲项目经验，最忌讳流水账式地罗列“我用了什么技术”。面试官想听的是：你遇到了什么问题，怎么分析的，为什么选这个方案，最后效果如何。比如你说“我写了一个I2C触摸屏驱动”，这没什么亮点。但如果你说“触摸屏中断偶尔丢失，我通过分析发现是I2C传输在中断上下文里耗时太长，改成线程化中断后问题解决”，这就体现了你的排查能力和对内核机制的理解。

准备项目经验时，可以按STAR法则组织：Situation（背景）、Task（任务）、Action（行动）、Result（结果）。重点放在Action和Result上，尤其是那些“踩坑后调整方案”的经历，最能体现真实水平。

6.4 学习路线建议：从裸机到Linux驱动

如果你是从零开始学嵌入式Linux，我建议的路线是：先学C语言和数据结构，然后玩STM32裸机开发（理解寄存器、中断、时钟），再过渡到Linux应用编程（文件IO、进程线程、网络），最后深入Linux驱动开发。这个路线看起来长，但每一步都在为下一步打基础。

裸机开发能让你理解硬件怎么工作，这是嵌入式跟纯软件最大的区别。Linux应用编程能让你熟悉Linux的运行机制和系统调用。到了驱动阶段，你会发现之前学的寄存器操作、中断处理、内存管理都用上了，只是换了一套框架。

学习资料方面，韦东山的视频和书籍适合入门，宋宝华的《Linux设备驱动开发详解》适合进阶，内核源码和Documentation目录是最好的参考。遇到问题多查内核邮件列表和Stack Overflow，很多坑别人已经踩过了。

7. 一些个人体会

嵌入式Linux驱动开发这条路，入门门槛确实比应用层高，前期要学的东西多，调试手段也没那么友好。但它的护城河也深，因为底层的东西变化慢，你积累的经验不会轻易过时。我做了这么多年，最大的感受是：驱动开发的核心能力不是“会写代码”，而是“会分析问题”。代码写错了可以改，但问题定位错了，方向就全偏了。

另外，这个领域特别看重动手能力。看再多书，不如自己买块板子从头跑一遍。从点灯开始，到按键、串口、I2C、SPI、USB，一个一个外设啃下来，每啃一个都会对内核有新的理解。遇到问题不要急着问人，先自己查手册、看源码、做实验，这个过程中学到的东西才是真正属于你的。

大疆这类公司的嵌入式岗位，面试时除了技术，也会看你对硬件的兴趣和动手经验。如果你平时自己玩过开发板、做过小项目，面试时聊起来会很有说服力。技术问题答不上来没关系，但要让面试官感觉到你是个愿意钻研、能解决问题的人。