卓驭嵌入式驱动二面面经（线上 40 分钟）

《面试题目》

通用问题

1. 自我介绍。
2. 讲一下实习情况。
3. 你对卓驭和自动驾驶行业的理解是什么？
4. 是否体验过自动驾驶车？
5. 项目与毕设讲解。
6. 你的职业规划是什么？
7. 你对首份工作的期待是什么？
8. 能否来实习？

技术题

9. I2C 的传感器地址如何处理？总线串扰怎么解决？单个器件故障会不会把总线拉死？I2C 占用几个 IO？
10. 数据采集用轮询还是中断？采样频率怎么定？DMA 搬运时机怎么把握？DMA 传输完成如何通知？环形缓冲区加 DMA 异步怎么实现？
11. FreeRTOS 原生多任务的情况下，你设计的并行架构解决了什么问题？
12. STM32 采集到传感器数据后，如何向上层主控板传数据？

《参考解析》

I2C 的地址、串扰与故障隔离。I2C 是两线（SCL、SDA）开漏总线，必须外接上拉电阻，任何时刻只占两个 IO；地址冲突是设计期就要解决的：同型号传感器的可选地址往往由 ADDR 引脚或寄存器配置决定，选型时要把挂在同一总线上的所有器件地址列表拉出来核对（7 位地址的高位是厂商段，低位可配），冲突就拆成两条总线或用 I2C 多路复用器（如 TCA9548A）分通道。串扰与信号完整性来自走线过长、上拉过弱、总线电容超标（规范上限约 400pF）以及时钟太快：做法是缩短走线、把上拉电阻按总线速率与容性负载重算（标准模式常用 4.7k、快速模式用 2.2k 左右）、必要时降速到 100kHz、远离电机与开关电源这类干扰源、并给关键线做串阻与滤波。单个器件故障会不会拉死整条总线，取决于故障形态：器件把 SDA 或 SCL 长期拉低（掉电、复位期间、状态机卡死）就会占住总线，导致主机等不到总线空闲；工程上的对策有三层——硬件上给每个从器件留电源使能脚或做热插拔保护，软件上加总线恢复序列（主机发 9 个时钟脉冲把从机移位寄存器打空，再补一个 STOP 条件），以及给每次传输设超时并在超时后重新初始化外设。此外要有从设备的超时看门狗与错误计数，连续失败的器件要标记为离线并上报，而不是让整条总线反复重试阻塞采集任务。

采集链路：轮询、中断、DMA 与环形缓冲。选轮询还是中断取决于采样率和数据量：低频（几 Hz 到几十 Hz）简单状态量用轮询最省事；高频或事件驱动的量必须用中断或 DMA，否则 CPU 会一直被占。采样频率不能凭感觉定，要由信号带宽推：按奈奎斯特至少是关心的最高频率的两倍，工程上常取 5 到 10 倍，还要考虑传感器自身 ODR 档位与后续滤波器的截止频率；频率定高了不仅浪费带宽，还会让中断过密、CPU 打满。DMA 的搬运时机有两种：外设触发式（定时器触发 ADC 转换，转换完成由 DMA 请求搬运，形成「定时器 → ADC → DMA」的确定性链路，抖动最小）和空闲搬运式（串口用 IDLE 中断配合 DMA 收整帧）。传输完成的通知机制是 DMA 的传输完成中断（TC）与半传输中断（HT）：TC 表示一整块搬完，HT 表示搬了半块，配合「乒乓缓冲」就可以做到一半在写、一半在读，读写指针永不冲突。环形缓冲区加 DMA 异步的实现要点：DMA 的写入指针由硬件推进，消费者用读指针追，用「已写位置 - 已读位置」判有效数据量，回绕处要么用双缓冲分段、要么用镜像空间（把缓冲区大小翻倍，写满一遍后 memcpy 把前半复制到后半）避免跨边界的连续读；生产者只写指针、消费者只读数据，用单生产者单消费者模型就能免锁，跨任务时再用信号量或任务通知唤醒消费者。坑在于：缓冲区的大小要按「最坏情况下消费者被阻塞的时间 × 采样率」留出余量，否则会静默丢数据；DMA 与 CPU 同时访问同一内存要看一致性（多核或带 D-Cache 的 MCU 要处理 cache 回写与失效）；半传输与全传输中断里不能做重活，只能置标志或发通知。

FreeRTOS 并行架构解决了什么问题。裸机前后台架构把采集、处理、通信全塞在一个大循环里，任何一个环节耗时（比如 Flash 写入、网络发送）都会拖慢其他环节，采样周期抖动不可控。改成 FreeRTOS 多任务后，按「数据流」拆任务：采集任务（高优先级、周期由 vTaskDelayUntil 保证确定性）、处理任务（做滤波、标定、特征提取）、通信任务（打包上报）、监控与日志任务（低优先级）；任务之间用队列或流缓冲传数据，用二值信号量或任务通知做中断到任务的同步，用互斥量保护共享外设（同一 I2C 总线被多个任务访问时必须加锁，否则会出现交错传输）。真正的收益是解耦与优先级可调度：高优先级的采集不会被通信阻塞拖累，通信任务可以阻塞等待而不空转 CPU。要注意的坑是优先级反转（互斥量要开优先级继承）、队列深度不足导致的丢包策略（是覆盖旧数据还是丢新数据，要显式定义）、以及堆栈分配过小导致的高频溢出，通常配合 uxTaskGetStackHighWaterMark 与运行时统计来调。

STM32 向上层主控板传数据。选择取决于带宽、距离与实时性：板内或短距离高带宽用 SPI（可到几十 Mbps，需片选与主从约定）、CAN 或 CAN FD（车规首选，差分抗干扰、多节点、带仲裁与错误帧机制）、UART（简单可靠但速率有限，适合低频状态量）、车载以太网（高带宽、可跑 SOME/IP 之类协议）。协议设计上要固定帧格式（帧头、长度、序号、时间戳、载荷、CRC、帧尾），加序号与确认重传处理丢帧，加时间戳让主控能做多传感器对齐，采集侧要在发送前做一次量纲与字节序的统一（大端小端、定点缩放）并写进接口文档。工程上还需考虑发送阻塞时的降级——用环形缓冲加 DMA 发送保证采集侧不被网络拖住，以及断连时的重连与数据缓存策略。