1. 项目概述从“能显示”到“会思考”的桌面摆件进化几年前我折腾过一个叫“Display Cup”的小玩意儿说白了就是一个能显示信息的智能水杯。当时用了一块小屏幕和Arduino功能很基础就是显示个时间、天气或者几句鸡汤文字。东西做出来后新鲜感一过它就吃灰了。核心问题在于它只是一个被动的信息显示器和我这个使用者之间几乎没有互动。这次重启“Display Cup MK2”项目目标很明确不再是做一个简单的桌面摆件而是要打造一个具备环境感知与智能交互能力的“桌面信息中枢”。我希望它不仅能看还能“感受”周围并基于我的状态做出反应。这个MK2版本核心定位是一个高度集成化的个人微环境监测与信息交互终端。它需要无缝融入我的办公桌或家居环境在不增加干扰的前提下提供有价值的信息和轻量级交互。比如当我长时间伏案它能提醒我起来活动当室内光线变暗它能自动调整屏幕亮度甚至提醒我开灯它还可以成为一个无需动手的快速信息看板显示待办事项、会议提醒或者连接智能家居显示状态。Display Cup MK2的关键词是“环境感知”、“无感交互”和“信息聚合”。它不再是一个孤立的设备而是试图成为连接数字世界与物理桌面环境的一个温和的触点。2. 整体设计与核心思路拆解2.1 从需求反推的技术选型逻辑上一代的失败教训让我意识到单纯的“显示”价值有限。因此MK2的设计必须围绕“感知-决策-反馈”这个闭环展开。我拆解了三个核心需求层环境感知层需要知道“周围发生了什么”。这包括环境光强度控制显示、温湿度舒适度参考、是否有人接近触发交互。信息处理与决策层需要理解“我可能需要什么”。这需要一个小型“大脑”来处理传感器数据、运行逻辑判断、并管理网络通信以获取外部信息如时间、天气、日历。交互与反馈层需要优雅地“告诉我并接受我的指令”。这包括一个观感良好的显示屏、可能的声音提示以及最关键的——一种无需拿起手机或大声说话的交互方式。基于这些需求硬件选型就清晰了主控ESP32系列芯片成为不二之选。它集成了Wi-Fi和蓝牙双核处理能力足以应对传感器数据采集、逻辑判断和网络请求且开发生态Arduino/ESP-IDF极其成熟。我选择了ESP32-S3因为它有更多的GPIO和更好的USB-JTAG支持调试更方便。感知模块环境光传感器选择了常见的BH1750I2C接口精度足够代码库成熟。温湿度传感器DHT22或SHT30。DHT22成本低但速度慢SHT30更准更快但贵。考虑到杯内环境相对稳定变化不剧烈我选了DHT22将成本投入其他地方。接近/手势传感器这是实现“无感交互”的关键。我选择了APDS-9960它集成了接近检测、手势识别上下左右挥动和RGB光感一个模块解决多个问题通过I2C与ESP32通信。反馈模块显示屏放弃了之前的OLED选择了2.8英寸的ILI9341驱动的TFT LCD。原因有二一是尺寸更大能显示更丰富的信息布局二是支持触摸屏电阻或电容为未来交互留出扩展空间。虽然功耗比OLED高但桌面设备常供电可以接受。其他反馈预留了一个小型无源蜂鸣器用于极简的提示音避免打扰。注意传感器布局是门学问。例如APDS-9960和光传感器必须朝向用户方向且不能被杯身或其他部件遮挡否则检测会失灵。温湿度传感器则应避开主板发热源最好有少量空气流通。2.2 系统架构与数据流设计整个系统的软件架构可以看作一个轻量级的“事件驱动”模型。我放弃了复杂的RTOS实时操作系统而是采用一个主循环配合状态机的设计这对于MK2的功能复杂度来说足够高效且易于维护。数据流是这样的传感器数据采集在主循环中以固定的、非阻塞的间隔如每500ms读取各传感器数据。对于DHT22这类慢速传感器读取失败时加入重试和超时机制避免主循环卡死。事件生成将原始数据转化为“事件”。例如环境光低于阈值 - 生成“光线变暗”事件APDS-9960检测到接近手势 - 生成“手势左滑”事件网络时间到达整点 - 生成“整点报时”事件。事件处理与状态更新一个中央状态机根据当前模式和接收到的事件更新内部状态如显示模式、亮度等级、提醒标志位。例如在“时钟模式”下收到“手势左滑”事件切换到“天气模式”收到“光线变暗”事件则调用函数降低屏幕背光PWM值。渲染与输出状态更新后触发显示渲染函数。这里采用“脏矩形”渲染思想只更新屏幕上发生变化的部分而不是全屏刷新以提高效率并减少闪烁。例如只有时间数字变化时才重绘时间区域。网络同步在后台通过Wi-Fi定期如每30分钟或由事件触发如切换到天气模式向网络API请求数据时间、天气、日历。网络操作必须完全异步使用非阻塞的HTTP客户端绝不能阻塞主循环。// 伪代码示例主循环与事件处理核心逻辑 void loop() { unsigned long currentMillis millis(); // 1. 定时传感器采样非阻塞 if (currentMillis - lastSensorReadMillis 500) { readSensors(); generateEvents(); // 将数据转化为事件放入事件队列 lastSensorReadMillis currentMillis; } // 2. 处理事件队列 while (eventQueue.hasEvent()) { Event e eventQueue.pop(); handleEvent(e); // 根据事件类型和当前状态更新状态机 } // 3. 状态驱动渲染 if (stateChanged) { renderDisplay(); // 差异化渲染 stateChanged false; } // 4. 处理异步网络任务如果有 handleNetworkTasks(); }这种架构清晰地将数据采集、逻辑处理和界面渲染解耦后续增加新传感器或显示模式都非常方便。3. 核心模块实现与软硬件联调3.1 硬件集成与PCB设计考量第一代用的是面包板和杜邦线可靠性差且体积臃肿。MK2我决定设计一块定制PCB将ESP32-S3、传感器、屏幕接口和电源管理集成在一块板子上做成一个“核心板”然后通过排线连接屏幕。这样做有几个好处一是体积最小化可以更好地融入杯体设计二是稳定性极大提升没有松动接触三是电源走线可以优化减少干扰。在设计PCB时我特别注意了以下几点电源分区为数字部分ESP32、逻辑电路和模拟部分传感器提供了独立的LC滤波电路防止数字噪声影响传感器读数尤其是APDS-9960对红外噪声比较敏感。I2C上拉电阻ESP32的内部上拉电阻较弱我在SDA和SCL线上都预留了外部4.7kΩ上拉电阻的焊盘实际调试中根据总线负载决定是否焊接。屏幕接口ILI9341屏幕通常使用SPI接口我选择了硬件SPI引脚ESP32的HSPI并将背光控制引脚连接到ESP32的PWM输出引脚以便实现亮度调节。调试接口除了USB-Type C用于供电和编程我还引出了ESP32-S3的串口UART引脚方便在屏幕无法显示时进行串口日志输出这是排查复杂问题的生命线。焊接完成后不要急于组装。先进行分模块测试单独测试ESP32能否烧录程序单独连接屏幕运行一个简单的图形测试程序逐个连接传感器读取数据。确保每个模块独立工作正常再进行整体联调。3.2 传感器数据融合与滤波实践原始传感器数据是充满噪声的。直接使用会导致系统行为“抖动”比如光线稍有变化屏幕亮度就频繁调整体验很差。因此必须对数据进行滤波。环境光采用移动平均滤波。连续采样10次取平均值作为当前光照值。只有当平均值与上一次输出值的差异超过一定阈值如10%才触发“光线变化”事件。// 简化的移动平均滤波示例 #define LIGHT_SAMPLE_COUNT 10 int lightReadings[LIGHT_SAMPLE_COUNT]; int lightIndex 0; int lightTotal 0; int lightAverage 0; int getFilteredLight() { lightTotal lightTotal - lightReadings[lightIndex]; // 减去最旧的读数 int raw readBH1750(); lightReadings[lightIndex] raw; lightTotal lightTotal raw; // 加上最新的读数 lightIndex (lightIndex 1) % LIGHT_SAMPLE_COUNT; return lightTotal / LIGHT_SAMPLE_COUNT; }接近检测APDS-9960的接近值Proximity波动很大。这里我使用了阈值迟滞算法。设置两个阈值THRESHOLD_HIGH如200和THRESHOLD_LOW如50。只有当读数持续高于HIGH阈值才判定为“有物体接近”只有当读数持续低于LOW阈值才判定为“物体远离”。这避免了在阈值边缘反复横跳。温湿度DHT22数据更新慢且偶尔会读失败。我的策略是增加读取间隔如每5秒一次并对失败进行指数退避重试。显示的温度值也做了移动平均处理使其变化更平滑。数据融合的更高阶应用是结合接近传感器和环境光传感器。例如当检测到有人接近手在杯前挥动且环境光足够亮时才提高屏幕亮度到最高以便查看无人时即使环境光亮也保持较低亮度以节能。3.3 显示系统与UI框架构建在ESP32上实现一个流畅的UI需要一些技巧。ILI9341屏幕驱动本身比较耗时全屏刷新慢。我采用了以下优化使用高效的图形库放弃了Adafruit_GFX Adafruit_ILI9341的默认组合转而使用TFT_eSPI库。这个库针对ESP32和常见屏幕驱动做了大量优化支持帧缓冲Frame Buffer渲染速度更快并且直接集成了多种字体和图形绘制函数。建立显示缓冲区在内存中建立一个与屏幕物理分辨率240x320相同的16位色彩缓冲区uint16_t frameBuffer[240*320]。所有UI元素的绘制都先操作这个缓冲区最后一次性调用tft.pushImage(0, 0, 240, 320, frameBuffer)将缓冲区内容发送到屏幕。这比直接操作屏幕内存要快且避免了局部更新带来的闪烁。差异化渲染脏矩形这是关键。我为每个UI区域如时间数字区、天气图标区、温度读数区定义了一个结构体记录其内容和位置。只有当某个区域的内容需要更新时才重绘该区域对应的缓冲区部分然后只更新屏幕上的这一小块区域。// 伪代码更新时间区域 if (timeNeedsUpdate) { // 1. 在缓冲区中擦除旧时间区域绘制背景色 fillRectInBuffer(oldTimeArea, BACKGROUND_COLOR); // 2. 在缓冲区中绘制新时间文本 drawTextInBuffer(newTimeString, timeArea, TEXT_COLOR); // 3. 只将这块缓冲区区域推送到屏幕 pushImageToScreen(timeArea.x, timeArea.y, timeArea.width, timeArea.height, frameBuffer); timeNeedsUpdate false; }UI状态管理我定义了几个主要的显示模式MODE_CLOCK,MODE_WEATHER,MODE_CALENDAR,MODE_STATS。每个模式有自己对应的渲染函数。状态机在切换模式时调用新模式的renderFull()函数进行全屏初始绘制之后在循环中只调用renderUpdate()进行增量更新。4. 网络服务与云端数据对接4.1 低功耗Wi-Fi连接策略虽然MK2是常供电设备但稳定的网络连接仍是挑战。ESP32的Wi-Fi连接如果处理不好会莫名断开或阻塞线程。我的策略是智能重连在setup()中初始化Wi-Fi并连接。在loop()中定期检查连接状态。如果断开不是立即重连而是等待几秒记录重连次数。连续失败多次后进入一个更长的等待期然后尝试重启ESP32ESP.restart()。这比无限快速重连更有效。非阻塞HTTP请求绝对避免使用WiFiClient的阻塞式connect和print。我使用了HTTPClient库并确保每次请求都设置超时如5秒。将HTTP请求封装成一个独立的任务函数该函数通过返回值告知主循环请求状态成功、失败、进行中。数据缓存从网络获取的数据如天气信息立即存入ESP32的非易失性存储NVS。这样即使网络暂时中断设备也能显示上一次成功获取的数据并在屏幕角落显示一个“缓存”或“离线”小图标提示用户信息可能不是最新的。4.2 免费API的选用与数据解析为了获取天气、时间等信息需要选用稳定免费的API。网络时间使用NTP网络时间协议是最简单的。ESP32内置了configTime()函数可以连接公共NTP服务器如pool.ntp.org同步时间。我设置每12小时同步一次。天气信息国内可用的免费天气API选择有限且经常变动。我最终选择了和风天气的免费开发版。它提供JSON格式的数据每天有较多次数的免费调用额度。获取数据后需要使用ArduinoJson库来解析复杂的JSON结构。// 示例解析和风天气JSON简化 DynamicJsonDocument doc(2048); deserializeJson(doc, httpClient.getString()); int temp doc[now][temp].asint(); // 当前温度 const char* weatherText doc[now][text].asconst char*(); // 天气状况文字 // 根据 weatherText 匹配显示对应的图标日历/待办事项这是更具挑战性的部分因为它需要访问个人数据。我采用了一个折中方案搭建一个简单的私有服务器可以用树莓派或云服务器上面运行一个脚本定期从我的日历服务如Google Calendar的iCal链接拉取事件然后提供一个非常简单的API给ESP32只返回下一个即将发生的事件标题和时间。ESP32只需要对这个私有API进行HTTPS请求即可。这避免了在MCU上处理复杂的OAuth认证。实操心得处理JSON时一定要用DynamicJsonDocument并预留足够大的容量可通过doc.capacity()检查解析失败是网络功能中最常见的崩溃原因之一。另外所有网络操作都必须放在try-catch块中或者进行严格的返回值判断确保单次网络失败不会导致系统重启。5. 结构设计与用户体验打磨5.1 杯体改造与散热考量我选用了一个双层不锈钢保温杯作为外壳。它的好处是内部空间规整隔热性好防止内部电子元件发热影响杯内水温感知也防止手温影响传感器。改造步骤开孔定位这是最需要耐心的一步。在杯身侧面用记号笔精确标出屏幕窗口、传感器窗口APDS-9960和环境光的位置。使用小型手电钻配合不同尺寸的钻头逐步开孔最后用锉刀和砂纸将孔边缘打磨光滑。内部固定设计并3D打印了一个内部支架用于固定核心PCB板和电池如果需要。支架与杯壁之间用海绵胶或导热硅胶垫填充起到减震和辅助散热的作用。屏幕安装将TFT屏幕用强力双面胶粘贴在杯身内部对准开孔。在屏幕与杯壁之间垫一圈薄海绵防止压伤屏幕并提升密封性。密封与防水虽然不要求完全防水但防尘防潮是必须的。我在所有内部线缆穿孔处使用了热熔胶进行密封。屏幕窗口和传感器窗口我切割了合适大小的亚克力板用透明的防水胶如UV胶或环氧树脂从内部粘合确保透光且密封。散热ESP32在持续高负载Wi-Fi屏幕下会发热。我将核心PCB的背面ESP32芯片处通过导热硅胶垫与金属杯身内壁接触利用整个金属杯体作为散热片。实测下来内部温度可以控制在比环境温度高8-12摄氏度的范围内属于安全区间。5.2 交互逻辑与用户体验优化硬件是骨架交互逻辑才是灵魂。我设计了以下几层交互基础信息轮播无人交互时屏幕在时钟、室内温湿度、天气、日历事件之间自动轮换显示每个页面显示10秒。屏幕亮度根据环境光自动调节。手势触发接近唤醒当APDS-9960检测到有物体通常是手在杯前5-10厘米内停留超过1秒系统立即点亮屏幕如果已熄灭或切换到高亮模式并暂停自动轮播停留在当前页面。手势切换在唤醒状态下在传感器前向左挥动切换到下一个信息页面向右挥动切换到上一个页面。向上挥动调出一个简易菜单如开关蜂鸣器、手动亮度向下挥动关闭菜单或返回。触摸扩展预留虽然当前固件未启用但硬件上预留了触摸屏接口。未来可以增加点击图标查看详情、长按进入设置等更丰富的交互。体验优化的细节动画过渡页面切换时我实现了一个简单的滑入动画新页面从右侧滑入让切换不那么生硬。这通过在缓冲区中按偏移量绘制图像并快速连续推送实现。视觉反馈当手势被识别时在屏幕边缘显示一个短暂的小箭头图标给予用户即时反馈。超时管理从最后一次交互手势或触摸开始计时如果30秒内无新交互则屏幕亮度逐渐降低至“待机亮度”很暗但仍可见如果再过2分钟仍无交互则关闭屏幕背光。任何接近或手势事件会立即唤醒。6. 电源管理与系统稳定性实战6.1 多模式电源方案设计我最初设想用电池供电以实现完全无线但高亮度屏幕和Wi-Fi是耗电大户续航会非常短。因此MK2最终采用了USB Type-C常供电为主内置小容量锂电池作为备用的方案。主电源5V USB输入通过一个DC-DC降压模块稳定到3.3V给整个系统供电。备用电池并联一组18650锂电池带保护板通过一个TP4056充电管理模块连接到USB输入。当USB供电时TP4056为电池充电当USB断电时电池通过一个理想二极管或MOSFET防反接电路自动为系统供电。电源路径管理核心是一个“电源路径管理”电路确保系统始终优先使用USB电源并在USB断开时无缝切换至电池电压无跌落。这可以用专用的芯片如LTC4412实现也可以用MOSFET搭建。在软件上需要实时监测输入电压通过ESP32的ADC引脚分压测量。当检测到使用电池供电时系统自动进入节能模式降低屏幕亮度上限、延长屏幕关闭超时时间、减少Wi-Fi同步频率如每小时一次、关闭非核心传感器如温湿度采样间隔拉长。6.2 固件稳定性与OTA升级一个需要长期运行的设备固件稳定性和可维护性至关重要。看门狗启用ESP32的硬件看门狗esp_task_wdt_init()和软件看门狗。在主循环的关键位置定期喂狗。如果某个任务卡死导致无法喂狗看门狗会自动重启系统。异常处理与日志所有可能失败的操作网络请求、传感器读取、文件操作都有完善的错误处理和重试机制。关键的运行状态、错误代码会通过串口打印并同时写入SPIFFS文件系统中的一个日志文件循环覆盖防止占满空间。这样当设备出现异常时我可以取出日志分析。OTA升级这是必备功能。我实现了两种OTA方式HTTP OTA设备启动后如果连接上Wi-Fi会向我指定的服务器请求一个版本文件比对本地版本。如果发现新版本则自动下载固件并更新。这适合功能迭代。本地串口OTA通过USB线使用Arduino IDE或ESP-Flasher工具进行烧录。这是开发调试和救砖的最后手段。配置门户第一次启动或长按某个隐藏按钮时设备会进入“配置模式”自身变成一个Wi-Fi热点。用手机连接这个热点后打开浏览器会自动弹出一个网页用于配置设备要连接的Wi-Fi SSID/密码、API密钥等参数。配置完成后设备自动重启并连接。这极大简化了部署流程。我使用了WiFiManager库来实现此功能。7. 开发中遇到的典型问题与排查实录在开发Display Cup MK2的过程中踩了不少坑这里记录几个典型问题及其解决方案。7.1 屏幕闪烁与图像撕裂问题现象屏幕在更新时特别是局部更新时出现明显的闪烁或图像撕裂上一帧和下一帧的部分内容同时显示。排查过程首先怀疑是电源问题用示波器测量3.3V电源线在屏幕刷新时有轻微毛刺但幅度不大50mV。检查代码发现最初使用的是tft.drawPixel和tft.drawLine等函数直接画屏这些函数每次调用都涉及一次SPI通信速度慢且不同步。改用tft.startWrite()和tft.endWrite()包裹一系列绘制指令略有改善但未根除。最终方案是引入帧缓冲区和脏矩形更新。闪烁和撕裂的根本原因是直接操作屏幕内存时屏幕的刷新周期由驱动器内部决定与MCU的写入周期不同步。使用缓冲区后所有绘制在内存中完成最后一气呵成地同步到屏幕完美解决了问题。7.2 APDS-9960手势识别不稳定问题现象手势识别时灵时不灵经常误触发或没反应。排查与解决环境光干扰APDS-9960使用红外LED和传感器。强烈的环境红外光如阳光、白炽灯会干扰它。我给传感器窗口加了一个深色的红外滤光片可以从旧的遥控器或摄像头拆只允许特定波段的红外光通过效果立竿见影。阈值设置不当初始的接近阈值和手势识别增益设置是默认值。我通过串口实时打印传感器的原始数据观察手在不同距离和速度下的数值变化。最终通过实验将接近检测的LED电流调高并设置了一套更符合我手势习惯的阈值和去抖参数。传感器朝向最初传感器朝向略微向上导致挥手时手掌的投影面积变化不规律。将其调整为水平正对前方识别率大幅提升。7.3 Wi-Fi频繁断开重连问题现象设备运行一段时间后Wi-Fi断开然后不断尝试重连有时能连上有时需要重启。排查与解决怀疑是路由器问题但其他设备正常。查看ESP32的日志发现断开前常有“esp_wifi: disassoc from AP”或“wifi: ap is disconnected, reason: 201”等信息。原因201通常是“无活动超时”。根本原因ESP32的Wi-Fi在默认的节能模式WIFI_PS_MIN_MODEM下为了省电可能会与路由器断开连接。对于常供电设备不需要此功能。解决方案在Wi-Fi初始化后添加esp_wifi_set_ps(WIFI_PS_NONE);这行代码将Wi-Fi电源模式设置为“无节能”强制保持连接。修改后Wi-Fi连接稳定性极大增强。7.4 内存泄漏导致系统重启问题现象设备连续运行几天后会自己重启。串口日志显示重启原因是“Brownout detector was triggered”欠压检测或“Guru Meditation Error”严重错误。排查与解决首先排除硬件供电问题用稳压电源供电问题依旧。怀疑是堆内存耗尽。使用ESP.getFreeHeap()在循环中打印剩余内存发现内存确实在缓慢减少。内存泄漏点经过逐段代码注释排查发现罪魁祸首是HTTP请求处理。我使用的HTTPClient在每次请求后虽然调用了end()但在某些异常路径下如网络超时资源没有完全释放。解决方案确保HTTPClient对象在每次使用无论成功失败后都将其置于局部作用域内或者显式调用~HTTPClient()析构。更好的做法是使用一个全局的、可复用的HTTPClient实例并在每次请求前彻底清理它client.end()。同时在JSON解析后确保DynamicJsonDocument对象离开作用域被自动销毁或手动调用doc.clear()。常见问题速查表问题现象可能原因排查步骤与解决方案屏幕白屏/不亮1. 电源未接通或电压不足2. 屏幕背光控制线未接/电平不对3. SPI引脚定义错误1. 测量屏幕VCC电压需5V或3.3V2. 检查背光引脚是否接对尝试给高电平3.3V3. 核对代码中SPI引脚定义与硬件连接传感器读数全为0或异常1. I2C地址错误2. I2C总线未正确初始化3. 电源或接地不良4. 传感器损坏1. 使用I2C扫描程序确认设备地址2. 检查Wire.begin()是否执行SDA/SCL引脚是否接对3. 用万用表测量传感器VCC和GND4. 更换传感器测试无法连接Wi-Fi1. SSID/密码错误2. 路由器频段或加密方式不支持3. Wi-Fi模块损坏1. 使用串口打印输入的配置信息核对2. 尝试将路由器设置为2.4GHz加密方式WPA2-PSK3. 运行简单的Wi-Fi扫描示例看能否搜到网络OTA升级失败1. 网络不稳定2. 固件文件损坏或不匹配3. 分区表空间不足1. 检查设备网络连接状态2. 确认下载的固件bin文件是针对此设备型号编译的3. 检查分区表配置确保OTA分区足够大系统运行一段时间后死机1. 内存泄漏2. 看门狗未及时喂食3. 堆栈溢出1. 监控ESP.getFreeHeap()变化2. 检查长耗时任务中是否调用了delay()阻塞了喂狗3. 增加任务堆栈大小或优化递归/大型局部变量8. 项目总结与未来可扩展方向Display Cup MK2从构思到实现是一个典型的嵌入式全栈项目涉及硬件选型、电路设计、PCB制作、固件开发、传感器融合、网络通信、UI设计和结构设计等多个环节。整个过程下来最深的体会是**“软硬结合细节制胜”**。一个想法从代码变成手中可运行的实体中间有无数需要权衡和调试的地方。比如为了那1%的识别率提升可能需要调整传感器位置、修改滤波参数、优化手势算法好几轮。这个项目的价值对我来说远不止于做出了一个酷炫的杯子。它更像是一个可定制的桌面交互平台。目前的功能只是冰山一角基于现有的硬件框架ESP32-S3、多种传感器、触摸屏未来可以扩展的方向非常多语音交互集成一个离线语音识别模块如LD3320实现“语音唤醒命令”功能比如说“明天天气”就直接显示天气预报。更多传感器加入空气质量传感器如SGP30监测室内CO2和TVOC加入麦克风实现简单的环境噪音监测或声控。与其他智能家居联动通过MQTT协议成为Home Assistant或米家等平台的一个节点。显示智能家居状态或者用手势控制其他设备比如向左挥关灯向右挥开灯。个性化信息流对接更多个人数据源如RSS订阅、股票信息、健身数据等真正成为个人专属的信息聚合终端。最后关于开源与分享我已经将MK2的硬件原理图、PCB文件立创EDA格式、核心固件代码整理上传到了GitHub。我强烈建议有兴趣的朋友不要直接照搬而是理解其中的设计思路尤其是事件驱动架构、传感器数据融合和电源管理这几个核心部分。你可以根据自己的需求更换传感器、修改UI甚至用不同的主控比如RP2040来实现。嵌入式开发的乐趣就在于这种从无到有、不断调试直至完美运行的创造过程。希望我的这些经验和踩过的坑能帮你更快地实现自己的那个“MK1”想法。
