1. 从硬件收尾到软件闭环为什么这个完结篇值得单独拿出来讲做嵌入式项目有个很典型的现象硬件调通那一刻的兴奋感是最强的电机转起来了、传感器能识别黑线了、小车能歪歪扭扭跑完一圈了然后很多人就停在这里了。但真正让一个循迹小车项目从能跑的Demo变成拿得出手的作品往往差的是最后那一层——无线控制与状态回传。这个完结篇要聊的就是这层东西用Android手机通过经典蓝牙Bluetooth Classic也就是常说的SPP串口透传去控制STM32小车同时接收小车回传的传感器数据。先说清楚这个内容适合谁看。如果你已经有一辆能自己循迹的STM32小车想给它加一个手机遥控的手动挡或者你正在做一个需要手机和单片机短距离通信的项目纠结用经典蓝牙还是低功耗蓝牙再或者你只是想搞明白Android端蓝牙开发那一堆权限、配对、Socket到底怎么串起来——那这篇就是写给你的。它不假设你是Android专家但假设你能看懂Java或Kotlin的基本语法也大概知道STM32的串口怎么用。我先把结论摆前面省得你走弯路在手机控制小车这个场景下经典蓝牙的SPP协议几乎是性价比最高的选择。原因很简单它本质上就是把蓝牙当成一根无线的串口线STM32这边你甚至不需要写任何蓝牙协议栈的代码只要把原来接USB转TTL的那两个引脚接到蓝牙模块上就行代码层面和串口通信一模一样。相比之下低功耗蓝牙BLE虽然省电、在iOS上支持更好但它的通信模型是基于GATT的服务-特征值你要自己定义服务UUID、特征值UUID、处理分包和MTU协商开发量至少翻倍。对于一辆靠电池跑、对功耗没那么敏感、又主要用Android手机控制的小车来说经典蓝牙是更务实的选择。这个完结篇的价值不在于教你点一个按钮发一个字节这么简单而在于把整条链路讲透从STM32端的串口中断接收与协议解析到蓝牙模块的AT配置与波特率匹配再到Android端的权限适配、配对流程、后台线程读写、UI状态更新最后到两端如何约定一套简单但不容易出错的通信协议。中间我会穿插大量实际踩过的坑比如为什么你的App在Android 12上扫描不到设备、为什么发指令小车偶尔卡死、为什么接收数据会粘包。这些东西文档里通常不会写但实际做的时候一个都躲不掉。2. 整体方案设计为什么是经典蓝牙自定义协议这套组合2.1 三种无线方案对比与选型逻辑在动手之前先把可选方案摆出来对比一下这样你后面做的每个决定都有依据。手机控制小车常见的无线方案无非三种经典蓝牙、低功耗蓝牙、WiFi比如ESP8266/ESP32做AP或连路由器。我把它们放在一张表里对比你可以对着自己的需求看。对比维度经典蓝牙 SPP低功耗蓝牙 BLEWiFiESP系列通信模型串口透传字节流GATT服务/特征值TCP/UDP Socket单片机侧开发量极低等同串口中等需协议栈中等需网络协议栈Android侧开发量低Socket读写中高需处理回调链低标准Socket功耗较高极低高传输距离约10米约10米约30米视环境传输速率约1-2Mbps较低高iOS支持需MFi认证基本不可用原生支持好支持好配对体验需手动配对一次无需配对需连WiFi看完这张表选型逻辑就很清楚了。如果你的控制端只有Android且希望单片机代码改动最小经典蓝牙是首选。如果你需要兼容iOS或者对功耗极其敏感比如小车靠纽扣电池跑几个月那必须上BLE。如果你要做图传、需要大带宽那WiFi更合适。这里有个很多人忽略的点经典蓝牙的配对是一次性的。第一次手机和蓝牙模块配对成功后之后只要模块上电、手机蓝牙开着系统层面会自动重连你的App只需要去已配对设备列表里找到它、建立Socket连接就行不需要每次都走扫描流程。这个特性让用户体验好很多也是我推荐经典蓝牙的重要原因。2.2 通信协议的设计别小看这几行约定方案定了接下来是最容易被新手忽略、但后期最折磨人的环节——通信协议。很多人一开始图省事手机发一个字符A代表前进B代表后退单片机收到就执行。跑起来好像没问题但一旦你要传参数比如以60%速度前进、要回传数据比如当前三个传感器状态是101这种单字符协议立刻就崩了。我的建议是从一开始就设计一个带帧头、带长度、带校验的简单二进制协议。不用搞得太复杂但基本要素要有。下面是我在小车上实际用的一套你可以直接抄帧结构[帧头0xAA][帧头0x55][命令字][数据长度][数据...][校验和]帧头 0xAA 0x55两个字节用来在字节流里定位一帧的开始。为什么用两个而不是一个因为单个字节很容易和数据内容撞车两个连续的特殊字节撞车概率极低。命令字1字节标识这一帧是干什么的。比如0x01是控制电机0x02是查询传感器0x03是单片机回传传感器数据。数据长度1字节表示后面跟多少个数据字节。数据变长具体含义由命令字决定。校验和1字节最简单的做法是把前面所有字节累加取低8位。用来判断这一帧在传输中是否出错。举个例子手机要让小车以速度60前进可以发AA 55 01 02 01 3C XX。其中01是命令字控制电机02是数据长度01代表前进方向3C是十六进制的60速度值XX是校验和。单片机收到后解析出来设置电机方向和PWM占空比。提示协议一旦定下来两端就要严格按它来。建议把协议写成一张表贴在代码注释里改的时候两端一起改否则调试时会怀疑人生。为什么值得花时间做这个因为带帧结构的协议天然能解决粘包和丢包问题。串口和蓝牙都是字节流你发两次数据接收端可能一次收到、也可能分三次收到。有了帧头接收端就可以用一个状态机去找帧头、读长度、收数据、验校验收到完整一帧才处理。这套机制后面我会在STM32和Android两端都实现一遍。2.3 系统整体数据流把整个系统的数据流理一遍你脑子里就有全景图了。手机App里用户点方向按钮或拖动速度滑块UI层把操作转成一个控制指令交给一个独立的后台线程去通过蓝牙Socket发送。为什么必须用后台线程因为蓝牙Socket的读写是阻塞操作放在主线程会直接触发ANR应用无响应这是新手最常犯的错。数据到了蓝牙模块模块通过串口把字节流吐给STM32。STM32的串口接收中断一个字节一个字节地收喂给一个解析状态机凑齐一帧后根据命令字执行动作。反过来STM32要回传数据时把传感器状态打包成帧通过串口发给蓝牙模块模块再无线传给手机。手机端的接收线程一直在阻塞读Socket读到数据后同样用状态机解析解析出完整帧后通过Handler或LiveData把数据抛回主线程更新UI。这条链路里蓝牙模块是透明的它不关心你发的是什么只负责把串口数据和无线数据互相搬运。所以你的调试可以分两段先用串口助手直接连蓝牙模块验证手机和模块之间通不通再用串口助手模拟手机验证STM32的协议解析对不对。分段调试能帮你快速定位问题出在哪一段。3. 硬件与STM32端把蓝牙模块当成一根无线串口线3.1 蓝牙模块选型与接线要点市面上常见的经典蓝牙串口模块核心芯片大多是那几款通用的功能大同小异都支持SPP协议、都能通过AT指令配置。选型时看三个参数就够是否支持SPP、默认波特率、供电电压。大部分模块默认波特率是9600也有115200的这个必须和STM32串口的波特率一致否则收到的全是乱码。接线其实非常简单模块一般有四个关键引脚VCC、GND、TXD、RXD。接线规则是交叉连接模块的TXD接STM32的RX模块的RXD接STM32的TXVCC和GND对应接上。这里有个坑要特别注意模块的RXD能不能直接接STM32的TX取决于模块的IO电平。有些模块是3.3V电平可以直接接有些标称支持5V但RXD内部没有电平转换长期接5V可能损坏。稳妥的做法是查一下模块手册或者干脆用3.3V的STM32串口引脚去接。还有一个新手常踩的坑调试阶段一定要先单独调通蓝牙模块。具体做法是用USB转TTL把模块接到电脑用串口助手打开对应端口手机下载一个通用的蓝牙串口调试App配对连接后互发数据。这一步通了说明模块和手机都没问题再接到STM32上。如果跳过这步直接上小车一旦不通你根本不知道是模块问题、接线问题还是代码问题。3.2 STM32串口接收中断与环形缓冲STM32这边我强烈建议用串口接收中断环形缓冲区的方式而不是轮询。轮询会占用CPU、还容易丢数据。中断方式下每收到一个字节就触发一次中断把字节塞进环形缓冲区主循环再从缓冲区里取数据做解析。这样即使主循环在忙别的事比如跑PID、更新PWM也不会丢字节。环形缓冲区的核心就是两个指针写指针中断里更新和读指针主循环里更新。缓冲区大小建议至少256字节太小了在高频通信时会溢出。下面是一个简化的实现思路#define BUF_SIZE 256 static volatile uint8_t rx_buf[BUF_SIZE]; static volatile uint16_t rx_head 0; // 写指针中断里改 static volatile uint16_t rx_tail 0; // 读指针主循环里改 // 串口中断服务函数 void USART1_IRQHandler(void) { if (USART_GetITStatus(USART1, USART_IT_RXNE) ! RESET) { uint8_t data USART_ReceiveData(USART1); uint16_t next (rx_head 1) % BUF_SIZE; if (next ! rx_tail) { // 缓冲区没满 rx_buf[rx_head] data; rx_head next; } // 满了就丢弃避免覆盖未读数据 } } // 主循环里取一个字节 int ring_get(uint8_t *out) { if (rx_head rx_tail) return 0; // 空 *out rx_buf[rx_tail]; rx_tail (rx_tail 1) % BUF_SIZE; return 1; }注意rx_head和rx_tail都加了volatile因为它们在中断和主循环之间共享编译器不能优化掉对它们的读写。另外判断满用的是next ! rx_tail而不是rx_head ! rx_tail这样能区分空和满两种状态是环形缓冲区的经典写法。3.3 协议解析状态机让字节流变成完整指令有了环形缓冲区接下来就是解析。前面定的协议是AA 55 [命令][长度][数据...][校验]解析它用一个状态机最清晰。状态机的思路是维护一个当前状态变量每来一个字节就根据当前状态决定下一步。typedef enum { STATE_HEAD1, // 等待第一个帧头0xAA STATE_HEAD2, // 等待第二个帧头0x55 STATE_CMD, // 读命令字 STATE_LEN, // 读长度 STATE_DATA, // 读数据 STATE_CHECK // 读校验 } ParseState; void parse_byte(uint8_t b) { static ParseState state STATE_HEAD1; static uint8_t cmd, len, data[32], idx, sum; switch (state) { case STATE_HEAD1: if (b 0xAA) { state STATE_HEAD2; sum b; } break; case STATE_HEAD2: if (b 0x55) { state STATE_CMD; sum b; } else state STATE_HEAD1; // 不是0x55重新找 break; case STATE_CMD: cmd b; sum b; state STATE_LEN; break; case STATE_LEN: len b; sum b; idx 0; state (len 0) ? STATE_DATA : STATE_CHECK; break; case STATE_DATA: data[idx] b; sum b; if (idx len) state STATE_CHECK; break; case STATE_CHECK: if (b sum) { handle_frame(cmd, data, len); } // 校验通过才处理 state STATE_HEAD1; break; } }这个状态机有个关键设计只有校验通过才执行动作。如果校验失败直接丢弃这一帧回到找帧头的状态。这样即使传输中某个字节出错也不会执行错误指令。另外data数组我给了32字节实际用多少按你的协议定但一定要设上限防止长度字段被干扰成一个大数导致数组越界——这是嵌入式里非常危险的安全隐患。注意handle_frame里执行动作要快别在里面做耗时操作比如延时、等待。如果某个动作确实耗时就设个标志位让主循环去处理。中断或高频调用的解析函数里做长耗时操作会拖垮整个系统的实时性。3.4 电机控制与PWM输出解析出控制指令后最终要落到电机上。小车的电机一般用H桥驱动比如常见的L298N、TB6612这类模块STM32通过两个GPIO控制方向、一个PWM引脚控制速度。以TB6612为例每个电机有IN1、IN2两个方向引脚和一个PWM引脚。前进就是IN1高、IN2低后退反过来停止就两个都低。PWM的配置用定时器输出比较模式。假设系统时钟72MHz你想要1kHz的PWM频率那么预分频和自动重装载值可以这样算先设预分频为71得到72MHz/(711)1MHz的计数频率再设自动重装载值为999得到1MHz/(9991)1kHz的PWM频率。占空比就是比较寄存器的值除以1000。速度60%就是比较值设600。// PWM初始化以TIM3通道1为例简化版 void PWM_Init(void) { // 时钟、GPIO配置略 TIM_TimeBaseInitTypeDef tb; tb.TIM_Prescaler 71; // 72MHz - 1MHz tb.TIM_Period 999; // 1MHz - 1kHz tb.TIM_CounterMode TIM_CounterMode_Up; TIM_TimeBaseInit(TIM3, tb); TIM_OCInitTypeDef oc; oc.TIM_OCMode TIM_OCMode_PWM1; oc.TIM_OutputState TIM_OutputState_Enable; oc.TIM_Pulse 0; // 初始占空比0 oc.TIM_OCPolarity TIM_OCPolarity_High; TIM_OC1Init(TIM3, oc); TIM_Cmd(TIM3, ENABLE); } // 设置速度speed范围0-100 void set_speed(uint8_t speed) { if (speed 100) speed 100; TIM_SetCompare1(TIM3, speed * 10); // 0-100映射到0-1000 }这里有个实操经验电机启动有个死区。占空比太低比如低于20%时电机可能根本不转或者转得很吃力还发热。所以实际用的时候可以把速度下限设成20%左右低于这个值直接当停止处理。另外换向时最好先停一下再反向直接从一个方向切到另一个方向H桥会有瞬间的大电流冲击长期这样容易烧驱动芯片。4. Android端开发权限、配对、Socket与线程模型4.1 蓝牙权限的版本适配这是最大的坑Android的蓝牙权限是随着版本不断收紧的这是新手最容易卡住的地方。我按版本给你理一遍你对着自己的targetSdkVersion看。在Android 6.0API 23之前蓝牙权限是安装时授予的不用管。从6.0开始BLUETOOTH和BLUETOOTH_ADMIN这两个权限虽然还是normal级别安装即授予但扫描设备需要定位权限因为蓝牙扫描理论上能推断位置。所以6.0到11你要动态申请ACCESS_FINE_LOCATION。到了Android 12API 31谷歌把蓝牙权限拆分了新增了BLUETOOTH_SCAN、BLUETOOTH_CONNECT、BLUETOOTH_ADVERTISE三个运行时权限。如果你targetSdkVersion升到31及以上就必须动态申请BLUETOOTH_SCAN和BLUETOOTH_CONNECT而且如果声明了neverForLocation扫描时就不需要定位权限了。!-- AndroidManifest.xml -- uses-permission android:nameandroid.permission.BLUETOOTH android:maxSdkVersion30 / uses-permission android:nameandroid.permission.BLUETOOTH_ADMIN android:maxSdkVersion30 / uses-permission android:nameandroid.permission.ACCESS_FINE_LOCATION android:maxSdkVersion30 / uses-permission android:nameandroid.permission.BLUETOOTH_SCAN android:usesPermissionFlagsneverForLocation / uses-permission android:nameandroid.permission.BLUETOOTH_CONNECT /代码里动态申请时要按版本分支if (Build.VERSION.SDK_INT Build.VERSION_CODES.S) { // Android 12 requestPermissions(new String[]{ Manifest.permission.BLUETOOTH_SCAN, Manifest.permission.BLUETOOTH_CONNECT }, REQ_CODE); } else if (Build.VERSION.SDK_INT Build.VERSION_CODES.M) { // Android 6.0 - 11 requestPermissions(new String[]{ Manifest.permission.ACCESS_FINE_LOCATION }, REQ_CODE); }提示如果你在Android 12上扫描不到任何设备十有八九是BLUETOOTH_SCAN没申请或者用户拒绝了。调试时先打印一下权限状态别一上来就怀疑硬件。4.2 配对与连接为什么建议跳过扫描直接用已配对列表前面说过经典蓝牙配对是一次性的。所以一个很实用的做法是引导用户先去系统设置里配对一次然后App直接从已配对设备列表里取。这样App里连扫描代码都不用写省掉一大堆权限麻烦。获取已配对设备用BluetoothAdapter.getBondedDevices()返回一个SetBluetoothDevice。遍历它按名字或MAC地址找到你的蓝牙模块然后就可以发起连接了。BluetoothAdapter adapter BluetoothAdapter.getDefaultAdapter(); if (adapter null) { // 设备不支持蓝牙 return; } if (!adapter.isEnabled()) { // 引导用户打开蓝牙 Intent intent new Intent(BluetoothAdapter.ACTION_REQUEST_ENABLE); startActivityForResult(intent, REQ_ENABLE_BT); } SetBluetoothDevice bonded adapter.getBondedDevices(); for (BluetoothDevice device : bonded) { if (你的模块名字.equals(device.getName())) { targetDevice device; break; } }连接用的是SPP的UUID这个UUID是固定的所有SPP设备都一样00001101-0000-1000-8000-00805F9B34FB。用device.createRfcommSocketToServiceRecord(uuid)创建Socket然后connect()。注意connect()是阻塞的必须放在子线程。private static final UUID SPP_UUID UUID.fromString(00001101-0000-1000-8000-00805F9B34FB); // 在子线程中执行 BluetoothSocket socket targetDevice.createRfcommSocketToServiceRecord(SPP_UUID); adapter.cancelDiscovery(); // 连接前一定要取消扫描否则连接会变慢甚至失败 socket.connect();这里有个经典坑连接前必须调用cancelDiscovery()。如果扫描还在进行连接会非常慢甚至直接失败。很多人连接超时就是因为忘了这行。4.3 后台线程模型读写分离绝不碰主线程蓝牙Socket的connect()、getInputStream().read()、getOutputStream().write()全是阻塞操作。主线程碰任何一个都会ANR。所以标准做法是开两个线程一个专门读一个专门写或者写操作按需在临时线程里做。读线程是一个死循环一直阻塞在read()上读到数据就丢给解析器new Thread(() - { InputStream in socket.getInputStream(); byte[] buffer new byte[1024]; while (running) { try { int len in.read(buffer); // 阻塞直到有数据 if (len 0) { parser.feed(buffer, len); // 喂给解析状态机 } } catch (IOException e) { // 连接断开退出循环 break; } } }).start();写操作相对简单但要注意多线程同时写会乱序。如果UI上有多个按钮可能同时触发发送最好用一个单线程的发送队列或者加锁。我一般用一个BlockingQueueUI线程把要发的数据丢进队列一个专门的发送线程从队列里取出来写。private final BlockingQueuebyte[] sendQueue new LinkedBlockingQueue(); // 发送线程 new Thread(() - { OutputStream out socket.getOutputStream(); while (running) { try { byte[] data sendQueue.take(); // 阻塞等待 out.write(data); out.flush(); } catch (Exception e) { break; } } }).start(); // UI线程调用 public void send(byte[] data) { sendQueue.offer(data); }这套模型的好处是UI线程永远不阻塞发送顺序有保证连接断开时两个线程都能干净地退出。4.4 接收解析与UI更新Handler还是LiveData接收线程解析出完整帧后要把数据更新到UI上比如显示当前传感器状态、连接状态。但子线程不能直接改UI必须切回主线程。两种主流做法老项目用Handler新项目用LiveData或Flow。用Handler的话在UI线程创建Handler子线程通过它发消息private final Handler uiHandler new Handler(Looper.getMainLooper()) { Override public void handleMessage(Message msg) { if (msg.what MSG_SENSOR_DATA) { // 更新UI sensorTextView.setText((String) msg.obj); } } }; // 子线程解析出数据后 Message m uiHandler.obtainMessage(MSG_SENSOR_DATA, 传感器: 101); m.sendToTarget();用LiveData的话在ViewModel里定义MutableLiveData子线程调postValue()UI层observe()。两种都行看你的项目架构。我个人在小项目里更倾向Handler简单直接不用引入额外依赖。注意更新UI前一定要判断Activity是否还活着。如果用户在连接过程中退出了界面子线程还在发消息Handler持有Activity引用会导致内存泄漏甚至崩溃。用WeakReference包一下Handler或者在onDestroy里移除所有回调。5. 联调实战从零到跑通的关键步骤与踩坑记录5.1 分段调试法把问题锁死在某一段整个系统涉及手机、蓝牙模块、STM32三段一起调的话出了问题根本不知道是谁的锅。我的做法是分段调试逐段打通。第一步只调蓝牙模块和手机。用USB转TTL接模块电脑串口助手打开手机装个通用蓝牙串口App配对连接后互发数据。这一步验证模块能不能被配对、手机能不能连上、双向数据通不通。如果这步不通后面都别谈。第二步只调STM32和电脑。用串口助手模拟手机按协议格式手动发十六进制数据给STM32看电机动作对不对、回传数据格式对不对。这一步验证STM32的解析状态机、电机控制、数据打包是否正确。第三步把蓝牙模块接到STM32手机App连上整体联调。因为前两步都通了这一步如果出问题大概率是波特率不匹配或者接线问题。这套方法能帮你把90%的问题在早期就定位掉比一上来就整体调试效率高得多。5.2 常见问题速查表下面这张表是我在实际调试中整理出来的基本覆盖了你会遇到的大部分问题。现象可能原因排查与解决手机扫描不到模块权限没给/模块没上电检查定位或蓝牙扫描权限确认模块指示灯亮配对成功但连不上扫描没取消/模块被占用连接前调cancelDiscovery确认模块没被其他设备连着收到数据全是乱码波特率不匹配两端波特率必须一致常见9600或115200指令偶尔不执行粘包/丢包/校验失败检查协议解析状态机确认校验逻辑小车收到指令但不动PWM死区/接线错提高占空比下限检查电机驱动接线App连接后闪退主线程做阻塞操作把connect和read放到子线程Android 12连不上新权限没申请动态申请BLUETOOTH_SCAN和CONNECT数据延迟大发送太频繁/缓冲区小降低发送频率增大环形缓冲区连接一段时间后断开模块供电不稳/距离远检查供电缩短距离加心跳包5.3 心跳包与断线重连让连接更稳实际用的时候蓝牙连接偶尔会因为干扰或距离变远而断开。如果不处理用户会发现点按钮没反应体验很差。两个改进心跳包和断线重连。心跳包就是手机每隔一两秒发一个特定的帧比如命令字0xFF无数据STM32收到后回一个同样的帧。如果手机连续几次没收到回应就认为连接断了主动关闭Socket并尝试重连。STM32那边也可以做超时判断如果超过几秒没收到任何数据就自动停车防止小车失控跑丢。// 心跳线程 new Thread(() - { while (running) { send(heartbeatFrame); try { Thread.sleep(2000); } catch (InterruptedException e) { break; } if (System.currentTimeMillis() - lastRecvTime 6000) { // 超过6秒没收到任何数据认为断开 reconnect(); } } }).start();断线重连的逻辑要小心别写成死循环疯狂重连把电量耗光。我的做法是重连失败后等待时间递增比如第一次等1秒第二次等2秒第三次等4秒最多等到30秒。5.4 一个容易被忽略的细节字符串编码如果你的协议里要传字符串比如设备名、状态文本一定要注意编码。Java的String.getBytes()默认用平台编码在不同设备上可能不一样。统一用UTF-8两端约定好避免中文乱码。STM32那边如果只传ASCII字符就无所谓但一旦涉及中文就要按UTF-8的字节序列处理。byte[] data 前进.getBytes(StandardCharsets.UTF_8); // 明确指定UTF-86. 性能与体验优化让小车从能用到好用6.1 控制指令的发送频率与去抖手动控制小车时用户可能快速连点方向按钮。如果每点一次就发一帧高频点击会把蓝牙带宽占满还会让STM32频繁切换电机状态。两个优化按钮去抖和状态合并。去抖就是在按钮的点击回调里加一个最小间隔判断比如200毫秒内只响应一次。状态合并是指如果用户连续发了前进又马上发前进其实没必要发第二次可以在发送前判断一下当前状态和目标状态是否相同相同就跳过。private long lastSendTime 0; private static final long MIN_INTERVAL 200; public void onForwardClick() { long now System.currentTimeMillis(); if (now - lastSendTime MIN_INTERVAL) return; lastSendTime now; send(buildFrame(CMD_MOTOR, new byte[]{DIR_FORWARD, speed})); }6.2 传感器数据的回传节流STM32回传传感器数据时如果每个控制周期比如每10毫秒都发一次数据量会很大手机端UI也来不及刷新。合理的做法是节流比如每100毫秒回传一次或者只在状态发生变化时才回传。这样既能看到实时状态又不会把带宽和CPU占满。// 每100ms回传一次 static uint32_t last_report 0; if (HAL_GetTick() - last_report 100) { last_report HAL_GetTick(); send_sensor_frame(); }6.3 电池电压监测与低电提醒这是个加分项但很实用。STM32用ADC采一下电池电压注意分压电池电压通常高于ADC参考电压打包进回传帧里。手机端显示电压低于阈值就弹提醒。这样用户不会玩到一半小车突然没电趴窝。// 假设电池经过1/2分压ADC参考3.3V12位精度 uint16_t adc_val get_adc(); float voltage adc_val / 4095.0f * 3.3f * 2.0f; // 乘2还原分压提示ADC采样要做多次取平均单次采样噪声很大。采个8次或16次求平均电压读数会稳很多。7. 我在这套方案里踩过的几个真实坑第一个坑是波特率不匹配导致的玄学问题。有次模块配置成115200STM32串口还是9600结果收到的数据时对时错偶尔能执行偶尔不能。我一开始以为是协议解析有问题查了半天状态机最后才发现是波特率。教训是联调第一步永远先确认两端波特率一致。第二个坑是Android 12的权限。项目在旧手机上跑得好好的换到新手机就扫描不到设备。查了半天才发现是新权限没申请。这个坑现在几乎每个做蓝牙的都会踩一次记住就行。第三个坑是主线程阻塞导致的ANR。早期图省事把connect()直接写在按钮回调里结果一点连接按钮App就卡死几秒运气不好直接弹应用无响应。后来老老实实把所有蓝牙操作都挪到子线程问题消失。第四个坑是校验和算错。我一开始把帧头也算进校验但STM32那边算的时候漏了第二个帧头字节导致所有帧校验都失败小车完全不动。这种问题很难从现象上看出来只能靠两端打印原始字节对比。所以调试协议时两端都把收发的原始十六进制打出来一眼就能看出差异。第五个坑是电机换向冲击。有次测试时快速来回切换前进后退结果驱动芯片发烫严重。后来加了换向前的短暂停止比如停50毫秒再反向温度就正常了。硬件的东西很多时候不是代码逻辑问题而是电气特性问题。这套方案跑通之后其实还能继续扩展。比如加一个简单的PID让循迹更平滑或者把手机端做成带虚拟摇杆的控制界面再或者加个摄像头做图传那就得换WiFi方案了。但核心的通信链路和协议设计就是这篇里讲的这些把这层打扎实上面加什么功能都不慌。