简介：本资源是一套完整的物联网毕业设计项目方案，面向嵌入式开发初学者与高校电子/自动化专业学生，聚焦智能小车多模态控制与跨平台图像传输实践。项目实现STM32主控小车的自动避障（三路超声波）与手动遥控（Android APP直连WiFi），并集成ESP32-CAM完成实时图像采集，通过CAN总线协同传输至STM32端，最终在Android端显示——完整覆盖感知、决策、执行与人机交互全链路。压缩包含297个文件，以C源码（45个.c）、头文件（47个.h）、编译中间文件（57个.d/54个.o）及Keil工程配置（.uvprojx/.uvoptx/.axf）为主，辅以APK安装包、调试脚本（bat）、原理图PDF和实操演示MP4，整体104.12MB，结构分层清晰，便于模块化学习与移植。已有1948人学习下载，提供可直接烧录的hex固件、APP源码级调试支持及典型通信协议注释，是理解嵌入式多MCU协同、WiFi图像回传与Android端联调的优质实战范例。
1. 这不是普通遥控小车：ESP32-CAN 图像回传 + STM32 多模避障 + Android 实时显示，三端协同才是毕业设计的硬核分水岭
很多同学做智能小车毕设，停在“蓝牙遥控+超声波避障”就交差了。但真正拉开差距的，是能否把图像采集、实时通信、多模控制、嵌入式显示这四件事在资源受限的硬件上闭环跑通。本项目用 ESP32 做图像采集与 WiFi 图传节点，STM32F103C8T6（Blue Pill）作为主控调度 CAN 总线避障、电机驱动和模式切换，Android 端 APP 不仅能手动遥控，还能接收并解码 H.264 流（或 JPEG 帧序列），实时渲染到 SurfaceView。关键在于——它没用任何云中转，所有通信走局域网直连；CAN 总线不是摆设，而是连接三个超声波模块的物理层，避免 I²C 或 UART 的地址冲突与轮询延迟；APP 内置轻量级 RTSP 客户端（非 VLC 全量库），启动延迟低于 800ms。适合需要展示完整嵌入式系统链路、有图像处理基础、且对实时性有明确指标要求的本科毕设场景。
2. 硬件架构与通信协议选型：为什么必须用 ESP32-CAN 而非 ESP32-WiFi 单节点？
2.1 为什么拆成 ESP32 + STM32 双 MCU？单片机性能边界决定分工逻辑
STM32F103C8T6 主频 72MHz，Flash 64KB，SRAM 20KB。若强行让其同时处理：
- 3 路超声波 TOF 计算（每路需定时器捕获高电平宽度）
- CAN 总线收发（需配置 CAN 波特率、过滤器、中断优先级）
- 电机 PID 控制（双路 PWM 输出 + 编码器反馈采样）
- JPEG 解码（哪怕只做 YUV→RGB 转换，也需至少 128KB RAM）
——内存直接溢出，FreeRTOS 都难调度。
而 ESP32-WROOM-32 具备双核 Xtensa LX6（主频 240MHz）、4MB Flash、520KB SRAM，且原生支持 WiFi + SDIO + JPEG 加速器（通过esp_camera库调用）。因此分工明确：
- ESP32：专注图像采集（OV2640 模组）、JPEG 压缩（Q=10~15 平衡画质与带宽）、WiFi TCP/UDP 流式发送（非 HTTP 上传）
- STM32：专注实时控制（CAN 总线管理超声波、PWM 电机驱动、按键状态机）、模式仲裁（自动/手动切换逻辑）、CAN-to-Serial 桥接（向 ESP32 转发控制指令）
提示：ESP32 的 “CAN” 并非指其自带 CAN 控制器（它没有），而是指其通过 GPIO 模拟 CAN 收发器接口（如 SN65HVD230）后接入 CAN 总线，实现与 STM32 的 CAN 通信。项目标题中的 “ESP32-CAN” 是工程简写，实际为 “ESP32 via CAN transceiver”。
2.2 CAN 总线在避障系统中的不可替代性：抗干扰、确定性、多节点扩展
三个超声波模块（HC-SR04 或 JSN-SR04T）若全接 STM32 的 GPIO，需占用 6 个引脚（Trig+Echo ×3），且 Echo 信号为脉冲宽度调制，必须用输入捕获（IC）功能。STM32F103 仅有 4 路高级定时器 IC 输入，无法满足。改用 I²C 接口的超声波（如 MaxBotix MB1043）虽节省引脚，但 I²C 在电机启停瞬间易受电磁干扰导致总线锁死。
CAN 总线方案则彻底规避此问题：
- 每个超声波模块配一片 STM32F030F4P6（成本＜¥2），运行裸机固件，将测距结果封装为 CAN 标准帧（ID=0x101 表示左，0x102 中，0x103 右），数据段为 2 字节距离值（单位 mm）
- STM32F103 主控配置 CAN1，波特率 500kbps（满足 10m 内测距更新率 ≥20Hz），启用 FIFO0 接收，设置 3 个验收滤波器匹配 ID=0x101/0x102/0x103
- 关键优势：CAN 差分信号抗共模干扰能力比 UART 强 20dB；帧结构自带 CRC 校验；总线仲裁机制确保紧急避障指令（如 ID=0x200 的急停帧）可抢占低优先级数据帧
2.2.1 STM32 CAN 初始化核心代码（Keil MDK）
// stm32f10x_can.c 中关键片段 void CAN1_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; CAN_InitTypeDef CAN_InitStructure; CAN_FilterInitTypeDef CAN_FilterInitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_CAN1, ENABLE); // PA11(CAN_RX), PA12(CAN_TX) 复用推挽输出 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_11 | GPIO_Pin_12; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); CAN_InitStructure.CAN_TTCM = DISABLE; CAN_InitStructure.CAN_ABOM = DISABLE; CAN_InitStructure.CAN_AWUM = DISABLE; CAN_InitStructure.CAN_NART = DISABLE; // 禁止自动重传，避障数据宁丢勿卡 CAN_InitStructure.CAN_RFLM = DISABLE; CAN_InitStructure.CAN_TXFP = ENABLE; // 发送优先级由报文ID决定 CAN_InitStructure.CAN_Mode = CAN_Mode_Normal; CAN_InitStructure.CAN_SJW = CAN_SJW_1tq; CAN_InitStructure.CAN_BS1 = CAN_BS1_8tq; // BS1=8TQ, BS2=7TQ → 总 16TQ CAN_InitStructure.CAN_BS2 = CAN_BS2_7tq; CAN_InitStructure.CAN_Prescaler = 6; // 72MHz / (1+8+7) / 6 = 500kbps CAN_Init(CAN1, &CAN_InitStructure); // 配置3个滤波器：只接收ID=0x101/0x102/0x103的标准帧 CAN_FilterInitStructure.CAN_FilterNumber = 0; CAN_FilterInitStructure.CAN_FilterMode = CAN_FilterMode_IdMask; CAN_FilterInitStructure.CAN_FilterScale = CAN_FilterScale_32bit; CAN_FilterInitStructure.CAN_FilterIdHigh = 0x101 << 5; // 标准帧ID左移5位 CAN_FilterInitStructure.CAN_FilterIdLow = 0x0000; CAN_FilterInitStructure.CAN_FilterMaskIdHigh = 0x7FF << 5; // 掩码全1，精确匹配 CAN_FilterInitStructure.CAN_FilterMaskIdLow = 0x0000; CAN_FilterInitStructure.CAN_FilterFIFOAssignment = CAN_Filter_FIFO0; CAN_FilterInitStructure.CAN_FilterActivation = ENABLE; CAN_FilterInit(&CAN_FilterInitStructure); // 启用CAN中断（仅接收中断） NVIC_InitTypeDef NVIC_InitStructure; NVIC_InitStructure.NVIC_IRQChannel = USB_LP_CAN1_RX0_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 0; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); CAN_ITConfig(CAN1, CAN_IT_FMP0, ENABLE); // FIFO0消息挂起中断 }参数说明：
CAN_Prescaler=6：预分频系数，决定时间量子（TQ）长度。72MHz 主频下，1 TQ = 6/72MHz ≈ 83.3nsBS1=8tq, BS2=7tq：传播段+相位缓冲段1共 8TQ，相位缓冲段2为 7TQ，同步跳转宽度（SJW）为 1TQ，总位时间=16TQ → 位速率=72MHz/(6×16)=750kbps？错！正确计算：位速率 = APB1_CLK / (Prescaler × (1 + BS1 + BS2)) = 36MHz / (6 × 16) = 375kbps。但实测 500kbps 更稳定，故常将 APB1 分频设为 36MHz（RCC_CFGR.PPRE1=0b100），再取Prescaler=3→ 36MHz/(3×16)=750kbps，最终选用Prescaler=4得 450kbps，兼顾容错与速度。项目中Prescaler=6对应的是 APB1=36MHz 下的 375kbps，属保守配置，适合长线布线（＞1m）。
2.3 图像传输协议选型：为什么不用 HTTP 或 MQTT，而用自定义 TCP 流？
Android 端需低延迟（＜1s）显示图像，HTTP 协议头开销大（约 200B/请求），且每次 GET 需建立 TCP 连接（三次握手+慢启动），实测首帧延迟达 1.2s。MQTT 虽轻量，但 QoS=1 会引入 ACK 重传，QoS=0 则丢帧不可控。
本项目采用TCP 长连接 + 自定义帧头：
- ESP32 启动后创建 TCP Server（端口 8080），等待 STM32 或 Android 连接
- 每帧 JPEG 数据前加 8 字节帧头：
[0xAA, 0x55, len_high, len_low, seq_num, 0x00, 0x00, 0x00] len为 JPEG 数据长度（≤65535B），seq_num为递增序列号（用于 Android 端丢帧检测）- STM32 作为中继：当 Android APP 连接到 STM32 的 WiFi AP（ESP32 创建的 SoftAP）后，STM32 将 TCP 数据透传给 ESP32，并转发 ESP32 的图像流至 Android
该方案实测平均帧率 12fps（Q=12，分辨率 320×240），首帧延迟 320ms（含 TCP 握手与首帧发送）。
3. STM32 固件开发：从 CAN 避障到模式切换的状态机实现
3.1 自动避障状态机：基于 CAN 数据的实时决策逻辑
自动模式下，小车需根据三路超声波距离动态调整方向。常见误区是写成“if-else 距离判断”，但实际需考虑：
- 距离抖动（超声波测量误差 ±3cm）
- 转向滞后（电机响应需 100ms）
- 路径连续性（避免左右摇摆）
本项目采用三区间模糊决策 + PID 角度补偿：
| 左距 L | 中距 M | 右距 R | 动作 |
|---|---|---|---|
| L>50 && M>50 && R>50 | 全距 >50cm | 直行加速（PWM=80%） | |
| L<30 | R<30 | 任一侧 <30cm | |
| 30≤L,R≤50 && M<30 | 前方近障 | 后退 500ms + 左转 90° |
关键优化：对原始 CAN 数据做滑动窗口中值滤波（窗口=5），消除单次异常脉冲。
3.1.1 CAN 接收中断服务函数（ISR）与数据解析
// usb_lp_can1_rx0_irq.c 中 extern uint16_t g_ultra_dist[3]; // 全局数组：g_ultra_dist[0]=左, [1]=中, [2]=右 uint16_t ultra_raw[3] = {0}; uint8_t ultra_cnt[3] = {0}; // 每路计数器，用于中值滤波 void USB_LP_CAN1_RX0_IRQHandler(void) { CanRxMsg RxMessage; uint8_t i; CAN_Receive(CAN1, CAN_FIFO0, &RxMessage); switch(RxMessage.StdId) { case 0x101: i = 0; break; // 左 case 0x102: i = 1; break; // 中 case 0x103: i = 2; break; // 右 default: return; } // 提取2字节距离值（大端序） uint16_t dist = ((uint16_t)RxMessage.Data[0] << 8) | RxMessage.Data[1]; // 滑动窗口中值滤波：存入环形缓冲区 ultra_raw[i] = dist; if (++ultra_cnt[i] > 5) ultra_cnt[i] = 0; // 简化中值：取最近5次的中间值（排序开销大，改用冒泡3轮） uint16_t buf[5]; for(uint8_t j=0; j<5; j++) { buf[j] = ultra_raw[(i*5 + j) % 5]; // 伪环形 } // 冒泡3轮得中值（省略完整排序） for(uint8_t j=0; j<3; j++) { for(uint8_t k=0; k<4-j; k++) { if(buf[k] > buf[k+1]) { uint16_t t = buf[k]; buf[k] = buf[k+1]; buf[k+1] = t; } } } g_ultra_dist[i] = buf[2]; // 第3个即中值 }逻辑说明：
RxMessage.Data[0]和RxMessage.Data[1]构成 16 位距离值，高位在前（标准 CAN 数据字节序）ultra_raw[i]存储原始值，ultra_cnt[i]作为索引指针，实现 5 元素环形缓冲区- 冒泡 3 轮即可使中值浮到
buf[2]位置（5 元素排序只需 3 轮），比完整快排节省 70% CPU 时间
3.2 模式切换与按键消抖：硬件去抖 + 软件状态机双保险
小车底部有 1 个物理按键（KEY_UP），短按切换自动/手动模式，长按（＞2s）进入配网模式（重置 WiFi SSID）。硬件上已加 RC 滤波（10kΩ+100nF），但软件仍需防误触发。
采用“边沿触发 + 时间戳”状态机：
- 检测到 KEY_UP 下降沿 → 记录
tick_start = SysTick->VAL - 持续检测按键状态，若 20ms 后仍为低电平 → 确认为有效按下
- 若松手时
tick_end - tick_start > 2000ms→ 长按事件 - 否则为短按，切换
g_mode = (g_mode == MODE_AUTO) ? MODE_MANUAL : MODE_AUTO
3.2.1 按键扫描任务（FreeRTOS Task）
// task_keyscan.c void vKeyScanTask(void *pvParameters) { TickType_t xLastWakeTime; const TickType_t xFrequency = 10 / portTICK_PERIOD_MS; // 10ms 扫描周期 xLastWakeTime = xTaskGetTickCount(); while(1) { static uint8_t key_state = KEY_RELEASED; static uint32_t press_start = 0; uint8_t key_val = GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0); // PA0 接按键 switch(key_state) { case KEY_RELEASED: if(key_val == Bit_RESET) { // 按下（低电平有效） press_start = HAL_GetTick(); key_state = KEY_PRESSING; } break; case KEY_PRESSING: if(key_val == Bit_SET) { // 松手 uint32_t press_time = HAL_GetTick() - press_start; if(press_time > 2000) { // 长按：进入配网模式 wifi_enter_smartconfig(); } else if(press_time > 20) { // 短按：切换模式 g_mode = (g_mode == MODE_AUTO) ? MODE_MANUAL : MODE_AUTO; OLED_ShowString(0, 2, g_mode==MODE_AUTO?"AUTO":"MANUAL", 16); } key_state = KEY_RELEASED; } break; } vTaskDelayUntil(&xLastWakeTime, xFrequency); } }参数说明：
xFrequency = 10 / portTICK_PERIOD_MS：将 10ms 转为 tick 数，适配不同 SysTick 配置HAL_GetTick()返回毫秒级时间戳，精度足够模式切换（无需微秒级）OLED_ShowString为 SSD1306 驱动函数，实时显示当前模式，方便调试
3.3 STM32 与 ESP32 的串口透传协议：AT 指令精简版
STM32 通过 UART2（PA2/PA3）与 ESP32 通信，不使用完整 AT 指令集，仅定义 3 条指令：
AT+MODE=0→ ESP32 切为 Station 模式，连接指定 APAT+MODE=1→ ESP32 切为 SoftAP 模式，SSID=Car_AP_XXXX（XXXX 为芯片 MAC 后 4 字节）AT+IMG=ON→ ESP32 启动摄像头并开始 TCP 发送
STM32 发送指令后，需等待 ESP32 返回OK\r\n或ERROR\r\n，超时（500ms）则重试。
3.3.1 UART2 初始化与指令发送函数
// stm32f10x_usart.c void USART2_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; USART_InitTypeDef USART_InitStructure; RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); RCC_APB1PeriphClockCmd(RCC_APB1Periph_USART2, ENABLE); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_2; // PA2 TX GPIO_InitStructure.GPIO_Mode = GPIO_Mode_AF_PP; GPIO_InitStructure.GPIO_Speed = GPIO_Speed_50MHz; GPIO_Init(GPIOA, &GPIO_InitStructure); GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3; // PA3 RX GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &GPIO_InitStructure); USART_InitStructure.USART_BaudRate = 115200; USART_InitStructure.USART_WordLength = USART_WordLength_8b; USART_InitStructure.USART_StopBits = USART_StopBits_1; USART_InitStructure.USART_Parity = USART_Parity_No; USART_InitStructure.USART_HardwareFlowControl = USART_HardwareFlowControl_None; USART_InitStructure.USART_Mode = USART_Mode_Rx | USART_Mode_Tx; USART_Init(USART2, &USART_InitStructure); USART_Cmd(USART2, ENABLE); } // 发送AT指令并等待响应 uint8_t Send_AT_Cmd(char *cmd, char *expect, uint16_t timeout_ms) { uint8_t rx_buf[64]; uint16_t len = strlen(cmd); uint32_t start = HAL_GetTick(); USART_SendData(USART2, (uint16_t)*cmd++); while(--len) { while(USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET); USART_SendData(USART2, (uint16_t)*cmd++); } while(USART_GetFlagStatus(USART2, USART_FLAG_TC) == RESET); // 等待 expect 响应 uint16_t rx_len = 0; while(HAL_GetTick() - start < timeout_ms) { if(USART_GetFlagStatus(USART2, USART_FLAG_RXNE) != RESET) { rx_buf[rx_len++] = (uint8_t)USART_ReceiveData(USART2); if(rx_len >= sizeof(rx_buf)-1) break; // 检查是否收到 expect 字符串 if(rx_len >= strlen(expect) && memcmp(&rx_buf[rx_len-strlen(expect)], expect, strlen(expect)) == 0) { return 1; // 成功 } } } return 0; // 超时 }关键点：
USART_SendData发送单字节，需循环发送整个字符串USART_FLAG_TC（Transmit Complete）标志确保每字节发送完毕再发下一个，避免乱码- 接收响应时采用滑动窗口匹配（
memcmp检查末尾子串），而非逐字符比对，提升鲁棒性
4. Android APP 开发：从 APK 解包到 SurfaceView 实时渲染
4.1 APK 逆向分析：定位图像接收与解码核心模块
提供的app-debug(6).apk可用apktool d app-debug(6).apk反编译。关键发现：
smali/com/example/carcontrol/VideoActivity.smali：主视频界面，继承AppCompatActivitysmali/com/example/carcontrol/rtsp/RtspClient.smali：自研 RTSP 客户端，未使用 ExoPlayer，而是基于java.net.Socket直连 ESP32 的 TCP Serversmali/com/example/carcontrol/decoder/JpegDecoder.smali：JNI 调用libjpeg.so，但实际被注释掉，改用纯 JavaBitmapFactory.decodeByteArray()
这意味着：APP 接收的是原始 JPEG 字节流，无 RTSP 协议解析开销，但需自行处理帧头校验。
4.1.1 Java 层 TCP 接收线程（简化版）
// VideoActivity.java private void startVideoStream() { new Thread(() -> { try { Socket socket = new Socket("192.168.4.1", 8080); // ESP32 SoftAP IP DataInputStream dis = new DataInputStream(socket.getInputStream()); byte[] frameHeader = new byte[8]; byte[] jpegBuffer = new byte[65535]; while (!Thread.currentThread().isInterrupted()) { // 读取8字节帧头 int headerLen = dis.read(frameHeader); if (headerLen != 8 || frameHeader[0] != (byte)0xAA || frameHeader[1] != (byte)0x55) { continue; // 帧头错误，跳过 } // 解析长度（大端序） int jpegLen = ((frameHeader[2] & 0xFF) << 8) | (frameHeader[3] & 0xFF); if (jpegLen <= 0 || jpegLen > 65535) continue; // 读取JPEG数据 int readLen = 0; while (readLen < jpegLen) { int ret = dis.read(jpegBuffer, readLen, jpegLen - readLen); if (ret <= 0) break; readLen += ret; } if (readLen == jpegLen) { // 解码并更新UI（需切回主线程） Bitmap bitmap = BitmapFactory.decodeByteArray(jpegBuffer, 0, jpegLen); runOnUiThread(() -> { mSurfaceView.getHolder().getSurface().lockCanvas(); // 绘制bitmap到Surface mSurfaceView.drawBitmap(bitmap); bitmap.recycle(); }); } } } catch (Exception e) { Log.e("Video", "Stream error", e); } }).start(); }逻辑说明：
Socket直连 ESP32 的 192.168.4.1（SoftAP 默认网关），避免 Android 端 WiFi 切换导致断连frameHeader[0]和[1]校验魔数0xAA55，过滤非法数据BitmapFactory.decodeByteArray在主线程调用会阻塞 UI，实际项目中应使用AsyncTask或HandlerThread异步解码，此处为简化演示
4.2 SurfaceView 渲染优化：避免 OOM 与卡顿
BitmapFactory.decodeByteArray直接解码 320×240 JPEG（约 8KB）看似安全，但 Android 系统对 Bitmap 内存单独计费（Heap 外），连续分配易触发OutOfMemoryError。
必须添加的防护措施：
- 设置
BitmapFactory.Options.inSampleSize = 2，解码为 160×120，内存减半 - 复用
Bitmap对象：声明private Bitmap mReusableBitmap;，每次decodeByteArray前调用Bitmap.createBitmap(160,120,Bitmap.Config.ARGB_8888)并传入options.inBitmap = mReusableBitmap - SurfaceView 双缓冲：
mSurfaceHolder.lockCanvas(new Rect(0,0,160,120))指定绘制区域，避免全屏刷新
4.2.1 安全解码函数（Kotlin）
private fun safeDecodeJpeg(data: ByteArray, length: Int): Bitmap? { val options = BitmapFactory.Options() options.inJustDecodeBounds = true BitmapFactory.decodeByteArray(data, 0, length, options) // 计算采样率：目标尺寸160x120 options.inSampleSize = calculateInSampleSize(options, 160, 120) options.inJustDecodeBounds = false options.inMutable = true options.inPreferredConfig = Bitmap.Config.ARGB_8888 // 复用Bitmap if (mReusableBitmap == null || mReusableBitmap.width != 160 || mReusableBitmap.height != 120) { mReusableBitmap = Bitmap.createBitmap(160, 120, Bitmap.Config.ARGB_8888) } options.inBitmap = mReusableBitmap return try { BitmapFactory.decodeByteArray(data, 0, length, options) } catch (e: Exception) { Log.w("Video", "Decode failed", e) null } } private fun calculateInSampleSize(options: BitmapFactory.Options, reqWidth: Int, reqHeight: Int): Int { val height = options.outHeight val width = options.outWidth var inSampleSize = 1 if (height > reqHeight || width > reqWidth) { val halfHeight = height / 2 val halfWidth = width / 2 while (halfHeight / inSampleSize >= reqHeight && halfWidth / inSampleSize >= reqWidth) { inSampleSize *= 2 } } return inSampleSize }参数说明：
inSampleSize=2表示解码时每 2×2 像素合并为 1 像素，输出尺寸减半，内存占用降至 1/4inBitmap复用机制要求新 Bitmap 尺寸、格式与旧 Bitmap 严格一致，否则抛IllegalArgumentException
5. 调试与排错实战：从 “no STM32 target found” 到图像卡顿的根因定位
5.1 Keil 下载失败：“error: no STM32 target found!” 的 5 类真实原因与验证命令
该错误在 Keil MDK 中高频出现，绝非单纯“ST-Link 接触不良”。需按优先级逐项排查：
| 排查项 | 验证方法 | 解决方案 |
|---|---|---|
| SWD 引脚被复用 | 用万用表测 PA13(SWDIO)/PA14(SWCLK) 是否对地短路 | 检查stm32f10x_rcc.c中RCC_APB2PeriphClockCmd(RCC_APB2Periph_AFIO, ENABLE)是否调用；确认GPIO_PinRemapConfig(GPIO_Remap_SWJ_JTAGDisable, ENABLE)未禁用 SWD |
| BOOT0 引脚电平错误 | 测量 BOOT0 对地电压：下载时需为 1（3.3V），运行时为 0 | 确保 BOOT0 上拉电阻（10kΩ）完好；下载前短接 BOOT0-GND，下载后断开 |
| ST-Link 固件过旧 | Keil → Project → Options → Debug → Settings → Trace → 查看 ST-Link 版本 | 用 ST-Link Utility 升级固件至 V3.J27.S7（2023 年最新） |
| 目标板供电不足 | 用万用表测 VDD 引脚：必须 ≥3.0V（ST-Link 仅提供 3.3V@50mA） | 改用外部 3.3V 电源供电，ST-Link 仅接 SWD 信号线（不供电） |
| Keil Pack 版本不匹配 | Project → Manage → Pack Installer → 检查 STM32F1xx_DFP 是否为最新（v2.3.0+） | 更新 DFP 包，旧版不支持 F103C8T6 的 Flash 算法 |
注意：若使用
keilkill.bat（项目中提供），它会强制关闭 Keil 进程并清理临时文件，但无法解决硬件连接问题。执行前务必先验证上述五项。
5.2 图像卡顿根因分析：从网络层到渲染层的链路追踪
Android 端图像卡顿（＜5fps）常见于以下环节，需逐层抓包验证：
| 层级 | 检测工具 | 正常指标 | 异常表现与修复 |
|---|---|---|---|
| ESP32 发送层 | 串口监视器（115200bps）打印printf("Send %d bytes\n", len) | 每 83ms（12fps）打印一次 | 若打印间隔＞200ms → 检查camera_fb_t *fb = esp_camera_fb_get()是否阻塞，增大CAMERA_CONFIG_T.frame_size = FRAMESIZE_QVGA的 buffer 数量（fb_count=2→fb_count=4） |
| WiFi 传输层 | Androidadb shell ping 192.168.4.1 | 丢包率=0%，延迟＜10ms | 若丢包＞5% → ESP32 SoftAP 信道拥堵，用AT+CWMODE=2切为 Station 模式，让小车连路由器，APP 与小车同网段 |
| Android 接收层 | `adb logcat | grep "Read len"` | 每秒接收 10~12 次Read len=xxxx |
| 解码渲染层 | Android Profiler → CPU → 录制 5s | BitmapFactory.decodeByteArray占用 ＜80ms/帧 | 若＞150ms → 启用inSampleSize=2并复用 Bitmap（见 4.2.1） |
5.2.1 快速验证 ESP32 图像发送速率（Python 脚本）
# test_esp32_stream.py import socket import time sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM) sock.connect(("192.168.4.1", 8080)) start = time.time() frame_count = 0 try: while frame_count < 60: # 测60帧 header = sock.recv(8) if len(header) < 8 or header[0] != 0xAA or header[1] != 0x55: continue jpeg_len = (header[2] << 8) | header[3] jpeg_data = sock.recv(jpeg_len) if len(jpeg_data) == jpeg_len: frame_count += 1 print(f"Frame {frame_count}, size={jpeg_len}B, avg_fps={frame_count/(time.time()-start):.1f}") except Exception as e: print("Error:", e) finally: sock.close()执行效果：
- 若输出
avg_fps=12.3→ 问题在 Android 端 - 若
avg_fps=3.1→ 问题在 ESP32 端，检查camera_config_t.jpeg_quality是否设为 5（过高压缩）或xTaskCreate任务栈不足
5.3 CAN 通信丢帧：用逻辑分析仪抓取波形的关键参数
当 STM32 无法稳定接收超声波数据
本文还有配套的精品资源，点击获取
