简介：本资源是一套基于STM32F103系列单片机开发的嵌入式水质监测系统完整工程，面向嵌入式初学者、电子类课程设计学生及物联网实践开发者，解决水质多参数实时采集与云平台上传的核心需求。系统采用标准C语言编写，支持PH值、TDS（总溶解固体）浓度及水温三参数同步检测，并通过ESP8266或类似Wi-Fi模块将数据稳定上传至OneNet物联网平台，具备完整的硬件驱动（ADC、I2C、定时器等）、传感器通信协议及网络传输逻辑。压缩包共280个文件，含72个头文件（.h）、46个源码文件（.c）、46个编译中间文件（.o）及调试配置、链接脚本、Hex/AXF固件等，整体大小为11.12MB，结构符合Keil MDK工程规范，便于直接编译烧录与二次开发。已有2038人学习下载，提供可运行的全功能工程模板、清晰的模块化代码组织及典型外设驱动实现参考，是理解嵌入式传感采集、RTOS轻量级应用与IoT端云协同的优质实践案例。 做水质检测项目的人不少，但能把传感器、主控、软件代码串成一套完整系统的，真不多见。这个标题我一看就很熟：C语言基于STM32的水质检测系统，简简单单一个压缩包，里面装的通常是源码、原理图、论文文档和PCB工程，正是高校毕设、电子设计竞赛和物联网课设里最常被翻牌的一种项目形态。
它解决的是这样一个问题：用一块几十块钱的STM32开发板，接上TDS（溶解性总固体）、pH、温度等传感器，把测量结果实时显示在屏幕上，同时通过串口或无线模块上报到上位机，甚至能联动继电器做自动处理。听上去不复杂，但真正动手做的时候，ADC采集、信号调理、滤波、标定、通信协议、状态机……每一个环节都能卡死人。
适合谁来参考？一是电子信息、自动化、物联网相关专业的应届生，拿它做毕业设计或课程设计，能快速理解“硬件+软件”的完整流程；二是刚想把单片机从点灯带到“带传感器+数据处理”阶段的新手；三是想给鱼缸、养殖场做低成本水质监测方案的爱好者。下文我会按照从方案选型到代码实现、再到调试标定的顺序，把整套系统的关键细节拆开讲，代码工程部分会直接给出C语言的组织方式和核心片段。
1. 项目概述与整体设计思路
1.1 这套水质检测系统能做什么
从功能上看，这套系统大致分成四个环节：采集、处理、显示、上报。
采集端负责把水里的物理量变成电信号，常见的检测项包括TDS、pH值、温度，进阶一点会加浊度、溶解氧、余氯。TDS反映的是水中可溶性固体总量，单位是ppm或者mg/L，日常判断自来水、纯净水、鱼缸水质都会用到；pH值体现酸碱度，是水质健康程度的核心指标；温度则是几乎所有水质参数都要用到的补偿基准，没有温度数据，TDS和pH的换算都不准。
处理环节由STM32承担，它要把传感器送来的模拟电压通过ADC变成数字量，再做滤波、标定、温度补偿，最终换算成用户能看懂的水质数值。显示通常在0.96寸OLED上完成，滚动显示TDS、pH、温度、电量或报警状态；上报则是通过串口打印或ESP8266模块把数据发到上位机、云端，实现远程监控。有些版本还会加一个继电器，当某指标越限时自动启动水泵、换水阀或投药装置。
你可能会觉得功能多，但实际拆开看，这套系统的核心链路并不长：模拟信号进来，ADC采样，C语言做滤波和标定，最后输出到显示和通信。真正决定系统好不好用的，不是某个模块多高级，而是信号链路上每一步是否处理干净了。
1.2 为什么是STM32+C语言，而不是51单片机或Arduino
这是很多新手会问的问题。先说结论：STM32在这个项目里的优势是“外设够用、处理能力余量大、生态资料多”，C语言则是嵌入式开发里绕不开的主语言。
51单片机最大的问题不在能不能跑，而在外设实在太简陋。ADC通常只有8~10位，多路扫描还要软件切换通道，采样过程中CPU被占得死死的；内部Flash也小，烧个标准库加OLED驱动就快满了；调试手段基本靠串口打印，真出问题定位很痛苦。Arduino虽然上手快，但它的优势在快速原型验证，真要写一套带标定参数存储、状态机、故障处理的产品级代码，靠几十行的setup和loop函数撑不起来，而且Arduino自带库隐藏了太多底层细节，做完这个项目你还是不明白寄存器到底发生了什么。
STM32F103C8T6这种芯片，72MHz主频，3个ADC、多个定时器、USART、I2C、SPI全都有，跑这套系统绰绰有余。更重要的是，STM32的生态已经非常成熟，HAL库配合CubeMX配置外设，能省掉大量底层时间；遇到问题随便一搜，江科大或者各路博主的教程都能帮你定位。C语言在其中的角色，从底层寄存器操作到应用层的状态机、滤波算法、协议解析，全部贯穿。做完这个项目，你对指针、结构体、函数指针、数组、宏定义这些C语言核心特性的理解，会比刷一百道题都深刻。
2. 硬件电路与传感器选型细节
2.1 传感器选型：TDS、pH、温度分别怎么挑
市面上的水质传感器五花八门，价格从十几块到几千块都有。毕设和课设场景下，我建议按“够用、有成熟模块、资料多”这三个原则来选，没必要一开始就上工业级传感器。
TDS传感器一般长这样：两根或四根金属电极，通过测量水的电导率来推算TDS。常见模块会把电极信号调理成0~2.3V或者0~3.3V的模拟电压，主控直接读ADC就行。选的时候注意两点：一是探头材质，不锈钢电极耐腐蚀，适合长期泡在水里；二是模块输出是否已经做了交流激励，因为直流激励会让电极极化，读数漂得厉害。很多便宜模块其实是直流方案，短暂测试还行，放十分钟数据就开始乱跳，这种就得在软件里做更多的滤波处理，否则没法用。
pH传感器是这套系统里最“娇气”的部分。它的核心是玻璃电极和参比电极，产生的电压信号非常微弱，内阻极高，通常几十兆欧到几百兆欧。所以模块上必须有一颗高输入阻抗的运放做阻抗变换和信号放大，典型模块如pH-4502C，输出0~5V或0~3V的模拟电压，pH范围0~14对应不同的电压值。选模块时确认它有没有信号调理电路，别买那种裸电极，STM32的ADC直接接上去，读数基本是废的。
温度传感器就简单多了，DS18B20和NTC二选一。DS18B20走单总线协议，数字输出，精度可以到0.5℃以内，接线就一根数据线，非常适合初学者；NTC成本更低，但需要自己做分压电路和查表换算，精度受电阻误差影响大。考虑到温度是用来做补偿的，建议直接用DS18B20，省事且稳定。
2.2 信号调理与电源设计：别让模拟信号毁在布线上
很多系统做出来跑不起来，不是代码问题，而是硬件连接和电源处理没到位。水质检测项目里最典型的坑，就是模拟小信号被数字噪声淹没了。
STM32跑在72MHz，IO口翻转、OLED刷新、无线模块发射，都会在电源和地线上产生毛刺。如果传感器的模拟信号线走在数字信号线旁边，或者供电直接从数字3.3V上拉出来，ADC采到的数据往往跳得像心电图。解决方法不复杂：模拟部分和数字部分在PCB上分区走线，ADC采样引脚附近加一个0.1uF去耦电容，传感器模块的电源入口加一个磁珠或10Ω电阻隔离，必要时用独立的LDO给传感器供电。
供电方案上，整个系统用5V直流输入，板载一颗AMS1117-3.3给STM32和OLED供电，TDS和pH模块直接吃5V，因为它们的运放电路需要5V才能保证输出动态范围。STM32的ADC参考电压VREF一般直接接3.3V，但要注意，很多开发板上的3.3V不是精密基准，芯片之间存在偏差，实测可能是3.27V。如果代码里硬按3.3V计算电压，最终TDS和pH值会整体偏大或偏小。严谨的做法是用万用表实测VREF电压，作为ADC换算的基准，或者用STM32内部的VREFINT通道做片上校准。
3. C语言工程实现与核心代码拆解
3.1 代码目录规划与模块划分
一套能长期维护的单片机工程，代码组织一定要清晰。我见过不少毕设代码，所有功能堆在一个main.c文件里，写了上千行，循环里又是采样又是显示又是按键，改一个模块就得牵动全局，这种代码看起来“能用”，但实际上可读性和可移植性都很差。
做这个水质检测系统，我会把工程按功能拆成这几个模块：main.c负责初始化和主循环调度；adc.c负责ADC和DMA配置，把原始采样值存到全局缓冲区；sensor.c负责从ADC缓冲区取数据，做滤波和电压换算，再调用标定参数得到TDS和pH值；ds18b20.c负责读温度；display.c负责OLED的绘制和刷新；uart.c负责串口打印和协议解析；app.c负责主状态机，把采集、显示、上报、报警这些动作串起来；calib.c负责标定参数的读取和写入Flash。
模块化带来两个直接好处：第一，每个文件只做一件事，代码量小，调试时定位问题快；第二，以后想换传感器或者换显示设备，只需要改对应的模块，不用动主逻辑。C语言里的头文件就是模块的“接口说明书”，我习惯在头文件里只暴露必要函数，内部的静态变量和Helper函数都用static修饰，防止外部误调用。这种做法借鉴了面向对象的封装思想，用C语言完全可以实现。
3.2 ADC+DMA采样：多点扫描，CPU全程不参与
水质传感器输出的是缓变信号，不需要很高的采样率，但需要采样稳定、抗干扰。我的方案是配置ADC1的三个通道分别接TDS、pH和一个预留通道（比如备用的浊度传感器），用扫描模式加连续转换，配合DMA循环模式，让硬件自动把转换结果搬进内存缓冲区。
用STM32CubeMX配置非常直观：ADC1的IN0、IN1、IN2三个通道，开启扫描模式，转换模式设为Continuous，DMA设为Circular。在代码里，定义一个16位无符号数组adc_buf[3]，DMA会不停地把三通道的转换结果写进去，CPU完全不用管，采完直接拿数据就行。采样率不需要拉满，实际测试下来，人眼看着稳定大概需要每秒10次以上的有效更新，但DMA连续跑起来是远远超这个速度的。为了避免数据被读一半时DMA又写入导致撕裂，我通常用DMA的半传输完成中断或者直接把缓冲区数组放在不会被编译优化掉的全局区，在主循环里一次性memcpy出来再处理。
这里有个关键参数要交代清楚：ADC采样时间。STM32的ADC是逐次逼近型，采样时间太短，内部采样电容充不满，读数会偏小。我用的是ADC_SAMPLETIME_239CYCLES_5，也就是最长那档，配合RCC的PCLK2分频到12MHz，能最大程度保证采集准确。ADC时钟不要超过14MHz，这是芯片手册给出的上限，超了转换结果会非线性。
电压换算公式很简单：
float adc_to_voltage(uint16_t raw) { return (float)raw * 3.3f / 4096.0f; }注意3.3这个值只是个示例，前面我提过，最好用实测值替换。如果你的系统用了内部基准校准，这里的分母可以改成从VREFINT换算出来的实际参考电压，精度还能再提一点。
3.3 数据处理：滤波、电压换算、斜率标定
ADC裸数据不能直接用，这是水质检测项目里最容易踩的坑。传感器模块本身就有噪声，电源上又有纹波，ADC采样结果经常在几个码值之间来回跳。如果不滤波直接显示，TDS数值会在几十ppm范围内乱飘，观感非常差。
我常用的是一阶滑动平均滤波，维护一个环形缓冲区，每次新采样进来就替换最旧的数据，然后算平均值。窗口长度取8到16个点，在实时性和平滑性之间比较均衡。为了去掉偶发尖峰，我还会再加上中位值滤波，把连续5个采样排一下序，取中间值作为有效值，然后再进滑动平均。两段滤波串起来之后，TDS读数基本能稳定在个位数变化，这在实际展示中足够用了。
TDS的换算要分情况看。如果是买回来的成品TDS模块，它内部通常已经用运放阵列把电导率换算成了TDS值，输出的电压直接对应ppm，这种就简单，直接曲线拟合就行。如果是自己用裸电极做电导率测量，则要先把电压转成电导率EC（单位uS/cm），再乘系数换算成TDS。常见做法是用公式校准：
float ec_to_tds(float ec, float temp) { // 温度补偿到25℃的基准电导率 float ec_25 = ec / (1.0f + 0.02f * (temp - 25.0f)); // k是TDS与电导率的比例系数，通常取0.5~0.9，按水质情况调整 float k = 0.7f; return ec_25 * k; }pH值的换算思路类似，但更具线性。pH电极在理想情况下，每1个pH单位对应59.16mV的电势变化，输出电压和pH呈线性关系。我用两点标定法确定直线的斜率和截距：先用pH=6.86的标准缓冲液测出一对电压和pH值，再用pH=4.0的标准液测出另一对，然后算出斜率和零点偏移。
typedef struct { float slope; // 电压变化量 / pH变化量，mV/pH float offset; // pH=7时的电压，mV } PhCalib_t; PhCalib_t g_ph_calib = { -59.16f, 0.0f }; float ph_calc(float voltage_mv) { return 7.0f + (voltage_mv - g_ph_calib.offset) / g_ph_calib.slope; }这个结构体和标定参数的存储直接相关，后面会在Flash保存章节再讲。
3.4 主逻辑状态机与显示刷新
主程序不建议用一个大while套所有功能的写法，那样按键、显示、通信之间容易互相卡住。我用一个简单状态机：系统上电后进入初始化，然后循环执行“采集处理→显示刷新→串口上报→按键检测→报警判断”这几个状态。
状态机的好处是逻辑清晰，而且方便扩展。如果某次采集耗时长，可以先处理其他状态；如果温度异常，可以跳到错误处理状态。对水质检测这种多任务不强、又希望代码可维护的场景，状态机比RTOS更轻量，也更容易让评审老师看懂。
显示刷新上，OLED是I2C接口，I2C时钟一般400kHz，刷新一屏全信息大约要几十毫秒，如果一直刷，CPU浪费很大。我习惯用1秒定时器来触发显示刷新，中间用局部区域更新代替整屏刷新，比如只有TDS数值变化时才重绘数字区域，图标和文字不变。这样不仅减少了I2C通信量，也减少了OLED的残影和闪烁问题。
OLED的驱动库我用过u8g2，也用过自写的SSD1306驱动。u8g2功能全，但ROM占用比较大，F103C8T6的64KB Flash如果再加上其他库，空间会比较紧张。我也试过自写精简驱动，只保留显示字符串和数字的函数，最终能省出15KB以上Flash。毕设这种场景，压缩包里有完整自写驱动往往比套一个大而全的库更讨喜。
4. 串口协议与物联网上报
4.1 串口协议怎么设计最省心
串口在这套系统里承担两个任务：一是调试时打印日志，二是和ESP8266这种无线模块通信。调试日志怎么随意都行，但和无线模块通信，必须有一个稳定的帧协议，否则数据乱了你自己都看不懂。
我常用的简单协议是这么设计的：帧头固定两个字节0xAA 0x55，紧接着是数据长度、命令字、数据区，最后是校验和。数据区里依次放TDS、pH、温度、报警标志，每种数值占2字节，避免浮点数在网络上传输的字节序问题。发送端用memcpy把float拆成字节再拼帧，接收端再拼回去。C语言里这属于典型的字节流处理场景，会用到联合体或指针强转，正好练手。
#pragma pack(1) typedef struct { uint16_t tds; // 实际值 * 100 int16_t ph; // 实际值 * 100 int16_t temp; // 实际值 * 100 uint8_t alarm; } WaterData_t; #pragma pack()数据区里我用定点数代替浮点数，把TDS乘100塞进uint16_t，这样传输过程不会因为浮点格式差异而出错。实际测试下来，串口9600波特率传这帧数据，一秒钟传20次都没问题，远够用了。关键是接收端要能正确判断帧边界，处理好粘包半包，这里就要用到状态机解析，每收到一个字节就判断当前处于哪个状态。
4.2 ESP8266接入：从AT指令到MQTT
如果要把数据放到云平台，ESP8266是最便宜的方案，十几块钱。它的用法分两种：AT指令模式和SDK二次开发模式。水质检测系统这种数据量小、上报频率低的应用，AT指令就够。
基本流程是：STM32通过串口2给ESP8266发AT指令，配置WiFi和TCP连接，把数据通过TCP socket发到服务器。第一步配置工作模式：
AT+CWMODE=1 // Station模式 AT+CWJAP="SSID","密码" // 连接WiFi AT+CIPSTART="TCP","47.xx.xx.xx",1883 // 连接服务器 AT+CIPSEND=数据长度 // 进入透传发送模式这里有一个很常见的坑：AT指令返回的时间不确定，ESP8266上电后需要好几秒才启动完成，如果STM32复位后立刻发指令，大概率没响应。所以代码里必须加超时和重试机制，我第一次写的时候就是没做等待，开机后系统根本连不上WiFi，最后在串口日志里看到一堆AT指令被丢弃才反应过来。
更稳妥的做法是给ESP8266刷MQTT固件，把数据以MQTT协议发到支持MQTT的物联网平台。这样不用自己写TCP协议栈，平台端接入也更标准化。STM32只需要按MQTT的PUBLISH报文格式组包，然后通过串口透传出去。代码里要处理的是报文长度、主题、QoS这些字段，涉及的结构体和字节序转换，正好又是对C语言基本功的一次检验。
5. 标定与温度补偿：数据靠谱的关键
5.1 为什么出厂数据不能直接用
很多第一次接触水质传感器的同学会有个误区：模块买回来，手册上说“输出电压对应多少TDS”，于是代码里直接套公式就以为完了。但实际测试会发现，不同批次的电极灵敏度、运放零点都不一样，出厂曲线只能作为参考，直接用来测量，误差可能超过20%。
以pH传感器为例，玻璃电极的老化速度挺快，用半个月零点就能偏出去将近0.2个pH单位。如果系统长期在线运行，不重新标定，测出来的数据会越来越不准。因此一套完整的水质检测系统，必须预留标定功能，让用户能在现场用标准液体修正参数，这才是工程实践和纯demo之间的分水岭。
标定的本质是求传感器输入输出曲线的斜率和截距。TDS用两点标定，标准液选电导率已知的溶液，比如84uS/cm和1413uS/cm两种；pH用两点或三点标定，常用标准缓冲液是4.0、6.86、9.18。标定完成后，把斜率和截距写进STM32内部Flash保存，系统重启后仍然有效。
5.2 两步标定法和温度补偿实操
标定流程做成菜单式交互比较友好：长按按键进入标定模式，屏幕提示“浸入标准液1，按确认”，系统采集稳定后的ADC值，再提示换上标准液2，同样流程走完，程序内部自动解算出斜率和截距。
具体到实现，标定参数用一个结构体统一管理，然后通过内部Flash的扇区保存。STM32F103的Flash不能按字节写，必须按扇区擦除再写入，我的做法是把标定参数放在最后一个扇区，每次进入标定模式时先读出来，用户重新标定后再擦除重写。这里有个注意事项：频繁擦写Flash会缩短寿命，虽然理论上能写上万次，但也不要每秒钟都写，标定完成写一次就够了。
温度补偿这块，最容易被忽略。电导率和pH测量都受温度影响，电导率的温度系数大约是每摄氏度2%左右，pH电极的斜率本身也会随温度变化。经验公式是电导率补偿到25℃基准，前面代码里已经给出来了；pH的温度补偿比较复杂，简单实现可以只补偿斜率：
float ph_slope_temp(float slope_25, float temp) { // 以25℃为基准，温度每升高1℃，斜率按0.34%/℃修正（近似值） return slope_25 * (1.0f + 0.0034f * (temp - 25.0f)); }实际的补偿系数不同电极差异很大，最好是看电极手册。我自己的经验是：把温度补偿函数独立出来，这样不管传感器怎么换，主逻辑都不用改，只要改补偿系数即可。这种设计思路本身也值得在C语言代码评审时作为亮点提。
6. 调试排错：我踩过的坑和排查清单
6.1 ADC数据跳动、偏移、悬空
ADC读出来的值乱跳，这是水质检测项目里最常见的故障。先别急着改代码，用万用表量一下传感器模块的输出引脚，看电压是否稳定。如果硬件电压本身就在跳，那是传感器供电或信号调理的问题；如果硬件电压稳定但ADC读数乱跳，问题在ADC配置和代码。
我遇到过两个特殊情况。一是ADC引脚没有配置成模拟模式，默认是浮空输入，结果采样值满量程乱跳，代码里漏写了GPIO初始化，检查半天才发现。二是DMA缓冲区没有清零，系统复位后缓冲区里残留上一次的数据，上电瞬间会显示一个巨大的异常值。解决方法是定义一个全局变量，在主函数入口处用memset清零，再启动DMA。
如果ADC读数偏大或偏小，优先查参考电压。VREF引脚如果有跳线帽连接3.3V以外的情况，或者板上LDO实际输出3.27V，那代码里的换算基准必须改。用万用表实测是一个比较稳妥的做法，比相信芯片手册快多了。
6.2 传感器漂移与接线干扰
传感器放水里几分钟后数值开始缓慢漂移，这通常不是代码问题，而是探头本身还没有稳定。TDS电极在刚放入水样时，电极表面会有一层电荷迁移过程，需要1到5分钟才能稳定；pH玻璃电极更是号称“至少要浸泡24小时才能获得稳定读数”，虽然实际使用中没这么夸张，但至少要让电极在保存液中充分活化。
接线干扰也很好排查：把传感器模块和单片机用杜邦线连接，信号线旁边再走一根电源线，示波器上能看到明显的串扰。遇到这种情况，最有效的方法是换屏蔽线，或者把信号线远离大电流走线，同时缩短导线长度。如果项目进入PCB阶段，除了分区布线，还要在ADC引脚入口加一个RC低通滤波器，时间常数取1ms左右，能滤掉大部分高频噪声。
还有个小坑：DS18B20的单总线要求上拉电阻，很多开发板上虽然引出了接口，但不一定带了4.7kΩ上拉。我用某款板子时，温度读出来一直是-55℃，就是上拉电阻缺失导致的。这时外接一个4.7kΩ电阻到3.3V就能解决。
6.3 DMA丢数据、OLED花屏、Flash写入异常
DMA丢数据这个问题，我之前遇到的情况是ADC初始化前DMA时钟没开，DMA通道配置成外设到内存模式，但外设地址写错了，导致数据乱跳。排查DMA问题要按顺序确认：RCC里DMA时钟、DMA通道映射（ADC1对应DMA1_Channel1）、外设基地址、内存地址、传输方向、缓冲区大小、工作模式。如果配置都没问题，剩下的优先级问题也很重要，DMA中断优先级低于某个高频中断时，可能出现丢数据，我习惯把DMA中断优先级设高一点。
OLED花屏的常见原因是I2C地址不对或者没有外部上拉电阻。SSD1306的I2C地址通常是0x3C或0x3D，代码里配置错了，屏幕要么没反应要么花屏。如果系统里同时挂了其他I2C设备，还要注意总线上拉电阻并联后总阻值是否太小，阻值太低了信号边沿会变差，显示就花。
把标定参数写进Flash后，系统重启发现参数是乱的，这个问题我遇到过一次。原因是写Flash之前忘了擦除扇区，数据虽然写进去了，但和原来的0xFF混在一起，读出来就成了乱码。另外，Flash写入要在Flash空闲状态下进行，并且需要关闭全局中断，否则写入过程中被中断打断会导致写入失败。代码里我加了DMA和中断临界区保护，之后再没出过问题。
7. 项目打包内容与二次开发建议
7.1 压缩包里一般有什么
像“水质检测-单片机.zip”这种命名，压缩包内的标准配置通常包括这几块：源码工程（KEIL MDK工程或CubeMX生成工程）、原理图PDF、PCB工程文件、元器件清单BOM、论文或设计报告Word、演示视频，可能还有仿真工程。
拿到包之后，建议按“先看文档、再跑Demo、最后拆代码”的顺序入手。先读论文里的系统框图和功能描述，快速理解设计意图；然后打开工程，把环境搭好，编译下载跑通Demo，确认硬件接线和串口输出；最后再逐模块读代码，把ADC采样、滤波、标定逻辑对应到电路图上，这是最快的学习路径。
但要注意，网上流传的代码质量参差不齐，有的工程在旧版HAL库上写的，用新版CubeMX打开会报一堆错；有的代码变量名全是拼音缩写，读起来很吃力。我自己的习惯是拿到任何代码包，先把工程里的全局宏和头文件列表过一遍，梳理由上到下的依赖关系，再用git做一次初始化，方便后续改坏了回滚。
7.2 还能往哪个方向升级
这套系统做到现在这一步，“能用”已经没问题了，但离“好用”还有不少距离。我给几个后续扩展方向，按优先级排列，每个的成本都不高。
第一是加浊度传感器。浊度传感器也是一个模拟输出模块，信号调理方式类似TDS，只需要占用一个ADC通道，在代码里把滤波和标定流程复制一份即可。第二是加继电器和自动控制逻辑，比如pH低于阈值时启动加药泵，温度过高时启动散热风扇，这就把检测系统变成了闭环控制系统，难度和档次都会上去。第三是改用低功耗方案，把STM32从72MHz降频到32MHz，进入STOP模式定时唤醒采样，可以实现电池供电，适合水产养殖野外部署场景。第四是本地数据记录，加一块SPI Flash或者SD卡，定时存储历史数据，并预留USB读取接口，这样脱离上位机也能保有数据记录能力。
扩展的时候，C语言的模块化设计会帮大忙：现有的adc.c、sensor.c直接复用，新增模块只需要提供对应的头文件接口，主状态机里挂一个新的状态就行。
做这个项目我个人最大的体会是：水质检测的难点从来不在单片机本身，而在从“传感器出来的模拟电压”到“屏幕上显示的最终数值”这整条链路上，每一环的误差都在累积。你把ADC采样时间调长一档、把滤波窗口加大一点、把基准电压实测校准一番，数值变化肉眼可见。很多同学问我说为什么我的TDS一直显示380多，怎么调都不一样，我让他们先量一下VREF，结果发现是3.19V，而代码里写的是3.3V，就这一项就差了3%。
所以如果你也打算复现或者改造这个项目，我的建议是：先花时间把传感器标定做扎实，再用软件滤波把数据稳住，最后才去折腾显示和云平台。基础链路如果糊里糊涂，后面所有花哨功能都是空中楼阁。最后再分享一个小技巧：标定参数不管存没存Flash，都建议在串口日志里打印出来，复位后先核对一遍参数再进主循环，能帮你少走很多“程序好像没问题但数据就是不对”的弯路。
本文还有配套的精品资源，点击获取
