全志科技 嵌入式一面 采集上报链路与实时性追问

《面试题目》

1. 简历里主攻 MCU + RTOS 业务软件，能挑一个最深入的项目，讲清业务背景、系统组成、任务与中断划分，以及你负责的模块边界吗？
2. 这个项目里 SPI/I2C/UART、ADC 采样链路和 MQTT/TCP 上报是怎么协同的？
3. 高频采集与慢速上报抢 CPU、多任务共享外设时，你如何用 DMA、环形缓冲、队列或锁保证实时性和可靠性？
4. 项目里有没有出现偶发挂死、内存碎片、看门狗复位或通信异常？你怎么用证据定位根因，并把它收敛到可量产边界？
5. 请举一个你真实遇到困难或逆境的例子，讲清背景、你的应对动作，以及从中学到了什么。
6. 如果任务多且相互冲突，你会怎么判断优先级、安排节奏、同步风险，确保关键交付不失控？

《参考解析》

采集链路的设计要点是「搬运不占 CPU、上报不堵采集」：典型的四层流水线——ADC/I2S 按固定采样率由 DMA 搬进环形缓冲（半传/全传中断各给一次信号）；采集任务只做轻量处理（滤波、量纲换算、打包），处理完把整帧指针投进 xQueueSend（传指针不传大数组，避免拷贝）；上报任务从队列取帧，做 MQTT/TCP 发送；网络断了就落到本地 Flash 环形区补传。SPI/I2C 这类外设属于慢速设备，读它们绝不能放在中断里，而是放在优先级较低的任务中轮询或等信号量，避免阻塞高优先级的采样任务。

高频采集与慢速上报抢 CPU 的解法：靠 DMA 把「搬」和「算」拆开，DMA 负责搬、CPU 只负责算；靠队列把「采样速率」和「上报速率」解耦，队列要有明确深度和溢出策略——丢最老帧（保实时）还是丢最新帧（保完整），这个策略必须写进设计文档，量产时才知道该看哪个计数。多任务共享外设（比如一个 SPI 上挂 Flash 和传感器）要么用互斥量保护，要么更彻底：指定唯一持有者任务，其他人通过消息队列把请求交给它，从根上避免并发。用互斥量要用支持优先级继承的那种（FreeRTOS 的 mutex 有，普通二值信号量没有），否则会出现优先级反转。

偶发挂死要能收敛到可量产边界：先分类——是死循环卡在某个 while（等标志位）、还是 HardFault、还是看门狗复位、还是通信对端不响应导致任务饿死。证据链：复位原因寄存器分配位、HardFault 现场（CFSR + 压栈 PC/LR）、任务运行统计（谁长时间不让出 CPU）、堆最低水位、通信超时计数。定位到根因后不能只改代码，要把它变成可量产边界：给所有等标志位的循环加超时并降级、给通信加心跳与重连、把关键内存改成静态分配、在产测脚本里加异常注入和长期拷机（比如 72 小时循环断网），把「偶发」变成可复现的验收项。

逆境类问题用 STAR 结构答，别讲情绪：背景（项目节点、约束、你手上的资源）、任务（你具体扛了什么指标）、动作（你做的三件关键事，越具体越好，比如重新排优先级、把阻塞点拆出来先做、每天同步一次风险）、结果（量化，比如按期交付、缺陷率下降）。收尾讲一条可迁移的经验——比如「先排阻塞路径再排工作量」，比空喊「我抗压能力强」有说服力。

多任务冲突时先定唯一关键路径：把所有任务按「不做就会阻塞别人」排序，关键路径上的任务优先拿到人和时间；其余任务明确延后并通知需求方，而不是都答应下来。风险同步用固定节奏（每日站会 + 风险清单，每条带负责人和截止日），冲突升级要有明确的升级路径和时限，不能等到交付前一天才暴露。