Wi-Fi-Enabled E-Paper做一个能远程更新内容的电子墨水屏到底该怎么玩这个标题看起来很简单就是把电子墨水屏通过 Wi-Fi 连上网。但真正动手做过的人都知道从“屏幕能显示”到“内容能稳定远程推送”中间隔着一大堆坑。我自己从最早的 SPI 接线开始玩到现在把设备部署在家里当信息牌用踩过的坑比屏幕上的刷新次数还多。这篇文章就把整个链路拆开讲清楚——硬件怎么选、固件怎么跑、低功耗怎么压、断线重连怎么处理以及最让人头疼的“远端内容更新不上”到底是怎么回事。适合手里有一块电子墨水屏、想把它真正用起来的人也适合刚入门想做物联网显示终端的开发者。先说清楚这个东西能干什么一台接了 Wi-Fi 的电子墨水屏本质上是一个超低功耗的“安静终端”。它不需要像手机那样保持屏幕常亮只在内容变化时刷新一次平时完全断电不耗电。放在桌面上当日程表、挂在门口当留言板、贴在货架上当价签或者做成室内空气质量显示器都非常合适。它和传统屏幕最大的区别只有一句话它不追求流畅度追求的是“把正确的信息显示出来然后继续睡觉”。1. 整体设计与思路拆解为什么选电子纸以及怎么组合方案1.1 电子纸的核心优势远不止省电很多朋友第一次接触电子墨水屏第一反应是“这个屏幕怎么这么慢也刷新不了几次”。这话没错但恰恰是这个“慢”和“少”造就了它独一无二的优势——双稳态显示。所谓双稳态就是屏幕上的画面在断电之后依然能保留不需要刷电维持也不需要存储阵列。简单类比一下这就像玻璃上的刻字你写完之后字就一直在那里不需要持续供能去“保持住”它。相比之下传统的 LCD 屏幕哪怕显示一个静止的画面也需要背光源持续照亮液晶层持续驱动每一秒钟都在耗电。这个特性直接决定了产品设计逻辑。一块 7.5 英寸的黑白电子纸在完全静态显示的状态下整机功耗可以做到微安级别。如果你用一颗 3000mAh 的锂电池供电理论上纯待机可以坚持一到两年。当然实际使用时 Wi-Fi 连接和周期性刷新才是耗电大头但即便如此把刷新频率调到“每小时一次”续航做个三到六个月也完全可行。这一点放在任何其他显示技术上都是不可想象的。同时电子纸在强光下的可读性极佳。它的显色原理是基于环境光的反射而不是屏幕自身发光所以阳光直射下反而看得更清楚。这一点用普通手机屏幕比不了户外场景下它的真实体验非常接近印刷品。所以如果你要做的项目是户外公告牌、车载标签、仓库货架标签这类场景电子纸就是最合适的显示方案没有之一。1.2 方案搭配Wi-Fi 模块、主控和屏幕选型Wi-Fi-Enabled E-Paper 这个词组从工程意义上拆开就是三个关键部分显示端、通信端和控制端。显示端是电子墨水屏面板通信端是 Wi-Fi 收发能力控制端则是决定“什么时候刷新、刷什么内容”的大脑。这三个部件的选型搭配决定了整个项目的上限和坑的多少。先说主控。目前主流方案其实非常清晰ESP32 系列几乎是这一场景的事实标准。原因不复杂它自带 Wi-Fi 和蓝牙算力对电子纸驱动绰绰有余开发环境成熟而且最重要的——库文件完善。如果你用 Arduino IDE 或者 PlatformIO管好一个电子纸项目几乎不需要手写底层驱动。ESP32 支持深度睡眠模式睡觉时电流可以压到 10 微安左右完美契合电子纸的低功耗逻辑。对比其他方案用 STM32 的话需要外挂 Wi-Fi 模块比如 ESP8266 或者 ATWINC1500通信和控制分在两个芯片上固件交互更复杂调试成本高。用树莓派的话算力完全浪费而且自身待机功耗就有两三瓦直接把电子纸的省电优势砍没了。所以除非你有特殊需求否则直接选 ESP32 就对了。再说屏幕。选择电子墨水面板时有几个核心参数需要看尺寸、分辨率、颜色数、刷新方式、接口类型。目前市面上最常见也最好上手的是来自元太科技E Ink的面板国内很多厂家做成模块出售常见的接口是 SPI少数大屏会用 HDMI 方案。SPI 接口的主要优势是接线简单而且主控资源占用小非常适合嵌入式环境。关于尺寸和分辨率我的建议是不要盲目追求大屏。7.5 英寸 800x480 是一个甜点位这个尺寸信息容量适中能显示一版日程或者一份待办清单SPI 驱动的刷新时间在三秒左右用户体验可以接受。更大的 9.7 英寸甚至 13.3 英寸分辨率更高但刷新时间明显拉长而且价格贵好几倍驱动压力也更大。如果是第一次做建议 1.54 英寸到 4.2 英寸起步先把链路跑通再逐步升级。1.3 内容更新链路从“屏幕显示什么”到“谁来决定显示什么”方案层面最后一个核心问题是屏幕上的内容从哪里来这就涉及“网络内容源”的设计。常见的有以下几种路径直接访问公开 API比如天气 API、新闻头条 API、比特币价格 API解析后绘制在屏幕上。通过局域网内的服务器或者 Home Assistant 等智能家居平台推送数据。通过 MQTT 协议接收消息适合做消息通知类应用。通过云端 BaaS 服务比如 Firebase、Supabase获取自定义数据。我自己的经验是第一版最好用最简单的 HTTP GET JSON 解析来跑通全链路不要一上来就上 MQTT。原因很简单MQTT 虽然实时性好但需要维护订阅关系、心跳保活、断线重连调试复杂度高。而 HTTP 请求是一次性的逻辑唤醒、请求、解析、绘制、合成、刷新、睡觉非常符合电子纸的使用节奏。等这套逻辑跑顺了再增加 MQTT 通道做实时消息推送也不会太吃力。2. 硬件选型与低温环境下的实操要点2.1 面板类型黑白、三色还是全彩电子纸面板按颜色显示能力分三类黑白、黑白红/黑白黄三色、以及最新的彩色电子纸。这三类在使用思路上有显著差别。黑白屏是功耗最低、刷新最快的显示对比度也最好适合文字为主的场景。三色屏在黑白基础上增加了红色或黄色适合需要强调信息的场景比如“超预算”“已售罄”“延期”这些需要警示的信息。但代价是刷新时间大幅增加通常在 15 秒上下而且刷新时会出现明显的颜色闪烁。全彩电子纸目前刷新速度更慢色彩饱和度也不如普通屏幕单独看可以接受和手机屏幕放一起对比就有些难受了。另外彩色的售价高出几个量级不是所有项目都需要。我的建议非常直接除非项目确实需要多色标注信息否则老老实实用黑白屏。刷新快、稳定、便宜而且在文字可读性上是最好的。做价签类项目再考虑黑白红三色。2.2 接口与驱动板SPI 接线前的准备工作市场上面板模组一般都带驱动板驱动板上有 FPC 排线接口和 SPI 引脚引出。拿到手之后先确认几个关键引脚BUSY忙信号、RST复位、DC数据/命令选择、CS片选、SCLK时钟、DIN数据输入。这几个脚必须全部接入主控少一个都无法工作。很多新手在这里会犯一个典型错误因为电子纸刷新过程很长就以为不需要关心时序随手乱接。实际上电子纸驱动对时序要求非常严格尤其BUSY脚必须接到一个支持中断或轮询的 GPIO 上否则程序无法判断屏是否完成了一次刷新只能靠延时硬等非常容易出现画面残缺或撕裂。关于供电还需要特别提醒一点电子纸的驱动电压是独立于逻辑电压的。很多模组内部有升压电路从 3.3V 升到 15V/-15V 来驱动墨水颗粒移动。所以不要在 3.3V 供电不稳的情况下驱动大尺寸屏否则会出现明显的灰阶不均和闪烁残影。建议给屏幕单独供一路稳定电源至少是低纹波的 LDO不要和 Wi-Fi 天线供电混在一起。2.3 驱动库怎么选GxEPD2、Adafruit 还是官方驱动软件层面市面上主流的电子纸驱动库有三个方向GxEPD2是我最推荐的选择。支持几乎所有市售电纸屏API 设计统一切换面板型号只需要改一两个宏资源占用也合理。Adafruit EPD封装更友好适合新手入门但适配的屏型号相对有限。官方驱动不同厂家会提供自己的参考代码优点是和硬件贴合最紧缺点是非常零散每换一个屏就得重新移植。如果你想快速做出来我建议直接用 GxEPD2。这个库把电子纸最繁琐的部分全包的很好比如初始化序列、刷新时序、部分刷新模式、帧缓冲管理。需要你做的核心工作只剩两件事定义引脚映射、把要显示的内容画到缓冲区上。另外要提醒的是千万不要用官方的“全屏刷新”API 做每一帧的绘制。电子纸的刷新是全局刷新的即使只改了一个小像素也会触发整屏的电泳过程这会导致严重的“残影”问题。正确做法是只在必要时候全刷平时用“局部刷新”或者“快速刷新”模式能大幅减少残影和屏幕损耗。3. 实操全过程从零开始做一个 Wi-Fi 天气信息牌3.1 物料清单与接线参考下面我给出一份经过实测的物料清单照着买基本不会踩坑部件型号参考说明主控开发板ESP32 DevKit V1或 NodeMCU-32S选 4MB Flash 的版本后续 OTA 升级空间充足电子墨水面板7.5 英寸 800x480 黑白SPI 接口推荐带驱动板的模组焊接成本低锂电池18650 单节带保护板或 4000mAh 软包电池电源管理TP4056 充电模块带锂电池保护用于充电和放电保护稳压芯片低压差 LDO 3.3V比如 ME6211电池电压直接供给 ESP32 会有问题必须稳压外壳3D 打印或亚克力开模注意留出天线位置接线参考如下以 ESP32 DevKit 为例BUSY→ GPIO 4RST→ GPIO 16DC→ GPIO 17CS→ GPIO 5注意不要用默认的 SS 引脚容易冲突SCLK→ GPIO 18DIN→ GPIO 23供电3.3V 和 GND 接入稳压后的电源这组引脚配置我用了很久避开了 ESP32 的默认 SPI 引脚也避开了启动时会有特殊电平的引脚GPIO 12、15比较省心。如果你用的板子不同照着手册改一下即可。3.2 固件流程设计唤醒、拉取、绘制、刷新、睡觉这个项目的固件核心是一个状态机跑完一轮之后直接进入深度睡眠等下一次定时唤醒。伪代码如下void loop() { // 1. 唤醒后先初始化显示面板 display.init(); // 2. 连接 Wi-Fi设置超时防止卡死 WiFi.begin(SSID, PASSWORD); if (!waitForWiFi(15)) { drawError(WiFi failed); goToDeepSleep(WAIT_SECONDS); return; } // 3. 发起 HTTP 请求获取天气数据 HTTPClient http; http.begin(WEATHER_API_URL); int httpCode http.GET(); // 4. 解析 JSON提取温度、湿度、天气描述、风力等字段 JsonDocument doc; deserializeJson(doc, http.getString()); // 5. 在内存缓冲区中绘制完整页面 drawWeatherData(doc); // 6. 一次性推送到屏幕 display.display(); // 7. 断开网络进入深度睡眠 WiFi.disconnect(true); esp_deep_sleep_start(); }这里有一个关键设计所有绘制操作都是在缓冲区中完成的只有最后调用display.display()时才真正把内容推送至屏幕。这个模式不仅是 GxEPD2 的推荐用法也是保障刷新质量的核心习惯。缓冲区其实是一个位图你在里面画任何东西都不会对屏幕产生直接影响只有最后渲染的时候才会整体生效。这样既能保证画面完整又能在内容出问题时随时取消刷新。3.3 深度睡眠这是整个项目省电的关键电子纸项目省不省电完全取决于“清醒时间”和“睡眠时间”的比例。ESP32 支持多种睡眠模式这里我们用的是最彻底的深度睡眠Deep Sleep。在深度睡眠下CPU 停止运行大部分 RAM 断电只有 RTC 存储器和 ULP 协处理器保持工作。用定时器唤醒是常见做法。esp_sleep_enable_timer_wakeup(30 * 60 * 1000000ULL); // 30分钟 esp_deep_sleep_start();这个模式下电流实测在 10 微安左右简单算一笔账如果 30 分钟唤醒一次每次清醒后执行网络请求和刷新操作耗时约 15 秒期间平均电流约 180 毫安那么一天的耗电量大约是清醒消耗: ( 15s \times 0.18A \times 48次 129.6mAh )睡眠消耗: ( 24h \times 0.00001A 0.24mAh )合计: 约 130mAh/天一颗 3000mAh 的电池理论续航约 23 天。如果把刷新频率降到每小时一次续航可以突破 50 天。如果你再加一个太阳能板做成户外信息牌几乎可以永久运行。这就是电子纸结合深度睡眠方案的核心价值。3.4 内容绘制字符字体、图片位图和布局拆解在电子纸上绘制内容字体处理是个小难点。常见做法有两种使用 Adafruit GFX 的字体或者自行取模嵌入更美观的字体。Adafruit GFX 默认字体比较简单放大后会有锯齿适合做原型但不够精致。如果你要做出能摆在桌面上的产品级效果建议用自定义字体把中文字库按需求提取出要用到的几个字转成位图数组嵌入固件比塞入全量中文字库省几百 KB 空间。这在 ESP32 的 4MB Flash 上是完全可行的。图片显示方面GxEPD2 提供了丰富的绘制函数支持从 SD 卡或内存读取 BMP 图片或者从 Base64 数组解码显示。做天气图标时自己准备一套黑白色的图标素材按 1-bit BMP 格式转换后嵌入固件显示效果会干净利落。布局建议采用“分区设计”顶部放日期时间、中间放天气图标和温度、底部放近期预报信息。在 800x480 的分辨率下这个布局可以做到清晰易读同时给重要信息留出大块显示区域。绘制时注意文字基线对齐不要出现上下参差不齐的观感这在电子纸这种低刷新率屏幕上格外重要因为一旦画错修正的成本远比 LCD 屏幕高。4. 网络连接、远程更新与典型故障排查4.1 热点连接失败的常见原因排查文章开头提到的那句“我们无法设置移动热点因为你的电脑未建立以太网、Wi-Fi 或手机网络数据连接”其实是你测试设备时最容易撞到的墙之一。很多开发者习惯在电脑上开一个“移动热点”让 ESP32 先连上局域网但 Windows 在开启热点时要求主机网络接口具备 Internet 连接能力如果当前电脑连的还是需要网页认证的公共 Wi-Fi或者断网状态热点就根本开不起来。这种情况下最快也最稳的办法是用手机开热点手机自身的数据网络作为上行设备连接手机热点访问外网。ESP32 连接这种热点后不需要处理额外的认证逻辑直接 DHCP 获取 IP速度反而最快。如果你必须用电脑做 AP先确保电脑的网络连接是正常的然后检查热点频段老款 ESP32 不支持 5GHz 频段只支持 2.4GHz电脑热点如果默认开了“首选 5GHz”频段设备会一直扫描不到。另外还有两个高频坑。第一个是Wi-Fi 信道干扰尤其当附近有很多 2.4G 无线设备时ESP32 的接收灵敏度会下降出现能搜索到信号但连接超时的现象固定 AP 信道可以缓解。第二个是低功耗模式下的 Wi-Fi 问题ESP32 默认开启 Wi-Fi 省电模式WIFI_PS_MIN_MODEM这在低功耗场景中是好事但在连接初期容易导致握手超时。调试阶段建议先关掉省电模式等逻辑稳定后再开启WiFi.setSleep(false); // 调试阶段关闭 Wi-Fi 省电4.2 屏幕显示异常残影、花屏与刷新失败电子纸用久了或者刷新逻辑不对最典型的问题就是残影俗称“鬼影”。上一帧画面的边界在下一帧画面上依然隐约可见。这对黑白屏来说是正常现象尤其是经过多次局部刷新后。解决办法有三个一是减少局部刷新频率让关键内容以全刷为主二是刷新前加一次“清屏”全屏切换为黑白交替能耗较高不建议频繁使用三是在硬件和驱动库允许的情况下调用 GxEPD2 提供的“反色刷新”模式先用反向电压驱动墨水颗粒再刷正向内容能显著抑制残影累积。花屏则通常和供电质量有关。电子纸的驱动需要瞬间的较大电流来建立高电压如果你的供电能力不足或者线路电阻太大刷新时电压跌落就会出现灰度混乱、白点、横纹横条纹。解决方法是给屏幕供电的线路尽量短粗或者加一个大电容比如 100μF 和 0.1μF 配合稳定瞬时电流。还有一个小技巧刷新过程中不要同时操作 Wi-Fi 的收发避免瞬间电流叠加Espressif 官方论坛上的老工程师也是这么建议的。刷新失败还有一个容易被忽略的原因初始化时序不完整。每款屏幕对初始化命令的要求都有细微差别如果你移植代码时直接套用了其他型号的库配置初始化序列可能不匹配。遇到这种情况先确认 GxEPD2 库中选择的模板型号是否和你手上的面板丝印一致这个检查往往比改代码更有效。4.3 OTA 远程固件更新改代码不用拆盒子设备部署之后最麻烦的就是固件升级。每次改代码都要拆盒子、插 USB太不优雅了。ESP32 支持 ArduinoOTA 库可以在局域网内无线烧录程序部署阶段强烈建议加上#include ArduinoOTA.h void setupOTA() { ArduinoOTA.setHostname(epaper-dev); ArduinoOTA.setPassword(your-admin-password); ArduinoOTA.begin(); } void loopOTA() { ArduinoOTA.handle(); }OTA 时有一个重要前提Flash 分区里必须有足够的 OTA 分区。在 Arduino IDE 中需要在“开发板”菜单里选择带 OTA 分区方案的选项比如Huge APP否则烧录新固件时会提示空间不足。设置好后固件就通过两个 APP 分区交替写入写完后自动切换启动。OTA 的最优实践是在 OTA 过程中保持屏幕继续显示当前内容不要刷新屏幕。因为整个下载、写入、重启的流程中任何一次意外断电都会导致变砖电子纸即使显示当前画面也不影响写入保持静止反而有助于散热。4.4 解决“内容更新不上”的问题排查链路五步法最后聊一个让很多人崩溃的问题屏幕正常显示Wi-Fi 也能连上但内容永远是旧的——就是更新不上。这个问题按照下面这个顺序排查效率最高检查 API 服务是否真的返回了数据。用 PC 浏览器或 curl 直接访问同一个 URL如果返回的 JSON 结构变了ESP32 端解析就会失败程序是不是在 deserializeJson 这一步直接 return 了。检查时间戳。很多免费 API 返回的数据有缓存如果服务器返回的还是 10 分钟前的数据那屏幕刷新的就是旧数据。可以打印响应体看看内容是否真的变化。检查 HTTP 状态码。很多项目的http.GET()返回 200 但不代表数据有效要检查响应体是否为空或包含错误信息。检查缓冲区是否被正确修改。绘制完成后先用display.drawPixel()或者打印缓冲区的特征值确认数据真的到了 buf而不是被某个逻辑错误重置了。检查刷新模式。如果你用了局部刷新且参数不对屏幕可能“看似没变化”。这时先切回全刷模式验证。五个步骤走下来至少能覆盖 90% 的更新失败问题。至于剩下的 10%大概率出在 NTP 时间同步上——如果设备的本地时间不准你依赖“按时间判断是否刷新”的逻辑就会失效导致设备错过了刷新窗口。这个坑我曾经在一个项目里耗了快两天才定位到最后发现是 RTC 芯片的时钟漂移在每周断网维护后没有重新同步。从那以后我每次初始化都要强制从 NTP 获取一次时间而不是信任上次保存的值。5. 高级玩法多设备管理、消息推送和功耗优化5.1 用 MQTT 做推送让设备变成“安静的收件箱”HTTP 轮询模式适合固定周期获取数据但有些场景需要实时推送。比如你希望通知信息到了就立刻显示在屏幕上而不是等下一次 30 分钟的唤醒周期。这时候 MQTT 就派上用场了。ESP32 上常用的 MQTT 库是 PubSubClient配合稳定的 Broker比如公有云的 EMQX、本地部署的 Mosquitto可以实现消息订阅。设备订阅一个主题比如epaper/device1/incoming消息内容用 JSON 封装接收后解析并刷新屏幕。一个很容易被忽略的点是MQTT 连接必须解决“保活”和“断线重连”。因为设备平时处于深度睡眠MQTT 长连接无法维持所以实际设计时需要拆成两类策略策略 A设备周期性唤醒连接 Broker检查是否有离线消息Persistent Session。策略 B设备保持浅睡眠或 Modem 休眠Wi-Fi 不断开维持 MQTT 长连接。策略 B 的实时性高但功耗明显提升失去了电子纸的优势。如果不是特别刚需实时推送我建议用策略 A简单可靠。如果一定要实时可以考虑“信号到达时路由器/Wi-Fi 唤醒”的方案这个比较复杂不建议新手一上来就试。5.2 多设备协同一套后端服务管理多块屏幕当项目从一块屏扩展到多块屏时单独为每块屏编写不同固件基本不可维护。推荐做法是把内容和固件分离所有屏幕跑同一个固件启动时根据设备 ID 从服务端拉取“显示配置”——包括要显示的组件、数据源、刷新频率、布局参数。这样后端改配置就能远程调整所有屏幕不需要重新烧录。我自己的服务端实现是用 Node-RED 做一个轻量 API接收 GET 请求返回该设备的完整显示配置再用 InfluxDB 存储各设备的上次报告状态方便监控。整个方案没有引入重型框架但足够支撑几十块屏的规模。多设备场景下还有一个容易忽略的问题NTP 时间同步。如果屏上要显示“最后更新时间”必须保证设备时间可靠否则用户看到的时间信息就不可信。在每块屏的固件里加上 NTP 同步逻辑每次唤醒都从时间服务器获取标准时间而不是依赖设备本地 RTC。5.3 功耗优化的几个进阶技巧除了深度睡眠还有几个让续航更长的关键手段降低 Wi-Fi 发射功率近距离场景用WiFi.setTxPower(WIFI_POWER_11dBm)就足够了不要用最大功率实测电流可以减少 30 到 40 毫安。减少初始化次数电子纸驱动板初始化时会有电流冲击如果只是一些简单的局部刷新尽量复用同一个初始化好的上下文。关掉不必要的模块如果固件不需要蓝牙在 setup 里直接btStop()可以省去蓝牙协议栈的空转电流。用轻量级协议替代 HTTPSHTTPS 握手开销远大于 HTTP在局域网内如果安全要求不高直接走 HTTP 能明显缩短清醒时间。注意加密与否要根据实际场景权衡敏感数据必须加密传输。分批绘制不要在同一帧里绘制大量小图形那样会拉长绘制时间多做几个整块区域减少数据写入量。这些细节单看每一项省的电不多但叠加起来对一个电池供电的长期运行设备来说是质变。6. 常见问题速查表结合前面的内容我整理了一个实用排查表值得收藏。现象可能原因快速解决办法设备搜不到 Wi-Fi频段不匹配或热点开了 5GHz确认热点为 2.4GHz多等几秒再扫描能连上但网络请求超时DHCP 获取慢、DNS 配置异常固定静态 IP手动指定 DNS屏幕刷新后出现严重残影刷新模式选择不合理对内容变化大的页面使用全刷模式屏幕显示花屏/灰阶不均供电电压跌落或线路电阻过大检查供电加粗电源线加大电容内容长期不更新数据源 API 结构变化打印响应体用 curl 对比设备重启后连不上网Wi-Fi 保存信息失效使用WiFi.setAutoReconnect(true)或重启后重新 scan显示的中文出现乱码字库编码不匹配确认字体数组基于 UTF-8 编码且包含需要显示的 ASCII 字符这个表看起来简单但每一条都是真实项目里反复踩过的。我个人做 Wi-Fi 电子纸最大的感受是这个项目绝对不是一个“入门三小时”的玩具它是一个横跨硬件、网络、嵌入式、接口设计的整合型任务。它的魅力在于组合——用最克制的功耗、最安静的方式把网络世界的关键信息呈现在一块像纸一样的屏幕上。做好一个你会学到 SPI 时序、低功耗设计、JSON 解析、断线重连、OTA 升级、后端数据流几乎每个物联网项目里都用得上的技能都会在这一块屏幕上过一遍。如果你刚拿到板子先别急着写代码建议按这篇文章的顺序先把一块屏幕点亮再让它连网拉到一条数据最后才考虑排版和美化。路一步步走坑一个个踩做出来的东西才经得起长期使用。最后再送一个小技巧调试时把串口打印拉开BEFORE_INIT、WIFI_CONNECTING、HTTP_REQUESTING、JSON_PARSING、DRAWING、REFRESH_DONE每个阶段都打印一行状态然后在家运行三天你会对这块屏幕每个环节的真实耗时和出错率有非常准确的体感。这些小数据比任何理论分析都管用。祝你们都能顺利点亮第一块 Wi-Fi 电子纸。 
长河君 · 2026/8/27 21:29:55 · 阅读 1.2k Wi-Fi电子墨水屏实战：ESP32远程信息牌从硬件选型到低功耗固件开发全攻略
Wi-Fi-Enabled E-Paper做一个能远程更新内容的电子墨水屏到底该怎么玩这个标题看起来很简单就是把电子墨水屏通过 Wi-Fi 连上网。但真正动手做过的人都知道从“屏幕能显示”到“内容能稳定远程推送”中间隔着一大堆坑。我自己从最早的 SPI 接线开始玩到现在把设备部署在家里当信息牌用踩过的坑比屏幕上的刷新次数还多。这篇文章就把整个链路拆开讲清楚——硬件怎么选、固件怎么跑、低功耗怎么压、断线重连怎么处理以及最让人头疼的“远端内容更新不上”到底是怎么回事。适合手里有一块电子墨水屏、想把它真正用起来的人也适合刚入门想做物联网显示终端的开发者。先说清楚这个东西能干什么一台接了 Wi-Fi 的电子墨水屏本质上是一个超低功耗的“安静终端”。它不需要像手机那样保持屏幕常亮只在内容变化时刷新一次平时完全断电不耗电。放在桌面上当日程表、挂在门口当留言板、贴在货架上当价签或者做成室内空气质量显示器都非常合适。它和传统屏幕最大的区别只有一句话它不追求流畅度追求的是“把正确的信息显示出来然后继续睡觉”。1. 整体设计与思路拆解为什么选电子纸以及怎么组合方案1.1 电子纸的核心优势远不止省电很多朋友第一次接触电子墨水屏第一反应是“这个屏幕怎么这么慢也刷新不了几次”。这话没错但恰恰是这个“慢”和“少”造就了它独一无二的优势——双稳态显示。所谓双稳态就是屏幕上的画面在断电之后依然能保留不需要刷电维持也不需要存储阵列。简单类比一下这就像玻璃上的刻字你写完之后字就一直在那里不需要持续供能去“保持住”它。相比之下传统的 LCD 屏幕哪怕显示一个静止的画面也需要背光源持续照亮液晶层持续驱动每一秒钟都在耗电。这个特性直接决定了产品设计逻辑。一块 7.5 英寸的黑白电子纸在完全静态显示的状态下整机功耗可以做到微安级别。如果你用一颗 3000mAh 的锂电池供电理论上纯待机可以坚持一到两年。当然实际使用时 Wi-Fi 连接和周期性刷新才是耗电大头但即便如此把刷新频率调到“每小时一次”续航做个三到六个月也完全可行。这一点放在任何其他显示技术上都是不可想象的。同时电子纸在强光下的可读性极佳。它的显色原理是基于环境光的反射而不是屏幕自身发光所以阳光直射下反而看得更清楚。这一点用普通手机屏幕比不了户外场景下它的真实体验非常接近印刷品。所以如果你要做的项目是户外公告牌、车载标签、仓库货架标签这类场景电子纸就是最合适的显示方案没有之一。1.2 方案搭配Wi-Fi 模块、主控和屏幕选型Wi-Fi-Enabled E-Paper 这个词组从工程意义上拆开就是三个关键部分显示端、通信端和控制端。显示端是电子墨水屏面板通信端是 Wi-Fi 收发能力控制端则是决定“什么时候刷新、刷什么内容”的大脑。这三个部件的选型搭配决定了整个项目的上限和坑的多少。先说主控。目前主流方案其实非常清晰ESP32 系列几乎是这一场景的事实标准。原因不复杂它自带 Wi-Fi 和蓝牙算力对电子纸驱动绰绰有余开发环境成熟而且最重要的——库文件完善。如果你用 Arduino IDE 或者 PlatformIO管好一个电子纸项目几乎不需要手写底层驱动。ESP32 支持深度睡眠模式睡觉时电流可以压到 10 微安左右完美契合电子纸的低功耗逻辑。对比其他方案用 STM32 的话需要外挂 Wi-Fi 模块比如 ESP8266 或者 ATWINC1500通信和控制分在两个芯片上固件交互更复杂调试成本高。用树莓派的话算力完全浪费而且自身待机功耗就有两三瓦直接把电子纸的省电优势砍没了。所以除非你有特殊需求否则直接选 ESP32 就对了。再说屏幕。选择电子墨水面板时有几个核心参数需要看尺寸、分辨率、颜色数、刷新方式、接口类型。目前市面上最常见也最好上手的是来自元太科技E Ink的面板国内很多厂家做成模块出售常见的接口是 SPI少数大屏会用 HDMI 方案。SPI 接口的主要优势是接线简单而且主控资源占用小非常适合嵌入式环境。关于尺寸和分辨率我的建议是不要盲目追求大屏。7.5 英寸 800x480 是一个甜点位这个尺寸信息容量适中能显示一版日程或者一份待办清单SPI 驱动的刷新时间在三秒左右用户体验可以接受。更大的 9.7 英寸甚至 13.3 英寸分辨率更高但刷新时间明显拉长而且价格贵好几倍驱动压力也更大。如果是第一次做建议 1.54 英寸到 4.2 英寸起步先把链路跑通再逐步升级。1.3 内容更新链路从“屏幕显示什么”到“谁来决定显示什么”方案层面最后一个核心问题是屏幕上的内容从哪里来这就涉及“网络内容源”的设计。常见的有以下几种路径直接访问公开 API比如天气 API、新闻头条 API、比特币价格 API解析后绘制在屏幕上。通过局域网内的服务器或者 Home Assistant 等智能家居平台推送数据。通过 MQTT 协议接收消息适合做消息通知类应用。通过云端 BaaS 服务比如 Firebase、Supabase获取自定义数据。我自己的经验是第一版最好用最简单的 HTTP GET JSON 解析来跑通全链路不要一上来就上 MQTT。原因很简单MQTT 虽然实时性好但需要维护订阅关系、心跳保活、断线重连调试复杂度高。而 HTTP 请求是一次性的逻辑唤醒、请求、解析、绘制、合成、刷新、睡觉非常符合电子纸的使用节奏。等这套逻辑跑顺了再增加 MQTT 通道做实时消息推送也不会太吃力。2. 硬件选型与低温环境下的实操要点2.1 面板类型黑白、三色还是全彩电子纸面板按颜色显示能力分三类黑白、黑白红/黑白黄三色、以及最新的彩色电子纸。这三类在使用思路上有显著差别。黑白屏是功耗最低、刷新最快的显示对比度也最好适合文字为主的场景。三色屏在黑白基础上增加了红色或黄色适合需要强调信息的场景比如“超预算”“已售罄”“延期”这些需要警示的信息。但代价是刷新时间大幅增加通常在 15 秒上下而且刷新时会出现明显的颜色闪烁。全彩电子纸目前刷新速度更慢色彩饱和度也不如普通屏幕单独看可以接受和手机屏幕放一起对比就有些难受了。另外彩色的售价高出几个量级不是所有项目都需要。我的建议非常直接除非项目确实需要多色标注信息否则老老实实用黑白屏。刷新快、稳定、便宜而且在文字可读性上是最好的。做价签类项目再考虑黑白红三色。2.2 接口与驱动板SPI 接线前的准备工作市场上面板模组一般都带驱动板驱动板上有 FPC 排线接口和 SPI 引脚引出。拿到手之后先确认几个关键引脚BUSY忙信号、RST复位、DC数据/命令选择、CS片选、SCLK时钟、DIN数据输入。这几个脚必须全部接入主控少一个都无法工作。很多新手在这里会犯一个典型错误因为电子纸刷新过程很长就以为不需要关心时序随手乱接。实际上电子纸驱动对时序要求非常严格尤其BUSY脚必须接到一个支持中断或轮询的 GPIO 上否则程序无法判断屏是否完成了一次刷新只能靠延时硬等非常容易出现画面残缺或撕裂。关于供电还需要特别提醒一点电子纸的驱动电压是独立于逻辑电压的。很多模组内部有升压电路从 3.3V 升到 15V/-15V 来驱动墨水颗粒移动。所以不要在 3.3V 供电不稳的情况下驱动大尺寸屏否则会出现明显的灰阶不均和闪烁残影。建议给屏幕单独供一路稳定电源至少是低纹波的 LDO不要和 Wi-Fi 天线供电混在一起。2.3 驱动库怎么选GxEPD2、Adafruit 还是官方驱动软件层面市面上主流的电子纸驱动库有三个方向GxEPD2是我最推荐的选择。支持几乎所有市售电纸屏API 设计统一切换面板型号只需要改一两个宏资源占用也合理。Adafruit EPD封装更友好适合新手入门但适配的屏型号相对有限。官方驱动不同厂家会提供自己的参考代码优点是和硬件贴合最紧缺点是非常零散每换一个屏就得重新移植。如果你想快速做出来我建议直接用 GxEPD2。这个库把电子纸最繁琐的部分全包的很好比如初始化序列、刷新时序、部分刷新模式、帧缓冲管理。需要你做的核心工作只剩两件事定义引脚映射、把要显示的内容画到缓冲区上。另外要提醒的是千万不要用官方的“全屏刷新”API 做每一帧的绘制。电子纸的刷新是全局刷新的即使只改了一个小像素也会触发整屏的电泳过程这会导致严重的“残影”问题。正确做法是只在必要时候全刷平时用“局部刷新”或者“快速刷新”模式能大幅减少残影和屏幕损耗。3. 实操全过程从零开始做一个 Wi-Fi 天气信息牌3.1 物料清单与接线参考下面我给出一份经过实测的物料清单照着买基本不会踩坑部件型号参考说明主控开发板ESP32 DevKit V1或 NodeMCU-32S选 4MB Flash 的版本后续 OTA 升级空间充足电子墨水面板7.5 英寸 800x480 黑白SPI 接口推荐带驱动板的模组焊接成本低锂电池18650 单节带保护板或 4000mAh 软包电池电源管理TP4056 充电模块带锂电池保护用于充电和放电保护稳压芯片低压差 LDO 3.3V比如 ME6211电池电压直接供给 ESP32 会有问题必须稳压外壳3D 打印或亚克力开模注意留出天线位置接线参考如下以 ESP32 DevKit 为例BUSY→ GPIO 4RST→ GPIO 16DC→ GPIO 17CS→ GPIO 5注意不要用默认的 SS 引脚容易冲突SCLK→ GPIO 18DIN→ GPIO 23供电3.3V 和 GND 接入稳压后的电源这组引脚配置我用了很久避开了 ESP32 的默认 SPI 引脚也避开了启动时会有特殊电平的引脚GPIO 12、15比较省心。如果你用的板子不同照着手册改一下即可。3.2 固件流程设计唤醒、拉取、绘制、刷新、睡觉这个项目的固件核心是一个状态机跑完一轮之后直接进入深度睡眠等下一次定时唤醒。伪代码如下void loop() { // 1. 唤醒后先初始化显示面板 display.init(); // 2. 连接 Wi-Fi设置超时防止卡死 WiFi.begin(SSID, PASSWORD); if (!waitForWiFi(15)) { drawError(WiFi failed); goToDeepSleep(WAIT_SECONDS); return; } // 3. 发起 HTTP 请求获取天气数据 HTTPClient http; http.begin(WEATHER_API_URL); int httpCode http.GET(); // 4. 解析 JSON提取温度、湿度、天气描述、风力等字段 JsonDocument doc; deserializeJson(doc, http.getString()); // 5. 在内存缓冲区中绘制完整页面 drawWeatherData(doc); // 6. 一次性推送到屏幕 display.display(); // 7. 断开网络进入深度睡眠 WiFi.disconnect(true); esp_deep_sleep_start(); }这里有一个关键设计所有绘制操作都是在缓冲区中完成的只有最后调用display.display()时才真正把内容推送至屏幕。这个模式不仅是 GxEPD2 的推荐用法也是保障刷新质量的核心习惯。缓冲区其实是一个位图你在里面画任何东西都不会对屏幕产生直接影响只有最后渲染的时候才会整体生效。这样既能保证画面完整又能在内容出问题时随时取消刷新。3.3 深度睡眠这是整个项目省电的关键电子纸项目省不省电完全取决于“清醒时间”和“睡眠时间”的比例。ESP32 支持多种睡眠模式这里我们用的是最彻底的深度睡眠Deep Sleep。在深度睡眠下CPU 停止运行大部分 RAM 断电只有 RTC 存储器和 ULP 协处理器保持工作。用定时器唤醒是常见做法。esp_sleep_enable_timer_wakeup(30 * 60 * 1000000ULL); // 30分钟 esp_deep_sleep_start();这个模式下电流实测在 10 微安左右简单算一笔账如果 30 分钟唤醒一次每次清醒后执行网络请求和刷新操作耗时约 15 秒期间平均电流约 180 毫安那么一天的耗电量大约是清醒消耗: ( 15s \times 0.18A \times 48次 129.6mAh )睡眠消耗: ( 24h \times 0.00001A 0.24mAh )合计: 约 130mAh/天一颗 3000mAh 的电池理论续航约 23 天。如果把刷新频率降到每小时一次续航可以突破 50 天。如果你再加一个太阳能板做成户外信息牌几乎可以永久运行。这就是电子纸结合深度睡眠方案的核心价值。3.4 内容绘制字符字体、图片位图和布局拆解在电子纸上绘制内容字体处理是个小难点。常见做法有两种使用 Adafruit GFX 的字体或者自行取模嵌入更美观的字体。Adafruit GFX 默认字体比较简单放大后会有锯齿适合做原型但不够精致。如果你要做出能摆在桌面上的产品级效果建议用自定义字体把中文字库按需求提取出要用到的几个字转成位图数组嵌入固件比塞入全量中文字库省几百 KB 空间。这在 ESP32 的 4MB Flash 上是完全可行的。图片显示方面GxEPD2 提供了丰富的绘制函数支持从 SD 卡或内存读取 BMP 图片或者从 Base64 数组解码显示。做天气图标时自己准备一套黑白色的图标素材按 1-bit BMP 格式转换后嵌入固件显示效果会干净利落。布局建议采用“分区设计”顶部放日期时间、中间放天气图标和温度、底部放近期预报信息。在 800x480 的分辨率下这个布局可以做到清晰易读同时给重要信息留出大块显示区域。绘制时注意文字基线对齐不要出现上下参差不齐的观感这在电子纸这种低刷新率屏幕上格外重要因为一旦画错修正的成本远比 LCD 屏幕高。4. 网络连接、远程更新与典型故障排查4.1 热点连接失败的常见原因排查文章开头提到的那句“我们无法设置移动热点因为你的电脑未建立以太网、Wi-Fi 或手机网络数据连接”其实是你测试设备时最容易撞到的墙之一。很多开发者习惯在电脑上开一个“移动热点”让 ESP32 先连上局域网但 Windows 在开启热点时要求主机网络接口具备 Internet 连接能力如果当前电脑连的还是需要网页认证的公共 Wi-Fi或者断网状态热点就根本开不起来。这种情况下最快也最稳的办法是用手机开热点手机自身的数据网络作为上行设备连接手机热点访问外网。ESP32 连接这种热点后不需要处理额外的认证逻辑直接 DHCP 获取 IP速度反而最快。如果你必须用电脑做 AP先确保电脑的网络连接是正常的然后检查热点频段老款 ESP32 不支持 5GHz 频段只支持 2.4GHz电脑热点如果默认开了“首选 5GHz”频段设备会一直扫描不到。另外还有两个高频坑。第一个是Wi-Fi 信道干扰尤其当附近有很多 2.4G 无线设备时ESP32 的接收灵敏度会下降出现能搜索到信号但连接超时的现象固定 AP 信道可以缓解。第二个是低功耗模式下的 Wi-Fi 问题ESP32 默认开启 Wi-Fi 省电模式WIFI_PS_MIN_MODEM这在低功耗场景中是好事但在连接初期容易导致握手超时。调试阶段建议先关掉省电模式等逻辑稳定后再开启WiFi.setSleep(false); // 调试阶段关闭 Wi-Fi 省电4.2 屏幕显示异常残影、花屏与刷新失败电子纸用久了或者刷新逻辑不对最典型的问题就是残影俗称“鬼影”。上一帧画面的边界在下一帧画面上依然隐约可见。这对黑白屏来说是正常现象尤其是经过多次局部刷新后。解决办法有三个一是减少局部刷新频率让关键内容以全刷为主二是刷新前加一次“清屏”全屏切换为黑白交替能耗较高不建议频繁使用三是在硬件和驱动库允许的情况下调用 GxEPD2 提供的“反色刷新”模式先用反向电压驱动墨水颗粒再刷正向内容能显著抑制残影累积。花屏则通常和供电质量有关。电子纸的驱动需要瞬间的较大电流来建立高电压如果你的供电能力不足或者线路电阻太大刷新时电压跌落就会出现灰度混乱、白点、横纹横条纹。解决方法是给屏幕供电的线路尽量短粗或者加一个大电容比如 100μF 和 0.1μF 配合稳定瞬时电流。还有一个小技巧刷新过程中不要同时操作 Wi-Fi 的收发避免瞬间电流叠加Espressif 官方论坛上的老工程师也是这么建议的。刷新失败还有一个容易被忽略的原因初始化时序不完整。每款屏幕对初始化命令的要求都有细微差别如果你移植代码时直接套用了其他型号的库配置初始化序列可能不匹配。遇到这种情况先确认 GxEPD2 库中选择的模板型号是否和你手上的面板丝印一致这个检查往往比改代码更有效。4.3 OTA 远程固件更新改代码不用拆盒子设备部署之后最麻烦的就是固件升级。每次改代码都要拆盒子、插 USB太不优雅了。ESP32 支持 ArduinoOTA 库可以在局域网内无线烧录程序部署阶段强烈建议加上#include ArduinoOTA.h void setupOTA() { ArduinoOTA.setHostname(epaper-dev); ArduinoOTA.setPassword(your-admin-password); ArduinoOTA.begin(); } void loopOTA() { ArduinoOTA.handle(); }OTA 时有一个重要前提Flash 分区里必须有足够的 OTA 分区。在 Arduino IDE 中需要在“开发板”菜单里选择带 OTA 分区方案的选项比如Huge APP否则烧录新固件时会提示空间不足。设置好后固件就通过两个 APP 分区交替写入写完后自动切换启动。OTA 的最优实践是在 OTA 过程中保持屏幕继续显示当前内容不要刷新屏幕。因为整个下载、写入、重启的流程中任何一次意外断电都会导致变砖电子纸即使显示当前画面也不影响写入保持静止反而有助于散热。4.4 解决“内容更新不上”的问题排查链路五步法最后聊一个让很多人崩溃的问题屏幕正常显示Wi-Fi 也能连上但内容永远是旧的——就是更新不上。这个问题按照下面这个顺序排查效率最高检查 API 服务是否真的返回了数据。用 PC 浏览器或 curl 直接访问同一个 URL如果返回的 JSON 结构变了ESP32 端解析就会失败程序是不是在 deserializeJson 这一步直接 return 了。检查时间戳。很多免费 API 返回的数据有缓存如果服务器返回的还是 10 分钟前的数据那屏幕刷新的就是旧数据。可以打印响应体看看内容是否真的变化。检查 HTTP 状态码。很多项目的http.GET()返回 200 但不代表数据有效要检查响应体是否为空或包含错误信息。检查缓冲区是否被正确修改。绘制完成后先用display.drawPixel()或者打印缓冲区的特征值确认数据真的到了 buf而不是被某个逻辑错误重置了。检查刷新模式。如果你用了局部刷新且参数不对屏幕可能“看似没变化”。这时先切回全刷模式验证。五个步骤走下来至少能覆盖 90% 的更新失败问题。至于剩下的 10%大概率出在 NTP 时间同步上——如果设备的本地时间不准你依赖“按时间判断是否刷新”的逻辑就会失效导致设备错过了刷新窗口。这个坑我曾经在一个项目里耗了快两天才定位到最后发现是 RTC 芯片的时钟漂移在每周断网维护后没有重新同步。从那以后我每次初始化都要强制从 NTP 获取一次时间而不是信任上次保存的值。5. 高级玩法多设备管理、消息推送和功耗优化5.1 用 MQTT 做推送让设备变成“安静的收件箱”HTTP 轮询模式适合固定周期获取数据但有些场景需要实时推送。比如你希望通知信息到了就立刻显示在屏幕上而不是等下一次 30 分钟的唤醒周期。这时候 MQTT 就派上用场了。ESP32 上常用的 MQTT 库是 PubSubClient配合稳定的 Broker比如公有云的 EMQX、本地部署的 Mosquitto可以实现消息订阅。设备订阅一个主题比如epaper/device1/incoming消息内容用 JSON 封装接收后解析并刷新屏幕。一个很容易被忽略的点是MQTT 连接必须解决“保活”和“断线重连”。因为设备平时处于深度睡眠MQTT 长连接无法维持所以实际设计时需要拆成两类策略策略 A设备周期性唤醒连接 Broker检查是否有离线消息Persistent Session。策略 B设备保持浅睡眠或 Modem 休眠Wi-Fi 不断开维持 MQTT 长连接。策略 B 的实时性高但功耗明显提升失去了电子纸的优势。如果不是特别刚需实时推送我建议用策略 A简单可靠。如果一定要实时可以考虑“信号到达时路由器/Wi-Fi 唤醒”的方案这个比较复杂不建议新手一上来就试。5.2 多设备协同一套后端服务管理多块屏幕当项目从一块屏扩展到多块屏时单独为每块屏编写不同固件基本不可维护。推荐做法是把内容和固件分离所有屏幕跑同一个固件启动时根据设备 ID 从服务端拉取“显示配置”——包括要显示的组件、数据源、刷新频率、布局参数。这样后端改配置就能远程调整所有屏幕不需要重新烧录。我自己的服务端实现是用 Node-RED 做一个轻量 API接收 GET 请求返回该设备的完整显示配置再用 InfluxDB 存储各设备的上次报告状态方便监控。整个方案没有引入重型框架但足够支撑几十块屏的规模。多设备场景下还有一个容易忽略的问题NTP 时间同步。如果屏上要显示“最后更新时间”必须保证设备时间可靠否则用户看到的时间信息就不可信。在每块屏的固件里加上 NTP 同步逻辑每次唤醒都从时间服务器获取标准时间而不是依赖设备本地 RTC。5.3 功耗优化的几个进阶技巧除了深度睡眠还有几个让续航更长的关键手段降低 Wi-Fi 发射功率近距离场景用WiFi.setTxPower(WIFI_POWER_11dBm)就足够了不要用最大功率实测电流可以减少 30 到 40 毫安。减少初始化次数电子纸驱动板初始化时会有电流冲击如果只是一些简单的局部刷新尽量复用同一个初始化好的上下文。关掉不必要的模块如果固件不需要蓝牙在 setup 里直接btStop()可以省去蓝牙协议栈的空转电流。用轻量级协议替代 HTTPSHTTPS 握手开销远大于 HTTP在局域网内如果安全要求不高直接走 HTTP 能明显缩短清醒时间。注意加密与否要根据实际场景权衡敏感数据必须加密传输。分批绘制不要在同一帧里绘制大量小图形那样会拉长绘制时间多做几个整块区域减少数据写入量。这些细节单看每一项省的电不多但叠加起来对一个电池供电的长期运行设备来说是质变。6. 常见问题速查表结合前面的内容我整理了一个实用排查表值得收藏。现象可能原因快速解决办法设备搜不到 Wi-Fi频段不匹配或热点开了 5GHz确认热点为 2.4GHz多等几秒再扫描能连上但网络请求超时DHCP 获取慢、DNS 配置异常固定静态 IP手动指定 DNS屏幕刷新后出现严重残影刷新模式选择不合理对内容变化大的页面使用全刷模式屏幕显示花屏/灰阶不均供电电压跌落或线路电阻过大检查供电加粗电源线加大电容内容长期不更新数据源 API 结构变化打印响应体用 curl 对比设备重启后连不上网Wi-Fi 保存信息失效使用WiFi.setAutoReconnect(true)或重启后重新 scan显示的中文出现乱码字库编码不匹配确认字体数组基于 UTF-8 编码且包含需要显示的 ASCII 字符这个表看起来简单但每一条都是真实项目里反复踩过的。我个人做 Wi-Fi 电子纸最大的感受是这个项目绝对不是一个“入门三小时”的玩具它是一个横跨硬件、网络、嵌入式、接口设计的整合型任务。它的魅力在于组合——用最克制的功耗、最安静的方式把网络世界的关键信息呈现在一块像纸一样的屏幕上。做好一个你会学到 SPI 时序、低功耗设计、JSON 解析、断线重连、OTA 升级、后端数据流几乎每个物联网项目里都用得上的技能都会在这一块屏幕上过一遍。如果你刚拿到板子先别急着写代码建议按这篇文章的顺序先把一块屏幕点亮再让它连网拉到一条数据最后才考虑排版和美化。路一步步走坑一个个踩做出来的东西才经得起长期使用。最后再送一个小技巧调试时把串口打印拉开BEFORE_INIT、WIFI_CONNECTING、HTTP_REQUESTING、JSON_PARSING、DRAWING、REFRESH_DONE每个阶段都打印一行状态然后在家运行三天你会对这块屏幕每个环节的真实耗时和出错率有非常准确的体感。这些小数据比任何理论分析都管用。祝你们都能顺利点亮第一块 Wi-Fi 电子纸。