简介本资源是一套基于STM32F103系列单片机的嵌入式水质监测系统完整源码面向嵌入式初学者、电子设计竞赛学生及环境监测类课程实践者解决TDS水质参数实时采集、本地可视化、越限声光报警与PC端串口数据回传等典型工程问题。压缩包含234个文件总计6.49MB涵盖47个.o目标文件、46个.d依赖文件、36个.c源文件、36个.h头文件及OLED驱动、ADC采样、I2C通信、TIM定时器、RCC时钟配置等核心模块代码结构清晰适合作为STM32标准外设库开发范例深入学习。已有57人下载学习资源包含可直接编译运行的Keil MDK工程uvprojx、调试配置文件dbgconf、链接脚本sct及一键清理脚本keilkill.bat无需额外配置即可上手验证TDS传感器读取、OLED动态刷新与蜂鸣器阈值报警全流程是理解传感器融合、人机交互与串口协议协同开发的优质实践素材。 做了这个项目之后我才体会到——真正让水质监测项目落地的往往不是那个ADC采集而是后续一连串的显示、报警、调试和参数校准问题。这篇博文就把我从零到一搭建这套系统的完整过程拆开讲清楚包括硬件选型的理由、核心代码的逐段逻辑、串口调试中的实测现象以及几个不常见但非常影响使用体验的坑。1. 项目需求与整体方案设计先交代一下这个项目的核心目标用STM32读取TDS水质传感器的模拟电压信号换算成当前水体的TDS值单位ppm实时显示在0.96寸OLED屏幕上当TDS值超过设定的安全阈值时触发蜂鸣器报警同时把采集到的原始电压、计算后的TDS值以及状态信息通过串口发送到电脑上的串口调试助手方便观察数据曲线和校验算法。这套系统听起来不复杂但它覆盖了嵌入式开发中最常见的几条主线——模拟量采集ADC、传感器标定与换算、外设显示驱动OLED、简单控制逻辑蜂鸣器报警、串口通信与上位机调试。把这套流程跑通你几乎就掌握了STM32项目开发最核心的闭环。适合刚学完单片机基础、想做一个有完整输入-处理-输出-调试链路的综合项目的人。做项目最忌讳的就是只写一个点比如只会读ADC值却不知道显示在哪儿、数据怎么发出来、异常怎么提示。这个项目的价值就在于把整条链拉通。整套系统的数据流大概是这样的TDS探头浸泡在水中探头内部是两个电极通过测量水的电导率间接反映溶解性固体总量。传感器模块把探头的电导率变化转换成0~3.3V或0~5V取决于模块供电的模拟电压输出。STM32的ADC外设采集这个模拟电压得到12位数字量0~4095。单片机根据电压值用标定公式换算成TDS值ppm。OLED屏幕第1行显示TDS值第2行显示状态Normal/Warning/Alarm第3行显示电压值。如果TDS值超过阈值蜂鸣器开始鸣叫。同时单片机通过USART1把打包好的数据帧发送到串口调试助手。为什么选择TDS水质传感器而不是更复杂的多参数水质检测探头原因很实际TDS传感器模块便宜、接线简单、输出是标准模拟量非常适合用于验证传感器-ADC-数据处理这套通用流程。等这条链路跑通了你想换PH传感器、浊度传感器几乎只需要换一下标定公式和探头其余框架都能复用。这也是为什么我建议新手从这个传感器入手而不是一上来就去调那些带modbus协议的工业级探头。整体方案确定后下面就是硬件选型了。这里必须强调一点选型不能只看能不能用还要看你手头现有的调试工具和资料水位。2. 硬件选型思路与关键外设接线2.1 主控芯片与最小系统板主控选的是最常见的STM32F103C8T6也就是大家俗称的蓝板或者C8T6核心板。选它的原因不只是便宜更重要的是它的资源恰好覆盖本项目的所有需求3个USART我们只用1个发数据绰绰有余。2个ADC每个ADC有10个通道本项目只占1个通道。I2C、SPI等显示接口全部具备后续想换屏幕方案也不用换主控。12位ADC分辨率对于TDS测量这种精度要求完全够用。如果你手头是STM32F407、STM32G030等型号代码逻辑基本不用大改只需要留意ADC通道号和时钟配置差异。这也是我喜欢用HAL库的原因移植成本低。2.2 TDS水质传感器模块的接线与检测原理市面上常见的TDS传感器模块长这样一侧是防水探头通过两根或三根线连接到信号转换板上转换板上通常有标着AO模拟输出、DO数字输出、GND、VCC的排针。本项目只用AO模拟输出。接线逻辑为模块VCC接STM32板子的5V或3.3V看模块说明大多数支持3.3~5.5V宽电压模块GND接GND模块AO接STM32的一个ADC引脚我这里接的是PA1ADC1_IN1但这里有一个非常关键的细节如果模块供电是5V那AO输出范围就是0~5V而STM32的ADC输入引脚最大只能承受3.3V。你不做分压就直连轻则采集数据严重偏大重则烧坏GPIO。所以我实际连接时在AO与PA1之间加了一个10K20K的电阻分压网络把0~5V映射到0~3.33V。如果模块本身就支持3.3V供电那就不用分压直接接线即可但前提是模块供电和ADC参考电压必须一致否则算出来的电压就不准。TDS检测的核心原理其实不复杂水中的溶解性固体主要是无机盐越多水的导电能力越强。TDS探头本质上是一对电极浸入水中后两极之间的电导率会随TDS浓度变化。传感器模块内部通过交流激励信号驱动探头避免直流极化然后对返回信号进行整流、放大最终以直流电压形式输出。单片机要做的就是把电压换算成TDS值。2.3 OLED显示屏与驱动方式显示部分我用的是0.96寸I2C接口OLED分辨率128x64主控芯片是SSD1306。这款屏在淘宝上几块钱一片驱动资料非常成熟。选I2C接口的原因一是省引脚SCL、SDA两根线就能搞定二是HAL库的I2C驱动写起来比SPI省事不用自己去拼接数据位。接线OLED VCC - 3.3VOLED GND - GNDOLED SCL - PB6I2C1_SCLOLED SDA - PB7I2C1_SDA这里注意STM32F103的I2C1默认引脚就是PB6/PB7很多朋友反映说STM32的硬件I2C不好用容易卡死于是直接上软件模拟I2C。我不否认硬件I2C在F1上有过一些兼容性问题但在HAL库上配合超时机制用下来稳定性是可控的。基于少一个CPU忙等就多一分实时性的原则我还是选择了硬件I2C但会在代码里做好错误处理和超时复位。这个后面在代码部分展开。2.4 蜂鸣器模块蜂鸣器我用的是低电平触发的有源蜂鸣器模块接在PB0上。选有源蜂鸣器是因为它内部自带振荡源只要给电平就会发声不需要用PWM去驱动。如果你用的是无源蜂鸣器就得用定时器输出PWM或者用GPIO翻转产生特定频率的方波信号噪声又大又难调。这里不是用PWM更高级而是有源无源决定了驱动方式不同如果本末倒置了最后调出来的声音可能跟闹钟一样刺耳。接线蜂鸣器VCC - 3.3V或5V看模块支持范围蜂鸣器GND - GND蜂鸣器I/O - PB0有些蜂鸣器模块是高电平触发有些是低电平触发买模块时一定要看卖家的原理图或丝印标注。我手上这块模块丝印标注是低电平触发也就是GPIO输出低时鸣叫高电平时关闭。因此代码里要用的逻辑是报警时拉低PB0。2.5 串口调试部分串口我用了USART1引脚是PA9TX、PA10RX通过USB转TTL模块连接到电脑。波特率直接定115200因为115200在数据量不大的场景下足够快而且绝大多数USB转串口芯片对这个波特率支持最稳定。如果以后要接蓝牙模块或WiFi模块把数据传到手机115200也是兼容性最好的档位。这里要给初接触串口的朋友一项关键提醒USB转TTL模块的TXD要接板子的RXDPA10RXD要接板子的TXDPA9两者需要交叉连接并且必须共地GND接GND否则串口通信会因为参考地不一致出现乱码甚至完全没数据。3. 核心代码实现从ADC采样到串口发送3.1 工程框架与CubeMX初始化我用的开发方式是基于STM32CubeMX生成初始化代码再在Keil MDK里写业务逻辑。之所以用这个流程是因为HAL库外设初始化代码量比较大手写容易漏掉时钟使能这类细节而CubeMX生成之后我们在main.c里只管读数据、算数据、发数据。在CubeMX中需要配置的引脚和应用如下PA1 - ADC1_IN1开启连续转换模式PB6/PB7 - I2C1标准模式100KHzPB0 - GPIO输出初始状态设置为高因为低电平触发蜂鸣器初始不报警就设为高PA9/PA10 - USART1模式Asynchronous波特率1152008位数据无校验1位停止位RCC - HSE外部晶振时钟配置为72MHz时钟树部分注意APB2总线上的ADC时钟不能超过14MHz否则ADC采样精度会下降。72MHz主频下APB2时钟是72MHzADC预分频器选6分频得到12MHz的ADC时钟这是最常见的配置。3.2 ADC采集与滑动平均滤波ADC要做的很简单启动转换读结果但直接读出来的原始值是12位的数字量不是电压。要换算成电压公式是float voltage (float)adc_value / 4096.0f * 3.3f;这里的3.3是ADC参考电压。如果你的板子用外部基准电压源或者5V供电导致参考电压不是标准3.3V就需要用万用表量一下实际的VREF电压填进去否则算出来的TDS值会整体偏移。但采集一次就读这个数据是不能直接用的。为什么TDS探头的信号虽然经过模块调理但水体流动、气泡、电磁干扰都会让ADC值出现抖动。解决抖动的常用方法就是滑动平均滤波——保留最近N次采样值每次取平均作为当前输出。我的实现是开一个长度为10的数组每次采样放入然后计算均值#define SAMPLE_COUNT 10 uint16_t adc_buf[SAMPLE_COUNT]; uint8_t sample_index 0; float read_tds_voltage(void) { uint32_t sum 0; for (int i 0; i SAMPLE_COUNT; i) { HAL_ADC_Start(hadc1); HAL_ADC_PollForConversion(hadc1, HAL_MAX_DELAY); adc_buf[i] HAL_ADC_GetValue(hadc1); } for (int i 0; i SAMPLE_COUNT; i) { sum adc_buf[i]; } return (float)sum / SAMPLE_COUNT / 4096.0f * 3.3f; }这里不用DMA也能跑但如果你同时还要做其他耗时操作比如刷新OLED建议把ADC配置成DMA循环模式让硬件自动把采样结果搬进内存主循环里只取平均值。本项目数据量不大用轮询模式就够。可一旦你把采样频率提高到每秒几百次、几千次轮询就会产生大量CPU占用那时DMA的优势就会非常明显。3.3 TDS电压到ppm值的换算算法现在有了电压值怎么换算成TDS这是整个项目最关键、也最容易出问题的地方。TDS与电压的关系并非严格的线性关系但大量实测数据表明在0~1000ppm范围内电压和TDS之间的曲线可以用多项式拟合。我参考的是TDS传感器厂家开放出来的经验公式基于5V供电的情况float tds_value 133.42f * pow(v, 3) - 255.86f * pow(v, 2) 857.39f * v;这个公式在输入电压为0~5V范围内有效。但我们的ADC是0~3.3V采集因为STM32供电是3.3V所以如果是5V供电的传感器模块你在3.3V下直接套这个公式会得到完全错误的结果。处理方式有两种一种是在模块供电端就固定为5V然后通过电阻分压把AO输出的0~5V映射到ADC的0~3.3V。此时ADC读到的电压其实只是真实输出电压的3.3/50.66倍。要还原真实电压需要在软件里除以0.66float sensor_v voltage / 0.66f; // 还原为模块AO输出的实际电压 float tds 133.42f * pow(sensor_v, 3) - 255.86f * pow(sensor_v, 2) 857.39f * sensor_v;另一种是模块直接用3.3V供电那AO输出范围就是0~3.3V但厂家公式是基于5V的这时需要把公式里的电压系数做一次比例缩放或者干脆不用公式改用两点定标法的线性关系。说实话厂家给的多项式公式是他们的标准探头在标准溶液下标定的结果换了一个探头或者模块批次偏差肯定存在。所以我实际项目里做了一次粗略的标定用一个已知TDS值的水样测量模块输出电压计算出折算系数然后在代码里用线性修正把最终结果拉回真实值。标定的过程也很简单拿一瓶已知TDS数值的矿泉水包装上会标注把探头放进去测出模块输出电压。然后用已知TDS / 当前电压得到一个k值之后就以这个k为准去换算#define TDS_CALIBRATION_K 650.0f // 根据自己探头微调 float tds sensor_v * TDS_CALIBRATION_K;线性标定当然不如厂家多项式全量程准确但在0~1000ppm的日常饮用水监测场景内误差完全可控而且这个k值是可以根据自己的探头微调的这才是真实项目的做派。如果你手里有TDS校准液例如342ppm的KCl标准溶液也可以把探头放进校准液里反推出更准确的k值。3.4 温度补偿要不要做严格来说TDS是随温度变化的。水的电导率在温度升高时会增大同一杯水从20度升到30度TDS读数可能上升2%左右。如果做长期监测、对比历史数据温度补偿是必要的。本项目如果只做入门演示可以默认水温25°C不做补偿。但如果想要更严谨可以在系统中加入一个DS18B20温度传感器读取温度后对TDS值进行修正。修正公式一般是float compensation 1.0f 0.02f * (temp - 25.0f); float tds_compensated tds / compensation;也就是温度每偏离25度1度修正2%。这个系数在不同水质下略有差异但0.02作为通用默认值是合理的。注意这个补偿是在TDS换算之后做不是在电压上做。我在代码里额外加了一个宏定义默认关闭温度补偿功能这样既可以让新手先跑通无温度传感器版本又给进阶留了接口。3.5 OLED显示驱动的关键逻辑OLED的驱动我用了SSD1306的HAL库版本。屏幕初始化之后核心操作就两件事清屏、显示字符串。因为OLED显示需要不断刷新的TDS值但数据变化频率并不高每秒刷新2次就足够。刷新太快反而会让画面闪烁。我按下面这个思路做了显示缓冲区所有要显示的内容先通过sprintf格式化到一个字符数组然后一次性调用OLED显示函数写入屏幕。这种方法比逐字符写显存效率高很多也不容易闪烁。char line1[20]; char line2[20]; char line3[20]; sprintf(line1, TDS:%dppm, (int)tds); sprintf(line2, V:%.2fV, sensor_v); sprintf(line3, State:%s, state_str); OLED_Clear(); OLED_ShowString(0, 0, line1); OLED_ShowString(0, 3, line2); OLED_ShowString(0, 6, line3); OLED_Refresh();0.96寸OLED是128x64每页8像素我这里用8x16字体的话一行16个像素高所以第1行在第0页第2行在第3页第3行在第6页。如果你用的是6x8小字体那行间距可以紧凑很多。多提一句OLED千万不要每帧都做全屏Clear再全屏重写那样刷新率低、闪烁严重。建议只清除内容变化的区域。我上面代码里用OLED_Clear是因为整个屏幕内容都会变实际如果只是TDS数字在变我建议用无背景色的数字刷新函数来减少闪烁。另外如果OLED上电后不显示但I2C能找到设备大概率是复位时序问题。SSD1306在有些模块上需要一个上电延时再初始化否则内部状态机没有就绪。最稳妥的办法是在初始化调用前加一个50ms的延迟如果还不行就把模块的RES引脚接到一个GPIO上软件控制复位。3.6 蜂鸣器报警状态机蜂鸣器报警看似只是if-else但实际要做好状态切换——否则会频繁抖动报警。一个常见场景TDS值在498和502之间抖动阈值设定500这时蜂鸣器就会一秒响一秒停非常恼人。解决办法是引入一个滞回区间。我设定了两个阈值报警触发阈值TDS_ALARM_ON500退出报警阈值TDS_ALARM_OFF450。只有当TDS大于500时才触发报警之后必须降到450以下才会解除。这样就能避免在阈值附近抖动引发的继电器反复通断。蜂鸣器鸣叫模式也做了一个小设计超标但未严重超标时用500ms间隔的滴答声提示严重超标时比如大于1000连续长鸣。这只需要在主循环里用非阻塞的方式判断时间static uint32_t last_beep_time 0; uint32_t now HAL_GetTick(); if (alarm_state ALARM_ON) { if (beep_mode BEEP_SLOW) { if (now - last_beep_time 500) { HAL_GPIO_TogglePin(BEEP_GPIO_Port, BEEP_Pin); last_beep_time now; } } else { HAL_GPIO_WritePin(BEEP_GPIO_Port, BEEP_Pin, GPIO_PIN_RESET); } }这里要特别注意一个高性能坑不要用HAL_Delay做蜂鸣器闪烁延时因为HAL_Delay会阻塞主循环导致同时段的OLED刷新和串口发送全部停摆。用时间戳非阻塞的方式才是嵌入式开发的常态。3.7 串口数据帧设计与调试助手对接串口发送数据很多人一上来就是printf(TDS%d, tds)。这样虽然能看但格式不固定后续想在串口助手里做波形曲线比如用VOFA、SerialPlot这类工具就非常不方便。我这边的做法是设计一个简单但完整的帧格式sprintf((char *)tx_buf, [ST]TDS:%d,Voltage:%.2f,Temp:%.1f,State:%s[ED]\r\n, (int)tds, sensor_v, temp, state_str); HAL_UART_Transmit(huart1, tx_buf, strlen((char *)tx_buf), 100);帧头是[ST]帧尾是[ED]中间用逗号分隔字段。这种固定格式有几个好处上位机可以轻松通过帧头帧尾做数据切割。即使有半个乱码下一帧也能重新同步。串口调试助手里直接能看到每行完整的记录不会因为换行符不匹配而挤在一起。以后接WIFI模块上云只需要把串口帧原封不动透传云平台解析也方便。如果你用的串口调试助手支持波形显示还可以把TDS数值单独作为一行纯数字发送这样绘制曲线更简单。我提供的源码里做了两个模式模式0输出完整帧模式1只输出纯TDS数字。用宏切换即可。关于串口发送频率我设为1秒一次。这个频率对水质监测场景是合理的因为水质变化本来就不是秒级的变化。如果你用5Hz甚至10Hz去刷Modbus上传频宽被占满不说OLED刷新和蜂鸣器控制反而受影响。做项目一定要学会够用就好。4. 串口调试助手使用与数据验证4.1 串口助手的基础配置在电脑上打开任意一款串口调试助手我这里用的是最常见的SSCOM32端口号在设备管理器里查看一般是USB-SERIAL CH340这样的设备。配置参数是波特率115200数据位8停止位1校验位None打开串口后板子一上电串口助手窗口应该就能按每秒一次的频率收到数据帧。如果你打开串口后发现收到的全是乱码通常是这三种原因之一波特率不匹配。板子程序里写的是115200但助手设置成了9600。注意要完全一致。USB转TTL模块的TXD/RXD接反导致数据无法正常传输。两个设备之间没有共地参考电压漂移太大。解决方法是把USB转TTL模块的GND接到板子上的GND。还有一种比较隐蔽的情况板子上电后没有任何输出。排查思路是先看串口助手有没有报错再测PA9引脚上是否在发送数据万用表量到3.3V左右跳变说明有数据示波器能看到方波更准确。如果PA9上没有信号那问题基本在程序里串口初始化没跑通检查CubeMX里USART1的GPIO配置。4.2 观察数据波动并判断传感器是否稳定数据发出来之后你会发现一个现象把TDS探头放在同一杯水里数值会在一个范围内轻微波动比如235ppm、237ppm、234ppm这样。这是正常的探头本身电导率测量受水中微观流动影响而ADC采样也有固定噪声。只要波动范围不超过±5%基本可以接受。但如果数值跳动特别大比如一会200多一会800多就要检查探头是不是没完全浸入水中或者探头周围有气泡也可能是探头长时间使用后电极表面污染了。TDS探头是需要定期清洁的脏了之后读数会明显偏高。另外注意TDS探头不适合测量静止过久的液体建议轻轻晃动容器让水流动这样读数更稳定。4.3 用已知水样验证精度拿到串口数据后一定要做一次验证。我常用的办法是准备一杯纯净水瓶装纯水TDS一般10ppm以下。准备一杯自来水TDS各地不同大概100~300ppm。准备一杯高浓度盐水TDS上千ppm用于测试报警功能。分别测量这三个样本把OLED上显示的值和串口收到的值记录下来。如果纯水显示50ppm以上说明探头或标定有偏差。如果盐水没有触发报警说明阈值设置或者换算公式有问题。验证过程中我踩过的一个坑直接把盐撒进水里后马上测量数值会先飙升然后缓慢下降这是因为盐还没完全溶解局部浓度过高。正确的做法是充分搅拌并静置1分钟再测量。做这种对比实验时要有耐心传感器本身是慢变量系统读数稳定需要一点时间。5. 报警阈值设计、灵敏度调优与误报规避5.1 阈值分级饮用水TDS的国家标准没有强制限定但很多净水器产品把50ppm以下作为纯水标准市政自来水一般在100~300ppm。我做的这套系统把报警阈值分成两级正常TDS 500ppm警告TDS 500ppm蜂鸣器滴答响超标TDS 1000ppm蜂鸣器连续长鸣阈值定义放在代码开头的宏定义处你可以根据自己的水质情况修改#define TDS_ALARM_WARNING 500 #define TDS_ALARM_CRITICAL 1000 #define TDS_ALARM_HYSTERESIS 505.2 如何判断报警属于读数偶尔跳动还是水质真正超标这个问题在真实项目中相当关键。刚才说了传感器数据有噪声那怎么确认报警不是假报警我的思路是在固件里加一个连续超标计数机制只有连续N次比如5次采样值都超过阈值才触发报警。如果只是偶尔一次超标不处理。这本质上是一个简单的数字去抖滤波。uint8_t over_count 0; if (tds TDS_ALARM_WARNING) { if (over_count 5) over_count; if (over_count 5) { alarm_state ALARM_ON; } } else { over_count 0; alarm_state ALARM_OFF; }这样设置之后即使TDS值瞬时跳到600然后又回来蜂鸣器也不会误响。但代价是报警响应时间会往后延迟几秒钟。水质监测场景对实时性要求不高这个代价完全值得。如果你用在需要即时响应的场景比如管道液体泄漏监测那可以把连续次数降为2并配合中断方式处理。5.3 OLED显示与报警状态联动的小技巧OLED上我加了一个状态提醒逻辑正常时显示Normal警告时显示Warning严重时显示Alarm。显示状态和蜂鸣器逻辑共享同一个状态机变量这样代码不会出现显示说正常但蜂鸣器在响的矛盾。一个很小的设计点在超标状态下OLED显示的文字背景可以反色即用白底黑字突出警告。SSD1306是单色屏但可以做一个矩形填充区域来实现反色效果。这一步虽然代码量不大但对实际体验提升非常明显。毕竟在项目演示或者实际使用时屏幕上能一眼看到状态信息比什么都强。6. 实测现象与代码调试中遇到的几个隐蔽问题6.1 ADC读取值不稳定的排查思路我第一次用轮询方式读取ADC时发现串口发出来的数值每隔几秒会出现一次明显的毛刺。一开始怀疑是传感器问题后来用示波器量了一下模块AO引脚发现确实有规律性的电压尖峰。排查到后面这个尖峰并不是传感器产生的而是我的主循环里每秒钟做一次OLED全屏刷新而OLED是全屏刷新瞬间会有比较大的电流脉冲这个脉冲通过共用的3.3V电源轨耦合到了传感器模块上。传感器模块内部虽然有一定滤波但扛不住这种尖峰。处理办法是给传感器模块单独加一个LC滤波电路或者在软件层面加大ADC的采样次数让毛刺信号在平均运算中被稀释掉。最终我是两者结合硬件上加了一个10uF电容并联在传感器VCC和GND之间软件上把滑动平均窗口从5次增加到10次。处理后数据波动范围从±15%降到±3%以内。这个排查过程给我最大的教训是模拟传感器的数据异常不要第一反应就怀疑代码先拿万用表和示波器去测硬件信号定位问题出现在哪个环节再对症下药。很多项目最后不是代码不会写而是定位问题的思路不对。6.2 硬件I2C偶尔卡死的处理上面提到我用硬件I2C驱动OLED。实测中发现长时间运行后偶尔会出现OLED黑屏无响应的情况。原因是I2C总线上出现错误后HAL库的I2C状态机没有自动恢复。我的处理方法是在I2C读写函数外层包了一层超时重试机制uint8_t oled_i2c_write(uint8_t addr, uint8_t *data, uint16_t len) { HAL_StatusTypeDef status; for (int retry 0; retry 3; retry) { status HAL_I2C_Master_Transmit(hi2c1, addr, data, len, 200); if (status HAL_OK) return 1; HAL_I2C_DeInit(hi2c1); HAL_I2C_Init(hi2c1); HAL_Delay(10); } return 0; }如果连续3次失败才对I2C做重新初始化。这个方案在实际运行中没有再出现过长时间黑屏的情况。加这个重试逻辑之后OLED刷新偶尔慢半拍但不会再卡死系统整体鲁棒性提升很多。6.3 串口发送包含换行符的正确姿势有一个很低级但常见的坑用HAL_UART_Transmit发送字符串时如果把\r\n当成可选装饰发送出去的数据在串口助手里会全部连成一行非常难读。原因是一些串口助手只在收到回车换行时才把当前行作为一条完整数据展示。所以我的代码里每一帧数据末尾都主动加上\r\n这个细节对调试体验影响极大。串口调试助手还有一个功能是自动换行但如果你发的数据没有换行符自动换行也没用。记得在初始化串口时确认printf底层是接在USART1上的直接用printf输出也可以但要注意重定向fputc函数int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 100); return ch; }这样就能愉快地用printf(%d, tds)输出了。不过我还是建议实际项目里用格式化字符串拼接的方式因为printf这种重定向在RTOS环境下可能涉及线程安全问题而HAL_UART_Transmit是裸机环境下最简单可控的发送方式。6.4 蜂鸣器持续鸣叫导致主循环响应变慢调试报警功能时出现过一个现象当TDS严重超标蜂鸣器进入连续长鸣模式后OLED刷新明显变慢。定位后发现是主循环里用了HAL_Delay(500)作为蜂鸣器鸣叫间隔这个Delay把整个循环卡住了后面的串口发送、OLED刷新都无法按时执行。后面我把所有延时都改成了非阻塞的时间判断方式整机实时性恢复了。这算是嵌入式开发里一个典型的隐性Bug单个外设的阻塞延时拖垮了整个系统的时序。经验就是只要主循环里同时存在多个周期性任务就尽量不要用阻塞延时统一的调度方式是基于HAL_GetTick()或定时器的时间切片。7. 后续扩展从串口到上云、从单点到多点监测这个项目跑通之后你可以顺着几条路继续深入。第一条路是数据记录和上云。把串口发出的数据帧接入ESP8266或者ESP32通过MQTT协议推送到公共MQTT服务器然后在小程序或者网页上查看实时水质。这样TDS监测系统就从一个本地演示项目变成了一个真正的物联网终端。串口帧格式在最初设计时已经考虑到了对接上云因为云平台解析数据的本质也是按帧格式做拆分。第二条路是增加多参数监测。在本项目的框架上多加一路ADC通道去接PH传感器、浊度传感器只需要把采集和换算逻辑抽象成几个独立的模块然后统一调度显示和发送。代码的骨架完全可以复用核心改动是增加一个传感器管理的抽象层。第三条路是提升电源设计和可靠性。TDS探头的激励信号受电源噪声影响很大如果要做长期在线监测建议把主控和传感器分开供电传感器侧用低噪声LDO主控侧用DC-DC。同时整机外壳做防水设计探头固定安装在水路中变成一套真正可长期运行的水质监测设备。我个人在实际操作中的体会是这套项目最大的收获不是那几个外设的驱动代码而是把多个外设放到一起协同工作的系统思维。ADC采样、OLED显示、蜂鸣器报警、串口发送每个模块单独做都不难但要让它们在一个主循环里稳定地各自运行而互不干扰需要你仔细编排时序、处理异常、做滤波和去抖。这个能力是任何单片机项目都绕不开的核心功。最后再分享一个小技巧如果你在做串口调试时觉得数据不好直观判断可以先在代码中临时把采样间隔改小到100ms让串口助手以更快的节奏打印数据用波形显示模式观察TDS值的噪声分布和滤波效果。等确认数据稳定了再把发送频率调回项目需要的1Hz。先排故障、再调参数调试效率和最终效果都会好很多。本文还有配套的精品资源点击获取
STM32 TDS水质监测系统实战：从ADC采样到串口调试完整指南
简介本资源是一套基于STM32F103系列单片机的嵌入式水质监测系统完整源码面向嵌入式初学者、电子设计竞赛学生及环境监测类课程实践者解决TDS水质参数实时采集、本地可视化、越限声光报警与PC端串口数据回传等典型工程问题。压缩包含234个文件总计6.49MB涵盖47个.o目标文件、46个.d依赖文件、36个.c源文件、36个.h头文件及OLED驱动、ADC采样、I2C通信、TIM定时器、RCC时钟配置等核心模块代码结构清晰适合作为STM32标准外设库开发范例深入学习。已有57人下载学习资源包含可直接编译运行的Keil MDK工程uvprojx、调试配置文件dbgconf、链接脚本sct及一键清理脚本keilkill.bat无需额外配置即可上手验证TDS传感器读取、OLED动态刷新与蜂鸣器阈值报警全流程是理解传感器融合、人机交互与串口协议协同开发的优质实践素材。 做了这个项目之后我才体会到——真正让水质监测项目落地的往往不是那个ADC采集而是后续一连串的显示、报警、调试和参数校准问题。这篇博文就把我从零到一搭建这套系统的完整过程拆开讲清楚包括硬件选型的理由、核心代码的逐段逻辑、串口调试中的实测现象以及几个不常见但非常影响使用体验的坑。1. 项目需求与整体方案设计先交代一下这个项目的核心目标用STM32读取TDS水质传感器的模拟电压信号换算成当前水体的TDS值单位ppm实时显示在0.96寸OLED屏幕上当TDS值超过设定的安全阈值时触发蜂鸣器报警同时把采集到的原始电压、计算后的TDS值以及状态信息通过串口发送到电脑上的串口调试助手方便观察数据曲线和校验算法。这套系统听起来不复杂但它覆盖了嵌入式开发中最常见的几条主线——模拟量采集ADC、传感器标定与换算、外设显示驱动OLED、简单控制逻辑蜂鸣器报警、串口通信与上位机调试。把这套流程跑通你几乎就掌握了STM32项目开发最核心的闭环。适合刚学完单片机基础、想做一个有完整输入-处理-输出-调试链路的综合项目的人。做项目最忌讳的就是只写一个点比如只会读ADC值却不知道显示在哪儿、数据怎么发出来、异常怎么提示。这个项目的价值就在于把整条链拉通。整套系统的数据流大概是这样的TDS探头浸泡在水中探头内部是两个电极通过测量水的电导率间接反映溶解性固体总量。传感器模块把探头的电导率变化转换成0~3.3V或0~5V取决于模块供电的模拟电压输出。STM32的ADC外设采集这个模拟电压得到12位数字量0~4095。单片机根据电压值用标定公式换算成TDS值ppm。OLED屏幕第1行显示TDS值第2行显示状态Normal/Warning/Alarm第3行显示电压值。如果TDS值超过阈值蜂鸣器开始鸣叫。同时单片机通过USART1把打包好的数据帧发送到串口调试助手。为什么选择TDS水质传感器而不是更复杂的多参数水质检测探头原因很实际TDS传感器模块便宜、接线简单、输出是标准模拟量非常适合用于验证传感器-ADC-数据处理这套通用流程。等这条链路跑通了你想换PH传感器、浊度传感器几乎只需要换一下标定公式和探头其余框架都能复用。这也是为什么我建议新手从这个传感器入手而不是一上来就去调那些带modbus协议的工业级探头。整体方案确定后下面就是硬件选型了。这里必须强调一点选型不能只看能不能用还要看你手头现有的调试工具和资料水位。2. 硬件选型思路与关键外设接线2.1 主控芯片与最小系统板主控选的是最常见的STM32F103C8T6也就是大家俗称的蓝板或者C8T6核心板。选它的原因不只是便宜更重要的是它的资源恰好覆盖本项目的所有需求3个USART我们只用1个发数据绰绰有余。2个ADC每个ADC有10个通道本项目只占1个通道。I2C、SPI等显示接口全部具备后续想换屏幕方案也不用换主控。12位ADC分辨率对于TDS测量这种精度要求完全够用。如果你手头是STM32F407、STM32G030等型号代码逻辑基本不用大改只需要留意ADC通道号和时钟配置差异。这也是我喜欢用HAL库的原因移植成本低。2.2 TDS水质传感器模块的接线与检测原理市面上常见的TDS传感器模块长这样一侧是防水探头通过两根或三根线连接到信号转换板上转换板上通常有标着AO模拟输出、DO数字输出、GND、VCC的排针。本项目只用AO模拟输出。接线逻辑为模块VCC接STM32板子的5V或3.3V看模块说明大多数支持3.3~5.5V宽电压模块GND接GND模块AO接STM32的一个ADC引脚我这里接的是PA1ADC1_IN1但这里有一个非常关键的细节如果模块供电是5V那AO输出范围就是0~5V而STM32的ADC输入引脚最大只能承受3.3V。你不做分压就直连轻则采集数据严重偏大重则烧坏GPIO。所以我实际连接时在AO与PA1之间加了一个10K20K的电阻分压网络把0~5V映射到0~3.33V。如果模块本身就支持3.3V供电那就不用分压直接接线即可但前提是模块供电和ADC参考电压必须一致否则算出来的电压就不准。TDS检测的核心原理其实不复杂水中的溶解性固体主要是无机盐越多水的导电能力越强。TDS探头本质上是一对电极浸入水中后两极之间的电导率会随TDS浓度变化。传感器模块内部通过交流激励信号驱动探头避免直流极化然后对返回信号进行整流、放大最终以直流电压形式输出。单片机要做的就是把电压换算成TDS值。2.3 OLED显示屏与驱动方式显示部分我用的是0.96寸I2C接口OLED分辨率128x64主控芯片是SSD1306。这款屏在淘宝上几块钱一片驱动资料非常成熟。选I2C接口的原因一是省引脚SCL、SDA两根线就能搞定二是HAL库的I2C驱动写起来比SPI省事不用自己去拼接数据位。接线OLED VCC - 3.3VOLED GND - GNDOLED SCL - PB6I2C1_SCLOLED SDA - PB7I2C1_SDA这里注意STM32F103的I2C1默认引脚就是PB6/PB7很多朋友反映说STM32的硬件I2C不好用容易卡死于是直接上软件模拟I2C。我不否认硬件I2C在F1上有过一些兼容性问题但在HAL库上配合超时机制用下来稳定性是可控的。基于少一个CPU忙等就多一分实时性的原则我还是选择了硬件I2C但会在代码里做好错误处理和超时复位。这个后面在代码部分展开。2.4 蜂鸣器模块蜂鸣器我用的是低电平触发的有源蜂鸣器模块接在PB0上。选有源蜂鸣器是因为它内部自带振荡源只要给电平就会发声不需要用PWM去驱动。如果你用的是无源蜂鸣器就得用定时器输出PWM或者用GPIO翻转产生特定频率的方波信号噪声又大又难调。这里不是用PWM更高级而是有源无源决定了驱动方式不同如果本末倒置了最后调出来的声音可能跟闹钟一样刺耳。接线蜂鸣器VCC - 3.3V或5V看模块支持范围蜂鸣器GND - GND蜂鸣器I/O - PB0有些蜂鸣器模块是高电平触发有些是低电平触发买模块时一定要看卖家的原理图或丝印标注。我手上这块模块丝印标注是低电平触发也就是GPIO输出低时鸣叫高电平时关闭。因此代码里要用的逻辑是报警时拉低PB0。2.5 串口调试部分串口我用了USART1引脚是PA9TX、PA10RX通过USB转TTL模块连接到电脑。波特率直接定115200因为115200在数据量不大的场景下足够快而且绝大多数USB转串口芯片对这个波特率支持最稳定。如果以后要接蓝牙模块或WiFi模块把数据传到手机115200也是兼容性最好的档位。这里要给初接触串口的朋友一项关键提醒USB转TTL模块的TXD要接板子的RXDPA10RXD要接板子的TXDPA9两者需要交叉连接并且必须共地GND接GND否则串口通信会因为参考地不一致出现乱码甚至完全没数据。3. 核心代码实现从ADC采样到串口发送3.1 工程框架与CubeMX初始化我用的开发方式是基于STM32CubeMX生成初始化代码再在Keil MDK里写业务逻辑。之所以用这个流程是因为HAL库外设初始化代码量比较大手写容易漏掉时钟使能这类细节而CubeMX生成之后我们在main.c里只管读数据、算数据、发数据。在CubeMX中需要配置的引脚和应用如下PA1 - ADC1_IN1开启连续转换模式PB6/PB7 - I2C1标准模式100KHzPB0 - GPIO输出初始状态设置为高因为低电平触发蜂鸣器初始不报警就设为高PA9/PA10 - USART1模式Asynchronous波特率1152008位数据无校验1位停止位RCC - HSE外部晶振时钟配置为72MHz时钟树部分注意APB2总线上的ADC时钟不能超过14MHz否则ADC采样精度会下降。72MHz主频下APB2时钟是72MHzADC预分频器选6分频得到12MHz的ADC时钟这是最常见的配置。3.2 ADC采集与滑动平均滤波ADC要做的很简单启动转换读结果但直接读出来的原始值是12位的数字量不是电压。要换算成电压公式是float voltage (float)adc_value / 4096.0f * 3.3f;这里的3.3是ADC参考电压。如果你的板子用外部基准电压源或者5V供电导致参考电压不是标准3.3V就需要用万用表量一下实际的VREF电压填进去否则算出来的TDS值会整体偏移。但采集一次就读这个数据是不能直接用的。为什么TDS探头的信号虽然经过模块调理但水体流动、气泡、电磁干扰都会让ADC值出现抖动。解决抖动的常用方法就是滑动平均滤波——保留最近N次采样值每次取平均作为当前输出。我的实现是开一个长度为10的数组每次采样放入然后计算均值#define SAMPLE_COUNT 10 uint16_t adc_buf[SAMPLE_COUNT]; uint8_t sample_index 0; float read_tds_voltage(void) { uint32_t sum 0; for (int i 0; i SAMPLE_COUNT; i) { HAL_ADC_Start(hadc1); HAL_ADC_PollForConversion(hadc1, HAL_MAX_DELAY); adc_buf[i] HAL_ADC_GetValue(hadc1); } for (int i 0; i SAMPLE_COUNT; i) { sum adc_buf[i]; } return (float)sum / SAMPLE_COUNT / 4096.0f * 3.3f; }这里不用DMA也能跑但如果你同时还要做其他耗时操作比如刷新OLED建议把ADC配置成DMA循环模式让硬件自动把采样结果搬进内存主循环里只取平均值。本项目数据量不大用轮询模式就够。可一旦你把采样频率提高到每秒几百次、几千次轮询就会产生大量CPU占用那时DMA的优势就会非常明显。3.3 TDS电压到ppm值的换算算法现在有了电压值怎么换算成TDS这是整个项目最关键、也最容易出问题的地方。TDS与电压的关系并非严格的线性关系但大量实测数据表明在0~1000ppm范围内电压和TDS之间的曲线可以用多项式拟合。我参考的是TDS传感器厂家开放出来的经验公式基于5V供电的情况float tds_value 133.42f * pow(v, 3) - 255.86f * pow(v, 2) 857.39f * v;这个公式在输入电压为0~5V范围内有效。但我们的ADC是0~3.3V采集因为STM32供电是3.3V所以如果是5V供电的传感器模块你在3.3V下直接套这个公式会得到完全错误的结果。处理方式有两种一种是在模块供电端就固定为5V然后通过电阻分压把AO输出的0~5V映射到ADC的0~3.3V。此时ADC读到的电压其实只是真实输出电压的3.3/50.66倍。要还原真实电压需要在软件里除以0.66float sensor_v voltage / 0.66f; // 还原为模块AO输出的实际电压 float tds 133.42f * pow(sensor_v, 3) - 255.86f * pow(sensor_v, 2) 857.39f * sensor_v;另一种是模块直接用3.3V供电那AO输出范围就是0~3.3V但厂家公式是基于5V的这时需要把公式里的电压系数做一次比例缩放或者干脆不用公式改用两点定标法的线性关系。说实话厂家给的多项式公式是他们的标准探头在标准溶液下标定的结果换了一个探头或者模块批次偏差肯定存在。所以我实际项目里做了一次粗略的标定用一个已知TDS值的水样测量模块输出电压计算出折算系数然后在代码里用线性修正把最终结果拉回真实值。标定的过程也很简单拿一瓶已知TDS数值的矿泉水包装上会标注把探头放进去测出模块输出电压。然后用已知TDS / 当前电压得到一个k值之后就以这个k为准去换算#define TDS_CALIBRATION_K 650.0f // 根据自己探头微调 float tds sensor_v * TDS_CALIBRATION_K;线性标定当然不如厂家多项式全量程准确但在0~1000ppm的日常饮用水监测场景内误差完全可控而且这个k值是可以根据自己的探头微调的这才是真实项目的做派。如果你手里有TDS校准液例如342ppm的KCl标准溶液也可以把探头放进校准液里反推出更准确的k值。3.4 温度补偿要不要做严格来说TDS是随温度变化的。水的电导率在温度升高时会增大同一杯水从20度升到30度TDS读数可能上升2%左右。如果做长期监测、对比历史数据温度补偿是必要的。本项目如果只做入门演示可以默认水温25°C不做补偿。但如果想要更严谨可以在系统中加入一个DS18B20温度传感器读取温度后对TDS值进行修正。修正公式一般是float compensation 1.0f 0.02f * (temp - 25.0f); float tds_compensated tds / compensation;也就是温度每偏离25度1度修正2%。这个系数在不同水质下略有差异但0.02作为通用默认值是合理的。注意这个补偿是在TDS换算之后做不是在电压上做。我在代码里额外加了一个宏定义默认关闭温度补偿功能这样既可以让新手先跑通无温度传感器版本又给进阶留了接口。3.5 OLED显示驱动的关键逻辑OLED的驱动我用了SSD1306的HAL库版本。屏幕初始化之后核心操作就两件事清屏、显示字符串。因为OLED显示需要不断刷新的TDS值但数据变化频率并不高每秒刷新2次就足够。刷新太快反而会让画面闪烁。我按下面这个思路做了显示缓冲区所有要显示的内容先通过sprintf格式化到一个字符数组然后一次性调用OLED显示函数写入屏幕。这种方法比逐字符写显存效率高很多也不容易闪烁。char line1[20]; char line2[20]; char line3[20]; sprintf(line1, TDS:%dppm, (int)tds); sprintf(line2, V:%.2fV, sensor_v); sprintf(line3, State:%s, state_str); OLED_Clear(); OLED_ShowString(0, 0, line1); OLED_ShowString(0, 3, line2); OLED_ShowString(0, 6, line3); OLED_Refresh();0.96寸OLED是128x64每页8像素我这里用8x16字体的话一行16个像素高所以第1行在第0页第2行在第3页第3行在第6页。如果你用的是6x8小字体那行间距可以紧凑很多。多提一句OLED千万不要每帧都做全屏Clear再全屏重写那样刷新率低、闪烁严重。建议只清除内容变化的区域。我上面代码里用OLED_Clear是因为整个屏幕内容都会变实际如果只是TDS数字在变我建议用无背景色的数字刷新函数来减少闪烁。另外如果OLED上电后不显示但I2C能找到设备大概率是复位时序问题。SSD1306在有些模块上需要一个上电延时再初始化否则内部状态机没有就绪。最稳妥的办法是在初始化调用前加一个50ms的延迟如果还不行就把模块的RES引脚接到一个GPIO上软件控制复位。3.6 蜂鸣器报警状态机蜂鸣器报警看似只是if-else但实际要做好状态切换——否则会频繁抖动报警。一个常见场景TDS值在498和502之间抖动阈值设定500这时蜂鸣器就会一秒响一秒停非常恼人。解决办法是引入一个滞回区间。我设定了两个阈值报警触发阈值TDS_ALARM_ON500退出报警阈值TDS_ALARM_OFF450。只有当TDS大于500时才触发报警之后必须降到450以下才会解除。这样就能避免在阈值附近抖动引发的继电器反复通断。蜂鸣器鸣叫模式也做了一个小设计超标但未严重超标时用500ms间隔的滴答声提示严重超标时比如大于1000连续长鸣。这只需要在主循环里用非阻塞的方式判断时间static uint32_t last_beep_time 0; uint32_t now HAL_GetTick(); if (alarm_state ALARM_ON) { if (beep_mode BEEP_SLOW) { if (now - last_beep_time 500) { HAL_GPIO_TogglePin(BEEP_GPIO_Port, BEEP_Pin); last_beep_time now; } } else { HAL_GPIO_WritePin(BEEP_GPIO_Port, BEEP_Pin, GPIO_PIN_RESET); } }这里要特别注意一个高性能坑不要用HAL_Delay做蜂鸣器闪烁延时因为HAL_Delay会阻塞主循环导致同时段的OLED刷新和串口发送全部停摆。用时间戳非阻塞的方式才是嵌入式开发的常态。3.7 串口数据帧设计与调试助手对接串口发送数据很多人一上来就是printf(TDS%d, tds)。这样虽然能看但格式不固定后续想在串口助手里做波形曲线比如用VOFA、SerialPlot这类工具就非常不方便。我这边的做法是设计一个简单但完整的帧格式sprintf((char *)tx_buf, [ST]TDS:%d,Voltage:%.2f,Temp:%.1f,State:%s[ED]\r\n, (int)tds, sensor_v, temp, state_str); HAL_UART_Transmit(huart1, tx_buf, strlen((char *)tx_buf), 100);帧头是[ST]帧尾是[ED]中间用逗号分隔字段。这种固定格式有几个好处上位机可以轻松通过帧头帧尾做数据切割。即使有半个乱码下一帧也能重新同步。串口调试助手里直接能看到每行完整的记录不会因为换行符不匹配而挤在一起。以后接WIFI模块上云只需要把串口帧原封不动透传云平台解析也方便。如果你用的串口调试助手支持波形显示还可以把TDS数值单独作为一行纯数字发送这样绘制曲线更简单。我提供的源码里做了两个模式模式0输出完整帧模式1只输出纯TDS数字。用宏切换即可。关于串口发送频率我设为1秒一次。这个频率对水质监测场景是合理的因为水质变化本来就不是秒级的变化。如果你用5Hz甚至10Hz去刷Modbus上传频宽被占满不说OLED刷新和蜂鸣器控制反而受影响。做项目一定要学会够用就好。4. 串口调试助手使用与数据验证4.1 串口助手的基础配置在电脑上打开任意一款串口调试助手我这里用的是最常见的SSCOM32端口号在设备管理器里查看一般是USB-SERIAL CH340这样的设备。配置参数是波特率115200数据位8停止位1校验位None打开串口后板子一上电串口助手窗口应该就能按每秒一次的频率收到数据帧。如果你打开串口后发现收到的全是乱码通常是这三种原因之一波特率不匹配。板子程序里写的是115200但助手设置成了9600。注意要完全一致。USB转TTL模块的TXD/RXD接反导致数据无法正常传输。两个设备之间没有共地参考电压漂移太大。解决方法是把USB转TTL模块的GND接到板子上的GND。还有一种比较隐蔽的情况板子上电后没有任何输出。排查思路是先看串口助手有没有报错再测PA9引脚上是否在发送数据万用表量到3.3V左右跳变说明有数据示波器能看到方波更准确。如果PA9上没有信号那问题基本在程序里串口初始化没跑通检查CubeMX里USART1的GPIO配置。4.2 观察数据波动并判断传感器是否稳定数据发出来之后你会发现一个现象把TDS探头放在同一杯水里数值会在一个范围内轻微波动比如235ppm、237ppm、234ppm这样。这是正常的探头本身电导率测量受水中微观流动影响而ADC采样也有固定噪声。只要波动范围不超过±5%基本可以接受。但如果数值跳动特别大比如一会200多一会800多就要检查探头是不是没完全浸入水中或者探头周围有气泡也可能是探头长时间使用后电极表面污染了。TDS探头是需要定期清洁的脏了之后读数会明显偏高。另外注意TDS探头不适合测量静止过久的液体建议轻轻晃动容器让水流动这样读数更稳定。4.3 用已知水样验证精度拿到串口数据后一定要做一次验证。我常用的办法是准备一杯纯净水瓶装纯水TDS一般10ppm以下。准备一杯自来水TDS各地不同大概100~300ppm。准备一杯高浓度盐水TDS上千ppm用于测试报警功能。分别测量这三个样本把OLED上显示的值和串口收到的值记录下来。如果纯水显示50ppm以上说明探头或标定有偏差。如果盐水没有触发报警说明阈值设置或者换算公式有问题。验证过程中我踩过的一个坑直接把盐撒进水里后马上测量数值会先飙升然后缓慢下降这是因为盐还没完全溶解局部浓度过高。正确的做法是充分搅拌并静置1分钟再测量。做这种对比实验时要有耐心传感器本身是慢变量系统读数稳定需要一点时间。5. 报警阈值设计、灵敏度调优与误报规避5.1 阈值分级饮用水TDS的国家标准没有强制限定但很多净水器产品把50ppm以下作为纯水标准市政自来水一般在100~300ppm。我做的这套系统把报警阈值分成两级正常TDS 500ppm警告TDS 500ppm蜂鸣器滴答响超标TDS 1000ppm蜂鸣器连续长鸣阈值定义放在代码开头的宏定义处你可以根据自己的水质情况修改#define TDS_ALARM_WARNING 500 #define TDS_ALARM_CRITICAL 1000 #define TDS_ALARM_HYSTERESIS 505.2 如何判断报警属于读数偶尔跳动还是水质真正超标这个问题在真实项目中相当关键。刚才说了传感器数据有噪声那怎么确认报警不是假报警我的思路是在固件里加一个连续超标计数机制只有连续N次比如5次采样值都超过阈值才触发报警。如果只是偶尔一次超标不处理。这本质上是一个简单的数字去抖滤波。uint8_t over_count 0; if (tds TDS_ALARM_WARNING) { if (over_count 5) over_count; if (over_count 5) { alarm_state ALARM_ON; } } else { over_count 0; alarm_state ALARM_OFF; }这样设置之后即使TDS值瞬时跳到600然后又回来蜂鸣器也不会误响。但代价是报警响应时间会往后延迟几秒钟。水质监测场景对实时性要求不高这个代价完全值得。如果你用在需要即时响应的场景比如管道液体泄漏监测那可以把连续次数降为2并配合中断方式处理。5.3 OLED显示与报警状态联动的小技巧OLED上我加了一个状态提醒逻辑正常时显示Normal警告时显示Warning严重时显示Alarm。显示状态和蜂鸣器逻辑共享同一个状态机变量这样代码不会出现显示说正常但蜂鸣器在响的矛盾。一个很小的设计点在超标状态下OLED显示的文字背景可以反色即用白底黑字突出警告。SSD1306是单色屏但可以做一个矩形填充区域来实现反色效果。这一步虽然代码量不大但对实际体验提升非常明显。毕竟在项目演示或者实际使用时屏幕上能一眼看到状态信息比什么都强。6. 实测现象与代码调试中遇到的几个隐蔽问题6.1 ADC读取值不稳定的排查思路我第一次用轮询方式读取ADC时发现串口发出来的数值每隔几秒会出现一次明显的毛刺。一开始怀疑是传感器问题后来用示波器量了一下模块AO引脚发现确实有规律性的电压尖峰。排查到后面这个尖峰并不是传感器产生的而是我的主循环里每秒钟做一次OLED全屏刷新而OLED是全屏刷新瞬间会有比较大的电流脉冲这个脉冲通过共用的3.3V电源轨耦合到了传感器模块上。传感器模块内部虽然有一定滤波但扛不住这种尖峰。处理办法是给传感器模块单独加一个LC滤波电路或者在软件层面加大ADC的采样次数让毛刺信号在平均运算中被稀释掉。最终我是两者结合硬件上加了一个10uF电容并联在传感器VCC和GND之间软件上把滑动平均窗口从5次增加到10次。处理后数据波动范围从±15%降到±3%以内。这个排查过程给我最大的教训是模拟传感器的数据异常不要第一反应就怀疑代码先拿万用表和示波器去测硬件信号定位问题出现在哪个环节再对症下药。很多项目最后不是代码不会写而是定位问题的思路不对。6.2 硬件I2C偶尔卡死的处理上面提到我用硬件I2C驱动OLED。实测中发现长时间运行后偶尔会出现OLED黑屏无响应的情况。原因是I2C总线上出现错误后HAL库的I2C状态机没有自动恢复。我的处理方法是在I2C读写函数外层包了一层超时重试机制uint8_t oled_i2c_write(uint8_t addr, uint8_t *data, uint16_t len) { HAL_StatusTypeDef status; for (int retry 0; retry 3; retry) { status HAL_I2C_Master_Transmit(hi2c1, addr, data, len, 200); if (status HAL_OK) return 1; HAL_I2C_DeInit(hi2c1); HAL_I2C_Init(hi2c1); HAL_Delay(10); } return 0; }如果连续3次失败才对I2C做重新初始化。这个方案在实际运行中没有再出现过长时间黑屏的情况。加这个重试逻辑之后OLED刷新偶尔慢半拍但不会再卡死系统整体鲁棒性提升很多。6.3 串口发送包含换行符的正确姿势有一个很低级但常见的坑用HAL_UART_Transmit发送字符串时如果把\r\n当成可选装饰发送出去的数据在串口助手里会全部连成一行非常难读。原因是一些串口助手只在收到回车换行时才把当前行作为一条完整数据展示。所以我的代码里每一帧数据末尾都主动加上\r\n这个细节对调试体验影响极大。串口调试助手还有一个功能是自动换行但如果你发的数据没有换行符自动换行也没用。记得在初始化串口时确认printf底层是接在USART1上的直接用printf输出也可以但要注意重定向fputc函数int fputc(int ch, FILE *f) { HAL_UART_Transmit(huart1, (uint8_t *)ch, 1, 100); return ch; }这样就能愉快地用printf(%d, tds)输出了。不过我还是建议实际项目里用格式化字符串拼接的方式因为printf这种重定向在RTOS环境下可能涉及线程安全问题而HAL_UART_Transmit是裸机环境下最简单可控的发送方式。6.4 蜂鸣器持续鸣叫导致主循环响应变慢调试报警功能时出现过一个现象当TDS严重超标蜂鸣器进入连续长鸣模式后OLED刷新明显变慢。定位后发现是主循环里用了HAL_Delay(500)作为蜂鸣器鸣叫间隔这个Delay把整个循环卡住了后面的串口发送、OLED刷新都无法按时执行。后面我把所有延时都改成了非阻塞的时间判断方式整机实时性恢复了。这算是嵌入式开发里一个典型的隐性Bug单个外设的阻塞延时拖垮了整个系统的时序。经验就是只要主循环里同时存在多个周期性任务就尽量不要用阻塞延时统一的调度方式是基于HAL_GetTick()或定时器的时间切片。7. 后续扩展从串口到上云、从单点到多点监测这个项目跑通之后你可以顺着几条路继续深入。第一条路是数据记录和上云。把串口发出的数据帧接入ESP8266或者ESP32通过MQTT协议推送到公共MQTT服务器然后在小程序或者网页上查看实时水质。这样TDS监测系统就从一个本地演示项目变成了一个真正的物联网终端。串口帧格式在最初设计时已经考虑到了对接上云因为云平台解析数据的本质也是按帧格式做拆分。第二条路是增加多参数监测。在本项目的框架上多加一路ADC通道去接PH传感器、浊度传感器只需要把采集和换算逻辑抽象成几个独立的模块然后统一调度显示和发送。代码的骨架完全可以复用核心改动是增加一个传感器管理的抽象层。第三条路是提升电源设计和可靠性。TDS探头的激励信号受电源噪声影响很大如果要做长期在线监测建议把主控和传感器分开供电传感器侧用低噪声LDO主控侧用DC-DC。同时整机外壳做防水设计探头固定安装在水路中变成一套真正可长期运行的水质监测设备。我个人在实际操作中的体会是这套项目最大的收获不是那几个外设的驱动代码而是把多个外设放到一起协同工作的系统思维。ADC采样、OLED显示、蜂鸣器报警、串口发送每个模块单独做都不难但要让它们在一个主循环里稳定地各自运行而互不干扰需要你仔细编排时序、处理异常、做滤波和去抖。这个能力是任何单片机项目都绕不开的核心功。最后再分享一个小技巧如果你在做串口调试时觉得数据不好直观判断可以先在代码中临时把采样间隔改小到100ms让串口助手以更快的节奏打印数据用波形显示模式观察TDS值的噪声分布和滤波效果。等确认数据稳定了再把发送频率调回项目需要的1Hz。先排故障、再调参数调试效率和最终效果都会好很多。本文还有配套的精品资源点击获取
