#WorkBuddy# 实战：用 AI 工作台给 ESP32-S3 做一台欧姆定律实验台一台欧姆定律实验台

作为一名中学物理教师，同时也是个嵌入式爱好者，我最近用 ESP32-S3 做了一台“欧姆定律实验台”。主控是 ESP32-S3-N16R8，配一块 4.3 寸 800×480 的 RGB 屏和 GT911 电容触摸，界面用 LVGL 8.4 编写，能实时显示电压、电流、反算电阻，还能描出 I-U 特性曲线。整个固件 812KB，全程在 WorkBuddy 这个 AI 工作台上完成。这篇文章不讲产品介绍，只记录真机调试中三个“编译能过、开机就崩或静默失效”的硬核问题，以及我和 WorkBuddy 是怎么一步步把它们挖出来的。

之所以做这台设备，是因为传统分组实验里，指针电表要换档、读数靠估读，一节课光接电表就耗掉不少时间，数据还没法直接数字化。我希望屏幕能同时充当电压表、电流表和描点器：学生接好电路，读数实时显示，按键就能把数据点描到图上，点是否连成过原点的直线一目了然。这也是我第一个从底层驱动一路做到界面的 LVGL 项目。

图1 板背丝印确认型号：VIEWE UEDX80480043E-WB-B V1.1（ESP32-S3 + 4.3寸 RGB 触摸一体板）

WorkBuddy 对我帮助最大的不是“帮我写代码”，而是它能直接操作本地工程：读我磁盘上最新的 .ino 文件、跑编译脚本、抓串口日志。它托管的工具链目录（用户目录下的 .workbuddy 文件夹）里自带 Node 和 Python 环境，生成字体用的 lv_font_conv、抓串口用的 pyserial 都是开箱即用。我不需要在“装环境”上耗时间，只需要把现象描述清楚、把日志喂给它，然后一起判断根因。

第一个坑最致命：I2C 新旧驱动在链接层冲突。为了驱动 INA226 电流传感器，我最初按常规做法引入了 Arduino 的 Wire 库，并在板子初始化之前调用 Wire.begin，把“先建总线”这一步做对。烧录后板子根本不进主程序，开机直接循环 abort，串口刷出的关键信息如下图：

图2 开机循环 abort：CONFLICT! driver_ng 不允许与旧驱动同时使用

我把日志丢给 WorkBuddy，它没有猜，而是直接用 addr2line 把 PC 地址和调用链解码出来，崩溃调用链如下图：

图3 addr2line 解码：崩溃点在 do_global_ctors 的 check_i2c_driver_conflict

这条链说明了一切：崩溃点在全局构造函数阶段，一行用户代码都没执行到。根因是，arduino-esp32 3.3.11 核心里，Arduino Wire 已经换成了新版 i2c_master 驱动，而显示库 ESP32_Display_Panel 的触摸还在用旧版 i2c_driver_install，两套驱动又都占着 0 号 I2C 端口。核心在链接层检测到新旧驱动共存，开机直接 abort，和调用顺序完全无关，只要 #include 了 Wire.h 就已经输了。顺带一提，第三方 INA226 库内部也会调 Wire.begin，同样不能用。

正解是全程不碰 Wire：传感器驱动直接 include “driver/i2c.h”，用旧驱动 API 读写寄存器，和触摸同端口同驱动；把显示库板级文件里的 TOUCH_BUS_SKIP_INIT_HOST 宏置 1，让库不要自建总线；setup() 里在板子初始化之前手工装好旧驱动主机，之后触摸和传感器都复用这一条总线。改完烧录，崩溃循环立刻消失。

第二个坑很有迷惑性：INA226 配置字导致“假死”。传感器接上后读数偶尔正常、随后就冻结不动，只有断电重启才变一次，我一度以为是接线虚焊。WorkBuddy 陪我逐位核对配置寄存器时发现，我把配置字写成了 0x4938，最低三位是 000，对应 Power-down 模式，ADC 被关闭、寄存器冻结，读数自然不刷新。改回 0x4907（模式位 111，分流和母线连续转换，平均 16 次），约 35 毫秒出一组新数据，读数恢复实时跟随。这个坑不报错、不崩溃，全靠逐位核对寄存器才抓到。

第三个坑最隐蔽：LVGL 字体缺字，界面静默空白。LVGL 自带的 simsun 字体只有 1262 个字形，“压、阻、欧、姆”这些界面必备字都没有，缺字的位置直接显示空白，编译器一声不吭。我用 WorkBuddy 托管的 Node 环境跑 lv_font_conv，从 Windows 黑体里只打包本界面用到的汉字和单位符号，现场生成 16、24、34 三个字号的定制字体。这里又踩了两个子坑，都真实发生过。

一是生成命令必须加 --lv-include “lvgl.h”，否则默认生成的 include 路径在 Arduino 下编译直接失败；二是微安符号必须用希腊字母 μ（U+03BC），不能用微符号 µ（U+00B5），黑体里没有后者，运行时每次重绘都刷 “glyph dsc. not found for U+B5”，串口日志直接被淹没。告警现场与修复命令如下图：

图4 缺字告警刷屏：微符号 U+00B5 黑体缺失，改用希腊字母 U+03BC 后消除

除了这三个坑，点屏阶段还踩过一个触摸的坑。最初我把按压回调挂在 LVGL 的根对象上，结果手指按屏幕，红点完全不跟手，坐标停成一条横线。查文档才发现，LVGL 8 的事件默认不冒泡，而根对象上铺了一个全屏的装饰边框，它是可点击对象，直接吃掉了所有按压事件，根对象的回调永远收不到。正解是绕过对象命中测试，用 lv_indev_get_next() 直接遍历输入设备，每 20 毫秒轮询一次按压状态和坐标，同时把所有装饰性对象设为不可点击，改完之后红点才真正做到指尖跟随。

焊接完成后，我先跑了一个不碰显示库的 I2C 扫描固件做体检：0x40 的 INA226 返回厂家 ID 0x5449、芯片 ID 0x2260，和 0x5D 的 GT911 同总线稳定共存，证明芯片是真的“活着”，而不只是地址应答，扫描结果如下图：

图5 I2C 总线体检：0x40 INA226（mfr=0x5449 die=0x2260）与 0x5D GT911 共存

最终固件的启动日志也干净利落，面板初始化成功、LVGL 启动、UI 就绪，堆内存和 PSRAM 余量充足，启动日志如下图：

图6 最终启动日志：panel OK 800×480 ST7262，LVGL 与 UI 正常就绪

复盘这次开发，我有三点心得。第一，AI 工作台最适合处理“有证据的硬问题”：崩溃日志、寄存器配置、字体码点都是确定的事实，把真实日志喂给它，比让它凭空猜方案高效得多。第二，要让 AI 用工具而不是用嘴：addr2line 解码、总线扫描、逐位核对寄存器，这些动作产出的结论才可靠。第三，把踩坑过程沉淀成文档，我维护了 WORKFLOW 和 STATUS 两份记录，下一次换板子、换电脑，AI 和我都能快速复现。

以前我总觉得 AI 写嵌入式不靠谱，因为它看不到我的真机；但当它能读工程、跑脚本、解码日志之后，信息差被填平了，它给出的每一个结论我都能在串口和屏幕上复验。WorkBuddy 在这个项目里更像一个“能动手的结对工程师”，而不是一个问答框。对嵌入式开发者来说，真机日志就是最好的协作语言。

#WorkBuddy# 实战：用 AI 工作台给 ESP32-S3 做

#WorkBuddy# 实战：用 AI 工作台给 ESP32-S3 做一台中学物理探究电流与电压关系的实验台

硬件

人工智能

开发工具

基于ESP32-S3的AI工作台实战记录，展示WorkBuddy如何辅助开发欧姆定律实验台。文章深入剖析三个编译通过但运行崩溃的硬核问题：I2C新旧驱动冲突、INA226配置寄存器错误及LVGL字体缺失，通过addr2line解码、寄存器逐位核对等真实调试手段，提供完整解决方案，体现AI工具在嵌入式开发中的实际价值。

编译器

WorkBuddy 

Windows

Python

2026上云采购 | AI焕新·智启新局

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

#WorkBuddy# 实战：用 AI 工作台给 ESP32-S3 做

#WorkBuddy# 实战：用 AI 工作台给 ESP32-S3 做

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐