搞智能插座有一段时间了ESP32 这颗芯片在项目里当主控确实省了不少事。不过硬件焊完、固件烧录进去真正考验人的不是电路能不能跑而是后续的调试软件功能测试怎么做。很多朋友私信问我说程序烧进去设备没反应、App 搜不到插座、WiFi 配网老失败这些问题大部分不是硬件坏了而是调试阶段没把工具用起来、功能测试没做透。这篇就结合我这个智能插座项目的实际经历把从烧录到测试的完整链路捋一遍重点聊聊调试软件怎么选、日志怎么看、功能测试怎么设计以及排查过程中踩过的一些坑。1. 为什么拿ESP32做智能插座硬件选型与调试前置条件1.1 主芯片选型背后的逻辑智能插座这个品类市面上用 ESP8266 的方案非常多价格便宜、资料也多那为什么我最后还是选了 ESP32主要是两个原因。第一是蓝牙配网。ESP8266 只有 WiFi配网只能走 SmartConfig 或者 SoftAP 方式而 ESP32 自带 WiFi 蓝牙双模可以先把蓝牙当配网通道手机通过 BLE 把 WiFi 的 SSID 和密码直接发给设备。这个体验差别在实际用户手里非常明显SmartConfig 对路由器型号和手机系统版本敏感家里网络环境复杂一点就容易失败而蓝牙配网的成功率基本是 100%只是实现成本略高一些。对于一款要量产的家用产品配网成功率直接决定了退货率这一点值得多花时间。第二是调试友好度。ESP32 的日志系统比 ESP8266 完善得多esp_log 组件支持按模块、按级别过滤输出搭配 idf.py monitor 或者 Arduino IDE 的串口监视器排查问题的时候信息量完全不是一个级别。比如 WiFi 掉线、TCP 重连、内存不足这类问题ESP32 的日志能直接把原因打印出来少了大量盲猜的时间。1.2 硬件架构与调试预留我这版智能插座的硬件架构是这样的主控ESP32-WROOM-32E4MB Flash经典款成本够低资料够多电源AC-DC 非隔离降压方案输出 3.3V给主控和继电器驱动供电继电器松乐 SRD-05VDC-SL-C5V 线圈10A 250VAC 触点计量HLW8032 电能计量芯片用来做功率、电压、电流采集过零检测PC817 光耦 整流桥为继电器开合控制提供过零信号按键 LEDGPIO 直连做本地开关和状态指示串口预留 TXD0/RXD0引出排针方便调试这里要特别强调一下调试预留。TXD0/RXD0 这两个引脚默认是烧录引脚同时也是串口日志输出脚开发阶段一定要把它们引出来接到排针上。我之前做过一版为了省空间把串口脚砍掉了结果固件跑起来所有问题只能靠猜那感觉太折磨了。调试排针占不了多少 PCB 面积换来的是整个开发周期的高效这个取舍非常划算。另外GPIO0 是烧录模式选择脚我单独做了个轻触开关接 GND这样不用每次烧录都去拔线。具体是按住 BOOT 键再按复位键进入下载模式这个操作在开发调试阶段一天要重复几十次没有按钮的话用杜邦线捅 GND效率极低且容易把焊盘捅掉。1.3 开发环境的取舍智能插座的开发环境我用过 Arduino IDE也用过 ESP-IDF现在主力是 PlatformIO VSCode。三者的区别简单说环境上手难度调试能力适合阶段Arduino IDE低串口打印日志格式简单功能验证、快速原型PlatformIO中串口监视器、多环境管理、依赖管理清晰正式开发、多板型维护ESP-IDF高esp_log 全功能、menuconfig、内存监控深入定制、量产优化如果你只是测试功能Arduino 刷起来快但如果要做成产品我强烈建议直接用 PlatformIO 或者 ESP-IDF。一个很重要的原因是 log 的信息密度差异——Arduino 的 Serial.println 只能打字符而 ESP-IDF 的 esp_log 可以带时间戳、模块名、日志等级还能用 menuconfig 控制某个模块的日志开关。真遇到疑难 bug这些信息就是救命稻草。2. 调试软件栈的搭建从烧录固件到日志分析2.1 烧录方式与常见失败原因ESP32 连接电脑常见的烧录方式就是 USB 转串口。开发板上一般自带 CP2102 或 CH340 芯片裸板的话需要外接 USB-TTL比如 CP2102 模块或者 CH340 模块。烧录前要注意检查三点确认串口驱动装好设备管理器里能看到 COM 口。CH340 在 Windows 下驱动偶尔会抽风建议直接去官网下最新版别用系统自动安装的旧版。确认 ESP32 处于下载模式也就是 IO0 拉低。大多数开发板是按住 BOOT 再按 EN有些板子设计了自动下载电路可以无视这一步但裸板必须要手动处理。确认波特率。默认的烧录波特率 460800 甚至 921600 在短线上没问题如果线比较长或者用了杜邦线建议降到 115200否则经常出现烧到一半报 sync 超时。命令行方式烧录推荐 esptool.pyesptool.py --chip esp32 --port COM3 --baud 460800 write_flash -z 0x1000 firmware.bin如果用 esptool 烧录时报错A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header百分之八十是硬件没有进入下载模式检查 IO0 电平或者按住 BOOT 再试一次。2.2 日志监视器调试的第一双眼睛烧录成功后第一件事就是打开串口监视器确认系统启动日志是正常的。波特率建议设置 115200这也是 ESP-IDF 的默认日志波特率。用 PlatformIO 的话项目配置里加一句monitor_speed 115200然后在终端执行pio device monitor就能实时看到日志。日志怎么看这里面的门道比很多人想象的多。ESP-IDF 的日志分为五个级别从低到高依次是VVerbose详细输出一般用于调试DDebug调试信息IInfo普通运行信息WWarning警告不影响运行但值得注意EError错误功能大概率已经异常我调试智能插座时日志里最常排查的就是这几种模式ESP_LOGI(TAG, relay on, current%dmA, current_ma); ESP_LOGW(TAG, wifi reconnect attempt %d, retry_cnt); ESP_LOGE(TAG, mqtt publish failed, rc%d, rc);在 menuconfig 里可以全局设置日志级别也可以按模块覆盖。比如量产版我只想看错误就把默认级别调成 Error开发阶段我习惯开成 DebugWiFi 驱动层的信息对定位连接问题帮助特别大。2.3 逻辑分析仪和电流表的辅助角色调试软件功能很多时候不能只看软件日志硬件信号的行为也要对照着看。我调试继电器控制时就出现过一次这样的场景日志打印relay on但继电器动作就是不对。后来用逻辑分析仪挂在 GPIO 输出脚上发现初始化代码执行之前引脚就已经被拉高了。这类时序问题光靠串口日志根本发现不了必须借助硬件工具。逻辑分析仪我用的是十几块钱的 Saleae 克隆版配合 PulseView 软件。抓取 GPIO 电平变化能看到代码执行到哪一步引脚发生了翻转。电流表则用来辅助判断继电器线圈有没有吸合我习惯在继电器线圈电源线上串一个数字万用表实测正常吸合电流大约 70mA如果日志说吸合了但电流没有变化那基本可以断定驱动电路有问题。3. WiFi 配网与连接稳定性的实测调优3.1 三种配网方式的实际体验差异智能插座这类设备WiFi 配网是第一道关卡。我同时实现了三种配网方式蓝牙 BLE 配网、SmartConfigESP-Touch、SoftAP 配网最后在实际测试中得出一个结论蓝牙配网远远比另外两种稳。做个对比配网方式成功率我的测试环境用户体验开发复杂度SmartConfig86%需要 App 和手机同一 WiFi5G 频段经常失败低SoftAP92%需要手动切换手机 WiFi操作繁琐低BLE 配网99%App 自动连接、无感支持任意网络环境高SmartConfig 失败的高发场景是路由器开启 AP 隔离、手机连接 5G WiFi 而设备只支持 2.4G、路由器开了 WPA3 模式。这些场景在用户家里是无法预判的所以我在量产版上最终是把 BLE 作为首选、SoftAP 作为兜底。BLE 配网的数据帧设计我踩过一次坑。BLE 的 ATT 最大传输单元MTU默认是 23 字节扣掉协议头之后实际单包最多只能放 20 字节数据。如果你的 WiFi 密码比较长一个包根本放不下。正确的做法是在 GATT 服务里定义一个长特征值支持分片发送比如每次 20 字节设备收齐后再拼装#define MTU_SIZE 512 #define BLE_PACKET_SIZE 20 static uint8_t ssid_buf[32] {0}; static uint8_t pass_buf[64] {0}; void on_ble_write(uint8_t *data, uint16_t len, uint16_t offset) { if (offset sizeof(ssid_buf)) { memcpy(ssid_buf offset, data, len); } else { memcpy(pass_buf offset - sizeof(ssid_buf), data, len); } }这里用 offset 来标识分片位置App 端每发完一个包等待设备回一个 ACK 再发下一包避免粘包。3.2 WiFi 连接日志从 disconnect 事件定位问题配网成功不等于连接稳定。我测试过程中遇到过非常典型的掉线问题具体表现是设备连上路由器正常跑一两个小时然后突然掉线不重启就再也连不回来。串口日志里反复出现W (12345) wifi: pm start, type: 2 W (22345) wifi: disconnect reason: 5reason 5 是 WIFI_REASON_NO_AP_FOUND意味着设备找了半天找不到目标 AP但路由器明明就在旁边。后来查 ESP-IDF 文档发现问题出在 WiFi 省电模式。默认情况下 WiFi 的 power save 模式是开启的设备会和路由器的 DTIM 周期对齐保持周期性休眠。如果路由器对省电模式兼容做得不好设备每次唤醒后关联关系就丢了表现为周期性掉线。解决办法是显式关闭省电esp_wifi_set_ps(WIFI_PS_NONE);实测关闭之后设备连续运行一周没有再掉线。当然代价是功耗上升对插电类设备无所谓如果是电池供电的场景就要权衡了。3.3 局域网通信的粘包与心跳设计智能插座的控制逻辑是手机 App - 路由器 - ESP32走的是 TCP。TCP 是流协议天然有粘包问题。我最初用简单的read直接解析 JSON结果两个指令连在一起时解析直接失败。解决办法是自定一个极简的应用层帧协议帧结构为帧头(0xAA55) 长度(2字节) 数据(N字节) 校验(CRC8)接收端维护一个环形缓冲区每次从 TCP 读数据后先找帧头再根据长度字段提取完整帧最后做 CRC 校验。心跳包的设计也值得说一句。设备端每 5 秒发一次心跳App 侧 15 秒内没有收到心跳就判定设备离线。这里有个细节设备端不能简单依赖 TCP 的 keepalive因为 NAT 超时会静默断开连接。我是在应用层做心跳一箭双雕既能保活连接又能让 App 实时感知设备在线状态。4. 继电器控制与负载安全功能测试最关键的环节4.1 上电瞬间继电器乱跳的根因这个坑可以说是我做智能插座以来遇到的最隐蔽的问题。现象是插上电源瞬间继电器会不规律地吸合一次再释放有时候直接把负载设备误开机了。用逻辑分析仪抓 GPIO 引脚发现代码运行到gpio_set_level之前引脚就已经有高电平出现了。原因是 ESP32 的 GPIO 在复位后到固件初始化完成之间处于高阻态外部环境噪声很容易把电平抬高而继电器驱动电路的前级如果用了达林顿管或者三极管这种微弱的浮动电压就可能让管子进入放大区从而触发继电器动作。解决思路分两层。硬件上GPIO 到三极管基极之间加了一个 10kΩ 下拉电阻确保默认低电平。软件上把所有外设初始化都放到一个init_hardware函数里并且把继电器控制引脚先初始化为下拉输入等系统完全启动再切换为输出模式void init_relay_gpio(void) { gpio_config_t io_conf { .pin_bit_mask (1ULL RELAY_GPIO), .mode GPIO_MODE_INPUT, .pull_down_en true, }; gpio_config(io_conf); // 系统其他初始化... gpio_set_direction(RELAY_GPIO, GPIO_MODE_OUTPUT); gpio_set_level(RELAY_GPIO, 0); }这里顺序很重要先让引脚处于受控状态下拉输入再切输出杜绝了上电瞬间的自由电平。4.2 过零检测与继电器寿命的关系继电器在交流电峰值附近通断会产生电弧严重缩短触点寿命同时也容易产生 EMI 干扰。过零检测的意义就是在电压过零点附近完成开关切换让电流从零开始流或从零截止从而大幅减小电弧。我用 PC817 光耦做了一次过零检测电路不复杂但固件里处理信号的逻辑要注意一个点外部中断回调里只做标记不要做继电器控制。volatile bool zero_cross_flag false; void IRAM_ATTR zero_cross_isr(void) { zero_cross_flag true; } void relay_control_task(void *arg) { while (1) { if (zero_cross_flag) { zero_cross_flag false; // 在这里切换继电器理论上在过零点附近动作 gpio_set_level(RELAY_GPIO, relay_state); } } }ISR 里处理任务太重会阻塞系统所以我用了一个任务循环去响应标记。实际测试中从过零中断标记到继电器动作之间大约有 200~300 微秒的延迟考虑到继电器本身的机械动作时间约 5ms这 300 微秒基本可忽略开关瞬间产生的电流尖峰比不做过零检测时小了一个数量级。4.3 不同类型负载下的实测数据智能插座的负载能力标称是 10A 250VAC但不代表所有负载都能这么跑。我做了三类负载的实测阻性负载白炽灯、电热水壶电流波形接近正弦继电器的负担最小。容性负载LED 驱动电源、开关电源适配器启动瞬间电流可能达到稳态的 10~20 倍继电器触点容易打火需要在固件里加软启动逻辑比如先用小功率挡再切全功率。感性负载小风扇、电机断电瞬间会产生反电动势如果没有续流保护继电器触点寿命会锐减。这类负载我实测继电器寿命只有阻性负载的六成左右。测试过程中我用功率计实时读取电压电流波形配合示波器抓继电器动作瞬间的触点电压直观地看到了电弧对触点的烧蚀。功能测试这一环节千万别跳过真实负载测试只看空载波形很容易被假象欺骗。5. 蓝牙配网、局域网控制与联调日志分析5.1 BLE GATT 服务的设计细节智能插座的 BLE 配网逻辑我建了一个自定义 GATT 服务包含三个特征值特征值UUID属性说明WiFi SSID0xFF01可写接收 WiFi 名称支持分片写入WiFi 密码0xFF02可写接收 WiFi 密码支持分片写入配网状态0xFF03可读/通知返回配网进度2.1 扫描中、2.2 连接中、2.3 已上线顺序是先写 SSID再写密码最后设备主动发一条配网开始的通知App 收到后关闭 BLE 连接并切到局域网控制。这里有个小程序层面的坑如果手机 App 在 BLE 配网成功后立刻去搜索局域网设备往往会失败因为设备从 Wi-Fi 连接成功到获得 DHCP 地址需要 1~3 秒。我直接在配网状态特征值里加了已上线这个通知App 等收到这个通知再跳转基本就可以避免这个问题。5.2 局域网控制指令的日志关键字联调阶段日志里我重点搜索几个关键字I (12345) app: rx cmd{relay:on,ts:123456} I (12345) app: set relay ON, current234mA I (12345) app: mqtt publish ok, topic/dev/abc/status如果rx cmd打了但set relay没打说明命令解析失败检查 JSON 格式或者帧结构。如果set relay打了但mqtt publish没打说明网络链路不通或者 MQTT 连接断了。通过这种层层打日志的方式可以快速把问题定位到具体节点。我还习惯在日志里带一个全局运行时间戳就是系统启动后的毫秒数这样前后两条日志之间的间隔可以直接算出来。比如下面这条日志就暴露了问题I (10001) app: mqtt connect success I (18004) app: rx cmd{relay:on}mqtt 连接成功到收到命令之间间隔 8 秒说明设备已经在线但长时间没收到消息可能是心跳周期太长或者 App 端发消息的时机不对。5.3 移动端联调时的抓包技巧手机 App 和 ESP32 之间的局域网通信想彻底弄清数据链路的问题推荐用 Wireshark 在路由器旁挂一个镜像端口抓包或者直接在设备侧打印所有收到的原始 TCP 数据。我一般是先在设备日志里开 verbose 级别的网络 dump确认应用层帧结构没问题再去怀疑链路层的问题。真遇到 Wireshark 抓到的数据和应用层解析结果不一致的情况十有八九是中间有代理或者 NAT 改写不过家里局域网一般不会这么复杂。在办公室测试时如果 WiFi 路由器开了客户端隔离设备之间互相 ping 不通这是最常见的伪故障排查网络问题之前先确认路由器有没有开 AP 隔离。6. 功能测试用例设计与自动化回归6.1 测试用例怎么设计才有参考价值功能测试不是点了按钮没报错就算过了。要把智能插座的场景拆细我总结了一份测试用例表实际执行的时候照表打勾覆盖率高得多编号测试项操作步骤预期结果实测结果TC01上电自启动插座上电不开控制开关设备自动连接 WiFi继电器保持断开通过TC02本地按键开关短按按键继电器吸合/释放LED 状态同步通过TC03App 远程开关App 发送开/关指令1 秒内继电器动作App 显示状态刷新通过TC04断电上电恢复关闭电源重新上电设备恢复断电前的继电器状态通过TC05WiFi 断开恢复路由器重启设备 2 分钟内自动重连并恢复在线通过TC06密码错误配网输入错误 WiFi 密码BLE 配网提示失败不会卡死通过TC07过量程负载接 2kW 电热水壶计量数据正确继电器不误动作通过TC08OTA 固件升级从 v1.0 升到 v1.1升级成功配置信息保留通过TC09电量统计精度接功率计对比读数误差小于 2%通过TC10长时间老化连续开关 1000 次无死机、无继电器卡死通过重点说下 TC04 断电上电恢复。很多用户在意插座断电后再来电能不能恢复断电前的状态。我的做法是在 flash 的 NVS 区域存取一个relay_state标志位上电时读取。这里有个细节不能用默认值因为第一次上电没有这个标志读取会失败必须先判断nvs_get_u8的返回值。6.2 自动化回归的实现思路手点测试做一轮两轮可以做十轮就崩溃了。我后来写了一个 Python 自动化脚本通过串口和 ESP32 通信把测试指令批量发进去再用脚本解析返回的日志自动判定测试是否通过。基本思路是这样import serial import time ser serial.Serial(COM3, 115200, timeout1) def send_cmd(cmd): ser.write(cmd.encode()) time.sleep(0.5) return ser.read_all().decode(errorsignore) # 测试继电器开关 100 次 for i in range(100): resp send_cmd(relay on\n) assert set relay ON in resp, f第{i1}次开失败 time.sleep(0.3) resp send_cmd(relay off\n) assert set relay OFF in resp, f第{i1}次关失败 time.sleep(0.3) print(100 次开关测试全部通过)这个脚本跑一轮不用管测试完看输出就行。自动化回归最有价值的场景是改完代码后跑全套用例确认没有引入新问题。我每次发布固件前都会让脚本把 TC01 到 TC10 全部过一遍至少能挡住八成的低级回归。6.3 兼容性测试不能省智能插座面向的用户手里路由器五花八门兼容性测试是功能测试里必不可少的一环。我这里列几个我实测出问题的场景路由器开启 WPA3 加密时ESP32 连接很慢而且容易失败。解决办法是在 menuconfig 里开启 WPA3 支持同时保留 WPA2 兼容模式。某些老路由器只支持 802.11b/g而 ESP32 默认启用 802.11n可能导致协商失败或速率极低。我在固件里加了一个配置项可以在配网时选择协议模式。路由器开了 DHCP 租约过短比如 1 小时设备到点续约失败后就掉线了。这个问题比较难复现但一旦出现用户感知非常明显。我最终的方案是应用层加了心跳检测逻辑检测到网络不通就主动重连。7. 三个疑难杂症的完整排查链路7.1 问题一插座上电瞬间继电器乱跳表面现象插电瞬间继电器会啪地吸合一下然后又断开。初步排查逻辑我先把继电器控制代码注释掉只留一个空循环问题依旧。这就排除了软件主动控制的问题把可疑范围缩小到硬件上。接着用万用表测 GPIO 引脚电压发现上电瞬间引脚确实有约 1.2V 的浮动电压说明是 GPIO 默认高阻态引起的。最终方案如前面 4.1 所述在硬件上加下拉电阻、在软件上调整初始化顺序。这个问题排查用了大半天但结论其实很简单核心经验是复位到初始化完成之间的这个时间段所有外设引脚的状态是不可控的设计时必须默认它是危险状态来处理。7.2 问题二设备运行几小时后自动掉线表面现象设备连上 WiFi 能正常跑几个小时然后毫无征兆地掉线不重启永远连不回来。排查过程我先在日志里加了几条调试输出记录每次 WiFi 断开的原因和当前的省电状态跑了半天抓到关键日志W (45678) wifi: disconnect reason: 5 I (45679) wifi: pm status: activereason 5 是找不到 AP。又查了联发科的文档和 ESP-IDF issue发现是省电模式导致的周期性问题。关闭省电后继续跑了一天一夜没有再复现确认为根因。这个问题的价值在于日志里的 disconnect reason 只是个结果真正的原因往往藏在触发这个结果之前的配置里。我后来养成了一个习惯任何 WiFi 问题先打印esp_wifi_get_ps的状态再看 keepalive 配置最后才是环境因素。7.3 问题三OTA 升级后设备变砖表面现象OTA 下载固件完成设备重启后无法正常启动串口日志卡在引导加载阶段进不了应用。排查过程我烧录的是合并固件merged.binFlash 分区表是默认的两层结构factory ota_0 ota_1。OTA 升级时新固件写到了 ota_0但启动时引导加载器去读 factory 分区里的固件结果发现被覆盖了或者镜像校验失败就卡住了。根因是我用错了烧录命令esptool.py write_flash 0x0 merged.bin把所有内容写到起始地址覆盖了 partition table。正确做法是先烧录一个带完整分区表的初始镜像然后在应用里通过 OTA 接口升级而不是通过串口直接刷合并包。解决后我重新烧录了 factory 镜像再用 App 走了一次 OTA升级正常。这个坑的教训是OTA 功能测试一定要在真机上完整走一遍从服务器下载到重启的全流程只测试打包流程没有任何意义。8. 回到调试软件本身选对一个工具少走一半弯路聊了这么多功能测试和踩坑记录最后想回到标题里的调试软件这个话题。很多开发者对调试软件的理解就是串口监视器但实际上嵌入式调试软件工具链比这宽得多我用得最顺手的几个PlatformIO 的 Serial Monitor直接集成日志过滤、时间戳、颜色高亮比 Arduino 自带的串口监视器好用太多。ESP-IDF 的 idf.py monitor支持将日志输出转成带颜色等级的终端界面还集成了 GDB 调试可以直接打断点。Wireshark配合路由器镜像端口看网络包定位和 WiFi/网络相关的问题非常高效。逻辑分析仪 PulseView看引脚时序、分析协议波形。QEMU 模拟器esp32 target在没有硬件的时候做一些纯逻辑的验证但不能替代真机测试。我个人推荐把 PlatformIO 作为日常主力主要原因是环境一致性做得很好——项目里的platformio.ini写清楚 board、framework 和 monitor 参数换一台电脑照样能编译烧录不用折腾环境。下面这个是我智能插座项目的配置片段[env:esp32dev] platform espressif32 board esp32dev framework arduino monitor_speed 115200 board_build.partitions custom_partitions.csvcustom_partitions.csv里我是这样定义的为 OTA 预留了两个 app 区# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x5000, otadata, data, ota, 0xe000, 0x2000, app0, app, ota_0, 0x10000, 0x1F0000, app1, app, ota_1, 0x200000, 0x1F0000,分区分得好OTA 功能的测试才会顺畅。不然像我在 7.3 里踩的坑分区表被覆盖整个设备就只能连串口重新烧录了。调试软件的另一个隐藏价值是日志留痕。我在做 7×24 小时老化测试时把串口日志落盘保存跑完一整天再回去翻日志看有没有偶发的异常打印。很多偶发问题不持续盯日志根本发现不了即使发现了也没法复现而日志落盘给了事后分析的可能。还有个技巧在固件里加一个version日志宏每次启动打印固件版本和编译时间。调试的时候如果同时测了好几个版本的固件日志里一眼就能分清当前跑的是哪个版本不然测来测去发现测的是旧版固件那就纯浪费时间了。智能插座这个项目整体做下来我对调试软件功能测试这件事最大的体会是不要把调试和测试割裂成两个阶段调试软件贯穿开发全程功能测试也不是上线的最后一次检查而是每个环节都要随手做。把日志埋好、把工具用熟、把测试用例沉淀成脚本项目推进速度会明显上一个台阶。后续我还打算把计量芯片的数据做成可视化的能耗报表再把 BLE 配网升级成二维码配网这些都是在这个调试框架上继续扩展的事。
搞智能插座有一段时间了ESP32 这颗芯片在项目里当主控确实省了不少事。不过硬件焊完、固件烧录进去真正考验人的不是电路能不能跑而是后续的调试软件功能测试怎么做。很多朋友私信问我说程序烧进去设备没反应、App 搜不到插座、WiFi 配网老失败这些问题大部分不是硬件坏了而是调试阶段没把工具用起来、功能测试没做透。这篇就结合我这个智能插座项目的实际经历把从烧录到测试的完整链路捋一遍重点聊聊调试软件怎么选、日志怎么看、功能测试怎么设计以及排查过程中踩过的一些坑。1. 为什么拿ESP32做智能插座硬件选型与调试前置条件1.1 主芯片选型背后的逻辑智能插座这个品类市面上用 ESP8266 的方案非常多价格便宜、资料也多那为什么我最后还是选了 ESP32主要是两个原因。第一是蓝牙配网。ESP8266 只有 WiFi配网只能走 SmartConfig 或者 SoftAP 方式而 ESP32 自带 WiFi 蓝牙双模可以先把蓝牙当配网通道手机通过 BLE 把 WiFi 的 SSID 和密码直接发给设备。这个体验差别在实际用户手里非常明显SmartConfig 对路由器型号和手机系统版本敏感家里网络环境复杂一点就容易失败而蓝牙配网的成功率基本是 100%只是实现成本略高一些。对于一款要量产的家用产品配网成功率直接决定了退货率这一点值得多花时间。第二是调试友好度。ESP32 的日志系统比 ESP8266 完善得多esp_log 组件支持按模块、按级别过滤输出搭配 idf.py monitor 或者 Arduino IDE 的串口监视器排查问题的时候信息量完全不是一个级别。比如 WiFi 掉线、TCP 重连、内存不足这类问题ESP32 的日志能直接把原因打印出来少了大量盲猜的时间。1.2 硬件架构与调试预留我这版智能插座的硬件架构是这样的主控ESP32-WROOM-32E4MB Flash经典款成本够低资料够多电源AC-DC 非隔离降压方案输出 3.3V给主控和继电器驱动供电继电器松乐 SRD-05VDC-SL-C5V 线圈10A 250VAC 触点计量HLW8032 电能计量芯片用来做功率、电压、电流采集过零检测PC817 光耦 整流桥为继电器开合控制提供过零信号按键 LEDGPIO 直连做本地开关和状态指示串口预留 TXD0/RXD0引出排针方便调试这里要特别强调一下调试预留。TXD0/RXD0 这两个引脚默认是烧录引脚同时也是串口日志输出脚开发阶段一定要把它们引出来接到排针上。我之前做过一版为了省空间把串口脚砍掉了结果固件跑起来所有问题只能靠猜那感觉太折磨了。调试排针占不了多少 PCB 面积换来的是整个开发周期的高效这个取舍非常划算。另外GPIO0 是烧录模式选择脚我单独做了个轻触开关接 GND这样不用每次烧录都去拔线。具体是按住 BOOT 键再按复位键进入下载模式这个操作在开发调试阶段一天要重复几十次没有按钮的话用杜邦线捅 GND效率极低且容易把焊盘捅掉。1.3 开发环境的取舍智能插座的开发环境我用过 Arduino IDE也用过 ESP-IDF现在主力是 PlatformIO VSCode。三者的区别简单说环境上手难度调试能力适合阶段Arduino IDE低串口打印日志格式简单功能验证、快速原型PlatformIO中串口监视器、多环境管理、依赖管理清晰正式开发、多板型维护ESP-IDF高esp_log 全功能、menuconfig、内存监控深入定制、量产优化如果你只是测试功能Arduino 刷起来快但如果要做成产品我强烈建议直接用 PlatformIO 或者 ESP-IDF。一个很重要的原因是 log 的信息密度差异——Arduino 的 Serial.println 只能打字符而 ESP-IDF 的 esp_log 可以带时间戳、模块名、日志等级还能用 menuconfig 控制某个模块的日志开关。真遇到疑难 bug这些信息就是救命稻草。2. 调试软件栈的搭建从烧录固件到日志分析2.1 烧录方式与常见失败原因ESP32 连接电脑常见的烧录方式就是 USB 转串口。开发板上一般自带 CP2102 或 CH340 芯片裸板的话需要外接 USB-TTL比如 CP2102 模块或者 CH340 模块。烧录前要注意检查三点确认串口驱动装好设备管理器里能看到 COM 口。CH340 在 Windows 下驱动偶尔会抽风建议直接去官网下最新版别用系统自动安装的旧版。确认 ESP32 处于下载模式也就是 IO0 拉低。大多数开发板是按住 BOOT 再按 EN有些板子设计了自动下载电路可以无视这一步但裸板必须要手动处理。确认波特率。默认的烧录波特率 460800 甚至 921600 在短线上没问题如果线比较长或者用了杜邦线建议降到 115200否则经常出现烧到一半报 sync 超时。命令行方式烧录推荐 esptool.pyesptool.py --chip esp32 --port COM3 --baud 460800 write_flash -z 0x1000 firmware.bin如果用 esptool 烧录时报错A fatal error occurred: Failed to connect to ESP32: Timed out waiting for packet header百分之八十是硬件没有进入下载模式检查 IO0 电平或者按住 BOOT 再试一次。2.2 日志监视器调试的第一双眼睛烧录成功后第一件事就是打开串口监视器确认系统启动日志是正常的。波特率建议设置 115200这也是 ESP-IDF 的默认日志波特率。用 PlatformIO 的话项目配置里加一句monitor_speed 115200然后在终端执行pio device monitor就能实时看到日志。日志怎么看这里面的门道比很多人想象的多。ESP-IDF 的日志分为五个级别从低到高依次是VVerbose详细输出一般用于调试DDebug调试信息IInfo普通运行信息WWarning警告不影响运行但值得注意EError错误功能大概率已经异常我调试智能插座时日志里最常排查的就是这几种模式ESP_LOGI(TAG, relay on, current%dmA, current_ma); ESP_LOGW(TAG, wifi reconnect attempt %d, retry_cnt); ESP_LOGE(TAG, mqtt publish failed, rc%d, rc);在 menuconfig 里可以全局设置日志级别也可以按模块覆盖。比如量产版我只想看错误就把默认级别调成 Error开发阶段我习惯开成 DebugWiFi 驱动层的信息对定位连接问题帮助特别大。2.3 逻辑分析仪和电流表的辅助角色调试软件功能很多时候不能只看软件日志硬件信号的行为也要对照着看。我调试继电器控制时就出现过一次这样的场景日志打印relay on但继电器动作就是不对。后来用逻辑分析仪挂在 GPIO 输出脚上发现初始化代码执行之前引脚就已经被拉高了。这类时序问题光靠串口日志根本发现不了必须借助硬件工具。逻辑分析仪我用的是十几块钱的 Saleae 克隆版配合 PulseView 软件。抓取 GPIO 电平变化能看到代码执行到哪一步引脚发生了翻转。电流表则用来辅助判断继电器线圈有没有吸合我习惯在继电器线圈电源线上串一个数字万用表实测正常吸合电流大约 70mA如果日志说吸合了但电流没有变化那基本可以断定驱动电路有问题。3. WiFi 配网与连接稳定性的实测调优3.1 三种配网方式的实际体验差异智能插座这类设备WiFi 配网是第一道关卡。我同时实现了三种配网方式蓝牙 BLE 配网、SmartConfigESP-Touch、SoftAP 配网最后在实际测试中得出一个结论蓝牙配网远远比另外两种稳。做个对比配网方式成功率我的测试环境用户体验开发复杂度SmartConfig86%需要 App 和手机同一 WiFi5G 频段经常失败低SoftAP92%需要手动切换手机 WiFi操作繁琐低BLE 配网99%App 自动连接、无感支持任意网络环境高SmartConfig 失败的高发场景是路由器开启 AP 隔离、手机连接 5G WiFi 而设备只支持 2.4G、路由器开了 WPA3 模式。这些场景在用户家里是无法预判的所以我在量产版上最终是把 BLE 作为首选、SoftAP 作为兜底。BLE 配网的数据帧设计我踩过一次坑。BLE 的 ATT 最大传输单元MTU默认是 23 字节扣掉协议头之后实际单包最多只能放 20 字节数据。如果你的 WiFi 密码比较长一个包根本放不下。正确的做法是在 GATT 服务里定义一个长特征值支持分片发送比如每次 20 字节设备收齐后再拼装#define MTU_SIZE 512 #define BLE_PACKET_SIZE 20 static uint8_t ssid_buf[32] {0}; static uint8_t pass_buf[64] {0}; void on_ble_write(uint8_t *data, uint16_t len, uint16_t offset) { if (offset sizeof(ssid_buf)) { memcpy(ssid_buf offset, data, len); } else { memcpy(pass_buf offset - sizeof(ssid_buf), data, len); } }这里用 offset 来标识分片位置App 端每发完一个包等待设备回一个 ACK 再发下一包避免粘包。3.2 WiFi 连接日志从 disconnect 事件定位问题配网成功不等于连接稳定。我测试过程中遇到过非常典型的掉线问题具体表现是设备连上路由器正常跑一两个小时然后突然掉线不重启就再也连不回来。串口日志里反复出现W (12345) wifi: pm start, type: 2 W (22345) wifi: disconnect reason: 5reason 5 是 WIFI_REASON_NO_AP_FOUND意味着设备找了半天找不到目标 AP但路由器明明就在旁边。后来查 ESP-IDF 文档发现问题出在 WiFi 省电模式。默认情况下 WiFi 的 power save 模式是开启的设备会和路由器的 DTIM 周期对齐保持周期性休眠。如果路由器对省电模式兼容做得不好设备每次唤醒后关联关系就丢了表现为周期性掉线。解决办法是显式关闭省电esp_wifi_set_ps(WIFI_PS_NONE);实测关闭之后设备连续运行一周没有再掉线。当然代价是功耗上升对插电类设备无所谓如果是电池供电的场景就要权衡了。3.3 局域网通信的粘包与心跳设计智能插座的控制逻辑是手机 App - 路由器 - ESP32走的是 TCP。TCP 是流协议天然有粘包问题。我最初用简单的read直接解析 JSON结果两个指令连在一起时解析直接失败。解决办法是自定一个极简的应用层帧协议帧结构为帧头(0xAA55) 长度(2字节) 数据(N字节) 校验(CRC8)接收端维护一个环形缓冲区每次从 TCP 读数据后先找帧头再根据长度字段提取完整帧最后做 CRC 校验。心跳包的设计也值得说一句。设备端每 5 秒发一次心跳App 侧 15 秒内没有收到心跳就判定设备离线。这里有个细节设备端不能简单依赖 TCP 的 keepalive因为 NAT 超时会静默断开连接。我是在应用层做心跳一箭双雕既能保活连接又能让 App 实时感知设备在线状态。4. 继电器控制与负载安全功能测试最关键的环节4.1 上电瞬间继电器乱跳的根因这个坑可以说是我做智能插座以来遇到的最隐蔽的问题。现象是插上电源瞬间继电器会不规律地吸合一次再释放有时候直接把负载设备误开机了。用逻辑分析仪抓 GPIO 引脚发现代码运行到gpio_set_level之前引脚就已经有高电平出现了。原因是 ESP32 的 GPIO 在复位后到固件初始化完成之间处于高阻态外部环境噪声很容易把电平抬高而继电器驱动电路的前级如果用了达林顿管或者三极管这种微弱的浮动电压就可能让管子进入放大区从而触发继电器动作。解决思路分两层。硬件上GPIO 到三极管基极之间加了一个 10kΩ 下拉电阻确保默认低电平。软件上把所有外设初始化都放到一个init_hardware函数里并且把继电器控制引脚先初始化为下拉输入等系统完全启动再切换为输出模式void init_relay_gpio(void) { gpio_config_t io_conf { .pin_bit_mask (1ULL RELAY_GPIO), .mode GPIO_MODE_INPUT, .pull_down_en true, }; gpio_config(io_conf); // 系统其他初始化... gpio_set_direction(RELAY_GPIO, GPIO_MODE_OUTPUT); gpio_set_level(RELAY_GPIO, 0); }这里顺序很重要先让引脚处于受控状态下拉输入再切输出杜绝了上电瞬间的自由电平。4.2 过零检测与继电器寿命的关系继电器在交流电峰值附近通断会产生电弧严重缩短触点寿命同时也容易产生 EMI 干扰。过零检测的意义就是在电压过零点附近完成开关切换让电流从零开始流或从零截止从而大幅减小电弧。我用 PC817 光耦做了一次过零检测电路不复杂但固件里处理信号的逻辑要注意一个点外部中断回调里只做标记不要做继电器控制。volatile bool zero_cross_flag false; void IRAM_ATTR zero_cross_isr(void) { zero_cross_flag true; } void relay_control_task(void *arg) { while (1) { if (zero_cross_flag) { zero_cross_flag false; // 在这里切换继电器理论上在过零点附近动作 gpio_set_level(RELAY_GPIO, relay_state); } } }ISR 里处理任务太重会阻塞系统所以我用了一个任务循环去响应标记。实际测试中从过零中断标记到继电器动作之间大约有 200~300 微秒的延迟考虑到继电器本身的机械动作时间约 5ms这 300 微秒基本可忽略开关瞬间产生的电流尖峰比不做过零检测时小了一个数量级。4.3 不同类型负载下的实测数据智能插座的负载能力标称是 10A 250VAC但不代表所有负载都能这么跑。我做了三类负载的实测阻性负载白炽灯、电热水壶电流波形接近正弦继电器的负担最小。容性负载LED 驱动电源、开关电源适配器启动瞬间电流可能达到稳态的 10~20 倍继电器触点容易打火需要在固件里加软启动逻辑比如先用小功率挡再切全功率。感性负载小风扇、电机断电瞬间会产生反电动势如果没有续流保护继电器触点寿命会锐减。这类负载我实测继电器寿命只有阻性负载的六成左右。测试过程中我用功率计实时读取电压电流波形配合示波器抓继电器动作瞬间的触点电压直观地看到了电弧对触点的烧蚀。功能测试这一环节千万别跳过真实负载测试只看空载波形很容易被假象欺骗。5. 蓝牙配网、局域网控制与联调日志分析5.1 BLE GATT 服务的设计细节智能插座的 BLE 配网逻辑我建了一个自定义 GATT 服务包含三个特征值特征值UUID属性说明WiFi SSID0xFF01可写接收 WiFi 名称支持分片写入WiFi 密码0xFF02可写接收 WiFi 密码支持分片写入配网状态0xFF03可读/通知返回配网进度2.1 扫描中、2.2 连接中、2.3 已上线顺序是先写 SSID再写密码最后设备主动发一条配网开始的通知App 收到后关闭 BLE 连接并切到局域网控制。这里有个小程序层面的坑如果手机 App 在 BLE 配网成功后立刻去搜索局域网设备往往会失败因为设备从 Wi-Fi 连接成功到获得 DHCP 地址需要 1~3 秒。我直接在配网状态特征值里加了已上线这个通知App 等收到这个通知再跳转基本就可以避免这个问题。5.2 局域网控制指令的日志关键字联调阶段日志里我重点搜索几个关键字I (12345) app: rx cmd{relay:on,ts:123456} I (12345) app: set relay ON, current234mA I (12345) app: mqtt publish ok, topic/dev/abc/status如果rx cmd打了但set relay没打说明命令解析失败检查 JSON 格式或者帧结构。如果set relay打了但mqtt publish没打说明网络链路不通或者 MQTT 连接断了。通过这种层层打日志的方式可以快速把问题定位到具体节点。我还习惯在日志里带一个全局运行时间戳就是系统启动后的毫秒数这样前后两条日志之间的间隔可以直接算出来。比如下面这条日志就暴露了问题I (10001) app: mqtt connect success I (18004) app: rx cmd{relay:on}mqtt 连接成功到收到命令之间间隔 8 秒说明设备已经在线但长时间没收到消息可能是心跳周期太长或者 App 端发消息的时机不对。5.3 移动端联调时的抓包技巧手机 App 和 ESP32 之间的局域网通信想彻底弄清数据链路的问题推荐用 Wireshark 在路由器旁挂一个镜像端口抓包或者直接在设备侧打印所有收到的原始 TCP 数据。我一般是先在设备日志里开 verbose 级别的网络 dump确认应用层帧结构没问题再去怀疑链路层的问题。真遇到 Wireshark 抓到的数据和应用层解析结果不一致的情况十有八九是中间有代理或者 NAT 改写不过家里局域网一般不会这么复杂。在办公室测试时如果 WiFi 路由器开了客户端隔离设备之间互相 ping 不通这是最常见的伪故障排查网络问题之前先确认路由器有没有开 AP 隔离。6. 功能测试用例设计与自动化回归6.1 测试用例怎么设计才有参考价值功能测试不是点了按钮没报错就算过了。要把智能插座的场景拆细我总结了一份测试用例表实际执行的时候照表打勾覆盖率高得多编号测试项操作步骤预期结果实测结果TC01上电自启动插座上电不开控制开关设备自动连接 WiFi继电器保持断开通过TC02本地按键开关短按按键继电器吸合/释放LED 状态同步通过TC03App 远程开关App 发送开/关指令1 秒内继电器动作App 显示状态刷新通过TC04断电上电恢复关闭电源重新上电设备恢复断电前的继电器状态通过TC05WiFi 断开恢复路由器重启设备 2 分钟内自动重连并恢复在线通过TC06密码错误配网输入错误 WiFi 密码BLE 配网提示失败不会卡死通过TC07过量程负载接 2kW 电热水壶计量数据正确继电器不误动作通过TC08OTA 固件升级从 v1.0 升到 v1.1升级成功配置信息保留通过TC09电量统计精度接功率计对比读数误差小于 2%通过TC10长时间老化连续开关 1000 次无死机、无继电器卡死通过重点说下 TC04 断电上电恢复。很多用户在意插座断电后再来电能不能恢复断电前的状态。我的做法是在 flash 的 NVS 区域存取一个relay_state标志位上电时读取。这里有个细节不能用默认值因为第一次上电没有这个标志读取会失败必须先判断nvs_get_u8的返回值。6.2 自动化回归的实现思路手点测试做一轮两轮可以做十轮就崩溃了。我后来写了一个 Python 自动化脚本通过串口和 ESP32 通信把测试指令批量发进去再用脚本解析返回的日志自动判定测试是否通过。基本思路是这样import serial import time ser serial.Serial(COM3, 115200, timeout1) def send_cmd(cmd): ser.write(cmd.encode()) time.sleep(0.5) return ser.read_all().decode(errorsignore) # 测试继电器开关 100 次 for i in range(100): resp send_cmd(relay on\n) assert set relay ON in resp, f第{i1}次开失败 time.sleep(0.3) resp send_cmd(relay off\n) assert set relay OFF in resp, f第{i1}次关失败 time.sleep(0.3) print(100 次开关测试全部通过)这个脚本跑一轮不用管测试完看输出就行。自动化回归最有价值的场景是改完代码后跑全套用例确认没有引入新问题。我每次发布固件前都会让脚本把 TC01 到 TC10 全部过一遍至少能挡住八成的低级回归。6.3 兼容性测试不能省智能插座面向的用户手里路由器五花八门兼容性测试是功能测试里必不可少的一环。我这里列几个我实测出问题的场景路由器开启 WPA3 加密时ESP32 连接很慢而且容易失败。解决办法是在 menuconfig 里开启 WPA3 支持同时保留 WPA2 兼容模式。某些老路由器只支持 802.11b/g而 ESP32 默认启用 802.11n可能导致协商失败或速率极低。我在固件里加了一个配置项可以在配网时选择协议模式。路由器开了 DHCP 租约过短比如 1 小时设备到点续约失败后就掉线了。这个问题比较难复现但一旦出现用户感知非常明显。我最终的方案是应用层加了心跳检测逻辑检测到网络不通就主动重连。7. 三个疑难杂症的完整排查链路7.1 问题一插座上电瞬间继电器乱跳表面现象插电瞬间继电器会啪地吸合一下然后又断开。初步排查逻辑我先把继电器控制代码注释掉只留一个空循环问题依旧。这就排除了软件主动控制的问题把可疑范围缩小到硬件上。接着用万用表测 GPIO 引脚电压发现上电瞬间引脚确实有约 1.2V 的浮动电压说明是 GPIO 默认高阻态引起的。最终方案如前面 4.1 所述在硬件上加下拉电阻、在软件上调整初始化顺序。这个问题排查用了大半天但结论其实很简单核心经验是复位到初始化完成之间的这个时间段所有外设引脚的状态是不可控的设计时必须默认它是危险状态来处理。7.2 问题二设备运行几小时后自动掉线表面现象设备连上 WiFi 能正常跑几个小时然后毫无征兆地掉线不重启永远连不回来。排查过程我先在日志里加了几条调试输出记录每次 WiFi 断开的原因和当前的省电状态跑了半天抓到关键日志W (45678) wifi: disconnect reason: 5 I (45679) wifi: pm status: activereason 5 是找不到 AP。又查了联发科的文档和 ESP-IDF issue发现是省电模式导致的周期性问题。关闭省电后继续跑了一天一夜没有再复现确认为根因。这个问题的价值在于日志里的 disconnect reason 只是个结果真正的原因往往藏在触发这个结果之前的配置里。我后来养成了一个习惯任何 WiFi 问题先打印esp_wifi_get_ps的状态再看 keepalive 配置最后才是环境因素。7.3 问题三OTA 升级后设备变砖表面现象OTA 下载固件完成设备重启后无法正常启动串口日志卡在引导加载阶段进不了应用。排查过程我烧录的是合并固件merged.binFlash 分区表是默认的两层结构factory ota_0 ota_1。OTA 升级时新固件写到了 ota_0但启动时引导加载器去读 factory 分区里的固件结果发现被覆盖了或者镜像校验失败就卡住了。根因是我用错了烧录命令esptool.py write_flash 0x0 merged.bin把所有内容写到起始地址覆盖了 partition table。正确做法是先烧录一个带完整分区表的初始镜像然后在应用里通过 OTA 接口升级而不是通过串口直接刷合并包。解决后我重新烧录了 factory 镜像再用 App 走了一次 OTA升级正常。这个坑的教训是OTA 功能测试一定要在真机上完整走一遍从服务器下载到重启的全流程只测试打包流程没有任何意义。8. 回到调试软件本身选对一个工具少走一半弯路聊了这么多功能测试和踩坑记录最后想回到标题里的调试软件这个话题。很多开发者对调试软件的理解就是串口监视器但实际上嵌入式调试软件工具链比这宽得多我用得最顺手的几个PlatformIO 的 Serial Monitor直接集成日志过滤、时间戳、颜色高亮比 Arduino 自带的串口监视器好用太多。ESP-IDF 的 idf.py monitor支持将日志输出转成带颜色等级的终端界面还集成了 GDB 调试可以直接打断点。Wireshark配合路由器镜像端口看网络包定位和 WiFi/网络相关的问题非常高效。逻辑分析仪 PulseView看引脚时序、分析协议波形。QEMU 模拟器esp32 target在没有硬件的时候做一些纯逻辑的验证但不能替代真机测试。我个人推荐把 PlatformIO 作为日常主力主要原因是环境一致性做得很好——项目里的platformio.ini写清楚 board、framework 和 monitor 参数换一台电脑照样能编译烧录不用折腾环境。下面这个是我智能插座项目的配置片段[env:esp32dev] platform espressif32 board esp32dev framework arduino monitor_speed 115200 board_build.partitions custom_partitions.csvcustom_partitions.csv里我是这样定义的为 OTA 预留了两个 app 区# Name, Type, SubType, Offset, Size, Flags nvs, data, nvs, 0x9000, 0x5000, otadata, data, ota, 0xe000, 0x2000, app0, app, ota_0, 0x10000, 0x1F0000, app1, app, ota_1, 0x200000, 0x1F0000,分区分得好OTA 功能的测试才会顺畅。不然像我在 7.3 里踩的坑分区表被覆盖整个设备就只能连串口重新烧录了。调试软件的另一个隐藏价值是日志留痕。我在做 7×24 小时老化测试时把串口日志落盘保存跑完一整天再回去翻日志看有没有偶发的异常打印。很多偶发问题不持续盯日志根本发现不了即使发现了也没法复现而日志落盘给了事后分析的可能。还有个技巧在固件里加一个version日志宏每次启动打印固件版本和编译时间。调试的时候如果同时测了好几个版本的固件日志里一眼就能分清当前跑的是哪个版本不然测来测去发现测的是旧版固件那就纯浪费时间了。智能插座这个项目整体做下来我对调试软件功能测试这件事最大的体会是不要把调试和测试割裂成两个阶段调试软件贯穿开发全程功能测试也不是上线的最后一次检查而是每个环节都要随手做。把日志埋好、把工具用熟、把测试用例沉淀成脚本项目推进速度会明显上一个台阶。后续我还打算把计量芯片的数据做成可视化的能耗报表再把 BLE 配网升级成二维码配网这些都是在这个调试框架上继续扩展的事。
