兆易创新嵌入式开发二面

1. 在你的项目里，如果一个任务既要保证实时性，又要避免占用过多 CPU，你会怎么设计？

答案：

我会优先采用事件驱动而不是纯轮询的方式。比如通过中断、消息队列、信号量或者任务通知来触发任务执行，而不是让任务一直空转检查状态。

如果任务对实时性要求很高，我会把它的优先级适当提高，同时保证任务内部逻辑尽量短，不做耗时操作。对于数据搬运类场景，还可以配合 DMA，减少 CPU 占用。核心思路是：用更少的轮询，换更高的响应效率。

2. 如果项目中有多个任务同时访问同一个外设，你会如何保证系统稳定？

答案：

首先要判断这个外设是否适合多任务共享。如果必须共享，我一般会在驱动层或服务层做统一管理，而不是让多个任务直接操作外设。

常见做法有：

• 用互斥锁保护访问过程
• 用消息队列让一个专门任务统一管理外设
• 对读写时序做状态机控制

这样可以避免资源竞争、时序混乱和数据覆盖问题。相比多个任务直接抢占外设，统一管理通常更稳定。

3. 在嵌入式系统中，为什么很多时候不建议把复杂业务逻辑直接写在驱动层？

答案：

因为驱动层的职责应该是屏蔽硬件细节并提供基础操作接口，如果把过多业务逻辑塞进去，会导致驱动层职责不清，耦合严重。

这样做的后果通常是：

• 驱动难复用
• 平台迁移困难
• 测试和维护成本变高
• 上下层边界混乱

更合理的方式是：驱动层只负责硬件访问，服务层负责数据处理和协议封装，应用层负责业务逻辑。

4. 如果系统偶发死机，但现场不好复现，你通常怎么定位？

答案：

这种问题一般不能只靠“猜”，我会优先做现场信息保留和最小范围缩小。

常用方法有：

• 加日志，记录关键状态和异常前后的操作
• 增加看门狗复位原因记录
• 保存异常现场寄存器信息
• 检查任务栈水位
• 检查是否有越界、空指针、野指针访问
• 回看最近改动的代码

如果怀疑是并发问题，会重点检查共享资源访问、临界区和中断交互。

如果怀疑是内存问题，会去看 map 文件、堆栈使用情况和缓冲区边界。

5. 在你看来，设计一个可靠的嵌入式系统，最重要的几个点是什么？

答案：

我觉得可靠性主要体现在以下几个方面：

• 架构清晰，模块边界明确
• 资源使用可控，尤其是内存、CPU、栈
• 异常处理完善，比如超时、重试、默认恢复机制
• 关键路径可监控，比如日志、状态记录、看门狗
• 充分测试边界场景，比如断电、通信异常、高频中断、长时间运行

嵌入式系统很多时候不是功能做出来就够了，而是要考虑设备能不能长期稳定运行。

6. 如果通信协议需要兼容后续升级，你会如何设计报文格式？

答案：

我会优先考虑可扩展性和兼容性。

常见做法是报