1. 从一块裸板到能用的桌面小终端这个项目到底在做什么Status Deck 这个概念说白了就是一块放在桌面上、能实时显示各种状态信息的小屏幕终端。你可以把它理解成一个“物理仪表盘”——天气、待办事项、服务器负载、消息提醒、股票行情甚至是你自己定义的各种数据都能通过它直观地展示出来。我做的这个版本核心是一块 ESP32-S3 开发板配合一块小尺寸的 TFT 屏幕通过无线网络和蓝牙两种方式跟外部世界通信最终做成一个可以摆在桌上、随时瞟一眼就能获取关键信息的设备。为什么选 ESP32-S3 而不是其他方案这个问题的答案贯穿了整个项目的技术选型逻辑。市面上做类似桌面小终端的方案其实不少比如用树莓派 Zero 加屏幕、用旧手机改造、用 Arduino 加各种模块拼装。但 ESP32-S3 有几个特性让它在这个场景下特别合适第一它自带 Wi-Fi 和蓝牙 5.0LE不需要额外挂模块硬件结构可以做得非常简洁第二它的算力对于驱动一块小屏幕、解析 JSON 数据、跑一个轻量级的 UI 框架来说绰绰有余双核 240MHz 的主频加上 512KB 的 SRAM 和可选的外部 PSRAM处理这些任务毫无压力第三它的功耗控制得很好如果做成电池供电的版本续航可以做到几天甚至几周第四它的生态非常成熟无论是乐鑫官方的 ESP-IDF 还是社区维护的 Arduino 核心和 MicroPython 固件都有大量的文档和示例可以参考。这个项目适合谁来参考如果你手头正好有一块 ESP32-S3 的开发板想做一个既有实用性又能学到东西的小项目那这个内容就是为你准备的。如果你之前只用过 Arduino Uno 或者 STM32 这类没有无线功能的单片机想跨入物联网设备开发的门槛ESP32-S3 是一个非常好的切入点。甚至如果你是一个纯软件开发者想了解一下嵌入式设备是怎么跟网络服务打交道的这个项目也能给你一个完整的视角——从硬件选型到固件开发从通信协议到数据格式从 UI 渲染到实际部署整条链路都会涉及到。我在这个项目里踩过的坑不算少从屏幕驱动的兼容性问题到蓝牙配对的稳定性从 JSON 解析的内存溢出到 Wi-Fi 重连的逻辑漏洞每一个问题都让我对这套技术栈有了更深的理解。接下来的内容会把这些经验完整地分享出来包括技术选型的思考过程、核心模块的实现细节、实操中遇到的典型问题以及解决方案。2. 技术栈选型为什么是这套组合而不是别的2.1 主控芯片ESP32-S3 的硬实力与软生态ESP32-S3 是乐鑫在 ESP32 基础上做的一次重要升级。它用的是 Xtensa LX7 双核处理器主频最高 240MHz相比初代 ESP32 的 LX6 在指令效率和 AI 加速方面都有提升。对于 Status Deck 这个场景来说最关键的是它支持 2.4GHz Wi-Fi802.11 b/g/n和 Bluetooth 5 (LE)这意味着设备可以同时具备两种无线通信能力而且不需要外挂任何模块。内存方面ESP32-S3 内置 512KB 的 SRAM对于跑 MicroPython 或者轻量级的 C 代码来说基本够用。但如果你要驱动一块分辨率较高的屏幕、同时还要解析 JSON 数据、维护多个网络连接内存就会比较紧张。这时候就需要用到外部 PSRAM。我用的这块开发板带了 8MB 的 Octal SPI PSRAM实际使用下来开了 PSRAM 之后整个系统的余量就非常充裕了屏幕的帧缓冲、JSON 解析的临时缓冲区都可以放在 PSRAM 里内部 SRAM 留给关键的任务栈和 DMA 缓冲区。这里有一个选型时容易忽略的点ESP32-S3 的 GPIO 数量和引脚复用能力。如果你选的屏幕用的是 SPI 接口那至少需要 5 根线SCK、MOSI、CS、DC、RST再加上背光控制、触摸中断如果用触摸屏的话引脚消耗还是不少的。ESP32-S3 有 45 个可编程 GPIO看起来很多但很多引脚有默认功能比如 strapping 引脚、USB 引脚、JTAG 引脚实际能自由使用的并没有那么多。我在设计电路的时候特意把屏幕的 SPI 引脚分配到了 IO11 到 IO14 这一组避开了 strapping 引脚和 USB 相关的 IO19、IO20这样在上电和下载程序的时候不会出现冲突。2.2 开发框架MicroPython 还是 ESP-IDF这是一个在社区里经常被讨论的问题。MicroPython 的优势在于开发速度快交互式的 REPL 环境让你可以一行一行地调试代码特别适合快速验证想法。ESP-IDF 的优势在于性能和底层控制能力你可以精确地管理内存、配置中断优先级、优化任务调度。我最终选择了 MicroPython 作为主要开发框架原因有几个。第一Status Deck 这个项目的核心逻辑是“获取数据-解析数据-显示数据”计算密集型的任务并不多MicroPython 的性能完全够用。第二MicroPython 的machine模块和network模块封装得很好初始化 SPI、I2C、Wi-Fi 这些外设只需要几行代码省去了大量底层配置的工作。第三MicroPython 的json模块是内置的解析 JSON 数据非常方便不需要额外引入 cJSON 这样的第三方库。第四社区里有大量针对 ESP32-S3 的 MicroPython 固件和示例代码遇到问题比较容易找到参考。当然MicroPython 也有它的局限性。比如它的垃圾回收机制在某些情况下会导致不可预测的延迟如果你在做需要严格实时响应的任务比如高速 PWM 输出或者精确的脉冲计数那还是得用 ESP-IDF 或者 Arduino 框架。但对于 Status Deck 来说屏幕刷新率不需要很高每秒几帧就够了网络请求也不是高频操作MicroPython 的实时性完全能满足需求。2.3 屏幕选型SPI TFT 还是 I2C OLED屏幕的选择直接影响到显示效果和开发复杂度。市面上常见的选项有几种SPI 接口的 TFT 彩屏比如 ST7789、ILI9341 驱动芯片、I2C 接口的 OLED 屏比如 SSD1306、以及 SPI 接口的墨水屏。我最终选的是 1.14 英寸的 ST7789 SPI TFT 彩屏分辨率 135x240。这个尺寸放在桌面上刚刚好不会太占地方显示几行文字和简单的图标完全够用。SPI 接口的刷新率比 I2C 高很多全屏刷新可以做到每秒 30 帧以上局部刷新更快。ST7789 这个驱动芯片在 MicroPython 里有现成的库支持初始化参数也比较简单。相比之下I2C OLED 屏虽然接线更简单只需要 SDA、SCL 两根线但刷新率低而且单色显示在展示丰富信息的时候不够直观。墨水屏的功耗极低适合电池供电的场景但刷新速度太慢不适合需要频繁更新数据的 Status Deck。这里有一个实操中的细节ST7789 的初始化参数里有一个“颜色反转”的设置。不同厂家生产的屏幕面板的默认颜色顺序可能不一样有的需要设置invertTrue有的不需要。如果你发现显示的颜色跟预期相反比如红色显示成青色那就是这个参数设错了。我一开始就是被这个问题困扰了很久后来查了屏幕的数据手册才确认需要开启颜色反转。2.4 通信协议BLE GATT 与 Wi-Fi TCP 的分工Status Deck 需要跟外部世界通信获取要显示的数据。我设计了两条通信路径一条是 Wi-Fi TCP用于设备主动从网络服务拉取数据另一条是 BLE GATT用于手机或者其他蓝牙设备向 Status Deck 推送数据。为什么不用一种协议搞定所有事情因为这两种场景的需求不一样。Wi-Fi TCP 适合设备主动去请求数据比如定时从天气 API 获取天气信息、从待办事项服务获取任务列表。这种方式下设备是客户端主动发起连接逻辑清晰实现简单。而 BLE GATT 适合被动接收数据比如手机上的 App 想把一条通知推送到 Status Deck 上显示这时候 Status Deck 作为 BLE 外设Peripheral手机作为中心设备Central通过 GATT 特征值来传输数据。BLE GATT 的数据模型需要理解几个核心概念。一个 BLE 设备可以定义多个 Service服务每个 Service 下面有多个 Characteristic特征值。每个 Characteristic 有一个 UUID 来标识还有一组属性读、写、通知等。Status Deck 上我定义了一个自定义 Service里面包含两个 Characteristic一个用于接收文本数据可写一个用于发送状态回执可通知。手机端往可写的 Characteristic 里写入 JSON 格式的数据Status Deck 解析后更新屏幕显示然后通过可通知的 Characteristic 把处理结果发回去。Wi-Fi TCP 这边我用的是一种简化的请求-响应模式。Status Deck 作为 TCP 客户端连接到指定的服务器地址和端口发送一个简单的请求比如一个 JSON 格式的查询指令服务器返回 JSON 格式的数据Status Deck 解析后更新显示。这种方式比 HTTP 更轻量省去了 HTTP 头部的开销对于嵌入式设备来说更友好。当然如果你要对接的是标准的 RESTful API那还是得用 HTTPMicroPython 的urequests模块可以处理这种情况。2.5 数据格式为什么选 JSON 而不是其他JSON 作为数据交换格式在嵌入式场景下有几个明显的优势。第一它是纯文本格式可读性好调试的时候可以直接在串口里看到原始数据不需要额外的解析工具。第二MicroPython 内置了json模块json.loads()和json.dumps()两个函数就能完成序列化和反序列化不需要引入第三方库。第三JSON 的结构灵活可以表示嵌套的对象和数组适合传输结构化的数据。但 JSON 也有它的缺点。相比 MessagePack 或者 CBOR 这样的二进制格式JSON 的冗余信息比较多同样的数据量JSON 的体积可能是二进制格式的两三倍。对于 Status Deck 来说每次传输的数据量并不大通常几百字节到几KB这点开销可以接受。而且 JSON 的可读性带来的调试便利性在开发阶段是非常有价值的。在 MicroPython 里解析 JSON 有一个需要注意的地方内存分配。json.loads()会把整个 JSON 字符串解析成一个 Python 字典或列表这个过程会分配新的内存。如果你的 JSON 数据很大比如超过 10KB在内存紧张的 ESP32-S3 上可能会触发MemoryError。我的做法是尽量控制单次传输的数据量把大的数据结构拆分成多次小的请求。另外解析完成后及时用del删除不再使用的对象帮助垃圾回收器尽快释放内存。3. 核心模块拆解从硬件连接到软件架构3.1 硬件连接与引脚分配先说一下我的硬件配置清单。主控是 ESP32-S3-DevKitC-1 开发板带 8MB PSRAM 和 16MB Flash。屏幕是 1.14 英寸 ST7789 SPI TFT分辨率 135x240。另外还有一个 EC11 旋转编码器用来做菜单导航和参数调节。供电方面开发阶段直接用 USB 供电后续如果要做成独立设备可以用 18650 锂电池加 TP4056 充电模块。引脚分配是这样的屏幕的 SPI 接口用 SPI2ESP32-S3 有两个 SPI 控制器SPI0 和 SPI1 通常保留给 Flash 和 PSRAM用户可用的是 SPI2 和 SPI3。SCK 接 IO12MOSI 接 IO11CS 接 IO10DC 接 IO9RST 接 IO8背光 BLK 接 IO7。旋转编码器的 A 相接 IO4B 相接 IO5按键接 IO6。这里有一个细节值得展开说一下SPI 的时钟频率。ST7789 支持的最高 SPI 时钟是 62.5MHz但实际能跑多快取决于你的布线质量和屏幕模块的质量。我一开始设的是 40MHz发现偶尔会出现花屏降到 26MHz 之后就非常稳定了。如果你也遇到类似的问题可以先把频率降下来测试确认是频率问题之后再逐步往上调。3.2 软件架构任务划分与内存管理MicroPython 在 ESP32-S3 上跑的时候底层其实是 FreeRTOS 在调度。但 MicroPython 层面我们通常用uasyncio来实现并发。我的软件架构分成了几个协程一个负责屏幕刷新一个负责 Wi-Fi 数据拉取一个负责 BLE 数据接收还有一个负责处理旋转编码器的输入。为什么用uasyncio而不是多线程因为 MicroPython 的_thread模块虽然可用但线程间的资源共享和同步比较麻烦容易出现竞态条件。uasyncio的协程模型是协作式的同一时间只有一个协程在运行不存在抢占的问题逻辑上更简单。当然这也意味着如果一个协程阻塞了比如在等待网络响应其他协程也会被卡住。所以我在写网络请求的时候都会设置超时时间避免无限等待。内存管理方面除了前面提到的用 PSRAM 存放帧缓冲和 JSON 数据之外还有一个技巧是预分配缓冲区。比如屏幕的帧缓冲我在初始化的时候就分配好一块固定大小的bytearray后续刷新的时候直接往里面写数据而不是每次都创建新的对象。这样可以减少垃圾回收的压力让系统运行更稳定。3.3 BLE GATT 服务的设计与实现BLE GATT 服务的设计需要考虑几个问题Service 和 Characteristic 的 UUID 怎么定数据怎么编码通知怎么发UUID 方面我用了自定义的 128 位 UUID而不是蓝牙 SIG 定义的标准 UUID。标准 UUID 是 16 位的比如电池服务是 0x180F设备信息服务是 0x180A。自定义 UUID 的好处是不会跟标准服务冲突而且可以用在线工具生成保证唯一性。我的 Service UUID 是6E400001-B5A3-F393-E0A9-E50E24DCCA9E这个其实是 Nordic UART Service 的 UUID社区里用得比较多各种 BLE 调试工具都能识别。Characteristic 的设计上我定义了两个一个是 RX Characteristic可写UUID 是6E400002-B5A3-F393-E0A9-E50E24DCCA9E用于接收手机发来的数据另一个是 TX Characteristic可通知UUID 是6E400003-B5A3-F393-E0A9-E50E24DCCA9E用于向手机发送回执。数据编码方面BLE 的 Characteristic 传输的是字节数组不是字符串。所以发送 JSON 数据的时候需要先encode(utf-8)转成字节接收的时候再decode(utf-8)转回字符串。这里有一个坑BLE 单次传输的数据量有限制默认的 MTU最大传输单元是 23 字节减去 3 字节的 ATT 头部实际能传的数据只有 20 字节。如果要传更大的数据要么协商更大的 MTUESP32-S3 支持最大 517 字节要么在应用层做分包处理。我的做法是在初始化的时候请求一个较大的 MTU然后在发送端做分包接收端做重组。3.4 Wi-Fi 连接与 TCP 通信的稳定性处理Wi-Fi 连接的稳定性是嵌入式设备的一个老大难问题。ESP32-S3 的 Wi-Fi 驱动虽然已经比较成熟但在实际使用中还是会遇到断连、重连失败、IP 获取超时等问题。我的处理策略是第一在连接 Wi-Fi 的时候设置合理的超时时间不要无限等待。第二连接成功后启动一个看门狗协程定期检查 Wi-Fi 状态如果发现断连就自动重连。第三重连的时候采用指数退避策略第一次等 1 秒第二次等 2 秒第三次等 4 秒最多等到 30 秒避免频繁重连导致路由器拒绝服务。第四在 TCP 通信的时候每次请求都设置超时如果超时就关闭连接重新建立不要在一个已经失效的连接上反复尝试。TCP 通信这边我用的是socket模块。创建一个 socket连接到服务器发送请求接收响应然后关闭连接。这种短连接的方式虽然每次都要重新建立连接但逻辑简单不容易出现连接状态不一致的问题。如果你需要保持长连接那就需要处理心跳包和断线重连的逻辑复杂度会高不少。4. 实操过程从零搭建一个可运行的 Status Deck4.1 固件烧录与环境搭建第一步是给 ESP32-S3 烧录 MicroPython 固件。去 MicroPython 官网下载最新的 ESP32-S3 固件注意要选对型号ESP32-S3 和 ESP32-S3 带 PSRAM 的版本固件不一样。然后用esptool.py烧录esptool.py --chip esp32s3 --port /dev/ttyUSB0 erase_flash esptool.py --chip esp32s3 --port /dev/ttyUSB0 write_flash -z 0x0 ESP32_GENERIC_S3-20240105-v1.22.1.bin烧录完成后用串口工具比如mpremote或者screen连接到开发板应该能看到 MicroPython 的 REPL 提示符。这时候可以测试一下基本功能import machine import time led machine.Pin(2, machine.Pin.OUT) while True: led.value(not led.value()) time.sleep(0.5)如果板载 LED 开始闪烁说明固件烧录成功环境搭建完成。4.2 屏幕驱动与显示测试接下来是屏幕驱动。ST7789 的 MicroPython 驱动在 GitHub 上有好几个版本我用的是st7789_mpy这个库。把驱动文件上传到开发板后初始化屏幕import st7789 import machine spi machine.SPI(2, baudrate26000000, polarity0, phase0, sckmachine.Pin(12), mosimachine.Pin(11)) tft st7789.ST7789(spi, 135, 240, resetmachine.Pin(8, machine.Pin.OUT), dcmachine.Pin(9, machine.Pin.OUT), csmachine.Pin(10, machine.Pin.OUT), backlightmachine.Pin(7, machine.Pin.OUT), rotation1) tft.init() tft.fill(st7789.BLACK) tft.text(Hello Status Deck, 10, 10, st7789.WHITE)如果屏幕显示正常说明驱动配置正确。如果出现花屏或者颜色不对检查前面提到的颜色反转设置和 SPI 频率。4.3 BLE GATT 服务的代码实现BLE 部分的代码基于 MicroPython 的bluetooth模块。先初始化 BLEimport bluetooth ble bluetooth.BLE() ble.active(True)然后定义 Service 和 Characteristic 的 UUID注册 GATT 服务from ble_advertising import advertising_payload _IRQ_CENTRAL_CONNECT 1 _IRQ_CENTRAL_DISCONNECT 2 _IRQ_GATTS_WRITE 3 RX_UUID bluetooth.UUID(6E400002-B5A3-F393-E0A9-E50E24DCCA9E) TX_UUID bluetooth.UUID(6E400003-B5A3-F393-E0A9-E50E24DCCA9E) RX_CHAR (RX_UUID, bluetooth.FLAG_WRITE | bluetooth.FLAG_WRITE_NO_RESPONSE) TX_CHAR (TX_UUID, bluetooth.FLAG_NOTIFY) SERVICE (bluetooth.UUID(6E400001-B5A3-F393-E0A9-E50E24DCCA9E), (RX_CHAR, TX_CHAR)) ((rx_handle, tx_handle),) ble.gatts_register_services((SERVICE,))注册完成后开始广播让手机能发现这个设备payload advertising_payload(nameStatusDeck) ble.gap_advertise(100000, adv_datapayload)手机端用 BLE 调试助手比如 nRF Connect 或者 LightBlue连接后往 RX Characteristic 写入 JSON 数据Status Deck 就能收到并处理。4.4 Wi-Fi 数据拉取与 JSON 解析Wi-Fi 连接和 TCP 通信的代码大概长这样import network import socket import json wlan network.WLAN(network.STA_IF) wlan.active(True) wlan.connect(SSID, PASSWORD) while not wlan.isconnected(): time.sleep(0.5) addr socket.getaddrinfo(api.example.com, 80)[0][-1] s socket.socket() s.settimeout(5) s.connect(addr) s.send(bGET /status HTTP/1.0\r\nHost: api.example.com\r\n\r\n) data s.recv(1024) s.close() json_str data.decode(utf-8).split(\r\n\r\n)[1] status json.loads(json_str)解析出来的status是一个 Python 字典可以直接用来更新屏幕显示。4.5 主循环与任务调度最后把所有模块整合到一个主循环里用uasyncio来调度import uasyncio as asyncio async def display_task(): while True: tft.fill(st7789.BLACK) tft.text(fTemp: {status.get(temp, --)}C, 10, 10, st7789.WHITE) tft.text(fHumidity: {status.get(humidity, --)}%, 10, 30, st7789.WHITE) await asyncio.sleep(1) async def wifi_task(): while True: await fetch_data() await asyncio.sleep(30) async def main(): await asyncio.gather(display_task(), wifi_task()) asyncio.run(main())这样屏幕每秒钟刷新一次Wi-Fi 数据每 30 秒拉取一次两个任务互不干扰。5. 常见问题与排查技巧实录5.1 BLE 配对失败或连接不稳定这是我在开发过程中遇到的最头疼的问题之一。现象是手机能搜索到 Status Deck 的广播但连接的时候经常失败或者连接成功后很快又断开。排查下来原因主要有几个。第一广播间隔设得太短导致 BLE 射频一直在工作功耗高而且容易跟 Wi-Fi 产生干扰。我把广播间隔从 100ms 调整到 500ms 之后稳定性明显提升。第二MTU 协商失败。有些手机默认的 MTU 比较小如果 Status Deck 请求的 MTU 超过了手机支持的范围协商就会失败。我的做法是先请求一个保守的值比如 128 字节如果协商成功再尝试更大的值。第三Wi-Fi 和 BLE 共存时的射频冲突。ESP32-S3 的 Wi-Fi 和 BLE 共用同一个射频前端如果 Wi-Fi 正在大量传输数据BLE 的响应就会变慢甚至丢包。解决办法是尽量错开 Wi-Fi 和 BLE 的高峰期比如 Wi-Fi 拉取数据的时候暂停 BLE 广播。5.2 JSON 解析报错或内存不足JSON 解析报错通常有两种情况一种是 JSON 格式本身有问题比如缺少引号、多了逗号、括号不匹配另一种是数据量太大解析过程中内存不够。对于格式问题我的建议是在发送端做严格的校验确保生成的 JSON 是合法的。接收端可以用try...except包裹json.loads()捕获异常后打印原始字符串方便定位问题。对于内存问题前面提到过尽量控制单次传输的数据量把大的 JSON 拆分成多次小的请求。另外MicroPython 的json模块在解析的时候会创建大量的临时对象如果内存碎片比较严重即使总内存够用也可能分配失败。定期手动调用gc.collect()可以帮助整理内存碎片。5.3 屏幕显示异常花屏、颜色错误、刷新慢屏幕问题我遇到过三种。第一种是花屏屏幕上出现随机噪点或者条纹。这通常是 SPI 时钟太快或者布线太长导致的信号完整性问题。降低 SPI 频率、缩短杜邦线长度、在 SCK 和 MOSI 上串联 33 欧姆的电阻都能改善这个问题。第二种是颜色错误比如红色显示成蓝色。这是颜色格式设置的问题。ST7789 支持 RGB565 和 BGR565 两种颜色格式如果设置反了红色和蓝色就会互换。在初始化的时候调整color_order参数即可。第三种是刷新慢全屏刷新要好几秒。这通常是因为没有使用 DMA直接内存访问传输。MicroPython 的 ST7789 驱动如果支持 DMA刷新速度会快很多。另外只刷新变化的部分局部刷新而不是全屏刷新也能显著提升响应速度。5.4 Wi-Fi 连接超时或频繁断连Wi-Fi 问题我在前面已经提到了一些处理策略这里再补充几个排查技巧。第一检查路由器的信道设置。如果路由器用的是 12 或 13 信道而 ESP32-S3 的 Wi-Fi 驱动默认只支持 1 到 11 信道那就连不上。解决办法是在路由器里把信道改成 1 到 11 之间的值。第二检查电源供应。ESP32-S3 在 Wi-Fi 传输的时候瞬间电流可能达到 500mA如果 USB 线质量不好或者供电不足就会导致电压跌落Wi-Fi 断连。换一根短而粗的 USB 线或者用带外部供电的 USB Hub通常能解决。第三如果周围 Wi-Fi 网络很多信道拥堵严重可以尝试在代码里主动扫描并选择最空闲的信道。5.5 常见问题速查表问题现象可能原因排查方法解决方案BLE 连接失败广播间隔太短、MTU 协商失败用 nRF Connect 查看广播参数和 MTU增大广播间隔、降低 MTU 请求值JSON 解析报错格式错误、内存不足打印原始字符串、检查内存使用校验 JSON 格式、拆分大数据、手动 gc屏幕花屏SPI 频率太高、布线太长降低频率测试、检查接线降频、缩短线长、串联电阻颜色错误颜色格式设置反了显示红绿蓝三色测试调整 color_order 参数Wi-Fi 断连信道不兼容、供电不足检查路由器信道、测量电压改信道、换 USB 线、加电容刷新慢未使用 DMA、全屏刷新查看驱动是否支持 DMA启用 DMA、改用局部刷新6. 一些实操心得和后续扩展方向这个项目从开始到基本能用大概花了我两个周末的时间。其中大部分时间不是在写代码而是在调试硬件和排查各种奇怪的问题。如果你也要做类似的东西我的建议是先把最小系统跑通——屏幕能亮、Wi-Fi 能连、BLE 能广播——然后再逐步往上加功能。不要一上来就把所有模块都接好那样出了问题很难定位是哪个部分的原因。另外MicroPython 的 REPL 是你最好的朋友。遇到问题的时候不要急着改代码重新烧录先在 REPL 里一行一行地测试确认每个模块都能正常工作再把它们组合起来。这样效率会高很多。后续如果要扩展有几个方向可以考虑。一是加入电池管理做成完全无线的桌面设备二是增加更多的数据源比如接入日历、邮件、GitHub 通知等三是做一个手机端的配置 App通过 BLE 来修改 Status Deck 的显示内容和刷新频率四是把外壳用 3D 打印做出来让它看起来更像一个成品而不是一个开发板。这些扩展每一个都涉及到新的技术点但核心的架构——ESP32-S3 加 MicroPython 加 BLE/Wi-Fi 加 JSON——是不变的。把这套基础打牢后面的扩展就是水到渠成的事情。 
长河君 · 2026/11/4 22:10:02 · 阅读 1.2k ESP32-S3 + MicroPython 打造桌面状态终端：从硬件选型到BLE/Wi-Fi通信
1. 从一块裸板到能用的桌面小终端这个项目到底在做什么Status Deck 这个概念说白了就是一块放在桌面上、能实时显示各种状态信息的小屏幕终端。你可以把它理解成一个“物理仪表盘”——天气、待办事项、服务器负载、消息提醒、股票行情甚至是你自己定义的各种数据都能通过它直观地展示出来。我做的这个版本核心是一块 ESP32-S3 开发板配合一块小尺寸的 TFT 屏幕通过无线网络和蓝牙两种方式跟外部世界通信最终做成一个可以摆在桌上、随时瞟一眼就能获取关键信息的设备。为什么选 ESP32-S3 而不是其他方案这个问题的答案贯穿了整个项目的技术选型逻辑。市面上做类似桌面小终端的方案其实不少比如用树莓派 Zero 加屏幕、用旧手机改造、用 Arduino 加各种模块拼装。但 ESP32-S3 有几个特性让它在这个场景下特别合适第一它自带 Wi-Fi 和蓝牙 5.0LE不需要额外挂模块硬件结构可以做得非常简洁第二它的算力对于驱动一块小屏幕、解析 JSON 数据、跑一个轻量级的 UI 框架来说绰绰有余双核 240MHz 的主频加上 512KB 的 SRAM 和可选的外部 PSRAM处理这些任务毫无压力第三它的功耗控制得很好如果做成电池供电的版本续航可以做到几天甚至几周第四它的生态非常成熟无论是乐鑫官方的 ESP-IDF 还是社区维护的 Arduino 核心和 MicroPython 固件都有大量的文档和示例可以参考。这个项目适合谁来参考如果你手头正好有一块 ESP32-S3 的开发板想做一个既有实用性又能学到东西的小项目那这个内容就是为你准备的。如果你之前只用过 Arduino Uno 或者 STM32 这类没有无线功能的单片机想跨入物联网设备开发的门槛ESP32-S3 是一个非常好的切入点。甚至如果你是一个纯软件开发者想了解一下嵌入式设备是怎么跟网络服务打交道的这个项目也能给你一个完整的视角——从硬件选型到固件开发从通信协议到数据格式从 UI 渲染到实际部署整条链路都会涉及到。我在这个项目里踩过的坑不算少从屏幕驱动的兼容性问题到蓝牙配对的稳定性从 JSON 解析的内存溢出到 Wi-Fi 重连的逻辑漏洞每一个问题都让我对这套技术栈有了更深的理解。接下来的内容会把这些经验完整地分享出来包括技术选型的思考过程、核心模块的实现细节、实操中遇到的典型问题以及解决方案。2. 技术栈选型为什么是这套组合而不是别的2.1 主控芯片ESP32-S3 的硬实力与软生态ESP32-S3 是乐鑫在 ESP32 基础上做的一次重要升级。它用的是 Xtensa LX7 双核处理器主频最高 240MHz相比初代 ESP32 的 LX6 在指令效率和 AI 加速方面都有提升。对于 Status Deck 这个场景来说最关键的是它支持 2.4GHz Wi-Fi802.11 b/g/n和 Bluetooth 5 (LE)这意味着设备可以同时具备两种无线通信能力而且不需要外挂任何模块。内存方面ESP32-S3 内置 512KB 的 SRAM对于跑 MicroPython 或者轻量级的 C 代码来说基本够用。但如果你要驱动一块分辨率较高的屏幕、同时还要解析 JSON 数据、维护多个网络连接内存就会比较紧张。这时候就需要用到外部 PSRAM。我用的这块开发板带了 8MB 的 Octal SPI PSRAM实际使用下来开了 PSRAM 之后整个系统的余量就非常充裕了屏幕的帧缓冲、JSON 解析的临时缓冲区都可以放在 PSRAM 里内部 SRAM 留给关键的任务栈和 DMA 缓冲区。这里有一个选型时容易忽略的点ESP32-S3 的 GPIO 数量和引脚复用能力。如果你选的屏幕用的是 SPI 接口那至少需要 5 根线SCK、MOSI、CS、DC、RST再加上背光控制、触摸中断如果用触摸屏的话引脚消耗还是不少的。ESP32-S3 有 45 个可编程 GPIO看起来很多但很多引脚有默认功能比如 strapping 引脚、USB 引脚、JTAG 引脚实际能自由使用的并没有那么多。我在设计电路的时候特意把屏幕的 SPI 引脚分配到了 IO11 到 IO14 这一组避开了 strapping 引脚和 USB 相关的 IO19、IO20这样在上电和下载程序的时候不会出现冲突。2.2 开发框架MicroPython 还是 ESP-IDF这是一个在社区里经常被讨论的问题。MicroPython 的优势在于开发速度快交互式的 REPL 环境让你可以一行一行地调试代码特别适合快速验证想法。ESP-IDF 的优势在于性能和底层控制能力你可以精确地管理内存、配置中断优先级、优化任务调度。我最终选择了 MicroPython 作为主要开发框架原因有几个。第一Status Deck 这个项目的核心逻辑是“获取数据-解析数据-显示数据”计算密集型的任务并不多MicroPython 的性能完全够用。第二MicroPython 的machine模块和network模块封装得很好初始化 SPI、I2C、Wi-Fi 这些外设只需要几行代码省去了大量底层配置的工作。第三MicroPython 的json模块是内置的解析 JSON 数据非常方便不需要额外引入 cJSON 这样的第三方库。第四社区里有大量针对 ESP32-S3 的 MicroPython 固件和示例代码遇到问题比较容易找到参考。当然MicroPython 也有它的局限性。比如它的垃圾回收机制在某些情况下会导致不可预测的延迟如果你在做需要严格实时响应的任务比如高速 PWM 输出或者精确的脉冲计数那还是得用 ESP-IDF 或者 Arduino 框架。但对于 Status Deck 来说屏幕刷新率不需要很高每秒几帧就够了网络请求也不是高频操作MicroPython 的实时性完全能满足需求。2.3 屏幕选型SPI TFT 还是 I2C OLED屏幕的选择直接影响到显示效果和开发复杂度。市面上常见的选项有几种SPI 接口的 TFT 彩屏比如 ST7789、ILI9341 驱动芯片、I2C 接口的 OLED 屏比如 SSD1306、以及 SPI 接口的墨水屏。我最终选的是 1.14 英寸的 ST7789 SPI TFT 彩屏分辨率 135x240。这个尺寸放在桌面上刚刚好不会太占地方显示几行文字和简单的图标完全够用。SPI 接口的刷新率比 I2C 高很多全屏刷新可以做到每秒 30 帧以上局部刷新更快。ST7789 这个驱动芯片在 MicroPython 里有现成的库支持初始化参数也比较简单。相比之下I2C OLED 屏虽然接线更简单只需要 SDA、SCL 两根线但刷新率低而且单色显示在展示丰富信息的时候不够直观。墨水屏的功耗极低适合电池供电的场景但刷新速度太慢不适合需要频繁更新数据的 Status Deck。这里有一个实操中的细节ST7789 的初始化参数里有一个“颜色反转”的设置。不同厂家生产的屏幕面板的默认颜色顺序可能不一样有的需要设置invertTrue有的不需要。如果你发现显示的颜色跟预期相反比如红色显示成青色那就是这个参数设错了。我一开始就是被这个问题困扰了很久后来查了屏幕的数据手册才确认需要开启颜色反转。2.4 通信协议BLE GATT 与 Wi-Fi TCP 的分工Status Deck 需要跟外部世界通信获取要显示的数据。我设计了两条通信路径一条是 Wi-Fi TCP用于设备主动从网络服务拉取数据另一条是 BLE GATT用于手机或者其他蓝牙设备向 Status Deck 推送数据。为什么不用一种协议搞定所有事情因为这两种场景的需求不一样。Wi-Fi TCP 适合设备主动去请求数据比如定时从天气 API 获取天气信息、从待办事项服务获取任务列表。这种方式下设备是客户端主动发起连接逻辑清晰实现简单。而 BLE GATT 适合被动接收数据比如手机上的 App 想把一条通知推送到 Status Deck 上显示这时候 Status Deck 作为 BLE 外设Peripheral手机作为中心设备Central通过 GATT 特征值来传输数据。BLE GATT 的数据模型需要理解几个核心概念。一个 BLE 设备可以定义多个 Service服务每个 Service 下面有多个 Characteristic特征值。每个 Characteristic 有一个 UUID 来标识还有一组属性读、写、通知等。Status Deck 上我定义了一个自定义 Service里面包含两个 Characteristic一个用于接收文本数据可写一个用于发送状态回执可通知。手机端往可写的 Characteristic 里写入 JSON 格式的数据Status Deck 解析后更新屏幕显示然后通过可通知的 Characteristic 把处理结果发回去。Wi-Fi TCP 这边我用的是一种简化的请求-响应模式。Status Deck 作为 TCP 客户端连接到指定的服务器地址和端口发送一个简单的请求比如一个 JSON 格式的查询指令服务器返回 JSON 格式的数据Status Deck 解析后更新显示。这种方式比 HTTP 更轻量省去了 HTTP 头部的开销对于嵌入式设备来说更友好。当然如果你要对接的是标准的 RESTful API那还是得用 HTTPMicroPython 的urequests模块可以处理这种情况。2.5 数据格式为什么选 JSON 而不是其他JSON 作为数据交换格式在嵌入式场景下有几个明显的优势。第一它是纯文本格式可读性好调试的时候可以直接在串口里看到原始数据不需要额外的解析工具。第二MicroPython 内置了json模块json.loads()和json.dumps()两个函数就能完成序列化和反序列化不需要引入第三方库。第三JSON 的结构灵活可以表示嵌套的对象和数组适合传输结构化的数据。但 JSON 也有它的缺点。相比 MessagePack 或者 CBOR 这样的二进制格式JSON 的冗余信息比较多同样的数据量JSON 的体积可能是二进制格式的两三倍。对于 Status Deck 来说每次传输的数据量并不大通常几百字节到几KB这点开销可以接受。而且 JSON 的可读性带来的调试便利性在开发阶段是非常有价值的。在 MicroPython 里解析 JSON 有一个需要注意的地方内存分配。json.loads()会把整个 JSON 字符串解析成一个 Python 字典或列表这个过程会分配新的内存。如果你的 JSON 数据很大比如超过 10KB在内存紧张的 ESP32-S3 上可能会触发MemoryError。我的做法是尽量控制单次传输的数据量把大的数据结构拆分成多次小的请求。另外解析完成后及时用del删除不再使用的对象帮助垃圾回收器尽快释放内存。3. 核心模块拆解从硬件连接到软件架构3.1 硬件连接与引脚分配先说一下我的硬件配置清单。主控是 ESP32-S3-DevKitC-1 开发板带 8MB PSRAM 和 16MB Flash。屏幕是 1.14 英寸 ST7789 SPI TFT分辨率 135x240。另外还有一个 EC11 旋转编码器用来做菜单导航和参数调节。供电方面开发阶段直接用 USB 供电后续如果要做成独立设备可以用 18650 锂电池加 TP4056 充电模块。引脚分配是这样的屏幕的 SPI 接口用 SPI2ESP32-S3 有两个 SPI 控制器SPI0 和 SPI1 通常保留给 Flash 和 PSRAM用户可用的是 SPI2 和 SPI3。SCK 接 IO12MOSI 接 IO11CS 接 IO10DC 接 IO9RST 接 IO8背光 BLK 接 IO7。旋转编码器的 A 相接 IO4B 相接 IO5按键接 IO6。这里有一个细节值得展开说一下SPI 的时钟频率。ST7789 支持的最高 SPI 时钟是 62.5MHz但实际能跑多快取决于你的布线质量和屏幕模块的质量。我一开始设的是 40MHz发现偶尔会出现花屏降到 26MHz 之后就非常稳定了。如果你也遇到类似的问题可以先把频率降下来测试确认是频率问题之后再逐步往上调。3.2 软件架构任务划分与内存管理MicroPython 在 ESP32-S3 上跑的时候底层其实是 FreeRTOS 在调度。但 MicroPython 层面我们通常用uasyncio来实现并发。我的软件架构分成了几个协程一个负责屏幕刷新一个负责 Wi-Fi 数据拉取一个负责 BLE 数据接收还有一个负责处理旋转编码器的输入。为什么用uasyncio而不是多线程因为 MicroPython 的_thread模块虽然可用但线程间的资源共享和同步比较麻烦容易出现竞态条件。uasyncio的协程模型是协作式的同一时间只有一个协程在运行不存在抢占的问题逻辑上更简单。当然这也意味着如果一个协程阻塞了比如在等待网络响应其他协程也会被卡住。所以我在写网络请求的时候都会设置超时时间避免无限等待。内存管理方面除了前面提到的用 PSRAM 存放帧缓冲和 JSON 数据之外还有一个技巧是预分配缓冲区。比如屏幕的帧缓冲我在初始化的时候就分配好一块固定大小的bytearray后续刷新的时候直接往里面写数据而不是每次都创建新的对象。这样可以减少垃圾回收的压力让系统运行更稳定。3.3 BLE GATT 服务的设计与实现BLE GATT 服务的设计需要考虑几个问题Service 和 Characteristic 的 UUID 怎么定数据怎么编码通知怎么发UUID 方面我用了自定义的 128 位 UUID而不是蓝牙 SIG 定义的标准 UUID。标准 UUID 是 16 位的比如电池服务是 0x180F设备信息服务是 0x180A。自定义 UUID 的好处是不会跟标准服务冲突而且可以用在线工具生成保证唯一性。我的 Service UUID 是6E400001-B5A3-F393-E0A9-E50E24DCCA9E这个其实是 Nordic UART Service 的 UUID社区里用得比较多各种 BLE 调试工具都能识别。Characteristic 的设计上我定义了两个一个是 RX Characteristic可写UUID 是6E400002-B5A3-F393-E0A9-E50E24DCCA9E用于接收手机发来的数据另一个是 TX Characteristic可通知UUID 是6E400003-B5A3-F393-E0A9-E50E24DCCA9E用于向手机发送回执。数据编码方面BLE 的 Characteristic 传输的是字节数组不是字符串。所以发送 JSON 数据的时候需要先encode(utf-8)转成字节接收的时候再decode(utf-8)转回字符串。这里有一个坑BLE 单次传输的数据量有限制默认的 MTU最大传输单元是 23 字节减去 3 字节的 ATT 头部实际能传的数据只有 20 字节。如果要传更大的数据要么协商更大的 MTUESP32-S3 支持最大 517 字节要么在应用层做分包处理。我的做法是在初始化的时候请求一个较大的 MTU然后在发送端做分包接收端做重组。3.4 Wi-Fi 连接与 TCP 通信的稳定性处理Wi-Fi 连接的稳定性是嵌入式设备的一个老大难问题。ESP32-S3 的 Wi-Fi 驱动虽然已经比较成熟但在实际使用中还是会遇到断连、重连失败、IP 获取超时等问题。我的处理策略是第一在连接 Wi-Fi 的时候设置合理的超时时间不要无限等待。第二连接成功后启动一个看门狗协程定期检查 Wi-Fi 状态如果发现断连就自动重连。第三重连的时候采用指数退避策略第一次等 1 秒第二次等 2 秒第三次等 4 秒最多等到 30 秒避免频繁重连导致路由器拒绝服务。第四在 TCP 通信的时候每次请求都设置超时如果超时就关闭连接重新建立不要在一个已经失效的连接上反复尝试。TCP 通信这边我用的是socket模块。创建一个 socket连接到服务器发送请求接收响应然后关闭连接。这种短连接的方式虽然每次都要重新建立连接但逻辑简单不容易出现连接状态不一致的问题。如果你需要保持长连接那就需要处理心跳包和断线重连的逻辑复杂度会高不少。4. 实操过程从零搭建一个可运行的 Status Deck4.1 固件烧录与环境搭建第一步是给 ESP32-S3 烧录 MicroPython 固件。去 MicroPython 官网下载最新的 ESP32-S3 固件注意要选对型号ESP32-S3 和 ESP32-S3 带 PSRAM 的版本固件不一样。然后用esptool.py烧录esptool.py --chip esp32s3 --port /dev/ttyUSB0 erase_flash esptool.py --chip esp32s3 --port /dev/ttyUSB0 write_flash -z 0x0 ESP32_GENERIC_S3-20240105-v1.22.1.bin烧录完成后用串口工具比如mpremote或者screen连接到开发板应该能看到 MicroPython 的 REPL 提示符。这时候可以测试一下基本功能import machine import time led machine.Pin(2, machine.Pin.OUT) while True: led.value(not led.value()) time.sleep(0.5)如果板载 LED 开始闪烁说明固件烧录成功环境搭建完成。4.2 屏幕驱动与显示测试接下来是屏幕驱动。ST7789 的 MicroPython 驱动在 GitHub 上有好几个版本我用的是st7789_mpy这个库。把驱动文件上传到开发板后初始化屏幕import st7789 import machine spi machine.SPI(2, baudrate26000000, polarity0, phase0, sckmachine.Pin(12), mosimachine.Pin(11)) tft st7789.ST7789(spi, 135, 240, resetmachine.Pin(8, machine.Pin.OUT), dcmachine.Pin(9, machine.Pin.OUT), csmachine.Pin(10, machine.Pin.OUT), backlightmachine.Pin(7, machine.Pin.OUT), rotation1) tft.init() tft.fill(st7789.BLACK) tft.text(Hello Status Deck, 10, 10, st7789.WHITE)如果屏幕显示正常说明驱动配置正确。如果出现花屏或者颜色不对检查前面提到的颜色反转设置和 SPI 频率。4.3 BLE GATT 服务的代码实现BLE 部分的代码基于 MicroPython 的bluetooth模块。先初始化 BLEimport bluetooth ble bluetooth.BLE() ble.active(True)然后定义 Service 和 Characteristic 的 UUID注册 GATT 服务from ble_advertising import advertising_payload _IRQ_CENTRAL_CONNECT 1 _IRQ_CENTRAL_DISCONNECT 2 _IRQ_GATTS_WRITE 3 RX_UUID bluetooth.UUID(6E400002-B5A3-F393-E0A9-E50E24DCCA9E) TX_UUID bluetooth.UUID(6E400003-B5A3-F393-E0A9-E50E24DCCA9E) RX_CHAR (RX_UUID, bluetooth.FLAG_WRITE | bluetooth.FLAG_WRITE_NO_RESPONSE) TX_CHAR (TX_UUID, bluetooth.FLAG_NOTIFY) SERVICE (bluetooth.UUID(6E400001-B5A3-F393-E0A9-E50E24DCCA9E), (RX_CHAR, TX_CHAR)) ((rx_handle, tx_handle),) ble.gatts_register_services((SERVICE,))注册完成后开始广播让手机能发现这个设备payload advertising_payload(nameStatusDeck) ble.gap_advertise(100000, adv_datapayload)手机端用 BLE 调试助手比如 nRF Connect 或者 LightBlue连接后往 RX Characteristic 写入 JSON 数据Status Deck 就能收到并处理。4.4 Wi-Fi 数据拉取与 JSON 解析Wi-Fi 连接和 TCP 通信的代码大概长这样import network import socket import json wlan network.WLAN(network.STA_IF) wlan.active(True) wlan.connect(SSID, PASSWORD) while not wlan.isconnected(): time.sleep(0.5) addr socket.getaddrinfo(api.example.com, 80)[0][-1] s socket.socket() s.settimeout(5) s.connect(addr) s.send(bGET /status HTTP/1.0\r\nHost: api.example.com\r\n\r\n) data s.recv(1024) s.close() json_str data.decode(utf-8).split(\r\n\r\n)[1] status json.loads(json_str)解析出来的status是一个 Python 字典可以直接用来更新屏幕显示。4.5 主循环与任务调度最后把所有模块整合到一个主循环里用uasyncio来调度import uasyncio as asyncio async def display_task(): while True: tft.fill(st7789.BLACK) tft.text(fTemp: {status.get(temp, --)}C, 10, 10, st7789.WHITE) tft.text(fHumidity: {status.get(humidity, --)}%, 10, 30, st7789.WHITE) await asyncio.sleep(1) async def wifi_task(): while True: await fetch_data() await asyncio.sleep(30) async def main(): await asyncio.gather(display_task(), wifi_task()) asyncio.run(main())这样屏幕每秒钟刷新一次Wi-Fi 数据每 30 秒拉取一次两个任务互不干扰。5. 常见问题与排查技巧实录5.1 BLE 配对失败或连接不稳定这是我在开发过程中遇到的最头疼的问题之一。现象是手机能搜索到 Status Deck 的广播但连接的时候经常失败或者连接成功后很快又断开。排查下来原因主要有几个。第一广播间隔设得太短导致 BLE 射频一直在工作功耗高而且容易跟 Wi-Fi 产生干扰。我把广播间隔从 100ms 调整到 500ms 之后稳定性明显提升。第二MTU 协商失败。有些手机默认的 MTU 比较小如果 Status Deck 请求的 MTU 超过了手机支持的范围协商就会失败。我的做法是先请求一个保守的值比如 128 字节如果协商成功再尝试更大的值。第三Wi-Fi 和 BLE 共存时的射频冲突。ESP32-S3 的 Wi-Fi 和 BLE 共用同一个射频前端如果 Wi-Fi 正在大量传输数据BLE 的响应就会变慢甚至丢包。解决办法是尽量错开 Wi-Fi 和 BLE 的高峰期比如 Wi-Fi 拉取数据的时候暂停 BLE 广播。5.2 JSON 解析报错或内存不足JSON 解析报错通常有两种情况一种是 JSON 格式本身有问题比如缺少引号、多了逗号、括号不匹配另一种是数据量太大解析过程中内存不够。对于格式问题我的建议是在发送端做严格的校验确保生成的 JSON 是合法的。接收端可以用try...except包裹json.loads()捕获异常后打印原始字符串方便定位问题。对于内存问题前面提到过尽量控制单次传输的数据量把大的 JSON 拆分成多次小的请求。另外MicroPython 的json模块在解析的时候会创建大量的临时对象如果内存碎片比较严重即使总内存够用也可能分配失败。定期手动调用gc.collect()可以帮助整理内存碎片。5.3 屏幕显示异常花屏、颜色错误、刷新慢屏幕问题我遇到过三种。第一种是花屏屏幕上出现随机噪点或者条纹。这通常是 SPI 时钟太快或者布线太长导致的信号完整性问题。降低 SPI 频率、缩短杜邦线长度、在 SCK 和 MOSI 上串联 33 欧姆的电阻都能改善这个问题。第二种是颜色错误比如红色显示成蓝色。这是颜色格式设置的问题。ST7789 支持 RGB565 和 BGR565 两种颜色格式如果设置反了红色和蓝色就会互换。在初始化的时候调整color_order参数即可。第三种是刷新慢全屏刷新要好几秒。这通常是因为没有使用 DMA直接内存访问传输。MicroPython 的 ST7789 驱动如果支持 DMA刷新速度会快很多。另外只刷新变化的部分局部刷新而不是全屏刷新也能显著提升响应速度。5.4 Wi-Fi 连接超时或频繁断连Wi-Fi 问题我在前面已经提到了一些处理策略这里再补充几个排查技巧。第一检查路由器的信道设置。如果路由器用的是 12 或 13 信道而 ESP32-S3 的 Wi-Fi 驱动默认只支持 1 到 11 信道那就连不上。解决办法是在路由器里把信道改成 1 到 11 之间的值。第二检查电源供应。ESP32-S3 在 Wi-Fi 传输的时候瞬间电流可能达到 500mA如果 USB 线质量不好或者供电不足就会导致电压跌落Wi-Fi 断连。换一根短而粗的 USB 线或者用带外部供电的 USB Hub通常能解决。第三如果周围 Wi-Fi 网络很多信道拥堵严重可以尝试在代码里主动扫描并选择最空闲的信道。5.5 常见问题速查表问题现象可能原因排查方法解决方案BLE 连接失败广播间隔太短、MTU 协商失败用 nRF Connect 查看广播参数和 MTU增大广播间隔、降低 MTU 请求值JSON 解析报错格式错误、内存不足打印原始字符串、检查内存使用校验 JSON 格式、拆分大数据、手动 gc屏幕花屏SPI 频率太高、布线太长降低频率测试、检查接线降频、缩短线长、串联电阻颜色错误颜色格式设置反了显示红绿蓝三色测试调整 color_order 参数Wi-Fi 断连信道不兼容、供电不足检查路由器信道、测量电压改信道、换 USB 线、加电容刷新慢未使用 DMA、全屏刷新查看驱动是否支持 DMA启用 DMA、改用局部刷新6. 一些实操心得和后续扩展方向这个项目从开始到基本能用大概花了我两个周末的时间。其中大部分时间不是在写代码而是在调试硬件和排查各种奇怪的问题。如果你也要做类似的东西我的建议是先把最小系统跑通——屏幕能亮、Wi-Fi 能连、BLE 能广播——然后再逐步往上加功能。不要一上来就把所有模块都接好那样出了问题很难定位是哪个部分的原因。另外MicroPython 的 REPL 是你最好的朋友。遇到问题的时候不要急着改代码重新烧录先在 REPL 里一行一行地测试确认每个模块都能正常工作再把它们组合起来。这样效率会高很多。后续如果要扩展有几个方向可以考虑。一是加入电池管理做成完全无线的桌面设备二是增加更多的数据源比如接入日历、邮件、GitHub 通知等三是做一个手机端的配置 App通过 BLE 来修改 Status Deck 的显示内容和刷新频率四是把外壳用 3D 打印做出来让它看起来更像一个成品而不是一个开发板。这些扩展每一个都涉及到新的技术点但核心的架构——ESP32-S3 加 MicroPython 加 BLE/Wi-Fi 加 JSON——是不变的。把这套基础打牢后面的扩展就是水到渠成的事情。