基于STM32的智能花盆养护系统设计与仿真实现

1. 项目概述与整体设计思路

1.1 这个项目到底解决了什么问题

先说个真实的场景。我自己养花属于“想起来才浇水”的那种，忙起来一周都不带看一眼的，结果就是阳台上那几盆绿萝、薄荷，要么干成柴火，要么涝到烂根。后来我实在受不了，就想着能不能用单片机做一套自动养护的东西——花盆里的土壤干了就自动浇水，光照不够就补光，温度湿度太高就通风。这就是这个智能花盆养护系统的起源。

这套系统核心就三件事：感知环境、判断决策、执行动作。感知端用的是土壤湿度传感器、DHT11温湿度传感器，再加上一个光敏电阻或者BH1750光照传感器；决策端就是一颗STM32单片机，把采集到的数据跟预设的阈值做比较，决定要不要浇水、要不要开补光灯；执行端就是继电器控制的小水泵和补光灯条。就这么一套东西，成本算下来也就三四十块钱，比起市面上动辄两三百的成品智能花盆，性价比完全不在一个量级。

我把这套系统完整开源了，包括STM32的工程代码、PCB原理图、Proteus仿真工程，全部打包放在文末。如果你是刚入门STM32的开发者，这个项目是特别好的练手素材——它麻雀虽小，五脏俱全：GPIO、ADC、定时器、PWM、串口、I2C这些STM32最常用的外设全都能覆盖到。如果你是想解决实际养花问题，那直接照着买元器件、抄原理图打板、烧录代码就能用。

1.2 为什么选择STM32F103C8T6这颗芯片

选型这件事我得展开说说，因为很多人做项目第一步就栽在选型上。市面上能做这套系统的方案太多了：Arduino UNO、ESP8266、ESP32、STC89C52，甚至51单片机都能做。但综合考量下来，STM32F103C8T6是最合适的，原因有三点。

第一，外设资源刚好够用。这套系统需要的ADC通道至少两个（土壤湿度一个、光照一个），定时器至少一个（做PWM调光或者按键消抖），还要有I2C或者模拟I2C来驱动OLED屏（如果加显示的话），再加上三四个GPIO控制继电器。C8T6是48引脚封装，Flash 64KB，RAM 20KB，这些资源绰绰有余，而且还有富余可以扩展蓝牙模块或者WiFi模块做远程控制。

第二，市场价格非常友好。全新原装的可能要七八块钱一片，但如果用国产替代（比如GD32、APM32，引脚完全兼容），两三块钱就能拿下。做一套系统下来，芯片成本只占总成本的零头。

第三，资料极其丰富，踩坑成本低。这颗芯片用的是ARM Cortex-M3内核，ARM的生态本身就非常成熟，再加上在国内有海量的教程和开源项目可以参考。真出了问题，搜索引擎一搜基本都能找到答案。对新手来说，这一点比芯片本身的性能更重要。

当然，如果你手头已经有ESP32或者ESP8266，用它们来做也完全可行，甚至还能直接上物联网，把数据传到云端。我这套系统之所以用STM32F103C8T6，还有一个原因是它没有射频前端，电磁环境更干净，作为纯本地控制的设备，稳定性要更好一些。

1.3 系统整体架构与工作流程

整个系统的工作流程是这样的：

系统上电后，STM32先做一轮自检和外设初始化——配置系统时钟、初始化GPIO、ADC、定时器、串口、I2C，然后把每个传感器的初始值读一遍，通过OLED或者串口打印出来，方便你确认传感器是否正常工作。

进入主循环之后，程序会每1秒钟采样一次土壤湿度、环境温湿度和光照强度。之所以是1秒而不是连续采样，是因为土壤湿度和光照的变化本身是慢变量，连续高频采样反而是浪费CPU——这一点很多新手会忽略，一上来就写个while(1)死循环让你的ADC跑满速，殊不知CPU在空转，白白吃电，也没有实际意义。

拿到数据之后，程序会把土壤湿度值和预设的阈值做比较。这里我预设了两个阈值：浇水阈值和停止阈值。当土壤湿度低于浇水阈值时，继电器吸合，小水泵开始抽水浇灌；当湿度回升到停止阈值以上时，继电器断开，停止浇水。这个双阈值设计有点像恒温器的回滞控制，目的是避免水泵在阈值边界反复启停，把继电器触点都打坏了。

光照控制的逻辑也是类似的，当光照强度低于某个阈值时，补光灯自动点亮，当光照恢复后自动熄灭。通风控制则看温湿度，如果环境温度过高或者湿度太大，就启动风扇（或者舵机打开通风口）。

同时，所有的传感器数据会通过串口以固定的帧格式发送到上位机（或者蓝牙模块、ESP8266透传到手机），方便你远程观察植物生长环境。整个控制逻辑大概两百行C代码就能写完，但把这个逻辑想清楚、把状态图在脑子里画出来，是做好这个项目的第一步。

2. 硬件设计与原理图拆解

2.1 核心器件选型与替代方案

硬件部分我尽量选择市面上容易买到、价格便宜、资料多的器件，这样你抄作业的时候不会遇到“买不到料”的尴尬。下面是这套系统的完整物料清单，附上我个人的选型经验和可以替换的方案。

这里多说一句土壤湿度传感器的选择。市面上最常见的是那种两针插头的电阻式传感器，靠检测土壤导电率来判断湿度，价格便宜，但用久了金属探头会电化学腐蚀，而且直接通直流电会让探头极化，影响读数。我实测下来，这种传感器泡在水里大概能撑两三个月，埋在土里基本一年就得换一根。如果你想让系统长期稳定运行，可以考虑电容式土壤湿度传感器，虽然贵几块钱，但不会腐蚀，寿命长得多。本项目用的是LM393输出的模拟量版本，因为它直接输出模拟电压，可以根据电压值精确控制浇水量，而不是简单的是/非判断，控制精度更高。

2.2 原理图设计的几个关键点

原理图部分我是在立创EDA（嘉立创EDA）上画的，因为它是免费的，而且可以直接生成PCB去打样，导出Gerber文件也就几步的事。你在GitHub仓库里下载的原理图PDF和立创EDA源文件，用立创EDA打开后可以直接编辑和修改。

画原理图的时候，有几点是需要特别注意的，我踩过的坑都在这里：

首先，STM32F103C8T6的供电滤波一定要做好。芯片每个电源引脚旁边都要加一个100nF的退耦电容，这几乎是MCU电路的铁律。为什么？因为MCU在工作时会产生高频的电流脉冲，如果电源没有足够的本地储能电容，这些高频脉冲会沿着电源线传导，造成电压跌落和纹波，严重的会导致芯片复位或者ADC采样值跳动。我见过不少新手画的板子，电源引脚旁边干干净净的什么都没有，结果板子一跑起来就有各种"玄学"问题。我的板子上，VDDA引脚还额外加了一个10uF的钽电容，专门给模拟电路供电——因为ADC的参考电压和电源噪声是直接挂钩的，电源越干净，采样值越稳定。

其次，BOOT0引脚一定要接地。很多人第一次画STM32的板子，BOOT0悬空，结果程序烧录之后根本没运行，查了半天发现是BOOT0电平不对，芯片一直在BootLoader模式里打转。我习惯在BOOT0上做一个跳线帽，默认接地，需要的时候可以接高进入串口下载模式，这样调试起来非常方便。

再者，复位电路不要省。虽然STM32内部有上电复位电路，但外部RC复位电路（10K电阻+100nF电容）仍然是推荐的标配。关键是要把NRST引脚拉高到3.3V，低电平有效复位，复位按键不一定要，但RC网络一定要有。如果NRST引脚长时间悬空，极易受电磁干扰导致芯片随机复位——我在调试的时候遇到过两次，程序跑得好好的突然就重启了，最后排查发现就是复位引脚悬空惹的祸。

最后，电源部分要加反接保护和过流保护。虽然USB供电基本不会接反，但如果你打算用外部适配器供电，一颗SS34肖特基二极管用于防反接，一颗500mA自恢复保险丝做限流保护，总共不到一块钱，能救回你大半块板子。我就是有一次调试时不小心把电源线插反了，一片景芯直接报废，从那以后每个板子都加防反接。

原理图里我还预留了一个OLED接口（4Pin，VCC/GND/SCL/SDA），一个串口排针（3Pin，TX/RX/GND），以及一个SWD下载接口（4Pin，SWDIO/SWCLK/GND/3V3）。这些都是调试的刚需接口，少了任何一个，你调试代码的时候都会想砸板子。

2.3 PCB布局布线的心得

PCB这部分我不打算展开全部布线过程，但有几个关键心得可以分享。这套系统如果用我的原理图直接打板，板子是两层板，尺寸大概是6cm×6cm，成本在嘉立创打样的话5片不到20块钱，基本就是打样费+运费。

布局上我采用的策略是分区规划：电源电路放在板子一角，MCU在中间，传感器接口在一侧，继电器/水泵驱动电路放到跟MCU相对较远的另一侧。为什么要这么做？因为继电器吸合和断开的瞬间会产生一个很强的反向电动势脉冲，虽然继电器模块上一般都自带了续流二极管，电磁干扰仍然可能通过PCB走线耦合到MCU的引脚上，导致误动作甚至死机。拉开它们之间的物理距离，要远远好过靠软件做滤波。

布线上要注意模拟地和数字地的分离。土壤湿度传感器输出的是模拟信号，如果它的地跟继电器驱动的数字地混在一起，继电器开关时的地弹噪声会直接污染模拟信号，ADC采样值就会莫名跳动。我的做法是：整个板子只有一个地平面，但在ADC采样引脚附近用一个0欧姆电阻把模拟地和数字地单点连接。0欧姆电阻在这里的作用是把模拟信号的回流路径限制在模拟区域内，避免噪音电流穿过传感器采样区。

还有一点，STM32的VDDA和VREF引脚一定要接一个干净的电源。如果板上空间允许，最好用一个LDO单独给模拟电路供电，而不是让VDDA直接吃VDD。我在整理原理图时用了一颗XC6206P332MR（3.3V LDO），这颗芯片纹波很小，实测大概只有几十毫伏的噪声，ADC数值跳动明显比直接用AMS1117要小。

3. 软件代码架构与核心逻辑实现

3.1 工程搭建与CubeMX配置

软件的开发环境我推荐用STM32CubeIDE，因为它是ST官方推出的免费IDE，集成了CubeMX配置工具和GCC编译工具链，装好就能用，不用像Keil那样折腾破解、担心中文注释乱码。如果你还是习惯Keil MDK-ARM v5，也可以，工程文件里我保留了.ioc文件，你可以用CubeMX重新生成Keil工程。

用CubeMX初始化工程的时候，几个关键配置如下：

• RCC：选择外部高速时钟（HSE），如果板子上没有8MHz晶振，那就选内部时钟（HSI），但注意HAL库默认的时钟配置可能不够稳定，建议用外部晶振。
• 时钟树：配置系统主频为72MHz。F103的最高主频就是72MHz，通过PLL倍频把8MHz的外部晶振倍频到72MHz：这是F103的标准配置。
• GPIO：AD引脚（土壤湿度 ADC1_IN0，光照 ADC1_IN1）、继电器控制引脚（PA0、PA1）、OLED的I2C引脚（PB6=SCL，PB7=SDA，我用的I2C1）、水泵MOS管控制引脚（PA2）、补光灯控制引脚（PA3）、风扇控制（PA4）。
• ADC1：开启两个通道，采样时间为239.5个周期，连续转换模式。这是为了尽量降低ADC的采样噪声——采样时间越长，采样电容充放电越充分，转换结果越准确。
• TIM1：配置为PWM输出，用来给补光灯调光或者做呼吸灯效果。
• USART1：115200，8数据位，1停止位，无校验。用来调试输出。
• I2C1：标准模式100KHz，用来驱动OLED。

这些配置在仓库的SmartPot.ioc文件里都有，你可以直接打开查看。能不用代码手写寄存器就尽量不要手写，HAL库虽然效率低一点，但胜在可读性和可维护性，对大多数人来说，易读比省那几百纳秒更重要。

3.2 主程序流程图与状态机设计

这套系统我采用的是简单的状态机架构，把系统工作状态划分为四个：

typedef enum { STATE_MONITOR, // 监测状态：读取传感器，判断是否要浇水/补光 STATE_WATERING, // 浇水状态：正在浇水，持续一段时间后回到监测 STATE_LIGHTING, // 补光状态：补光灯已点亮 STATE_ALARM // 异常状态：传感器读数异常，比如土壤湿度超出合理范围 } SystemState;

程序的主循环就是不断在这个状态机里流转。为什么用状态机而不是一堆if-else堆积？因为状态机有一个核心好处：行为可预测、逻辑分层清晰。每个状态只关心自己能做什么、该做什么，状态之间的转换条件是明确定义的，不容易出现“这里改一下那里又炸了”的连锁问题。而且后续想扩展功能，比如加一个人工控制模式、加一个定时浇水策略，只需要在状态机里加一个状态就行，代码的可扩展性要好得多。

主循环的伪代码大致是这样的：

while (1) { switch (current_state) { case STATE_MONITOR: read_all_sensors(); check_exception(); if (soil_humidity < HUMIDITY_LOW_THRESHOLD) { current_state = STATE_WATERING; turn_on_pump(); } else if (light_intensity < LIGHT_LOW_THRESHOLD) { current_state = STATE_LIGHTING; turn_on_light(); } else { // 一切正常，继续监测 delay(1000); } break; case STATE_WATERING: if (soil_humidity >= HUMIDITY_HIGH_THRESHOLD) { turn_off_pump(); current_state = STATE_MONITOR; } // 如果没有达到停止阈值，继续浇水，但加了最大浇水时间保护 if (watering_time > MAX_WATERING_TIME) { turn_off_pump(); alarm(); current_state = STATE_ALARM; } break; case STATE_LIGHTING: ... break; case STATE_ALARM: ... break; } }

细心的读者会发现我在浇水状态里加了一个最大浇水时间保护：如果水泵连续工作超过30秒土壤湿度还是没上来，就强制停泵并报警。为什么要这个保护？因为我实际测试的时候碰到过几种情况：一是土壤板结严重，水浇下去直接从花盆边缘流走了，传感器实际没接触多少水；二是储水罐没水了，水泵空转；三是传感器探头接触不良，读数始终偏低。不管哪种情况，让水泵一直运转下去肯定不是一个好主意——轻则浪费水，重则泵烧毁、花盆水淹。这个保护机制成本极低，收益却不小。

3.3 几个核心函数的实现细节

ADC读取土壤湿度：

uint16_t read_soil_humidity(void) { HAL_ADC_Start(&hadc1); if (HAL_ADC_PollForConversion(&hadc1, 100) == HAL_OK) { uint16_t adc_val = HAL_ADC_GetValue(&hadc1); HAL_ADC_Stop(&hadc1); // 将12位ADC值（0-4095）转换为湿度百分比 // 我这里标定过：传感器在干燥空气中的读数约为2700，在水中的读数约为1200 // 数值越小说明湿度越大（因为接地电阻变大/变小跟分布方式有关） // 这里的映射关系是：湿度百分比 = (干燥值 - 当前值) / (干燥值 - 水中值) * 100 uint16_t humidity = (uint16_t)((2700 - adc_val) * 100 / (2700 - 1200)); return humidity; } return 0xFFFF; // 出错返回值 }

需要注意，这个标定值是跟你的实际传感器、电路、土壤类型强相关的。同一块板子，同一个传感器，插在沙土里和插在黏土里，同样的含水量读出来的ADC值是不一样的。所以仓库的代码里我把阈值做成了全局变量，你可以先烧录一个测试代码，把传感器分别插入干燥土壤和湿润土壤，串口打印出相应的ADC值，然后根据实际值去调整阈值宏定义。

DHT11温湿度读取：

DHT11是单总线协议，时序非常严格。读取的时候要先拉低总线至少18ms（启动信号），然后释放总线，等待DHT11的响应。响应的时序是：80us低电平+80us高电平，然后开始输出40位数据。每一位数据的判断方法是：看高电平的脉宽，如果高电平持续约26-28us，表示逻辑0；如果持续约70us，表示逻辑1。

我一开始用HAL库的HAL_Delay()来做延时判断，结果发现完全不行——因为HAL_Delay是ms级别的，根本没法分辨几十微秒的差别。最后只能用寄存器操作直接操作GPIO，配合delay_us()微秒级延时函数（用定时器或者裸奔循环实现）。DHT11的代码在仓库里是完整可用的，如果你要用DHT22，时序逻辑是一样的，只是数据位判断的阈值要调一下。

OLED显示（SSD1306驱动）：

OLED驱动我直接用了开源的SSD1306库（Adafruit SSD1306的移植版），接口是I2C。显示内容可以做成这样的布局：第一行显示土壤湿度百分比，第二行显示环境温度/湿度，第三行显示光照强度，第四行显示系统状态（浇水中/运行正常）。这样就可以脱离上位机，直接在花盆旁边看数据，非常直观。

3.4 串口协议与上位机数据可视化

我把数据通过串口以JSON格式输出，方便上位机解析调试：

{"hum": 45, "temp": 26, "air_hum": 60, "light": 1800, "state": "MONITOR"}

使用JSON格式的好处是，你后面想接入阿里云、百度天工这类IoT平台，或者用Python写个简单的数据可视化脚本，解析起来非常方便。我在仓库里附带了一个Python脚本，监听串口数据实时绘制折线图，效果就跟一个小型监控中心似的。当然了，如果你只是想简单看看数据有没有变化，用串口助手加个分号分隔符就够了，不一定非要JSON这么大的开销。

4. Proteus仿真与验证过程

4.1 为什么需要仿真，以及仿真和实物的差异

很多人觉得仿真没什么用，想看效果直接搭实物不就行了？我的看法是，仿真和实物是两种互补的手段，各有各的优势。

仿真的核心价值在于：安全、快速、低成本地验证逻辑。尤其是像土壤传感器、水泵驱动这种涉及外部硬件的部分，在Proteus里可以随便“造数据”——直接把ADC引脚的电压改大改小，就能模拟土壤从干到湿的全过程，不需要真的去折腾一套花盆、水泵、储水罐。这在调试的时候简直太方便了。Debug一个浇水逻辑的bug，在实物上可能要来回烧录10次、倒腾5盆土，在仿真里可能只要10秒。

但仿真也有明显的天花板。Proteus里的LM393传感器模型、DHT11模型，跟真实器件的电气特性是有差距的。尤其是DHT11的单总线时序，仿真器里经常会出现时序偏差，导致读不到数据——这不是你的代码有问题，是仿真模型不够精细。所以我的建议是：用仿真正逻辑，能帮你减少70%的调试时间；但烧录前一定要测试实物，因为最终跑在真芯片上，各种噪声、干扰、时序问题才会显现出来。

4.2 Proteus仿真工程的使用说明

仓库里提供了一份Proteus 8.11版本的仿真工程，文件名为SmartPot.pdsprj，直接用Proteus 8以上版本打开即可。打开之后你会看到完整的电路：STM32F103C8T6最小系统、LM393土壤传感器、DHT11温湿度模块、继电器+水泵、OLED显示屏、串口虚拟终端（Virtual Terminal）。

仿真运行之前，有几个地方要特别留意：

第一，STM32的晶振频率配置。Proteus仿真里STM32的晶振默认是8MHz，但你如果把代码里的时钟树配置成72MHz的PLL倍频，Proteus是可以正常仿真的，它有内置的时钟仿真引擎。但DHT11的时序在Proteus里跑得比实物快，实测读数会偏小，这是我知道的仿真跟实物的一个明显差异。

第二，虚拟串口终端要提前添加。在Proteus的"Virtual Instruments"里拖一个"Virtual Terminal"到原理图上，把它的RXD引脚接到STM32的PA9（USART1_TX），TXD引脚接到PA10（USART1_RX），波特率设置成跟代码一致（115200）。这样跑仿真的时候就能看到串口输出的JSON数据流。

第三，传感器变量的调节。仿真中最有价值的操作是：双击LM393传感器模型，改变它的ADC输出电压。你可以把输出从3.3V调到0.5V，然后观察程序是否正确地进入了浇水状态。同理，光敏电阻的输出也可以调节，用来模拟白天/黑夜的变化，验证补光灯的自动开关逻辑。

4.3 仿真踩坑记录

仿真过程中我碰到的几个典型问题，这里集中说一下：

Proteus不能仿真RCC时钟树配置不当的问题。如果你的CubeMX时钟配置搞错了，在Proteus里是看不出来的，它照样能跑；但烧到真机上多半会死在启动阶段——芯片时钟没跑起来根本进不了main函数。所以，凡是涉及时钟配置的问题，仿真通过了也不代表实物没问题，务必用示波器量一下PA8的MCO引脚输出的时钟信号。

I2C的时序在Proteus里比较慢。如果你的I2C总线速度设置成400KHz快速模式，Proteus的仿真速度会拖得很慢，OLED刷新跟幻灯片一样。建议在仿真的时候把I2C速度降成100KHz，看到的效果会流畅很多。实物上400KHz没任何问题。

Proteus的水泵模型本身没有。我用的是一个普通LED指示灯来模拟水泵的开关状态——亮表示浇水，灭表示没浇。你当然也可以用一个"MAINS MOTOR"模型加上开关来模拟，但没必要，核心是看逻辑，不是看泵。

5. 常见问题与排查技巧实录

5.1 传感器数据异常

5.2 程序下载与调试相关

这块内容特别新手向，但我必须单独列出来，因为真的是高频问题。

下载失败错误：Error: Flash Download failed - "Cortex-M3"

这个错误出现，八成是BOOT0引脚没接地或者SWD接口线序接错。检查顺序：先量一下SWDIO和SWCLK引脚是否有3.3V电压（IDE在连接目标板时会主动拉高这两个引脚），如果量不到电压，大概率是没连接上或其中一根线虚接。还有一个常见原因是，用了DAP Link但驱动没装好，Windows设备管理器里能看到一个黄色的感叹号设备。解决办法是重装驱动或者换一个ST-Link V2，十块钱包邮那种就足够用。

程序能下载但运行没反应

下载成功只能说明Flash写入成功了，不代表程序逻辑没问题。先看核心问题：串口有没有打印？如果串口打印了但现象不对，说明代码逻辑有问题；如果串口完全没反应，先查SystemClock_Config()这一步有没有卡住——我见过不少新手从别的项目拷贝时钟配置代码，结果那代码跟他的板子晶振不一样，HSE起振失败，程序就死在时钟配置的死循环里。

调试时无法单步执行或变量不更新

如果你用ST-Link单步调试，发现断点不停或者变量值不更新，大概率是优化等级设置太高了。在STM32CubeIDE里把-O2改成-O0（关闭优化），变量列表才能实时更新。之前我为了性能把优化开到-O2，结果调试时这个变量死活不刷新，折腾了半小时才发现是优化搞的鬼。

5.3 系统实际运行中的杂项问题

继电器频繁吸合/断开

这个问题跟前面说的回滞控制有很大关系。如果你用的是单阈值控制，比如湿度低于30%就浇水、高于30%就停止，而传感器在30%附近不断跳动，那继电器就会频繁吸合断开，不仅噪音烦人，继电器寿命也急剧下降。我解决的办法是引入双阈值+延时确认：湿度低于阈值持续5秒以上才动作，高于停止阈值持续10秒以上才停。这个延时相当于一个“确认时间”，防止瞬时噪声导致的误动作。

水泵漏水或者流量太大

这个算是机械问题，但直接影响电路安全。如果你直接用一个小潜水泵，出水口如果没有接软管，水会顺着泵体流到电路板上，轻则短路重启，重则烧芯片。我给的方案是：泵的出水口接一根硅胶管，管末端接到土壤表面或者直接插到土壤深处（10cm左右），这样水不会乱溅；另外泵的电源如果跟单片机共用5V，要注意泵启动瞬间的电流冲击可能会拉低5V电压，导致单片机复位。我实测一个6mm水泵启动电流能达到400mA，普通的稳压芯片（比如AMS1117）瞬间会掉压，最好给泵单独的一路5V供电，或者至少加一个大容量电解电容（1000uF）做缓冲。

长时间运行后传感器数据漂移

这是所有嵌入式系统的通病。元器件会随温度变化、传感器会被介质污染，导致读数漂移。我的经验是：定期校准。最简单的校准方式是，用一个已知湿度的土壤样本作为参考点，然后调整代码里的映射公式的斜率和截距。我在代码里预留了校准常量：

// 校准参数：干燥值和水饱和值 #define SOIL_DRY_VALUE 2700 #define SOIL_WET_VALUE 1200

你可以实际测量后修改这两个值，让湿度百分比更贴近真实值。另外一个细节：不要让传感器探头长期处于通电状态，因为直流电场会加速电极的电解腐蚀。我的思路是，用PC13引脚控制传感器供电，每次读数据前上电100ms，读完立即断电——这样既能省电，又能延长传感器寿命。

6. 扩展方向与进阶玩法

6.1 从离线到在线：接入物联网

这套系统目前是纯本地控制，没联网。但你养花不可能总蹲在花盆旁边看串口数据吧？加个ESP8266模块（四五块钱一片），通过串口跟STM32通信，STM32把传感器数据打包成JSON发给ESP8266，ESP8266再通过MQTT协议转发到云端或者局域网里的一台树莓派上。这样你人坐在工位上，打开手机网页就能看到家里的花盆土壤湿度是多少，也能远程手动开关补光灯、水泵。

如果想省掉ESP8266这颗独立的芯片，直接把主控换成ESP32，虽然PIN_TO_PIN不兼容，但CubeMX里建个ESP32的工程也不难，GPIO资源还更多。不过ESP32的ADC线性度不如STM32F103的ADC，土壤湿度的精度会略差一些，取舍看你自己。

6.2 从单盆到多盆：节点化部署

一套系统管一个花盆，显得有点浪费。如果你想管理阳台上的五六盆花，可以把系统升级成一主多从的结构：每个花盆放一个"从机"（STM32 + 传感器 + 水泵），主机统一协调。从机之间可以用RS485总线或者CAN总线连接，距离几十米都没问题；如果想无线，就用nRF24L01+，一个2.4G模块几块钱，功耗低、稳定性也不错。

多节点的优势不仅仅是省代码——每个从机的控制逻辑可以区分植物种类，比如多肉需要偏干的土壤（湿度阈值10%-20%），薄荷需要偏湿的土壤（湿度阈值40%-50%），完全可以在代码里用查表法实现不同植物的个性化浇灌策略。

6.3 从单盆到智能：加入自动学习

再往深了说，这套系统还有一个很值得玩的方向：根据环境数据自动调节浇水策略。比如通过长期采集土壤湿度、温湿度、光照数据，建立一个简单的浇水预测模型：温度高、光照强的天气，土壤失水快，提前多浇一点；阴雨天则少浇或不浇。虽然STM32F103的计算能力跑不了神经网络，但一个线性回归模型还是能跑的，甚至更简单的查表法就能实现不错的自适应控制。

这个方向我觉得是"智能花盆"四个字的真正内涵所在——不是简单地让程序定时浇水，而是让系统逐渐理解植物的"脾气"，像老花农一样根据天气、季节、植物状态做动态调整。

6.4 社区贡献与代码维护

既然是开源项目，我把完整的资料都放在GitHub仓库里，具体包括：

• Code/：STM32CubeIDE工程源码（C语言，HAL库）
• Hardware/：立创EDA原理图源文件、PCB源文件、Gerber文件
• Simulation/：Proteus仿真工程
• Doc/：BOM清单、接线文档、调试笔记
• Python/：上位机可视化脚本（依赖pyserial和matplotlib）

如果你发现代码有bug，或者想增加功能（比如新增一个雨滴感应器来检测是否在下雨），随时提Issue或者直接发PR。我在这个项目的开发过程中也参考了很多社区资料，现在把自己整理的成果回馈出来，希望给后来的学习者省一点时间。遇到问题可以在仓库的Discussion区留言，我看到就会回复。

最后再分享一个我在整个项目中体会最深的一点：嵌入式项目的意义，从来不只是"跑通"那一瞬间的爽感。真正让你技术成长的是中间那几十个小时的调试过程——DHT11时序对不上、OLED不亮、继电器乱跳、水泵漏水、ADC值跳动……每一个问题背后都对应一个真实的物理世界原理。把这些问题一个个捋清楚，你对单片机、传感器、电路设计的理解，就已经超过绝大多数"照着教程敲代码"的初学者了。这套系统的代码你可以直接抄，但希望在抄的过程中，多问几个为什么，多试几组参数，那才是把这套开源项目真正"占有"的方式。