代码工程类

1. 你平时怎么组织 STM32 工程代码

你可以这样答：

我一般会按模块来组织 STM32 工程代码，让每个模块职责清晰，方便维护和调试。
通常我会把工程分成硬件驱动层、业务逻辑层和主控调度层。
硬件驱动层负责 GPIO、UART、I2C、ADC、PWM、按键、显示这些外设或模块的初始化和基础接口。
业务逻辑层负责数据处理、模式切换、控制逻辑、协议解析这些功能。
main 函数里尽量不堆很多细节代码，主要做初始化和任务调度。
这样组织的好处是，后续加功能、改功能或者排查问题时，范围会比较清楚。

如果你想说得更工程一点，可以补一句：

我习惯每个模块分别写 .c 和 .h 文件，对外只暴露必要接口，内部细节尽量封装起来。

---

2. main 函数里通常放什么

这个问题很常见，面试官在看你有没有工程习惯。

你可以这样答：

main 函数里我通常放三类内容。
第一类是系统初始化，比如 HAL 初始化、时钟配置、外设初始化。
第二类是模块初始化，比如显示模块、按键模块、串口接收状态、控制参数初值。
第三类是主循环调度，也就是不断执行一些非阻塞任务，比如扫描按键、刷新显示、处理串口命令、执行状态机、处理标志位。
我一般不会把大量具体业务逻辑直接堆在 main 里，因为那样后面代码会越来越乱。

你还可以补一句很加分的话：

main 更像系统入口和任务调度中心，具体功能应该下沉到各自模块中。

---

3. 中断回调和主循环如何配合

这是面试里非常关键的问题，因为它能直接看出你有没有做过真正的单片机开发。

你可以这样答：

我通常会让中断回调和主循环分工明确。
中断回调里只做快速、必要的事情，比如读取硬件数据、更新计数值、写入缓冲区、置一个完成标志。
主循环里再根据这些标志做进一步处理，比如数据解析、状态更新、界面刷新、控制决策。
这样做的原因是中断要尽量短，避免影响系统实时性，也方便后续调试。
比如串口接收中断里，我通常只收字节进缓冲区，真正的协议解析放到主循环里做。
定时器中断里，我可能只做节拍计数或者置位，具体任务调度由主循环完成。

你可以总结成一句适合面试背诵的话：

我的习惯是中断负责“采集事件”，主循环负责“处理事件”。

这句话很好用。

---

4. 全局变量为什么有时要加 volatile

这是典型基础题，但很多人答得很空。你要答到“编译器优化”和“异步修改”。

你可以这样说：

volatile 的作用是告诉编译器，这个变量的值可能在程序当前执行路径之外被改变，所以每次使用它时都要重新去内存里读取，不能擅自优化成寄存器缓存值。
在 STM32 开发里，最常见的场景就是中断和主循环共享变量，或者变量对应的是硬件寄存器。
如果一个变量在中断里会被修改，主循环里会读取，那这个变量通常要考虑加 volatile。
否则编译器可能觉得它“看起来没变”，结果主循环一直拿旧值，程序现象就会不对。

举个你面试时能直接说的小例子：

比如我定义一个串口接收完成标志 rx_flag，中断里把它置 1，主循环里轮询这个标志。如果没有 volatile，主循环有可能读不到最新值。

如果面试官继续追问，你可以补：

但 volatile 只能保证每次都重新读值，它不保证多字节访问的原子性，也不等于线程安全。

这个回答会显得你理解更深。

---

5. 状态机你怎么理解

这个问题在嵌入式面试里很高频，因为很多控制逻辑都离不开状态机。

你可以这样答：

我理解状态机就是把系统运行过程拆成若干个明确状态，在不同状态下执行不同逻辑，再根据条件在状态之间切换。
这样做的好处是逻辑会更清晰，尤其适合按步骤执行、模式切换明显、事件驱动强的功能。
比如一个系统可以有待机状态、运行状态、报警状态、设置状态，不同状态下按键功能、显示内容、控制输出都可能不同。
如果不用状态机，代码容易写成很多嵌套的 if else，后面会越来越难维护。
用状态机以后，我只需要关注当前状态是什么、触发条件是什么、下一状态是什么，代码可读性会好很多。

你可以再说一个更贴近项目的例子：

比如串口命令解析、菜单切换、舵机动作流程、比赛题里的模式切换，我都会优先考虑用状态机来组织逻辑。

---

6. 如何避免各模块代码耦合太重

这题本质是在问你有没有模块化思维。

你可以这样答：

我会从接口设计和职责划分两个方面减少模块耦合。
首先，每个模块只负责自己那部分功能，比如按键模块只负责按键扫描和键值输出，显示模块只负责显示接口，串口模块只负责收发和缓存。
其次，模块之间尽量通过函数接口和数据结构交互，少直接互相访问内部变量。
另外，我会避免一个模块里直接写另一个模块的大量细节逻辑，尽量让主控层去做统一调度。
这样某个模块后面要替换实现方式时，对其他模块影响会比较小。

你还可以补一句很实用的话：

我一般会尽量减少跨文件直接引用全局变量，因为这种方式短期写起来快，后期维护和排错都会比较麻烦。

这个表述很像真实做过工程的人。

---

7. 如果一个功能调不出来，你怎么定位问题

这是面试最喜欢问的题之一。关键是你要体现“分层定位”和“最小化验证”。

你可以这样答：

如果一个功能调不出来，我一般不会一上来就在整份代码里乱改，我会先分层定位。
我通常按这几个顺序查。
第一，先看硬件层面，比如供电、接线、引脚复用、时钟是否正确。
第二，看初始化是否正确，比如外设配置、参数设置、中断使能、GPIO 模式。
第三，看底层现象有没有出来，比如串口有没有波形、PWM 有没有输出、I2C 有没有 ACK、ADC 数值有没有变化。
第四，再看上层逻辑，比如标志位有没有置位、状态机有没有切换、数据有没有被正确处理。
我习惯先验证最小可运行部分，把问题范围一步步缩小。
比如串口功能有问题，我会先发固定字符串确认发送正常，再查接收中断和缓冲区；如果 PWM 不对，我先核对时钟、PSC、ARR、CCR，再看输出引脚；如果 I2C 不通，我先确认地址和 ACK，再检查时序流程。

最后你可以用一句话收尾，很适合面试：

我的定位思路是先确认底层链路通不通，再确认上层逻辑对不对，尽量用现象反推问题位置。

---

给你一版适合直接背的回答

如果面试官把这几个问题连着问，你可以整体这样答：

我平时会按模块来组织 STM32 工程，把驱动层、业务逻辑层和主控调度层分开。
main 函数里主要放系统初始化、模块初始化和主循环调度，尽量不把大量细节逻辑都堆进去。
对于中断和主循环的配合，我习惯让中断只做轻量工作，比如读数据、置标志，主循环再做解析和处理。
对于中断和主循环共享的变量，我会根据场景加 volatile，避免编译器优化导致读不到最新值。
状态机方面，我把它理解成把系统拆成多个明确状态，通过事件和条件切换状态，这样逻辑更清晰，也更容易维护。
在模块设计上，我会尽量通过接口交互，减少跨模块直接访问内部变量，避免耦合太重。
如果一个功能调不出来，我会按硬件、初始化、底层现象、上层逻辑这几个层次逐步排查，先验证最小功能单元，再一步步缩小范围。

---

这类问题里面试官真正想确认的点

其实他们想听的是这几件事：

你有没有基本工程组织能力
你是不是只会写功能，还是也会考虑维护性
你知不知道中断和主循环该怎么分工
你排错时有没有方法，而不是靠试运气