如果跟你说一块手表能连续用一个月不充电同时还支持换表盘、看天气、连蓝牙甚至还能当指南针和番茄钟你第一反应多半是不可能。但如果你愿意花点时间跟着开源社区的方案折腾一块墨水屏手表这件事还真能落地——而且是完全免费开源、用 Arduino 编程就能搞定的那种。我把这个项目从选型到成品完整走了一遍整个过程涉及屏幕选型、低功耗设计、表盘定制、网络配网、断电存储等不少坑也有不少值得记录的技巧。这篇文章就围绕30天长续航和墨水屏这两个核心点把整个项目的来龙去脉、硬件搭建、软件架构和踩坑经验一次讲透。无论你只是想复刻一块自己专属的手表还是想深入了解低功耗物联网设备的编程思路这篇文章应该都能给你一些启发。1. 为什么是墨水屏加低功耗主控这个组合才是续航的根本先把最核心的问题摆出来一块手表要做到30天续航靠大电池是走不通的手表体积就那么大塞不下太多毫安时。真正要解决的是显示器件和主控平台两者的能耗结构。1.1 墨水屏的功耗模型和手机屏幕完全不一样普通的 TFT 屏幕或者 OLED 屏幕只要亮着就在耗电刷新频率越高耗电越猛。墨水屏完全相反它只有在画面改变的那一瞬间才消耗电流画面静止的时候屏幕本身是零功耗的断电之后画面依然保留。这个特性对穿戴设备来说太关键了。一块手表绝大多数时间界面都是静止的——看时间、看日期、看天气这些内容一分钟最多变化一次。墨水屏把功耗从持续不断变成了按需刷新光是这一点就能让续航从几天拉到几周。我当时选的是某款 1.54 英寸三色墨水屏黑、白、红三种颜色分辨率 200 x 200。选它的原因有三尺寸适合表盘、驱动资料全、三色显示让 UI 有更多设计空间。红色可以用来做高亮提醒比如闹钟图标、低电量警告都能做出明显的视觉层次。1.2 主控选型性能和功耗之间怎么权衡墨水屏把显示功耗解决了另一个耗电大头就是主控芯片和无线模块。这个项目要求同时支持蓝牙和 Wi-Fi还能跑物联网协议所以主控的选择直接决定了整体功耗的下限。市面上的主流方案大致分两类方案特点适合场景低功耗蓝牙 MCU如 nRF 系列只支持 BLE不支持 Wi-Fi功耗极低追求极限续航但功能受限Wi-Fi BLE 集成 MCU如 ESP32 系列支持双模无线生态成熟Arduino 支持好功能全面可玩性高需要深度睡眠配合板级 SiP 模块集成度高体积小小批量产品化但成本偏高我最终选了带 Wi-Fi 和 BLE 的低功耗双模 MCU 方案也就是 ESP32 这一路。虽然它在跑 Wi-Fi 时功耗不算低但通过 Arduino 框架的esp_sleep深度睡眠机制可以把待机电流压到微安级别。配合 RTC 定时唤醒日常使用完全能做到只在需要时干活。提示ESP32 的电池供电不建议直接接 5V 引脚。最好用锂电池供电经过稳压到 3.3V 再给主控和屏幕确保电压纹波小防止屏幕刷新异常。1.3 系统架构思路Arduino 生态帮你省掉大量底层工作很多做嵌入式的人可能会想这么复杂的系统是不是得上 RTOS其实用 Arduino 框架完全够。Arduino 的优势在于生态库——墨水屏驱动、Wi-Fi 配网、JSON 解析、低功耗 API 都有现成轮子写的代码几乎全是业务逻辑层面的不需要纠结寄存器配置。项目整体架构是一个主循环 定时唤醒的事件驱动模型。日常处于深度睡眠RTC 闹钟每 90 秒唤醒一次主动拉取传感器数据刷新表盘如果用户在操作则进入短时活跃状态空闲后自动睡回。这套逻辑用 Arduino 写起来很直观维护成本也低非常适合开源项目的协作形式。2. 硬件搭建阶段的部件选配与装配避坑清单软件写得再好硬件焊接不过关一切都白搭。这个项目涉及电池、屏幕、传感器等多个模块装配过程有几个坑特别容易踩我一个个说。2.1 完整部件清单每一件都是续命的关键主控ESP32 开发板选带电池充电管理的那类更省事墨水屏1.54 英寸三色墨水屏模块200x200电池200mAh 锂聚合物电池扁平封装适合塞表壳充电管理TP4056 充电保护一体板带锂电池保护传感器6 轴 IMU 模块加速度计 磁力计用于指南针实时时钟低功耗 RTC 模块带闹钟中断功能按键2 个微动开关用于翻页、确认表壳3D 打印或手工改造的表壳你可能注意到我加了 RTC 模块。很多人问主控本身不是有内部 RTC 吗但问题是深度睡眠状态下内部 RTC 的计时精度和唤醒能力都不够稳尤其是走时间长了会漂。外挂低功耗 RTC 相当于闹钟把唤醒信号直接接给主控的 EXT1 唤醒引脚精度和功耗都能兼顾。2.2 焊接与调试顺序先点亮屏幕再做其他我强烈建议遵循这个顺序装配别图快。先把主控和墨水屏焊接好刷一个出厂画面测试程序点亮点亮正常之后再接传感器和 RTC。原因是墨水屏是整套系统里最脆的部件排线非常薄焊接手法不对容易虚焊甚至断线。如果一上来就把所有模块都焊好出了问题很难定位。焊接墨水屏的 FPC 排线时注意使用助焊剂温度控制在 320°C 以内焊完后用放大镜检查有没有桥连。我第一块屏幕就是因为没看清桥连刷新时出现花屏排查了整整一天。2.3 电池充电管理别忽略的低电量关断问题锂电池在过放之后会被保护板切断输出这时如果强推开机会出现反复重启的现象。TP4056 充电管理模块上的输出端最好加一个大一点的电容器比如 100uF 钽电容用来吸收电池接入瞬间的浪涌电流避免主控在开机瞬间因电压跌落而复位。另外如果开发板上自带充电电路要看它是否带升压路径管理。很多时候电池充满 4.2V但主控和屏幕需要稳定 3.3V中间必须加 LDO 稳压。不要直接把电池正极接到 3V3 引脚那样会导致电压波动屏幕刷新时尤其明显容易出噪点。3. 表盘 UI 与自定义机制墨水屏的显示策略决定观感墨水屏显示刷新慢这是它的物理特性也就决定了 UI 不能像手机一样随便动效。表盘设计必须把刷新次数和刷新区域这两个指标当成第一原则来考虑。3.1 分区域刷新别整屏刷新全局刷一次要两秒这块屏幕的全刷full refresh时间大约在 2 到 3 秒如果每一次更新时间都整屏刷那用户体验就是每隔几十秒闪一次大黑场眼睛很难受而且墨水屏全刷次数过多还会加速老化。正确做法是分区域局部刷新partial refresh。我把表盘划分成几个固定区域左上区星期和日期每天刷新一次右上区天气图标和温度每 30 分钟刷新中央区时分秒主时间每秒或每分钟刷新下沿区闹钟状态、蓝牙连接图标、指南针小箭头这样每次唤醒只需要把对应区域的像素推送到屏幕控制器局部刷新一次大约 300 到 500 毫秒观感好很多功耗也小。3.2 表盘布局参数与数据结构设计因为是开源项目自定义表盘就意味着用户能改配置。我设计了一个简单的watchface_config结构体把表盘的各个要素抽象出来typedef struct { bool show_seconds; // 是否显示秒 bool show_date; // 是否显示日期 bool show_weather; // 是否显示天气 uint8_t color_mode; // 黑白 or 三色模式 uint8_t refresh_interval; // 刷新间隔秒 char city_code[16]; // 天气城市代码 } watchface_config;用户在配置网页里改完设置后配置会被写进 NVS非易失存储下次开机自动加载。这里有个关键细节配置写入频率不要太高因为闪存有擦写寿命正常使用完全够但如果为了调试反复擦写寿命损耗会比较明显。3.3 UI 框架选型LVGL 还是裸写用 LVGL 做表盘很炫字体渲染、控件布局都方便。但是 LVGL 在 ESP32 上跑起来需要占用不少内存而且墨水屏驱动和 LVGL 的刷新适配还得额外写。对于这种小尺寸、固定布局的墨水面板我觉得裸写更划算。裸写的方式很简单预置一张 1-bit 位图字体自己实现draw_char和draw_text函数。虽然字体是点阵的但配合三色屏反而做出了那种复古电子表和现代慢设计结合的质感。开源项目的好处是你可以把它作为精简内核来维护想上 LVGL 的用户自己往上层加。注意三色墨水屏的红色像素刷新比黑白像素慢布局时尽量避免红色元素和黑色元素贴太近否则刷新时容易串色。我实测红色区域和黑色文字保持至少 4 像素间距观感最干净。4. 配网与功能扩展天气、蓝牙同步、指南针一个都不能少手表的核心功能不只是看时间标题里的实时天气、番茄闹钟、指南针也要真正落地。这三块分别对应了网络请求、本地状态机控制和传感器数据融合各有各的门道。4.1 Wi-Fi 配网AP 模式还是 BLE 配网手表没有键盘输入 Wi-Fi 密码是个难题。我最终采用了AP 配网方案首次开机时主控开启一个临时热点手机连上这个热点后打开 192.168.4.1 配置页输入家中 Wi-Fi 的 SSID 和密码同时设置天气城市一并保存。这个方案在 Arduino 生态里成熟稳定ESP32 开 SoftAP 的代码量也就几十行配合WiFiManager库几乎算是标配。配网成功后主控自动切换为 STA 模式连接路由器。注意连接 Wi-Fi 的瞬间电流可能冲到 200mA 以上如果电池电压偏低建议在 Wi-Fi 连接前先检测电池电量低于 3.6V 就跳过这次天气更新直接显示上次缓存的数据。否则网络请求会让电池电压骤降导致意外关机。4.2 实时天气与 JSON 解析拉数据前先想好异常情况天气数据来源用的是公开的开放接口返回 JSON。Arduino 上解析 JSON 可以用ArduinoJson库内存开销要注意ESP32 跑起来没问题但解析时尽量复用同一个 JSON 文档对象避免频繁分配堆内存造成碎片。我的处理逻辑是从 NVS 读取城市代码和上次缓存天气。尝试连接 Wi-Fi设置 10 秒超时。拉取天气 API解析温度、天气码。如果成功刷新天气区域并缓存数据到 NVS。如果失败继续显示旧缓存并在下次唤醒后再试。这里有一个容易忽略的细节不同天气 API 返回的天气码含义差别很大。我在设计数据结构时让 UI 层只认识晴、多云、雨、雪、雾这几种枚举而把天气码映射放在数据接入层。这样以后换数据源只需要改映射函数UI 完全不动。4.3 蓝牙同步的三种玩法推荐从配置同步入手手表支持蓝牙以后可玩性就高了。最简单的场景是和手机 App 同步表盘配置、闹钟列表。BLE 协议栈在 ESP32 上属于成熟方案Arduino 的BLE库封装得也比较友好。BLE 的数据结构我用的是服务 特征值模型一个自定义服务里面放三个 characteristic分别对应配置下发、时间同步、命令回执。手机端写入新的表盘配置后手表收到数据先做校验再落盘到 NVS下次刷新立刻生效。进阶玩法是推送手机通知——来电提醒、消息提醒都可以做。不过 BLE 通知推送需要手机 App 常驻后台不同手机系统的策略差异很大这块调试成本较高你要有心理准备。建议先把配置同步和基础时间校准做好通知推送作为后期可插拔模块。4.4 指南针功能的可靠实现磁力计校准绕不开指南针看起来简单把磁力计数据读出来算个角度就行但实际做起来没校准的磁力计误差能偏出几十度。尤其是手表戴在手上周围有磁铁表扣、马达、金属表壳都会干扰磁场。我做了一个三步校准流程椭圆拟合校准让用户在空中画8字采集 3 轴磁力数据用最小二乘法做偏移和缩放修正。固定偏置补偿因为表壳中可能有固定磁干扰在校准完成后计算一个固定的偏置量写进配置。姿态融合单纯用磁力计算角度手腕一倾斜数据就乱。需要把加速度计数据也读进来通过互补滤波稳定姿态。至于怎么显示我画了一个表盘下方的小型罗盘条因为墨水屏不适合做连续动画所以罗盘用的是每 15 度一格的离散刻度指针方向变化时做局部刷新避免整块屏幕闪来闪去。5. 低功耗实现的完整链路从 5 小时到 30 天的关键修改如果一个 ESP32 开发板什么都不做跑一个空循环电流可能在 30 到 50mA 左右200mAh 电池最多撑 5 小时。做到 30 天是一整套功耗控制的组合拳每一环都不能掉链子。5.1 电量消耗拆解每一天的预算要算清楚先算一个账。200mAh 电池30 天意味着平均每天的可用电量是 6.67mAh。各项消耗深度睡眠 RTC 唤醒待机约 5uA24 小时共 0.12mAh每 90 秒唤醒一次做基本时间显示每次约 2mA 持续 4 秒一天 960 次约 2.13mAhWi-Fi 天气获取每天 8 次每次 20 秒约 1.33mAh局部屏幕刷新每天 300 次每次 15mA 持续 0.5 秒约 0.62mAh指南针 / 传感器采样按需约 0.2mAh无线电蓝牙广播仅配网/同步时开启可忽略加起来约 4.4mAh离 6.67mAh 的预算还有余量。所以 30 天这个数字不是吹的是严格按照功耗模型算出来的实测中只要把 Wi-Fi 更新频率控制在 30 分钟一次整个月跑下来是没问题的。5.2 外设独立供电不用的设备就该完全断电墨水屏模块和传感器模块带有自己的电源引脚把它们分别接到主控的 GPIO 控制引脚上就能实现用的时候上电不用的时候断电。比如传感器在指南针功能打开时才供电平时是断电状态可以省掉不少漏电流。主控本身的esp_sleep_enable_timer_wakeup和esp_sleep_enable_ext1_wakeup是两把钥匙。前一个实现周期唤醒后一个实现按键唤醒。我在主循环里加了一个状态判断如果是周期唤醒就只刷新时间如果是按键唤醒就进入菜单操作流程操作结束后再睡回去。5.3 避开隐藏耗电GPIO 悬空和串口输出低功耗设计最坑的一点是 GPIO 悬空。深度睡眠状态下如果有 GPIO 引脚处于高阻态且没有接上下拉它会不断在高低电平之间跳变产生额外的电流消耗。把所有未使用的 GPIO 都设置成输出低电平或者启用内部下拉电阻能明显降低睡眠电流。还有一个很容易忽略的是串口输出。开发阶段大家都在跑Serial.println但如果这个代码在低功耗模式下没关掉串口外设本身会持续耗电。正式运行固件时建议用宏开关把调试输出整个关掉#define DEBUG_ENABLE 0 #if DEBUG_ENABLE #define DEBUG_PRINT(...) Serial.print(__VA_ARGS__) #else #define DEBUG_PRINT(...) #endif这样在调试时打开开关发布时关闭代码不用改第二遍。5.4 实时时钟与闪存数据保护掉电不丢表盘设置RTC 模块自带电池备份断电后时间不丢这是整个系统稳定性的基石。每次进入睡前把当前时间写入 RTC每次唤醒后从 RTC 读时间。即使主控完全没电只要 RTC 的纽扣电池还在时间就不会乱。配置数据存在 NVS 里我按配置版本号 校验和的方式管理。用户从网页传配置文件时先校验、再写入、后读回确认三重保护避免配置写入一半导致开机后 NVS 数据错乱。如果校验失败固件会自动恢复默认配置并提示重新配网这个兜底逻辑很关键至少不会变砖。6. 常见问题排查与整体复盘整套系统做完之后我有几个实际体会如果你准备复刻这些经验能帮你节省大量时间。6.1 墨水屏刷新异常的快速定位方法如果是花屏、残影、条纹先不要怀疑代码。99% 的情况是供电问题、时序问题、或者屏幕排线接触不良。我的定位顺序是测量屏幕供电电压是否稳定在 3.3V观察刷新瞬间电压跌落幅度。用示波器抓 SPI 通信时序看时钟频率是否超过屏幕的规格上限。尝试用示例代码反复刷新 100 次看故障出现概率。如果局部刷新时颜色串扰严重把刷新函数改成整屏刷新对比一下。6.2 重量级项目的精简建议把不常用的功能做成模块式扩展开源项目最容易犯的毛病是主干越堆越庞大。我的建议是核心手表功能时间、表盘、闹钟保持精简稳定天气、蓝牙、指南针这些功能做成独立的代码文件通过编译宏开关来控制是否启用。这样你拿到一个干净的基线固件任何时候都可以快速回归测试。想加功能再把对应模块的宏打开。我自己的仓库就一直保持这个策略每次社区里有人提交新功能模块我都强烈建议他们先以扩展模块的形式提交合入主干之前再充分测试。6.3 最后一点关于续航的真心话续航这个东西其实是一个全系统协同的结果。屏幕选型、主控休眠策略、外设电源管理、软件刷新逻辑任何一环漏电都会影响最终数值。我做第一版的时候光是一个 GPIO 悬空问题就多耗了 10 倍睡眠电流排查了很久才发现。所以如果你复刻后测出的续航达不到 30 天不要急着质疑器件先拿出电流表逐项测一下睡眠电流、唤醒电流和刷新电流定位到具体的偷电环节再针对性优化。这条 DIY 路走下来我最大的收获其实不是手表本身而是对低功耗系统设计有了真正的直觉。以后再看到任何宣称长续航的智能硬件我脑子里会自动把它拆成显示、唤醒、通信、交互四个模块来估算功耗基本八九不离十。希望这篇分享能给你同样的启发。
