今天 08:38 蚌埠坦克学院嵌入式软件开发发布于上海

关注

嵌入式面试里，项目到底要怎么讲？

很多嵌入式面试，自我介绍刚结束，面试官就会来一句：

“挑一个你最熟悉的项目，详细讲讲。”

接着往往还有三连：

你在项目里具体负责什么？
项目里最难的问题是什么，怎么解决的？
如果现在让你重做一遍，你会怎么改？

这三问看起来都在问“项目”，但本质上考的是同一件事：你有没有真正参与过工程，能不能把问题从现象追到根因，再落到方案、验证和取舍。

功能堆再多，讲不清楚“为什么这样做、还试过什么、最后怎么验证有效”，在面试官眼里都接近 Demo 级经历。

先说结论：项目面不是背简历，是展示“工程闭环”

嵌入式项目面，面试官通常不在找“背过多少名词”，而在判断四件事：

项目是否真实 —— 不是你简历上写的那几个关键词，而是你确实碰过板子、调过协议、查过波形、改过代码。
职责是否清楚 —— 团队项目里，你到底做了什么，边界在哪，哪些是你主导、哪些是协作。
难点是否站得住 —— 不是“通信不稳定”“性能不够”这种空话，而是有现象、有定位过程、有方案对比、有结果。
思路是否工程化 —— 会不会分层排查、会不会做取舍、会不会验证、知不知道代价。

一句话：项目介绍负责建立信任，项目职责负责划清边界，项目难点负责证明能力，解题思路才是最终得分点。

嵌入式大厂面试题，基础八股文资料合集整理：

https://www.nowcoder.com/creation/manager/columnDetail/mPZ4kk

（20+大厂嵌入式经典面试八股文资料）

一、项目介绍：1 分钟讲清“是什么”，3 分钟讲清“怎么跑”

1. 项目介绍到底要介绍什么

很多候选人一开口就陷入两种极端：

太虚：做了一个智能家居系统，用了 STM32、FreeRTOS、MQTT……
太细：从上电复位向量表开始，寄存器一位一位讲……

这两种都不理想。项目介绍的目标不是炫技，而是让面试官快速建立项目画像，并愿意继续往下问。

建议用 “1 分钟 + 3 分钟” 两层结构：

1 分钟版（背景 + 目标 + 技术栈 + 你的角色）

这是一个基于 STM32F407 + FreeRTOS 的工业数据采集节点项目，主要完成多路传感器采集、本地缓存和 Modbus RTU 上报。项目周期 4 个月，团队 3 人，我负责底层驱动、采集任务调度和通信模块。硬件是自研板，软件约 6000 行 C 代码。

这一段要交代：

项目解决什么问题（不是“学习用”）
用了什么平台/协议/RTOS
规模大概多大
你在其中的角色

3 分钟版（架构 + 主流程 + 关键设计点）

接着按数据流或启动流程讲，例如：

上电后完成时钟、GPIO、UART/SPI/I2C 初始化
传感器驱动层完成寄存器配置和数据读取
DMA + 中断把采样数据送入环形缓冲区
采集任务做滤波/打包
通信任务按周期通过 Modbus 上报
异常情况下进入降级或重传机制

这里重点不是罗列模块，而是让面试官看到：你知道系统是怎么跑起来的。

2. 什么样的项目介绍算“合格”

合格的项目介绍，至少满足下面几条：

背景	能说清为什么做、给谁用	只说“课程设计/练手”
架构	能分层：驱动/中间件/应用	只会说“实现了某某功能”
流程	能讲清主数据流或启动流	只会背模块名
角色	明确个人负责边界	“我们都一起做”
技术点	自然带出 2~3 个可深挖点	技术栈堆砌

3. 项目介绍里最容易犯的错

第一，把教程 Demo 当项目。

点亮 LED、跑通 UART 打印、移植一个开源例程，这些可以写进简历，但很难撑住 10 分钟深挖。面试官会继续问：你为什么这样设计任务划分？中断和 DMA 怎么配合？异常怎么处理？Demo 往往答不上来。

第二，介绍时把技术细节全倒出来。

项目介绍阶段点到为止即可。你说到的每个技术点，面试官都可能当场深挖。更好的做法是：先讲主线，把“钩子”留出来。

比如：

采集这块我们用了 DMA 双缓冲，主要是为了降低 CPU 占用，后面通信异常时也做了重传机制。

这样面试官自然会问：为什么用双缓冲？重传怎么设计？你就有了准备好的展开点。

第三，只讲“做了什么”，不讲“为什么这样做”。

“实现了 SPI 读取传感器”不算项目介绍；“因为传感器要求 1ms 内完成一次采样，Polling 会阻塞其他任务，所以改成 SPI + DMA + 信号量通知采集任务”才像工程表达。

二、项目职责：团队项目里，最怕一句“我们都参与了”

1. 面试官为什么要问职责

团队项目非常常见，面试官并不排斥，但会警惕两种人：

把团队成果全部说成自己的
只说“打杂”“协助”，完全讲不出独立贡献

问职责，是在确认：你到底掌握了哪一段链路。

2. 职责回答的标准结构

推荐用这个模板：

我主要负责 A，配合 B，最终交付了 C。

例如：

我主要负责 I2C 传感器驱动、采集任务和 Modbus 通信协议栈移植；和另一位同事协作完成了 PCB 联调和上位机联调；最终实现了 8 路传感器 100ms 周期稳定上报，现场连续运行 72 小时无丢包。

这里有三层信息：

负责模块 —— 驱动 / 任务 / 协议 / Bootloader / 调试
协作边界 —— 哪些不是你独立完成
可量化结果 —— 周期、稳定性、资源占用、故障率

3. 职责要写到什么粒度

不要只说：

我负责软件部分。

要说：

我负责 FreeRTOS 任务划分、I2C 驱动、采集状态机和异常恢复；Bootloader 和硬件原理图是同事负责，但我参与了启动流程联调。

也不要过度包装：

我独立完成了整个系统。

如果实际上用了大量开源代码、参考例程、同事模块，被追问调用链时很容易露馅。

4. 不同岗位，职责表达侧重点不同

MCU / RTOS 方向

外设驱动怎么写
任务怎么划分
中断、DMA、优先级怎么设计
资源占用和实时性怎么保证

Linux 驱动 / BSP 方向

设备树、驱动框架、probe/remove 流程
中断、时钟、GPIO、DMA 配置
用户态与内核态接口
调试手段：dmesg、逻辑分析仪、示波器

Bootloader / 底层方向

上电启动流程
Flash 分区、镜像校验、升级机制
异常恢复、回滚策略

职责表达要和目标岗位对齐，否则面试官会觉得你“做过很多，但都不深”。

三、项目难点：不是“难”，而是“你是怎么把它解决的”

1. 很多“难点”其实不合格

下面这些听起来像难点，实际上面试官一听就知道没准备：

项目时间紧，任务重
通信有时候不稳定
调 bug 调了很久
资料少，学习成本高

这些最多说明项目不容易，不能证明你有工程能力。

合格的难点，必须包含四要素：

现象 —— 出了什么问题
定位 —— 怎么确认根因
方案 —— 试过什么，为什么选这个
结果 —— 改完效果如何

2. 用“问题闭环”讲难点，比 STAR 更适合嵌入式

STAR 可以用，但嵌入式面试里更推荐 “现象 → 假设 → 验证 → 方案 → 结果 → 反思” 这条链：

示例 1：I2C 偶发 NACK

现象：温湿度传感器偶发读取失败，失败率约 3%，上电前 10 分钟更明显
假设：上拉不足 / 时序问题 / 中断抢占导致 I2C 时序被打断
验证：示波器看 SCL/SDA，失败时 SDA 被拉低；关闭某高优先级任务后失败率下降
方案：I2C 访问加互斥锁；调整任务优先级；SCL 改为开漏并检查上拉电阻
结果：失败率降到 0.1% 以下
反思：裸机轮询和 RTOS 下访问共享外设，要考虑并发和时序完整性

示例 2：FreeRTOS 队列阻塞导致采集延迟

现象：采集周期设计 10ms，实测偶尔 30ms+
定位：trace 发现通信任务长时间占用 CPU，采集任务被饿死
方案：调整优先级、缩小临界区、队列改为通知机制、通信任务分片处理
结果：99% 周期稳定在 10ms±1ms
反思：RTOS 不是“创建任务就行”，还要考虑优先级反转和资源竞争

示例 3：Flash 升级后偶发启动失败

现象：OTA 后 1% 设备无法启动
定位：CRC 校验通过，但镜像边界未对齐，Bootloader 跳转地址错误
方案：增加镜像头校验、双分区备份、升级失败自动回滚
结果：升级成功率 99.9%+

这类回答的分值，远高于“我优化了滤波算法”这种没有过程的表述。

3. 难点不要只准备一个

建议每个核心项目准备 2~3 个难点，分别覆盖不同能力：

一个偏驱动/硬件联调
一个偏 RTOS/并发/性能
一个偏协议/可靠性/异常处理

这样无论面试官从哪个角度切入，你都有真实材料。

4. 面试官追问难点时，常见下一层问题

讲完难点后，通常会继续问：

还有没有别的方案？为什么没选？
这个方案的代价是什么？
你怎么验证问题真的解决了？
如果量产 1 万台，这个问题还会不会出现？
现在重做，你会怎么设计得更稳？

所以难点不能只会“最终结果”，还要准备方案对比和 trade-off。

四、解题思路：这才是项目面的核心得分项

很多候选人把项目面理解成“把项目讲清楚”。其实面试官真正想听的是：

遇到问题后，你的脑子是怎么转的。

1. 嵌入式问题排查的基本思路

可以记一个通用框架：

先复现 → 再分层 → 再缩小范围 → 再验证假设 → 最后改方案和回归测试

先复现

问题是必现还是偶发？
什么条件下出现？上电初期、高温、长时间运行、特定任务并发时？

再分层

嵌入式问题通常落在几层：

硬件层：供电、时钟、信号完整性、焊接
驱动层：寄存器配置、中断、DMA、时序
系统层：任务优先级、锁、内存、栈
协议层：帧格式、超时、重传、状态机
应用层：算法、业务逻辑

不要一上来就改代码。先判断问题在哪一层。

再缩小范围

注释某个任务后问题是否消失？
降低采样率后是否缓解？
换板子/换传感器后是否复现？
逻辑分析仪/串口 log/ GPIO 翻转打点能否定位卡点？

再验证假设

每个假设都要有证据，不是“我觉得可能是……”

最后改方案并回归

改了什么
为什么这样改
有没有引入新问题
如何回归测试

2. 面试官想听到的“方法论”，不是口号

下面这些表达是有分的：

“我先确认是硬件还是软件问题，再决定要不要动代码。”
“我加了时间戳 log，把问题定位到某个任务切换窗口。”
“我对比了 Polling、中断、DMA 三种方案，最后选 DMA 是因为 CPU 占用和实时性更平衡。”
“我没有直接上复杂算法，先用状态机过滤异常点，确认有效后再优化滤波窗口。”
“我改了优先级后，专门做了长时间压测和异常注入测试。”

下面这些表达分值很低：

“查资料后改好了。”
“试了很多方法，最后成功了。”
“导师帮忙看的。”
“重启一下就好了。”

3. 项目面里，思路比结果更重要

有时候项目并没有完美解决，这并不致命。更致命的是：

说不清问题现象
说不清排查路径
把开源代码当成自己的设计
被追问调用链时找不到函数入口

如果你能说：

这个问题当时只把失败率从 3% 降到 0.5%，没有彻底清零。后来再分析，怀疑还有电源噪声因素，但当时缺少硬件条件，所以我在软件里加了重试和异常隔离，保证业务不中断。

这反而比“我一下就解决了”更可信。

4. 一个高分回答的结构模板

以后回答“项目难点”或“你怎么排查问题”，可以直接套这个结构：

1. 背景：模块和目标

2. 现象：具体异常表现和数据

3. 排查：做了哪些验证，排除了哪些可能

4. 根因：最终确认的问题

5. 方案：为什么选这个，备选方案是什么

6. 结果：量化指标

7. 反思：如果重做会怎么设计

五、怎么准备，才真正扛得住项目深挖

1. 先选一个“主项目”，不要摊大饼

春招/社招都建议：准备 1 个主项目 + 1 个辅项目。

主项目要能讲 10~15 分钟，并承受 30 分钟追问。辅项目用于补充广度。

比“4 个项目每个 1 分钟”强得多。

2. 准备时至少过一遍这五张表

表 1：项目基本信息

背景、目标、周期、团队规模
芯片/系统/协议/RTOS
你的职责

表 2：系统架构图

分层结构
主数据流
任务/模块关系

表 3：关键流程

上电启动流程
一次完整业务链路
异常处理流程

表 4：2~3 个真实难点

每个难点按“现象-定位-方案-结果”写一页

表 5：可深挖技术点

I2C/SPI/UART 时序
中断/DMA
任务优先级/队列/互斥锁
内存/栈/缓冲区
协议状态机
性能指标和资源占用

3. 代码必须能顺着讲

现在很多二面/PPT 面，会直接问：

这个功能入口函数在哪？
谁调用了它？
中断里做了什么？
这个全局变量在哪个任务里改？

所以准备项目时，至少把以下内容过一遍：

main() 到系统跑起来
外设初始化流程
关键中断服务函数
任务创建和任务间通信
你最熟悉的 1~2 个核心模块

不是背代码，而是能画出调用链。

4. 每个技术点都准备“三问”

以 FreeRTOS 队列为例：

为什么这里用队列，不用信号量？
队列长度怎么定的？
满了怎么办？会不会阻塞别的任务？

以 I2C 为例：

主机从机模式？时钟多少？
为什么读某个寄存器要先写地址？
NACK 时你怎么处理？

以 DMA 为例：

为什么用 DMA，不用中断或 Polling？
缓冲区怎么管理？
DMA 传输完成怎么通知任务？

5. 模拟面试时，优先练这些“送命题”

这个项目是不是你独立做的？
哪部分代码是你写的？
最难的问题是什么？
你为什么不用另一种方案？
如果现在重做，你会改什么？
项目上线后出现过什么问题？
你怎么证明你的改动有效？

能把这些答稳，项目面就成功一半了。

六、一个完整示例：3 分钟项目介绍 + 难点回答

项目介绍示例

我做的是一个基于 STM32F407 和 FreeRTOS 的多通道数据采集模块，主要采集温度、压力和开关量，并通过 Modbus RTU 上报给主控 PLC。项目周期 4 个月，团队 3 人，我负责驱动层、采集任务和通信模块。
系统分三层：底层是 I2C、SPI、GPIO 驱动；中间是采集缓冲和状态机；上层是两个 FreeRTOS 任务，一个是 10ms 周期的采集任务，一个是通信任务。传感器数据通过 DMA 和环形缓冲区进入采集任务，打包后放进队列，由通信任务按 Modbus 协议发送。
我主要解决了 I2C 偶发 NACK 和采集周期抖动两个问题，最终实现了 8 路数据 100ms 周期稳定上报，现场运行 72 小时无异常。

难点回答示例

项目里一个比较典型的问题是 I2C 读取温湿度传感器时偶发 NACK，失败率大概 3%，而且集中出现在上电后的前 10 分钟。
我一开始怀疑是驱动写法问题，但单独跑 I2C 测试任务时失败率很低，说明不是单纯寄存器配置错误。后来用示波器抓波形，发现失败时 SDA 会被异常拉低；同时我发现某个高优先级任务里也有 I2C 访问，但没有统一保护。
所以根因是 RTOS 下多个任务并发访问 I2C，总线访问被打断。我的处理是给 I2C 外设访问加互斥锁，并把相关任务优先级重新梳理，另外检查了上拉电阻和开漏配置。
改完之后，连续跑 24 小时压力测试，失败率降到 0.1% 以下。如果重做，我会一开始就把 I2C 访问封装成统一接口，而不是让多个任务直接调底层读写函数。

这个回答里，职责、难点、思路、结果都齐了。