STM32智能医疗输液点滴系统这个题目，光看关键词就知道是个硬核项目：代码、原理图、仿真三大件全带，属于可以在技术社区直接放出来让大家抄作业的完整工程。我自己玩嵌入式这些年，医疗电子方向的项目一直觉得很有意思，倒不是说非得做成医用级，而是这类项目天然具备“传感器采集 - 数据处理 - 控制执行 - 人机交互”的完整链路，用来练手和学习STM32相当合适。这篇文章就围绕我手头这个开源版本的智能输液点滴系统，把设计思路、硬件电路、核心代码、Proteus仿真流程和一些调试时踩过的坑全部梳理一遍，希望能给正在做类似课程设计、毕业设计或者纯粹想深入学习STM32的朋友提供一份能复现的参考。
1. 方案选型与整体架构拆解
1.1 这个系统到底在解决什么问题
病房里输液是一件看起来简单但实际挺费护士精力的事情。传统重力输液完全靠人工观察滴速，护士需要频繁巡视，患者家属也得盯着吊瓶，一旦液体输完没能及时发现，回血、凝血、空气栓塞这些风险就会找上门。做这个STM32系统的核心诉求很直接：用光电传感器实时检测莫菲氏滴管里的液滴落数，计算出当前滴速，在异常时自动报警，甚至进一步闭环控制滴速。
很多第一次接触这个项目的朋友会问：为什么不直接用称重传感器去测剩余液体量？我的回答是，称重方案做的是“存量监测”，只能告诉你还有多少液体，很难精准反映“当前每一滴落的节奏”。而医疗场景里，滴速本身就是最核心的监护指标，医生开医嘱、护士执行时用的都是“滴/分钟”这个单位。用红外对射管对着莫菲氏滴管做滴落检测，结构上最简单、反馈最直接，这也是我最终选择光电检测路线的根本原因。
1.2 为什么用STM32而不是51或者ESP32
主控选型上，我得先把话说在前面：51单片机在这个项目里真的有点吃力。液滴检测需要做定时器输入捕获、软件消抖、滴速滤波，之后还要跑PID控制、驱动OLED刷新和蜂鸣器报警，51的定时器资源和主频都不够从容。ESP32虽然性能强、还带WiFi，但这个项目的核心是精确的时域测量和实时控制，ESP32那块模数混合的单片机跑起来当然没问题，可开发复杂度、功耗和成本都被拉高了，属于杀鸡用了牛刀。
STM32F103C8T6这个型号是我个人在快速原型验证阶段比较常用的选择，原因很朴素：资料多到爆炸，HAL库和标准库都成熟稳定，价格又便宜，核心板上手即用。关键的是它自带输入捕获功能和足够多的定时器，能在同一颗芯片上同时完成滴速测量、PWM调速控制、按键扫描和显示刷新。对于一个需要对外开源、让别人也能轻松复刻的项目来说，STM32显然是覆盖面最广、门槛最低的主流答案。
1.3 整体架构：从传感器到执行机构的信号流
整个系统的数据链路大概是这样的：
红外对射传感器 -> 信号整形电路 -> STM32定时器输入捕获 -> 软件计算滴速 -> OLED实时显示 -> 滴速误差 -> PID算法 -> PWM输出 -> 步进电机 -> 异常状态 -> 蜂鸣器报警 + LED指示输入捕获负责“检测滴落事件”，滴速计算和PID控制负责“决策”，步进电机或者比例夹管阀负责“执行”，OLED和蜂鸣器负责“人机交互”。这四块各自独立、相互解耦，恰好也是模块化开发的经典思路。下面几个章节我会把每一块的设计细节和踩坑经验单独展开讲。
2. 硬件电路设计：原理图里的每一个元件都有讲究
2.1 液滴检测单元：红外对射管+信号整形
液滴检测是整个系统的感官，这里出问题，后面算法写得再好都白搭。我用的是红外对射传感器，发射管和接收管面对面安装在莫菲氏滴管两侧。没有液滴落下时，接收管能稳定接收到红外光，输出一个稳定的电平；当液滴经过光路时，红外光被遮挡，接收管输出电平发生跳变。这个“跳变”就是一次滴落事件。
但这里有个很多新手容易忽略的问题：红外接收管的输出波形并不是干净的数字方波，而是缓慢变化的模拟信号，直接进单片机引脚会导致误触发。解决方法是加一级信号整形电路。我在原理图里用了比较器或者施密特触发器，把缓慢变化的模拟信号转换成边沿陡峭的数字脉冲。实测下来，LM393比较器或者74HC14施密特触发器都是可靠的选择。信号整形之后，还需要加一个上拉电阻和一个10nF左右的滤电容，防止高频噪声干扰。
下面是液滴检测接口这一部分的参考接线方式：
| 元件 | 连接到STM32 | 说明 |
|---|---|---|
| 红外发射管阳极 | 3.3V | 需要串一个限流电阻，阻值根据LED规格选择 |
| 红外发射管阴极 | GND | 直接接地 |
| 红外接收管集电极 | PA0 (TIM2_CH1) | 接STM32定时器输入捕获引脚 |
| 红外接收管发射极 | GND | 直接接地 |
| 比较器输出 | PA0 | 若使用LM393，输出端要加上拉电阻 |
| 滤波电容 | 信号线与GND之间 | 10nF电容滤除高频毛刺 |
实际操作中还有一个非常要紧的点：莫菲氏滴管本身的透光性、所处环境的环境光干扰、红外管的对射角度，都会影响检测稳定性。因此我给传感器加了一个不透明的遮光罩，把环境光隔离开来。这个细节在原理图里看不出来，但却是能不能稳定检测的关键。
2.2 STM32最小系统与电源设计
STM32F103C8T6的最小系统不算复杂，但也别掉以轻心。我见过不少同学画原理图时漏了Boot0引脚的上下拉电阻、复位电路的电容参数选错，导致板子死活下载不了程序或者运行不稳定。
电源部分我用的是USB的5V输入，经过AMS1117-3.3稳压到3.3V给STM32和传感器供电。注意AMS1117的输入输出都需要接滤波电容，输入侧建议10uF+100nF，输出侧建议10uF+100nF，这是数据手册里明确要求的，能防止电源纹波导致单片机复位。如果项目还要驱动步进电机，那么电机电源必须单独供电，不能和单片机的3.3V共用一路，否则电机启动瞬间的电流冲击会把单片机拉死。这是我在项目初期踩过的一个典型电源坑。
晶振用的是8MHz无源晶振，两个20pF负载电容分别接到晶振两端到地。复位电路用一个10K电阻上拉、一个100nF电容下拉到地，按下复位按键时拉低RESET引脚。
2.3 显示模块、报警电路与预留接口
人机交互部分我用的是0.96寸OLED显示屏，I2C接口，SCL和SDA分别接到PB6和PB7。OLED的好处是显示刷新快、功耗低、尺寸小，放在输液监控器这种小设备上非常合适。报警部分用一个有源蜂鸣器接到某个普通的GPIO口，单片机输出高电平就能驱动，不需要额外振荡电路。如果嫌有源蜂鸣器声音太单调，可以换无源蜂鸣器，用PWM驱动，能发出滴滴响的效果，报警辨识度更高。
考虑到这是一个开源项目，我在设计时还预留了一个串口调试接口（PA9/PA10）和一个WiFi模块接口。串口调试在开发阶段几乎是必需的，能用串口打印各种中间变量来定位问题；WiFi接口则是给项目留了后续上云、远程监护的扩展空间。原理图里多画这两个接口成本几乎为零，但后期扩展却非常方便。
3. 软件核心：滴速检测与自动控制的算法设计
3.1 两种滴速测量方案的比较
滴速测量的核心算法，其实有两种路线：一种是“测周期倒数”，另一种是“固定窗口计滴数”。前面那种思路是记录相邻两滴之间的时间间隔，然后用间隔秒数去除60，得到每分钟滴数。举个例子，如果两滴之间间隔刚好是1秒，那滴速就是60滴/分钟。这个方案响应最快，一滴落下来马上就能更新显示值，但它有个致命弱点——对单滴时间抖动过于敏感，一滴水的抖动可能导致显示数字大幅跳动。
后面那种思路则是用固定时间窗口，比如在2秒或者5秒内统计滴数，再折算成每分钟滴数。这种方案的稳定性明显更好，适合作为最终显示和控制用的滴速值。我最终采用的是“5秒窗口计数法”：每5秒统计一次滴数，乘以12得到每分钟滴速。虽然单次更新有最多5秒的延迟，但测出来的数值非常平稳，不会出现显示值剧烈跳变吓到患者的情况。在实际护理场景里，滴速短时间的波动本来也不是必须立即反馈的，稳定性优先于实时性。
由于我用了定时器输入捕获检测滴落边沿，两滴之间的间隔也是现成的数据。所以我把两种方案都实现了：窗口计数法用于显示和PID反馈，测周期法用于快速响应报警（比如检测到长时间没有新滴落，立即判断为异常）。
3.2 定时器输入捕获的配置思路
输入捕获是STM32定时器的一个经典功能。简单来说，定时器内部有个计数器在不断递增，外部信号发生跳变的那一刻，硬件会把当前的计数值“拍快照”保存下来，并触发一次中断。这样一来，脉冲间隔就能用计数值差乘以定时器时钟周期精确计算出来。
我选择的映射关系是PA0作为TIM2_CH1的输入捕获通道。初始化时要把GPIO配置为浮空输入，确定好分频系数和计数周期。假设定时器时钟为72MHz，分频72得到1MHz的计数频率，也就是每个计数单位代表1微秒。计数周期设得足够大（比如0xFFFF），这样1微秒分辨率下能测量最长约65毫秒的间隔，对应滴速大约为920滴/分钟，远远够用了。
输入捕获的硬件滤波也要重视。STM32的通道集成了一个数字滤波器，可以滤除小于指定宽度的脉冲毛刺。我把滤波值配置在中等水平，既能滤掉大部分干扰，又不至于漏掉真实的液滴信号。
3.3 PID控制：从理论到调参实践
如果项目只做“监测+报警”，到前面那步就结束了。但既然标题里写着“智能”，我当然希望它能自动调节滴速，让实际滴速稳定在医生设定的目标值附近。这时PID控制器就登场了。
位置式PID的标准公式是：
输出 = Kp * 误差 + Ki * 积分(误差) + Kd * 误差变化率放在这个项目里，误差就是“目标滴速 - 当前滴速”，输出是PWM的占空比，用来控制步进电机或者比例夹管阀的夹紧程度。步进电机使滚轮转动，改变输液管的截面积，从而影响滴速。电机夹得紧，滴速变慢；电机放松，滴速变快。
调参方面我的习惯是先P后I再D。先把Ki和Kd设为0，只调Kp，让系统产生一个比较明显的振荡但不过度发散，得到一个临界比例增益。然后加入少量Ki消除稳态误差，最后根据响应曲线的超调量决定是否加Kd。医疗场景下垂稳比快更重要，我不追求极短的调节时间，稳定无超调才是首要目标。实际测试下来，Kp取2左右、Ki取0.1、Kd取0.5可以作为这个系统的起始参数，再根据电机的响应特性微调。
需要特别说明的是，PID控制输出的上限一定要做限幅，否则步进电机会转到底把输液管完全压死，这是很危险的。我在代码里把PWM占空比限制在10%到90%之间，即便算法异常，物理机构也不会走到极端位置。
3.4 系统状态机设计
为了让整个系统行为清晰可控，我引入了状态机的思想。系统一共分成四个状态：待机态、运行态、报警态和完成态。
待机态时，系统上电自检，等待用户按下“启动”键并设定目标滴速。进入运行态后，传感器开始检测滴落，实时计算滴速并刷新OLED显示，同时PID控制器根据偏差驱动电机。如果检测到超过10秒没有新的滴落事件，认为输液管堵塞或者液体已经输完，系统切到报警态，蜂鸣器鸣叫、OLED显示具体异常类型。若用户按键确认或者更换药液后重新启动，系统可以回到运行态。当累计滴数达到预设总量时，系统进入完成态，提示输液结束。
把整个逻辑拆成状态机之后，代码的可读性和可维护性都提升了很多。新增一个功能时，只需要在对应的状态下加一个分支，不需要动其他状态的代码，这对开源项目后续的二次开发特别友好。
4. 工程实操：核心代码段与关键实现细节
4.1 滴速测量代码：输入捕获中断里该做什么
这里给出输入捕获中断服务函数的核心写法，我尽量保持简洁，方便你移植到自己的工程：
volatile uint32_t g_drop_count = 0; // 滴数计数器 volatile uint32_t g_last_capture = 0; // 上一次捕获的计数值 volatile uint32_t g_interval_us = 0; // 相邻两滴之间的间隔，单位us void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_CC1) != RESET) { TIM_ClearITPendingBit(TIM2, TIM_IT_CC1); uint32_t current_capture = TIM_GetCapture1(TIM2); if (g_last_capture != 0) { g_interval_us = current_capture - g_last_capture; } g_last_capture = current_capture; g_drop_count++; } }这里有一个特别容易被忽略的点：中断服务函数里不要做任何耗时操作，什么OLED显示、数值换算、串口打印统统都别放这里。中断里只做“保存数据、更新标志”这两件事，所有计算都放到主循环里处理。因为输入捕获中断本身可能会有几微秒的软件延迟，如果你在中断里做太多事，下一滴落下来的时候中断还没退出，就会丢失滴落事件。我一开始就是吃了这个亏，把滴速计算直接放在中断里，结果一调用除法函数，中断时间急剧拉长，高滴速时频繁丢滴。
4.2 滴速换算与数字滤波
在中滴主循环中，我每5秒取一次统计数据：
uint32_t drops_in_window; float drip_rate_per_min; if (timer_5s_flag) { timer_5s_flag = 0; __disable_irq(); // 临界区保护 drops_in_window = g_drop_count; g_drop_count = 0; __enable_irq(); drip_rate_per_min = drops_in_window * 12.0f; // 5秒*12=60秒 }窗口计数算出来的滴速比较平稳，但我还是加了一级一阶低通滤波，让显示值的变化更平滑：
filtered_rate = 0.8f * filtered_rate + 0.2f * raw_rate;滤波系数0.2意味着新值只贡献20%的变化量，显示出来的数字会慢慢逼近真实滴速，不会出现大起大落。实际临床中，护士本来也不需要看到滴速瞬时突变，平滑后的数值反而更容易判断趋势。
4.3 PID控制器实现与PWM驱动
PID的代码实现我放在了主循环中，以固定周期调用：
float pid_update(float setpoint, float feedback) { float error = setpoint - feedback; integral += error; integral = constrain(integral, -integral_limit, integral_limit); float derivative = error - last_error; last_error = error; float output = Kp * error + Ki * integral + Kd * derivative; output = constrain(output, output_min, output_max); return output; }积分项一定要做限幅，否则系统长时间达不到目标滴速时，积分会不断累加，最后导致严重的超调，这是PID使用中非常典型的“积分饱和”问题。至于PWM输出来控制电机，我用的是TIM3的PWM通道，通过修改比较寄存器值来改变占空比。电机方向控制则由两个普通GPIO引脚决定。
如果你用的是比例夹管阀而不是步进电机，那么直接把PWM输出接到阀门的驱动电路上即可，控制逻辑几乎不用改。
4.4 OLED显示与按键交互
显示部分用I2C驱动OLED，每次刷新时按固定格式输出以下关键信息：当前滴速、目标滴速、累计滴数、系统状态。按键我用的是三个独立按键：一个是“设置/确认”，一个是“加”，一个是“减”。长按“设置”键进入目标滴速调节模式，“加/减”键调整数值，再按“设置”确认退出。
按键处理最忌讳在主循环里做扫描时把人卡死。我采用10ms定时扫描加边沿检测的方式：每10ms读一次按键电平，检测到按下沿时加分频计数，连续几次都确认是低电平后才认定按键有效。这样既能消抖，又不会因为等待按键松手而阻塞主循环。
4.5 一个容易被忽略的定时器冲突问题
写代码时特别提醒大家注意一个坑：STM32F103的定时器资源其实是共享的，TIM2和TIM3等定时器虽然独立，但如果你同时在用PWM、输入捕获、延时函数，最好列一张资源占用表，明确每个定时器被哪个功能占用。我在这个项目里就遇到过TIM2既想做输入捕获又想作为延时基准，结果两边配置互相覆盖，最后功能错乱的问题。解决办法是给延时专门用SysTick做基准，把TIM2完全让给输入捕获，TIM3负责PWM，TIM4用来做窗口计时的时基。
5. 仿真搭建：Proteus里完整跑通系统的细节
5.1 元件选型与连线注意事项
仿真环境我用的是Proteus 8.x，加载STM32F103C8T6模型，然后从库中拖出OLED、按键、蜂鸣器、红外对射传感器等元件。有一点要先说清楚：Proteus里并没有完全等同于真实物理环境下液滴遮挡红外光路的传感器模型，最直接有效的替代方案是用一个脉冲信号源来模拟传感器输出。脉冲信号的频率对应不同的滴速，比如要模拟60滴/分钟的滴速，就设置脉冲频率为1Hz，占空比调小一点，模拟液滴短暂遮挡光路的波形。
这个替换方法在仿真阶段是完全够用的，因为仿真关注的焦点是单片机的算法逻辑和系统联动。等到实物阶段，再换成真实的光电对射管和物理液滴。
连线时要注意OLED的I2C引脚地址，Proteus的OLED模型默认地址和真实模块可能不一样，我遇到过程序在实物上正常、在仿真里黑屏的情况，最后查出来是I2C从机地址不匹配。修改代码里的设备地址，或者换一个与实物一致的OLED模型，都能解决问题。
5.2 仿真中两个值得注意的坑
第一个坑是晶振配置。Proteus默认使用的STM32模型内部时钟频率和真实芯片不同，可能默认跑的是内部RC振荡器，频率和你在代码里初始化外部8MHz晶振时的预期不一致，导致定时器时间基准全偏。解决方法是按真实硬件一样在仿真原理图中放置一个8MHz晶振模型，并在代码中明确配置外部高速晶振为时钟源。
第二个坑是仿真速度。如果仿真模型加入大量元件，Proteus的实时性可能变差，你会发现滴速计算明显偏慢。这时候优先检查有没有开启“Run at real time”选项，如果没有，仿真运行速度会被限制，中断频率和计时周期都会失真。我通常还会尽量减少仿真中的LED闪烁动画效果，这类动态元件的刷新渲染非常消耗CPU。
5.3 仿真对“算法验证”的价值大于“硬件验证”
仿真在这个项目里的定位，我觉得应该说得客观一点：它最适合用来验证算法逻辑的完备性和状态机的正确性，比如滴速计算是否准确、报警条件能否触发、PID输出是否有界。至于模拟信号的噪声、按键的真实抖动、电机的实际负载特性，这些在纯仿真环境里是模拟不出来的，必须回到实物调试阶段去处理。
所以我的建议是仿真阶段重点观察：脉冲频率变化时，OLED显示值是否随之变化；把脉冲源停掉，系统能否在10秒内进入报警态；把目标滴速设成一个高于当前脉冲频率的值，PWM输出是否按照PID逐步增大。这三条链路走通了，核心功能就算验证到位，可以去画PCB做实物了。
6. 调试实录：那些必须写出来的血泪教训
6.1 液滴计数乱跳：90%是硬件信号问题
调试中最常见的故障就是滴速数值乱跳，明明液体匀速滴落，显示值却忽高忽低。遇到这种问题，先把软件滤波都关掉，用示波器（或逻辑分析仪）观察进入PA0的波形。如果波形边沿不够陡、带有回振，就说明信号整形部分没做好，加施密特触发器或者调大滤波电容。如果波形是干净的方波但计数依然乱跳，再回头看是不是两个相邻滴落间隔太短、定时器计数溢出导致捕获差值错误。
还有一个容易被忽略的问题：滴管本身的位置移动。莫菲氏滴管如果没有固定好，液滴下落的轨迹会漂移，经常擦着红外光路的边缘经过，接收管输出的脉冲非常窄，输入捕获的硬件滤波器可能直接把它滤掉了。我后来在结构上加了一个3D打印的固定支架，把传感器和滴管牢牢固定住，误检率才真正降下来。
6.2 定时器捕获中断偶尔丢滴：优先检查中断优先级
中断嵌套问题在STM32里属于比较隐蔽的故障。如果输入捕获中断设置为最低优先级，而其他外设（比如串口、SysTick）又在频繁触发中断，那么输入捕获中断可能被延迟响应。当滴速较高时，两滴之间的间隔可能只有几百毫秒，延迟通常不会致命；但如果中断被长时间阻塞，就会直接丢滴。我最终将TIM2的NVIC抢占优先级设为最高，确保任何时刻滴落事件都能被立即记录。
6.3 电机启动瞬间导致系统复位：电源隔离是硬道理
这个问题前面提过，但值得再强调一次。我最初为了让原理图简单，把电机驱动和单片机共用了同一个电源模块。结果是电机一启动，电压瞬间跌落，单片机直接复位。后来我给电机单独加了一路电源，并加了光耦隔离，把控制信号和功率地完全分开，系统才稳定下来。开源版本里我画了两个电源域，也是为了让后来的人少走这个弯路。
6.4 常见问题速查表
| 问题现象 | 可能原因 | 排查与解决 |
|---|---|---|
| OLED黑屏 | I2C地址不匹配 / SCL、SDA接反 | 核对设备地址，用I2C扫描程序确认 |
| 滴速显示偏高 | 传感器受环境光干扰产生误触发 | 加遮光罩，调整红外对射角度 |
| 滴速显示偏低 | 两滴间隔超过定时器计时范围或者滤波太强 | 提高计数频率，适当降低硬件滤波强度 |
| 步进电机不动作 | PWM通道未使能 / 使能引脚接错 | 检查TIM3配置，用逻辑分析仪看PWM输出 |
| 仿真空跑、没有反应 | 晶振配置或烧录的hex文件路径错误 | 检查时钟源配置，确认Proteus加载的是最新hex |
| 蜂鸣器不响 | 有源蜂鸣器误选成无源 / 驱动电流不够 | 确认蜂鸣器类型，必要时加三极管驱动 |
7. 开源版本里的文件结构与二次开发建议
开源包里除了代码和原理图，我还整理了一份简单的文件结构说明，方便拿到项目的人快速找东西：
project_root/ ├── firmware/ │ ├── Core/ # 主程序、中断服务 │ ├── Drivers/ # HAL库或标准库驱动 │ ├── App/ # 应用层：滴速计算、PID、状态机 │ └── Project/ # Keil工程文件 ├── hardware/ │ ├── schematic.pdf # 原理图PDF版 │ ├── schematic/ # 可编辑原理图工程 │ └── datasheet/ # 关键芯片数据手册 ├── simulation/ │ ├── infusion_sys.pdsprj # Proteus工程 │ └── README.md # 仿真使用说明 └── doc/ └── 设计说明文档.md二次开发的方向我自己觉得有两个比较值得做：一是加通信模块，把滴速和报警信息通过WiFi或者蓝牙上传到护士站，这就往物联网医疗方向靠了；二是做多通道，同时监护多瓶输液，在硬件上增加传感器接口，软件层把状态机实例化多份。两个方向的技术栈都是现成的，我预留的串口和通信接口就是为了后续接这些扩展模块。
代码层面我也建议二次开发者遵循原有的模块化风格：传感器驱动放到独立的.c/.h文件里，PID算法保持纯函数，不依赖具体硬件。这样不管是换传感器型号还是换执行机构，改动范围都能控制在最低。
另外，开源项目最常见的毛病是“能跑就行”，注释写得稀烂。我在核心函数的头部都写明了输入输出参数和调用条件，主循环的逻辑也有清晰的段落注释，这一点在开源分享时特别重要，因为别人读你的代码往往比你写的时候更痛苦，别让人家在阅读上消耗太多耐心。
我实际测试时发现，使用软件定时器做5秒窗口计时时，如果系统同时在进行OLED刷新和按键扫描，窗口的边界会有微小的抖动，虽然不影响最终结果，但在追求高精度时还是应该用硬件定时器定时触发一个标志位，而不是在中断里累计计数。这个建议也写进了代码注释，算是给后来者的一个小提示。
这次把整个项目从选型到仿真完整走了一遍，心里最大的感受是：医疗电子类项目真正有难度的不在于某个单一技术点，而在于多个模块之间的协调与容错。传感器要稳、算法要准、控制要安全、界面要直观，任何一环掉链子都会让“智能”两个字大打折扣。好在这套开源方案把硬件、软件、仿真三条路径都铺好了，照着走一遍，基本就能把STM32的常用外设和系统设计的思路给吃透。
