最近很多人问我有没有适合练手的STM32开源项目最好是那种功能完整、能直接抄作业、又不至于复杂到劝退的。正好我手头这套智能水杯系统刚整理完开源资料从硬件选型到协议设计到低功耗调优都踩过一遍拿出来聊聊最合适不过。这套系统的定位很明确用STM32F103C8T6作为主控实现水温实时检测、水位检测、喝水定时提醒、运动姿态识别和设备异常报警再加上一个可选的手机APP联动功能。说白了就是一个“能提醒你喝水、能告诉你水烫不烫、还能记录饮水习惯”的物联网小终端。对正在找毕业设计题目的同学、想入门嵌入式物联网开发的工程师或者是单纯想给生活添点小乐趣的DIY玩家都有参考价值。1. 为什么用STM32做智能水杯需求梳理与方案取舍先别急着看电路图和代码。做项目最关键的一步是搞清楚你到底要做什么以及为什么这么做。智能水杯这个选题看似简单真较真起来功能需求能列出长长一串。1.1 功能性需求拆解我当初给自己列的需求清单是这样的水温监测测量杯中液体温度范围0到100摄氏度精度正负1度以内并在OLED屏幕上实时显示。这个功能看上去基础实际上是整个系统里最容易出问题的部分。温度传感器的封装选型、导热方式、ADC采样滤波都直接影响精度。水位提醒检测杯中液体剩余量低于设定阈值时提醒用户加水。听起来简单但水位检测在杯子上做远比在敞开容器里做棘手。定时饮水提醒每隔设定时间默认一小时通过蜂鸣器和震动马达提醒用户喝水。这个功能没有技术难度难在不能做得太吵。饮水动作识别通过加速度传感器识别用户拿起水杯喝水的动作自动记录饮水次数和大致饮水量。这部分是整套系统智能化的点睛之笔也是最值得写进简历的技能点。异常报警水温过高超过60摄氏度防止烫伤或水温过低时立即报警。数据上传与记录通过蓝牙模块将温度数据和饮水记录上传至手机APP或微信小程序方便长期追踪。1.2 方案评估MCU选型与传感器选型在MCU选型上我几乎没有犹豫就选了STM32F103C8T6。原因很实在资料多到溢出遇到问题随便搜都能找到解决方案价格便宜正品十几块钱一片兼容的国产型号甚至可以做到几块钱片上资源对于一个智能水杯来说绰绰有余2路ADC、I2C、UART、定时器全都能派上用场。传感器选型则是踩了些坑的。水温和水位方案我对比过几轮后面会用专门章节细说。这里先把整机方案和关键器件的选型思路讲清楚。1.3 关键器件选型对比模块选型选型理由主控MCUSTM32F103C8T6资源够用资料丰富成本低水温传感器DS18B20防水探头数字输出免校准精度正负0.5度水位传感器电容式非接触水位传感器不接触液体更卫生避免电极腐蚀姿态识别ADXL345加速度传感器三轴数据I2C接口功耗低显示模块0.96寸OLED SSD1306I2C接口占IO少显示信息足够蓝牙透传HC-05从机模块经典蓝牙配对简单兼容性好报警模块有源蜂鸣器 震动马达声学和触觉双通道提醒供电方案18650锂电池 HT7333 LDO容量大静态功耗低选型时我在水位传感器上犹豫了很久最初的方案是电极式水位传感器后来在测试中发现两个问题一是金属探针长期浸泡在茶水、咖啡、果汁等液体里会产生电化学反应导致测量漂移二是探针本身需要接触液体在食品卫生角度说不过去。后来换成了电容式非接触水位传感器贴在杯壁外侧就能工作液体不接触任何金属部件清洁起来也方便。2. 系统整体架构不止是“主控加传感器”那么简单很多新手画系统框图喜欢所有模块并排接在MCU上功能实现了但代码乱成一锅粥。这是因为只搭了硬件框架没有设计软件架构。我这套系统在动手写代码之前先画了两张图一张是硬件连接图一张是软件状态机图。硬件图保证“线怎么接”软件状态机保证“程序怎么跑”。2.1 硬件架构说明STM32F103C8T6作为整个系统的大脑通过不同的外设接口与各个模块交互DS18B20通过单总线协议挂在PB12引脚上只需要一根数据线就能完成双向通信。这里有个容易踩的坑单总线对时序要求非常严格特别是在STM32主频72MHz下延时函数的精度直接影响通信成功率。我的做法是优先使用定时器做微秒级延时。ADXL345加速度传感器和OLED显示屏都挂在I2C1总线上SCL为PB6SDA为PB7。两个器件挂同一总线没问题但地址不能冲突。OLED的I2C地址通常是0x3CADXL345默认是0x1DSAO引脚接VCC或0x53SAO引脚接GND操作前务必确认硬件上的电平设置。HC-05蓝牙模块接USART1TX接PA10RX接PA9波特率固定为9600。蓝牙模块在这里扮演的角色是透明传输通道MCU只管往串口写数据至于数据怎么传到手机那是HC-05和手机之间的事。蜂鸣器接PB0震动马达接PB1两者都通过三极管驱动。这里特别提醒STM32的GPIO输出电流只有8mA左右直接驱动蜂鸣器和马达会电压跌落甚至烧引脚一定用S8050三极管或者ULN2003做放大。2.2 软件状态机设计整机的软件框架没有采用裸机大循环而是设计了一套简单的状态机让程序在不同工作模式之间切换SLEEP模式系统上电后的默认状态传感器按低频率采样OLED息屏蓝牙待机整机功耗控制在几个毫安以内。ACTIVE模式检测到用户拿起杯子或按下按键后进入OLED亮屏显示温度和电量传感器高频采样持续30秒后自动返回SLEEP模式。ALERT模式水温超过安全阈值或到达定时提醒时间蜂鸣器间歇发声震动马达同步震动直到用户干预才退出这个模式优先级最高任何状态下触发都要立即响应。BLE_COMM模式手机APP连接蓝牙后进入通信状态MCU定期打包温度数据、饮水记录和电量数据上传同时能够接收APP下发的参数配置。状态切换的核心是什么呢是“事件驱动定时轮询”的组合。紧急事件如温度异常用中断方式处理非紧急事件如饮水记录统计放在主循环轮询。这样做的好处是系统响应灵敏关键时刻不会卡在某个延时函数里错过报警。2.3 代码结构规划代码功能模块划分参考的是正规嵌入式项目的分层思路main.c系统初始化、状态机主循环DS18B20.c/.h单总线驱动、温度读取、CRC校验ADXL345.c/.hI2C驱动、三轴数据读取、姿态解算OLED.c/.hSSD1306驱动、UI界面绘制HC05.c/.h串口驱动、协议解析bsp.c/.h板级支持包时钟/GPIO/定时器初始化app.c/.h业务逻辑层状态切换、报警策略、数据管理分层架构的最大好处是容错率高哪个模块出问题就查哪个模块。比如OLED不亮了只需要检查OLED.c和I2C配置不需要把整个程序翻个底朝天。3. 硬件设计要点传感器选型之外的几个关键决策很多开源项目分享只会告诉你“用了什么芯片、接了哪些引脚”但不太会讲为什么要这样做。这一节聊几个真正影响系统成败的硬件细节。3.1 DS18B20的温度采集细节DS18B20吃温度采样这件事从我实测的角度看最大的坑不在软件通信协议而在物理安装位置。传感器如果暴露在空气中测出来的是环境温度而不是水温。所以选型时一定要选择带不锈钢探头的防水封装并且把探头固定在杯内靠近底部的位置。水杯的液体量少热容量小探头位置没放对温度读数可能差出五六度。DS18B20还提供一个很实用的功能——温度报警寄存器可以设置TH和TL两个阈值当温度超限时DS18B20会返回一个报警标志。这个功能在低功耗场景下特别好用MCU不必频繁唤醒读取温度让DS18B20自己盯阈值超限后再通过中断方式通知MCU。精度方面的实测数据DS18B20在-10到85摄氏度范围内精度为正负0.5摄氏度对于“这杯水能不能直接喝”这种判断需求已经足够。相比NTC热敏电阻省掉了校准和查表两个麻烦步骤。用NTC的方案成本确实更低但每个传感器都需要校准确认批量生产还好自己做一台样机完全没必要省这个事。3.2 水位检测的卫生与可靠性平衡前面提过我做坏了两个电极式传感器之后果断换电容式这里补充一个实际测试数据。电极式方案在纯净水中的表现还算正常一旦换成茶水或者柠檬水浸泡大约三天后读数就开始漂移。原因很简单茶多酚和柠檬酸对金属电极有腐蚀作用电极表面状态改变导致导电率变化。电容式非接触传感器利用水和空气的介电常数差异水的介电常数约80空气约为1来检测水位变化。传感器贴在杯壁外侧无需接触液体。这个方案精度不如电极式误差大概在正负10%左右对喝水提醒这个场景完全够用。需要注意的是电容式水位传感器对杯壁材质有要求玻璃和塑料效果最好不锈钢杯壁会屏蔽电容场导致失效。如果你打算做金属杯版本要改用其他检测方案。3.3 ADXL345与饮水动作识别饮水动作识别是我觉得本项目最有技术含量的一块。最开始我的方案是固定时间提醒后来觉得这个逻辑太傻了——两个小时内一直在开会没碰杯子手机在那狂响你如果正忙着完全不想被打扰。更合理的逻辑应该是检测到用户长时间没有饮水动作时再提醒。ADXL345三轴加速度计负责姿态检测。当用户拿起杯子喝水时水杯的姿态会经历一个“水平-倾斜-回正”的过程同时伴随明显的加速度变化。通过分析X轴和Y轴的倾角变化量和持续时间就能够识别出是否有喝水动作。具体实现是在定时器中断里以50Hz的频率采样加速度数据通过低通滤波去除高频抖动再计算姿态角变化。实际调试中需要解决的是误识别问题。我把杯子放在桌上移动、拿起来又放下、倾倒液体等场景都测了一遍通过限定倾角变化幅度大于45度和倾斜持续时间超过3秒这两个条件基本能过滤日常误触发。3.4 低功耗设计一杯水要喝一天电也得撑一天智能水杯是典型的电池供电设备续航是刚需。我第一版原型机用了一块500mAh锂电池实测续航只有十几个小时。后来把功耗一处处抠最终做到一杯水能撑四五天。STM32F103在72MHz全速运行时的电流大约是40mA左右不能一直开着跑。我的设计思路是默认进入SLEEP模式借助STM32的停机模式STOP Mode电流降到微安级。通过RTC唤醒定时器每30秒醒来一次快速采样温度和水位然后继续睡。OLED平时完全不刷新只有进入ACTIVE模式才点亮显示。DS18B20平时处于掉电状态需要读取时再发复位指令唤醒。HC-05蓝牙模块在不需要通信时通过EN引脚拉低进入AT模式就休眠了。这一套组合拳下来实测整机休眠电流控制在0.5mA以内唤醒后平均工作电流约25mA按唤醒时间占比计算500mAh电池用四天以上没有问题。4. 驱动层实现温度、水位与运动识别的代码细节这章节把核心代码怎么写的、为什么这么写讲透。给完整源码不现实但把关键函数和逻辑罗列出来你完全可以照着写。4.1 DS18B20时序控制背后的时钟校准DS18B20单总线协议里有严格的时序要求复位脉冲至少480微秒写0的时间隙至少60微秒读时隙必须在15微秒内采样。STM32F103主频72MHz跑起来快得很延时如果直接用简单循环稍有偏差就可能导致通信失败。我之前踩过一个很无语的坑DS18B20代码在一台开发板上完全正常换了一块板子就读不到温度。排查到最后发现是两块板子的外部晶振质量不同导致微秒级延时精度有偏差。从那之后我再也不敢用简单循环做延时了改为使用SysTick定时器实现HAL_Delay级别的微秒延时保证时序精度。DS18B20的核心读取流程是发送复位脉冲等待存在脉冲跳过ROM匹配启动温度转换等待转换完成默认12位精度下需750ms再发送读暂存器命令连续读取两个字节的温数据。温度值换算int16_t raw (temp_LSB) | (temp_MSB 8); 温度摄氏度 raw * 0.0625;12位分辨率下DS18B20每次温度转换需要750毫秒对于一杯水这种缓慢变化的对象来说完全够用。如果你的应用需要更快的采集频率可以配置为9位分辨率转换时间只需要94毫秒但分辨率会下降为0.5摄氏度。4.2 水位传感器数据稳定性处理电容式水位传感器输出的是模拟电压信号输入到STM32的ADC引脚PA0进行采样。由于液体晃动、气泡附壁等原因ADC读取的原始数据波动很大。直接拿原始值做判断会频繁误报必须做滤波处理。我用的是滑动平均滤波取最近10次采样值的平均作为当前水位值。每隔200ms采样一次10次正好是2秒既能平滑波动又不会让响应太迟钝。#define ADC_SAMPLE_COUNT 10 uint16_t adc_buf[ADC_SAMPLE_COUNT]; uint8_t adc_index 0; uint16_t get_smooth_adc_value(void) { uint32_t sum 0; uint8_t i; for (i 0; i ADC_SAMPLE_COUNT; i) { sum adc_buf[i]; } return (uint16_t)(sum / ADC_SAMPLE_COUNT); }水位状态划分为三档高水位满杯、中水位半杯、低水位需加水。判断逻辑放在主循环里每读取一次平滑值就更新当前状态状态变化超过10次才真正改变水位档位。这个“变化确认”机制在工业控制领域很常见是对抗抖动信号的经典手段。4.3 喝水动作识别的阈值标定流程加速度传感器识别喝水动作走的是“初始化配置-数据读取-动作特征判定”三步流程。ADXL345的I2C地址是0x53初始化时设置数据格式寄存器为16g量程避免拿着杯子走路时数据溢出设置带宽为50Hz过滤高频噪声然后开启测量模式。喝水动作的特征模式我总结为三个阶段抬杯阶段杯子从桌面平移上升到嘴边Z轴加速度有明显正向尖峰持续时间约为0.3到0.8秒。倾斜阶段杯身绕X轴或Y轴倾斜重力加速度在水平方向的分量发生变化倾斜角度一般超过45度持续时间3到10秒。放回阶段杯身回到垂直姿态加速度归位Z轴重力分量恢复为约1g。对应到代码逻辑我维护了一个简单状态变量DRINK_STATE_IDLE、DRINK_STATE_LIFTED、DRINK_STATE_TILTED、DRINK_STATE_RETURNED。状态按顺序迁移任何一步超时比如抬杯后5秒内没有倾斜则重置回IDLE。完整走完一轮迁移后视为完成一次喝水动作。if (state DRINK_STATE_IDLE tilt_angle 30) { state DRINK_STATE_LIFTED; } if (state DRINK_STATE_LIFTED tilt_angle 60) { state DRINK_STATE_TILTED; drink_start_time current_time; } if (state DRINK_STATE_TILTED tilt_angle 15 current_time - drink_start_time 3) { drink_count; state DRINK_STATE_IDLE; }这个逻辑在实机测试中识别率大概在85%到90%。会漏判的典型场景是用户把杯子一直举在手里慢慢喝倾斜角度始终在30度到50度之间状态机一直没走到TILTED。解决方式是在TILTED的触发条件里增加“倾斜持续时间”作为补充条件角度稍小但持续时间够长也判定为喝水。4.4 OLED界面的多页面切换0.96寸OLED以SSD1306为主控芯片我给它分了三块界面可以在主显示、详细信息和历史统计之间切换。界面切换通过一个物理按键PA8引脚实现短按切换页面长按超过2秒进入饮水记录清零确认。主界面显示当前水温、水位、时间和电池电量图标。OLED的SSD1306本身不带字库显示汉字需要取模我用的取模工具是PCtoLCD2002取模方式选择阴码、逐行式、逆向。自定义图标则在画布指定位置用画点方式绘制。UI刷新频率不需要太高每秒刷新一次就够了。刷新太快反而会造成OLED显示闪烁因为SSD1306内部没有帧缓存每次刷新都是全屏数据重传I2C在400kHz下传一帧约30ms。如果数据更新频率高于这个值就会导致画面撕裂感。5. 通信协议设计0xAA开头的帧格式与APP联动智能水杯如果没有“智能”这两个字的支撑实际上就是一个温度计加定时器。真正的智能体现在与手机联动能够记录和展示数据。蓝牙串口透传让我们不必关心射频细节但数据怎么组织、怎么解析完全由我们说了算。5.1 自定义轻量级协议帧HC-05蓝牙模块的工作模式是透明传输MCU的串口往外面发什么手机上就收到什么。刚开始我直接发的是裸字符串比如“TEMP:25.5”后来发现这种格式在解析时极其痛苦——字符串切片、类型转换、异常字符处理代码越写越复杂还容易出bug。最终我设计了一套简单的二进制协议帧格式字节位置内容说明00xAA帧头10x55帧头2双重校验2命令字0x01温度数据0x02饮水记录0x03设备状态3数据长度有效数据的字节数4到4N-1数据域根据命令字字段定义4N校验和从命令字到数据域末尾的累加和低8位5N0xBB帧尾以温度数据为例一帧完整的报文是AA 55 01 02 19 01 BB。命令字0x01表示温度数据数据长度0x02表示两个字节有效数据0x19 0x01表示整数部分25、小数部分1合起来就是25.1摄氏度。手机上解析时先寻找帧头0xAA 0x55找到后按格式提取长度字段再根据长度读取完整数据最后做校验和验证。万一校验失败直接丢弃整帧等待重新对齐。这套协议虽然简单但设计上是参考了Modbus和YModem的思路——有帧头定位、有长度约束、有校验兜底误码率和粘包问题基本都能控制住。5.2 蓝牙模块的AT模式配置HC-05模块出厂默认是AT模式还是通信模式取决于模块的EN引脚状态。上电前把EN引脚拉高模块就进入AT模式可以通过串口发送AT指令进行配置。我用USB转TTL工具直接连HC-05完成了以下配置ATNAMESmartCup // 设置蓝牙名称为SmartCup ATROLE0 // 设置为从机模式等待手机连接 ATUART9600,0,0 // 设置串口波特率9600无校验1位停止位 ATPSWD1234 // 设置配对密码为1234注意HC-05配置完成后一定要重新上电使配置生效。如果发现PC串口工具发送AT指令没有响应多半是进了通信模式而不是AT模式把EN引脚电平重新确认一下。5.3 手机端Debug工具与数据透传测试开发调试阶段我没急着写APP而是使用了一个现成的蓝牙串口助手工具Android平台的Serial Bluetooth Terminal做透传测试。手机配对连接后MCU上报的数据会直接显示在调试工具界面上。我先把各种异常报文、长数据帧、高频数据发送全部测试一轮确认协议解析稳定后才开始写正式的APP界面。测试中很容易出现的问题是串口波特率不匹配。HC-05模块配置成9600而STM32的HAL_UART_Init默认也是9600问题不大。但如果你从别处复制代码USART1的初始化参数里波特率写的是115200而模块实际配的是9600就会产生乱码。排查这类问题先用逻辑分析仪或者串口调试助手看原始数据不要一上来就怀疑协议逻辑。考虑到很多网友第一次接触蓝牙串口透传我补充一个容易忽略的概念HC-05的板上逻辑电平是3.3V而不是5V直接接在5V单片机上虽然不至于烧毁但长时间运行会降低模块寿命甚至损坏。如果主控板是5V供电的系统务必用电平转换模块。STM32F103本身就是3.3V系统与HC-05直接互连没有问题。6. 实测调优我在开发中遇到的五个“坑”任何开源项目的价值都体现在“别人踩过的坑你不用再踩一遍”。我把开发过程中最耗费时间的五个问题整理出来每个都附带完整的排查链路和解决方案。6.1 ADC采样值跳变罪魁祸首是参考电压水位传感器刚开始接入ADC时我读取到的值在600到780之间快速跳动完全无法稳定判断水位。起初怀疑是传感器信号本身噪声大加了滑动平均滤波后情况有所改善但还是不够稳定。后来用万用表测量传感器的实际输出电压发现电压本身就存在0.1V左右的波动。进一步排查发现是STM32的VDDA引脚没有充分滤波。数据手册要求VDDA和VSSA之间接一个1uF和一个100nF的电容我在第一版PCB上偷懒只接了一个100nF导致ADC参考电压不稳定直接把量化结果带偏了。补上1uF电容后ADC读数跳变范围从180个LSB降到了10个LSB左右。6.2 OLED花屏是I2C上拉电阻引起的OLED显示出现随机花屏的时候我一度以为是屏幕本身的问题换了三块屏幕都没解决。后来用示波器看I2C信号质量发现SDA和SCL的上升沿非常平缓——原来是I2C总线上缺少上拉电阻或者上拉电阻阻值太大。STM32的I2C引脚是开漏输出需要外部上拉电阻才能拉高电平。我手里正好有10k的排阻直接用在了I2C总线上结果因为上拉太弱导致信号边沿变缓。换上4.7k的上拉电阻后波形恢复正常。经验分享I2C总线上拉电阻的值400kHz速率下建议用2.2k到4.7k100kHz速率下可以用4.7k到10k阻值太小会增加功耗太大则信号边沿过缓中间值最合适。6.3 蓝牙连接不稳定源于供电不足HC-05蓝牙模块在工作时存在电流尖峰特别是建立连接的瞬间瞬时电流可以达到50mA左右。第一版我用的是AMS1117-3.3稳压芯片实测HC-05重连时系统电压会跌落到3.0V左右导致MCU复位重启蓝牙模块始终连不上手机。排查这个问题花了很长时间。刚开始以为是HC-05模块坏了换了好几个都一样。后来用示波器抓3.3V供电轨的电压波形才发现连接瞬间有个明显的电压跌落到了MCU复位阈值以下。处理办法一是换用压差更低、输出能力更强的HT7333 LDO静态电流仅2uA极适合电池设备二是在HC-05供电引脚旁边加一个100uF的储能电容应对瞬间大电流需求。6.4 单总线通信偶发失败根因是长线干扰DS18B20探头通过一根约30cm的延长线连接到主板运行中会出现偶发性的读取失败错误码是CRC校验不通过。查了DS18B20的datasheet单总线的通信线如果超过一定长度分布电容会使信号边沿变缓在高速主机下容易读到错误位。解决办法有三招一是将DS18B20的采样频率降低原来每秒读一次现在改为每5秒读一次减少通信出错概率二是在数据线和GND之间加一个4.7nF的电容做滤波三是在代码层面对读取失败的返回值做兜底处理连续3次读取失败才判定为传感器异常否则沿用上一次的合法值。这三招组合应用后长时间测试再也没出现过温度跳变或读取失败。6.5 低功耗模式下外部中断误唤醒系统进入STOP模式后待机电流实测在4mA左右比预期的0.5mA高了一个数量级。逐项排查发现在进入STOP模式前我把GPIO配置为外部中断唤醒用于检测按键和串口数据但没有给未使用的GPIO统一设置电平状态。浮空的GPIO引脚在STOP模式下会不断产生外部中断请求把MCU频繁唤醒导致功耗居高不下。解决办法是进入STOP模式前把所有未使用的GPIO统一配置为模拟输入模式已使用的外部中断引脚按键PA8启用内部上拉电阻确保电平稳定。同时确认ADC的外设时钟在STOP模式下是关闭的——如果ADC时钟没有关闭它会持续工作并增加功耗。处理后STOP模式电流降到了实测0.4mA终于达到设计要求。7. 工程文件组织与后续扩展方向开源项目如果文件组织一塌糊涂别人拿到手根本没法用。我自己整理这套工程时特意按照“谁都能快速上手”的标准做了规划。7.1 开源仓库结构说明上传到Gitee/GitHub的仓库按如下结构组织Smart-Cup/ ├── README.md # 项目概述硬件配置快速上手说明 ├── Hardware/ │ ├── Schematic.pdf # 原理图PDF版 │ └── PCB_Project/ # 立创EDA源文件 ├── Firmware/ │ ├── Core/ # 启动文件、中断处理、系统时钟配置 │ ├── Drivers/ # HAL库和LL库 │ ├── Middlewares/ # 第三方中间件可选 │ └── App/ # 用户应用层各外设驱动和业务逻辑 │ ├── Src/ │ └── Inc/ ├── Tools/ │ ├── 串口调试助手.py # Python写的简单串口接收工具 │ └── 字模提取配置.txt # OLED取模参数说明 └── Docs/ ├── 硬件连接说明.md ├── 通信协议说明书.md └── 常见问题FAQ.mdFirmware源码基于STM32CubeMX生成的工程芯片型号选择STM32F103C8Tx时钟配置为外部8MHz晶振倍频到72MHzIDE使用Keil MDK 5.27以上版本。如果你用的是STM32CubeIDE直接导入Keil工程后可以在Project菜单里选择Convert to STM32CubeIDE Project完成迁移。7.2 从这台样机到后续量产需要补的功课这套系统目前的状态是“功能验证完成、可作为学习参考”离真正的商品化还有一段距离。如果要往产品方向走我认为需要补以下几个方面电池管理升级引入锂电池充电管理芯片TP4056和电量计MAX17048支持USB充电和精准电量显示。无线通信升级经典蓝牙换成BLE 4.0以上模块如nRF52832或ESP32-C3功耗更低与iOS和Android的兼容性更好。防水等级设计整机需要做到IPX7级别相关接缝和开口要做硅胶密封处理PCB需要做三防漆涂覆。传感器冗余与自校准增加温度传感器自检功能当检测到DS18B20数据异常时自动切换到备用传感器或触发系统告警。7.3 我还想做的三个进阶功能后面我打算在开源仓库里继续加这三个功能分支目前其中一个已经完成原型验证第一个是水温变化率检测。喝水时用户最担心的是“这杯水还烫不烫嘴”单纯看当前温度不够直观如果能通过分析过去5分钟内温度下降的速率预测30秒后的温度变化趋势就能更智能地回答这个问题。原型验证中用最小二乘法做了线性回归预测效果不错。第二个是基于饮水习惯的个性化提醒。目前提醒间隔是固定的后续想把不同时间段的喝水习惯数据上传到手机由手机端做聚类分析匹配出用户一天中喝水的高频时段和低频时段动态调整提醒策略。第三个是配网与云端记录。当前选用的是蓝牙方案适合近距离交互。如果做远程数据监控就需要引入ESP8266或ESP32-C3模块通过WiFi接入家庭网络把数据上报到云端IoT平台。这部分的设计比蓝牙要复杂不少涉及MQTT协议、JSON数据封装、云平台设备管理我正在做方案评估。这套智能水杯系统从立项到稳定运行前前后后花了大约三周。回顾整个过程收获最大的不是跑通了某个传感器驱动而是完整走了一遍“需求定义-方案选型-硬件设计-软件架构-协议规划-整机调优”的产品闭环。现在把全部资料整理打包开源无论你是学生做课程设计、开发者练手做作品集还是纯粹想给桌子上加个实用的Apple小玩具都可以直接拿去改。硬件有问题在仓库Issue里提代码有问题欢迎直接PR希望它能成为你嵌入式路上的第一个完整作品。