★ FEATURED ARTICLE 简介面向车载电子与嵌入式硬件开发者的方案选型文档围绕智能后视镜的控制、联网与影像处理需求梳理 TI、东芝、展讯三条技术路线。内容涉及 TI CC2541 蓝牙低功耗控制、DRV8801/DRV8802 马达驱动、TPS1H100 除雾加热、LM2936 与 TPS55340 电源设计也提到展讯 SC7731 的 Android 车载后视镜功能及东芝图像处理方案。资源包仅含 1 个 docx 文件约 250KB便于集中查阅方案框图、系统功能、特性与场景说明。已有 514 人学习适合做后视镜项目预研、硬件架构比对或方案汇报时快速建立整体认识并据此整理选型要点与功能清单。1. 需求先摆正一块镜子背后是三条技术栈给一台老车加装后视镜用户真正想要的往往不是一块能刷视频的大屏而是三件小事锁车自动收镜、倒车自动下翻、雨雾天镜面能除雾。这几件事看着不起眼却分别落在机械执行、人机交互和电气驱动三个完全不同的领域任何一环掉链子整机体验就会崩。这套车载智能后视镜设计方案之所以值得单独拆开讲是因为它把 12V 电气环境、低功耗无线控制、安卓应用和影像处理硬塞进了同一个巴掌大的结构件里冲突点非常密集。这份资料里收录的三条路线无线 MCU 做执行器控制、四核应用处理器做整机、图像处理 SoC 做前方感知恰好对应上面三层。它适合两类人要交毕设或课设、需要一个完整模块划分和选型依据的学生以及做后装产品、想直接照着画原理图和写驱动的工程师。下面按“选型—通道—电源—避坑—验收”的顺序把整套东西铺开。2. 三条技术路线怎么选执行、应用、感知各归各位拿到资料的人第一反应通常是“这三家选哪一家”但把三套方案摊在桌面上看它们并不是互为竞品的关系而是同一台整机里三个不同层的实现。选型选错通常不是因为芯片不好而是因为把不同层的职责搞混了。2.1 三套参考方案的能力边界先把三套方案的能力边界列清楚后面所有设计决策都从这里推。路线主控关键器件主要职责明确做不到的事执行控制路线CC2541 蓝牙低功耗无线 MCU8051 内核DRV8801、DRV8802、TPS1H100、LM2936、TPS55340、LMV341镜面收合、上下左右调节、除雾加热、手机 App 直连跑不了操作系统撑不起导航、录像、语音应用处理路线SC7731Cortex-A7 四核 1.4GHz1GB DDR3 8GB eMMC 4.5、WiFi/BT/GPS/FM、500 万前摄 100 万倒车后摄Android 系统、云导航、前后双录、SOS、语音操控、停车监控马达闭环和待机功耗控制做不精细视觉感知路线TMPV7502XBG 图像处理芯片行人、移动物体侦测与辨识ADAS 前向预警、行人识别没有通信和显示能力必须由主控配合从这张表能看出一个反直觉的结论决定一台后视镜“能不能用”的往往不是安卓跑得多花哨而是最不起眼的执行控制那条线。原厂给的 BLE 参考设计里收合马达交给 DRV8801 这颗单通道 H 桥上下和左右两个自由度交给 DRV8802 这颗双通道 H 桥除雾加热丝的通断交给 TPS1H100 高边开关LMV341 做电流采样的信号调理LM2936 和 TPS55340 分别管控制域和功率域的供电。这套分工值得照抄原因是它把“弱电控制”和“强电执行”用器件边界彻底隔开了任何一路出问题都不会把 MCU 拖进复位。2.2 从 12V 电气环境倒推选型原厂方案里写着电瓶提供 10~24V 直流输入这六个字背后是一整套约束。10V 对应的是冷启动瞬间电瓶被起动机拉垮的工况24V 对应的是商用车平台两个边界合起来意味着所有前级器件都得按 40V 以上耐压选同时还要兼顾 -40℃ 到 85℃ 的工作区间。很多人在实验室用稳压电源 12V 调得好好的装车之后早上第一次打火就翻车问题基本都出在这一段。我一般按三条判据做取舍。控制域优先用 LDO 而不是开关电源CC2541 的峰值电流只有几十毫安LM2936 这类超低静态电流 LDO 在待机时不给整车暗电流添负担——停车监控类产品如果待机电流压不到 5mA 以内停两周就能把电瓶耗光这是血泪经验。功率域反过来一定要用开关电源TPS55340 把 10~24V 升到稳定的马达母线电压冷启动掉到 10V 时马达扭矩明显变软收合时间会从 1.2 秒拉长到 1.8 秒以上把母线稳住之后这个波动能压到 0.2 秒以内。加热和马达这类大电流负载一律走高边开关TPS1H100 自带电流检测输出除雾丝是断了还是短路了MCU 读一次 ADC 就能分辨继电器做不到这一点。2.3 组合式整机架构三层之间怎么连真要做一台完整产品我的做法是把三条路线拼起来而不是三选一。感知层的 TMPV7502XBG 只负责出目标框和预警结果通过串口或并口把结构化数据送上去应用层的 SC7731 跑 Android负责导航、双录、语音和微信侧的停车监控执行层的 CC2541 独立于安卓系统之外既接受手机 App 的直连指令也接受 SoC 转发过来的指令。这里有个必须提前定死的规则两条指令链路要有优先级仲裁。倒车下翻的优先级最高其次是用户 App 的直接操作最后才是 SoC 的场景联动。原因很实际安卓从挂倒挡到 Camera 出图要一到两秒如果下翻指令排在安卓后面用户看到的就是“挡挂完了镜子还在慢慢动”。让 CC2541 直接从倒车信号线上取一路 GPIO比什么都快。3. 蓝牙控制通道设计GATT 服务、指令帧与动作状态机执行层能不能做稳八成取决于通信协议定义得够不够“死”。这里的死不是说复杂而是每条指令的边界、超时、失败回滚都要有明确定义不能留给“应该没问题”。3.1 自定义 GATT 服务与指令帧格式不建议直接拿串口透传模块套一层 BLE透传的坑在于默认 MTU 只有 20 字节、并发写容易丢包而且没有回执App 发完就以为成功了。自己定义服务虽然多写几十行代码但换来的是可观测性。服务定义我用得比较顺手的一套是这样属性UUID长度权限用途控制服务0xFFF0——执行器控制主服务指令特征0xFFF16WriteApp 下发动作指令状态特征0xFFF24Notify上报执行状态、电流、故障码配置特征0xFFF38Read / Write收合时长、堵转阈值、除雾限时指令帧固定 6 字节结构如下偏移字段长度说明0SOF1固定 0xA5用于帧同步1CMD10x01 收合 / 0x02 展开 / 0x03 角度调节 / 0x04 除雾 / 0x05 读状态2LEN1负载长度0~23PAYLOADLEN参数角度用 100ms 为单位的定点数3LENCRC81多项式 0x07覆盖 CMD 到 PAYLOAD选 CRC8 而不是简单累加和是因为 BLE 链路上真正会出事的是单比特翻转和短突发错误累加和对这两类几乎没检出能力CRC8 能把漏检率压下去一个量级。角度参数用 100ms 定点数而不是浮点一方面 8051 上浮点开销大另一方面执行器本来就不需要 0.1ms 级的分辨率过度精确反而让协议变复杂。3.2 CC2541 端的帧解析与动作状态机CC2541 是 8051 内核资源紧张解析函数要写得足够短且任何异常帧都必须快速丢弃绝不能在中断里做重活。/* 指令解析与执行器状态机收到 GATT 写回调后调用 */ #define CMD_FOLD 0x01 #define CMD_UNFOLD 0x02 #define CMD_ADJUST 0x03 #define CMD_DEFROST 0x04 #define ACT_TIMEOUT_TICKS 30 /* 最长通电 3s100ms 一个 tick硬上限 */ #define CURRENT_STALL_MA 2500 /* 堵转阈值实测收合到位电流约 1.8A */ static uint8 act_ticks; /* 剩余超时计时 */ static uint8 moving; /* 0空闲 1动作中 */ static uint8 cur_cmd; void actuator_parse(uint8 *p, uint8 len) { uint8 cmd, plen; if (len 4 || p[0] ! 0xA5) return; /* 帧头不对静默丢弃 */ cmd p[1]; plen p[2]; if (len ! plen 4) return; /* 长度字段对不上 */ if (crc8(p[1], plen 2) ! p[3 plen]) { /* 校验失败上报故障码 */ report_status(ERR_CRC, 0); return; } if (moving cmd ! CMD_DEFROST) { /* 动作互斥除雾可并行 */ report_status(ERR_BUSY, cur_cmd); return; } switch (cmd) { case CMD_FOLD: motor_ramp(DRV8801, FOLD_DIR, 70, 120); /* 120ms 内占空比 0→70% */ act_ticks ACT_TIMEOUT_TICKS; moving 1; cur_cmd cmd; break; case CMD_ADJUST: motor_ramp(DRV8802, p[3], 55, 80); /* p[3] 第 0/1 位选轴第 2 位选方向 */ act_ticks ACT_TIMEOUT_TICKS; moving 1; cur_cmd cmd; break; case CMD_DEFROST: tps1h100_soft_start(50); /* 50ms 软启动斜坡压住冷态浪涌 */ act_ticks ACT_TIMEOUT_TICKS * 10; /* 除雾按 30s 限时 */ moving 1; cur_cmd cmd; break; default: report_status(ERR_CMD, cmd); } }这段代码里有两个参数值得单独说。CURRENT_STALL_MA不能照抄必须按你自己选的马达和减速箱实测方法是空载全程录一次电流曲线取到位前 200ms 的峰值再上浮 30%我做的这套里落在 2.5A 比较合适。ACT_TIMEOUT_TICKS是后悔药机械结构卡滞、霍尔信号失效这类故障在实验室里复现不出来装车之后一定会遇到靠固定延时兜底比靠电流检测更简单可靠两者同时存在才叫双保险。3.3 手机端下发、回执与超时兜底Android 端最容易翻车的地方在于writeCharacteristic返回 true 只代表数据进了本机蓝牙栈的发送队列跟对端有没有收到没有半点关系。所以我一般强制要求每条指令都有 Notify 回执。// 下发指令并等待回执超时则重试一次仍失败则回滚 UI 状态 private void sendCommand(byte[] frame, int retry) { if (!mCtrlChar.setValue(frame)) return; if (!mGatt.writeCharacteristic(mCtrlChar)) return; mHandler.postDelayed(() - { // 1.5s 内没收到 Notify 视为失败 if (!mAwaitingAck) return; if (retry 0) { sendCommand(frame, retry - 1); // 重试前必须重新建立连接或重写 CCCD } else { rollbackUiState(); // 镜面状态以最后一次回执为准 mAwaitingAck false; } }, 1500); }超时时间定在 1.5 秒不是拍的收合全程大约 1.2 秒加上 BLE 一个连接间隔 15~30ms 和安卓侧的调度抖动1.5 秒是既能覆盖正常动作、又不会让用户觉得“点了没反应”的折中值。重试前要重写一次 CCCD 描述符这是踩过的坑某些机型在连接参数更新后 Notify 会静默失效不重写描述符就再也收不到回执。4. 电源与马达驱动链路从 10~24V 输入到三路负载的落地电源部分是最容易被“先画个 LDO 试试”糊弄过去、也最容易在装车后集中爆发的地方。这一章把三级供电和三路负载的驱动细节摊开讲。4.1 电源树的四级划分供电轨器件输入输出负载关键参数前级防反接 PMOS TVS π 滤波10~24VVBAT全部TVS 钳位按 24V 平台选储能电容 470µF 起马达母线 VMTPS55340 升压10~24V16V / 3ADRV8801、DRV8802开关频率 600kHz效率约 90%控制域 VCCLM2936 LDO10~24V3.3V / 50mACC2541、LMV341静态电流典型 15µA决定整车暗电流加热路TPS1H100 高边开关VBAT直通加热丝除雾丝限流点设 8A 以上带电流检测输出前级的储能电容值得单独强调。原厂框图里只画了一个电源符号实际装机时点火瞬间 VBAT 会跌到 6~7V 并伴随几百毫秒的振荡如果前级只有几十微法LM2936 的输入会跟着塌CC2541 直接欠压复位表现就是“早上第一次打火镜子收合到一半停住App 显示断开”。470µF 是能明显改善这个现象的下限再配一级 LC 滤波压住马达换向产生的纹波。4.2 收合、调节、除雾三路负载的驱动差异DRV8801 驱动收合马达这类马达带减速箱启动瞬间电流能冲到堵转值的 1.5 倍所以必须做占空比软启动120ms 内从 0 爬到 70%PWM 频率压在 20kHz 以上避开可听频段否则晚上在地下车库收镜会有明显的啸叫。DRV8802 驱动上下和左右两个电机要注意的是两路不能同时启动母线电流会叠加轻则触发 TPS55340 限流导致动作卡顿重则把升压电路拉进保护。TPS1H100 驱动除雾加热丝这一路最容易被低估。加热丝的冷态电阻比热态低六到八倍也就是说开机瞬间的浪涌电流会是稳态的六倍以上一个 40W 的加热丝稳态不到 5A冷态瞬间能到 20A 以上。我的做法是用使能脚做 50ms 的软启动斜坡把占空比从 10% 线性拉到 100%同时把限流点按稳态的 1.8 倍设置既躲开冷态浪涌又能在真正短路时快速切断。4.3 上电时序与保护顺序时序错了前面所有的器件选型都白费。我固定按这个顺序走/* 上电初始化任何一步失败都停在当前状态并报故障不降级继续跑 */ void system_boot(void) { ldo_wait_stable(5); /* 等 3.3V 稳定5ms 足够 LM2936 建立 */ adc_sample_vbat(); /* 读一次电瓶电压冷启动可能只有 7V */ if (vbat_mv 9000) { delay_ms(300); /* 低于 9V 先等起动机工况过去再采样 */ adc_sample_vbat(); if (vbat_mv 9000) { report_status(ERR_LOW_VBAT, vbat_mv); return; /* 电压太低不使能马达避免把电瓶彻底拉垮 */ } } boost_enable(); /* 使能 TPS55340母线升到 16V */ delay_ms(50); /* 等母线建立这 50ms 不能省 */ motor_init(); /* 初始化 PWM 与方向脚全部置为惯性停止 */ tps1h100_init(); /* 高边开关先关断等指令再开 */ ble_start_advertising(); }这套顺序的核心思想是“宁可不动作也不能在异常电压下动作”。实测下来冷启动时强行收镜除了让电瓶雪上加霜还会因为母线电压不足导致 H 桥工作在半导通状态MOS 发热明显长期下来是隐性失效点。5. 避坑与排查五处最容易翻车的地方下面这五条都是装车之后才会暴露、实验室里基本测不出来的问题每条按现象、原因、解决写。5.1 电源与上电时序类第一处冷启动后视镜复位、蓝牙掉线。现象是低温早晨打火镜子收到一半停住App 显示连接断开重新上电又恢复正常。原因是点火瞬间 VBAT 跌到 6~7VLM2936 输入跟随塌陷导致输出跌破 CC2541 的欠压复位点而马达母线上还挂着感性负载的反灌。解决办法是前级储能电容加到 470µF 以上并串一级 LC同时把马达启动前的电压判断阈值定在 9V低于阈值延时 300ms 再采样两次都低就干脆不动。第二处一开除雾蓝牙就断。现象是除雾加热开启的瞬间手机连接中断重连后除雾还在正常工作。原因是加热丝几十瓦的电流和射频共用回流路径地弹让 BLE 的参考地抖动加上高边开关硬开通带来很大的 di/dt。解决办法是加热回路单点接地、回流走线远离天线至少 15mm同时给 TPS1H100 的使能做 50ms 软启动斜坡把浪涌摊平。5.2 无线链路与执行器类第三处安卓能连苹果连上三秒就断。现象很有辨识度同一台设备安卓正常iPhone 连接后立刻断开或者根本搜不到。原因基本是两个GATT 属性表里 0xFFF2 这个 Notify 特征缺了 CCCD 描述符或者连接参数超出了 iOS 的接受范围。解决办法是把连接间隔定在 15~30ms、slave latency 设 0、supervision timeout 设 4~6 秒并逐个检查每个 Notify 特征的 CCCD 是否完整——这一条几乎是 BLE 外设的必修课。第四处镜子到位了电机还在转或者嗡嗡响不停。现象是点收合之后镜面已经贴到底马达还在通电几秒后才停偶尔伴随异响。原因是状态机只靠固定延时判断到位没有电流兜底减速箱批次差异或者低温下阻力变大都会让实际到位时间偏移。解决办法是固定延时加堵转电流双重判定任一条件满足立即停止同时保留 3 秒最长通电保护做最后一道闸。5.3 影像与存储类第五处挂倒挡后一两秒才出图甚至黑屏。现象是倒车影像明显延迟用户体验极差。原因是倒车信号走的是安卓层轮询Camera 需要重新初始化和申请 buffers这一套流程在低端四核上要一到两秒。解决办法是把倒车检测信号直接引到 SoC 的 GPIO 中断让 Camera 常驻低码流预初始化中断触发后只做切流不做初始化后摄和倒车摄两路复用同一个 CSI 输入时切换要在驱动层完成不要放到应用层。6. 验收与答辩用一张测试表证明这套后视镜能过方案写完只是及格能不能交付看的是验收。答辩或者交付评审时评委和甲方最想听的不是“我用了什么芯片”而是“你怎么证明它在车上不会坏”。我一般把验收拆成可量化的六项每项都给判定方法和通过标准现场演示两项、其余给测试记录。验收项测试方法通过标准收合一致性常温、-20℃、70℃ 各 50 次收放记录耗时耗时波动 ≤ 0.3s无到位不停堵转保护收合过程中人为阻挡镜面2.5A 阈值内 200ms 内断电故障码正确上报除雾效能25℃ 环境镜面喷雾后开除雾热电偶贴镜背60s 内镜面区域温升 ≥ 15℃无限流触发待机暗电流整机进入停车监控待机串接电流表静置 10 分钟≤ 5mA超过就要回去查 LDO 和外设漏电冷启动可编程电源模拟 12V→6V→12V 跌落不复位、不丢连接或按设计延时后正常动作射频共存除雾开启状态下测 BLE 连接保持10 分钟内不掉线RSSI 波动 ≤ 6dB前两项现场演示价值最高尤其是堵转保护拿手挡一下镜面、看它 200ms 内停住并弹回故障提示比讲十分钟状态机设计有说服力。老化测试我习惯用一个脚本跑通宵把连接、下发、等待回执、记录耗时全串起来#!/bin/bash # 执行器老化500 次收放循环记录失败次数与耗时异常 ADDRAA:BB:CC:DD:EE:FF # 被测设备地址 HANDLE0x0025 # 0xFFF1 指令特征的句柄需先用 gatttool 探测确认 PASS0; FAIL0 for i in $(seq 1 500); do if gatttool -b $ADDR --char-write-req -a $HANDLE -n a5010101c3 /dev/null 21; then PASS$((PASS1)) else FAIL$((FAIL1)) echo 第 $i 次下发失败 /var/log/mirror_aging.log fi sleep 2 # 留出完整动作周期避免指令互斥被拒 done echo 通过 $PASS 次失败 $FAIL 次答辩时还有一个小技巧主动讲一个你踩过的坑比讲十个顺利的功能更让人信服。我一般会讲除雾干扰 BLE 那一段因为它是典型的“功能都对、体验全毁”能体现你真的把东西装到车上跑过而不是只在开发板上点过灯。从那以后我每次评审前都强制自己走一遍这张表哪怕时间再紧也不跳项因为跳过的那一项往往就是装车后第一个暴露的问题。希望这套结构能帮到你祝顺利。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
