STM32智能输液点滴系统：滴速检测与PID闭环控制全解析

做过医疗电子相关项目的人都知道，输液监护这块有个很尴尬的现状：医院里高端设备不少，但基层诊所、社区医院、居家康复场景下，大量还是靠护士人工巡房、患者家属盯瓶。真正能做到滴速可控、异常报警、信息可视的输液系统，要么贵得离谱，要么闭源得彻底。所以我一直觉得，STM32 + 传感器 + 步进电机这套组合做出来的智能输液点滴系统，是嵌入式开发者最值得复刻的医疗方向项目之一——它麻雀虽小，但把信号采集、执行控制、人机交互、异常保护全串起来了，做完一遍，等于把嵌入式开发的完整链路重新捋了一遍。

这篇文章把整套方案摊开讲：从系统架构设计、硬件选型原理，到滴速检测和PID控制的落地代码、Proteus仿真环境搭建，包括我实际调试中踩过的坑，一次性说清楚。整套项目的代码、原理图和仿真工程都已经整理好，开源放在文末，拿到就能直接编译烧录，适合正在做课程设计、毕业设计，或者想转医疗电子方向的工程师参考。

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

1.1 这个系统到底解决什么问题

先聊需求。传统输液过程有三个痛点：第一，滴速全靠护士用秒表数，一分钟数一次，误差大且费人力；第二，输液完毕如果没人及时处理，血液回流的风险真实存在；第三，患者或者家属需要频繁抬头看输液瓶，心理负担很重。

这套智能输液点滴系统做的事情，就是把这三个痛点用嵌入式方案解决掉：

• 滴速实时检测：用红外对射传感器识别滴管中每一滴液体的下落，MCU测量相邻两滴的时间间隔，换算成“滴/分钟”的滴速值。
• 滴速闭环控制：设定一个目标滴速，系统通过步进电机挤压或放松输液管，调节实际滴速逼近目标值。
• 异常状态报警：输液完成（液位过低）、滴速异常（堵管/空瓶/意外波动）、设备故障时，驱动蜂鸣器和LED报警。
• 信息可视化：OLED屏幕实时显示目标滴速、当前滴速、累计液量和运行状态。
• 仿真验证：配套Proteus工程，即使手头没有硬件，也能完整跑通滴速检测、PID调节和报警逻辑。

这个定位决定了它的设计原则：能用便宜成熟的器件，就不用冷门方案；能在裸机上用状态机解决，就不贸然上RTOS；能靠硬件电路做信号整形，就不把压力全压在软件滤波上。整个项目预算控制在100元以内，这也是它能大规模复现的基础。

1.2 为什么主控选STM32F103C8T6

很多人在知乎、CSDN上问，做输液系统用51单片机行不行？我的答案是：能跑，但很勉强。原因有三点：

第一，滴速检测需要输入捕获功能。用定时器的输入捕获通道测量脉冲间隔，精度是微秒级的，51单片机的定时器资源做这个事情要频繁中断，代码写起来很别扭，实时性也差一截。STM32F103C8T6有3个定时器，其中TIM2、TIM3、TIM4都支持输入捕获，完全够用。

第二，闭环控制需要多任务并行。系统同时要处理滴速采样、PID计算、按键扫描、OLED刷新、蜂鸣器驱动，如果用51，光OLED刷屏就能把CPU时间吃掉大半，PID计算会变得断断续续。而STM32主频72MHz，加上硬件SPI/I2C外设，可以做到外设中断驱动，CPU只在关键时刻干活。

第三，就是生态和扩展性。STM32的固件库、HAL库、FreeRTOS移植资料太成熟了，后面想加Wi-Fi模块做物联网远程监护、加MAX30102做血氧监测，引脚和外设都够用。做医疗电子方向，从STM32入手是投入产出比最高的路线。

1.3 系统架构与数据流

整个系统的数据流可以概括为：传感器感知 → 信号调理 → MCU计算 → 执行器动作 → 人机交互反馈。

红外对射传感器 → 信号整形电路 → STM32定时器输入捕获 ↓ 滴速计算（滴/分钟） ↓ PID控制器 / 阈值判断 ↓ 步进电机（滴速调节）→ OLED + 蜂鸣器报警

这个架构的巧妙之处在于分层清晰：检测层只负责把物理量变成干净的脉冲信号；控制层只负责计算和决策；执行层只负责把控制量变成物理动作；交互层只负责给人看和听。每一层之间用明确的接口通信，调试的时候就能逐层排查，不用一上来就怀疑整个系统。

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

2.1 传感器选型与信号调理电路

滴速检测是整个系统的感知核心，方案上有两种常见选择：

一种是红外对射式。在输液滴管两侧分别放一个红外发射管和一个红外接收管，液体滴落时遮断光路，接收管输出电平跳变。这个方案的优点是结构简单、成本极低（一对红外对管几毛钱）、响应速度快，缺点是容易受环境光干扰，对安装位置敏感。

另一种是电容式非接触检测。通过检测滴管壁电容的变化判断液滴通过，优点是传感器可以不接触液体，卫生安全性好，但电路复杂，成本高，个人项目复现难度大。

我最终选了红外对射式，因为作为开源项目，必须把复现门槛降到最低。硬件电路长这样：

红外发射管：串联一个100Ω限流电阻，接到3.3V电源 红外接收管：接成光敏三极管形式，集电极接3.3V，发射极串联10K电阻到GND 比较器整形：LM393，同相输入端接接收管分压点，反相输入端接10K电位器分压作为阈值 输出：LM393输出引脚接STM32的PA0（TIM2_CH1）

这里有个关键细节：红外接收管输出的信号不能直接进MCU。因为液滴下落速度快（一滴大约50~100ms），光路被遮挡的时间可能只有几毫秒到十几毫秒，而且信号会有上升沿抖动，如果直接进GPIO，要么检测不到，要么产生多次误触发。用LM393做比较器整形，把模拟信号变成干净的方波，MCU只需要做一件事：数上升沿或者测脉宽。

阈值电位器的调节方法我在后面调试章节详细说，这里先记住一个原则：阈值不能设定在信号波形中间，要靠近接收到红外光时的电平，这样液滴刚产生一点遮挡，比较器就翻转，检测灵敏度最高。

2.2 液位检测与报警电路

输液报警的核心前提是知道什么时候药液快没了。这里考虑过超声波传感器、重力传感器，但最终选了电容式薄膜液位传感器贴在输液瓶底部外侧。

为什么选这个方案？因为医院场景下不允许破坏输液瓶的密封性，也不方便在瓶口加装机械结构。电容式液位传感器通过检测液体介电常数变化引起电容变化来判断液位，探头是贴片式的，用3M胶固定就能工作，安装无创、成本低、响应可靠。

TP4056之类成品模块不适用这里，我直接用比较器电路检测：传感器电容变化经过555定时器转成频率信号，MCU用输入捕获测频，根据频率阈值判断液位。具体原理图在工程文件夹里有完整版，这里不贴全图，重点说下核心参数：

• 传感器静态电容约20pF，满液时变化约5~10pF
• 555工作频率约100KHz，液位变化引起频率偏移约5~8KHz
• MCU测频窗口用100ms，频率变化超过3KHz判定为液位过低

报警电路相对简单，蜂鸣器用三极管S8050驱动，PA8引脚输出PWM可以控制报警音调。这里有个坑：医用设备的报警音不能太刺耳，需要是有节奏的“滴—滴—”声而不是连续长鸣。所以我在程序里用定时器中断做了一个0.5秒周期的滴答音效，占空比30%，而不是简单地把蜂鸣器引脚拉高。

2.3 步进电机驱动与执行机构

滴速控制执行机构我选了28BYJ-48步进电机，配合ULN2003驱动板。选它的理由很简单：5V供电，减速比1:64，扭矩足够挤压输液管，价格几块钱，资料多到泛滥。

但这里得提醒大家一个实际装机时容易忽略的问题：步进电机不能直接去“捏”输液管，需要设计一个凸轮机构。我用的方案是：步进电机轴上装一个偏心凸轮，凸轮旋转挤压输液管，旋转角度越大，管道压得越紧，流速越小。这样电机的旋转运动就转化成了对管道的线性挤压。

控制上，ULN2003的IN1~IN4接STM32的PB12~PB15，采用四相八拍驱动方式。转速控制不需要很精细，因为输液滴速本身是一个慢变量，电机每秒走几十步就足够了。我在程序里把电机最大速度限制在每分钟120转，防止过快的挤压导致输液管疲劳破损。

2.4 原理图设计的几个关键细节

原理图设计时有几个细节值得单独拎出来说。

电源部分是最容易翻车的地方。整个系统有两个电源域：STM32和传感器用3.3V，步进电机和蜂鸣器用5V。我用了AMS1117-3.3稳压芯片，输入接5V，输出接3.3V。要注意AMS1117的效率不高，输入输出压差越大发热越严重，但这里5V转3.3V只有1.7V压差，电流不超过200mA，完全没问题。滤波电容要靠近芯片引脚放置，我习惯用10uF+100nF组合，一个滤低频纹波，一个滤高频噪声。

复位电路用经典的10K上拉电阻+0.1uF电容到地，NRST引脚接按键。BOOT0和BOOT1分别通过10K电阻下拉到GND，保证从Flash启动。

去耦电容的原则是每个电源引脚旁边放一个100nF，STM32F103C8T6有VDDA、VDD两个电源引脚，都在旁边就近放置。这个细节虽然基础，但很多新手画完板子发现程序跑飞、ADC采不准，去耦电容没放好是很常见的原因。

晶振电路用的是8MHz无源晶振，两个20pF负载电容。这里要注意：8MHz晶振并联一个1MΩ电阻，这是给晶振提供一个直流偏置点，保证起振可靠。很多教程里没画这个电阻，实际做板子时低温环境可能出现起振困难的问题。

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

3.1 滴速检测的三种实现方式对比

软件上第一个要解决的核心问题是：怎么准确算出每分钟多少滴。有三种做法：

方式一：脉冲计数法。在固定时间窗口（比如10秒）内统计红外传感器的脉冲个数，乘以6换算成滴/分钟。优点是实现简单，缺点是实时性差，10秒才更新一次滴速，对于需要快速响应的闭环控制来说太慢。

方式二：周期测量法。用定时器输入捕获测量相邻两个脉冲的上升沿间隔，然后按公式算出滴速。

float calculate_drop_speed(uint32_t time_interval_us) { // 时间间隔单位：微秒 // 滴速 = 60,000,000 / time_interval_us (滴/分钟) if (time_interval_us == 0) return 0; return 60000000.0f / (float)time_interval_us; }

这个公式的逻辑很好理解：如果两滴之间的时间间隔是1000ms（1000000us），那一分钟就是60滴。周期测量法实时性好，每来一个脉冲就更新一次滴速，灵敏度和稳定性都很好。缺点是脉冲间隔本身会有波动，所以需要对测量值做滤波处理。

方式三：两者结合。连续测量3次脉冲间隔，取移动平均值作为当前滴速。既保持了实时性，又抑制了单个脉冲抖动带来的误差。推荐用这个。

我实际代码里用的是方式三，滤波算法用一阶低通滤波，效果很好：

#define FILTER_ALPHA 0.3f float drop_speed_filtered = 0.0f; void update_drop_speed(float latest_speed) { if (drop_speed_filtered == 0.0f) { drop_speed_filtered = latest_speed; } else { // 一阶低通滤波：新值 = 上次值 * (1-alpha) + 当前值 * alpha drop_speed_filtered = drop_speed_filtered * (1.0f - FILTER_ALPHA) + latest_speed * FILTER_ALPHA; } }

alpha取0.3意味着新值占30%权重，历史值占70%，这样既能跟上滴速变化，又不会因为偶尔一次测量异常导致剧烈跳动。

3.2 定时器输入捕获与中断配置

输入捕获是STM32定时器的一个核心功能，原理可以这样理解：定时器内部有一个自由运行的计数器，当引脚上出现设定的边沿跳变时，硬件会把当前计数值自动锁存到捕获寄存器里，同时触发中断。MCU只需要在中断里读取两次捕获值的差，乘以定时器的时钟周期，就能算出边沿间隔。

配置代码我用的是标准外设库，流程很清晰：

void TIM2_InputCapture_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure; TIM_ICInitTypeDef TIM_ICInitStructure; NVIC_InitTypeDef NVIC_InitStructure; // 1. 使能时钟 RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM2, ENABLE); RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); // 2. 配置PA0为浮空输入模式 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_0; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &GPIO_InitStructure); // 3. 配置TIM2时基：72MHz / 72 = 1MHz，计数周期为0xFFFF TIM_TimeBaseStructure.TIM_Period = 0xFFFF; TIM_TimeBaseStructure.TIM_Prescaler = 72 - 1; TIM_TimeBaseStructure.TIM_ClockDivision = 0; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM2, &TIM_TimeBaseStructure); // 4. 配置输入捕获通道：捕获上升沿 TIM_ICInitStructure.TIM_Channel = TIM_Channel_1; TIM_ICInitStructure.TIM_ICPolarity = TIM_ICPolarity_Rising; TIM_ICInitStructure.TIM_ICSelection = TIM_ICSelection_DirectTI; TIM_ICInitStructure.TIM_ICPrescaler = TIM_ICPSC_DIV1; TIM_ICInitStructure.TIM_ICFilter = 0x0F; // 数字滤波器，滤除毛刺 TIM_ICInit(TIM2, &TIM_ICInitStructure); // 5. 配置中断优先级 NVIC_InitStructure.NVIC_IRQChannel = TIM2_IRQn; NVIC_InitStructure.NVIC_IRQChannelPreemptionPriority = 0; NVIC_InitStructure.NVIC_IRQChannelSubPriority = 1; NVIC_InitStructure.NVIC_IRQChannelCmd = ENABLE; NVIC_Init(&NVIC_InitStructure); // 6. 使能捕获中断和定时器 TIM_ITConfig(TIM2, TIM_IT_CC1, ENABLE); TIM_Cmd(TIM2, ENABLE); }

两个容易踩的坑：

第一，TIM_ICFilter参数建议设大一点。这个参数是硬件层面的输入滤波器，能滤掉脉宽小于设定值的毛刺。实测下来设0x0F（约13个采样周期的滤波窗口）效果最好，既不会滤掉真实液滴信号（液滴遮挡时间通常在毫秒级），又能把继电器抖动、电磁干扰产生的高频毛刺挡在门外。

第二，定时器重装载值要够大。如果把Prescaler设为72-1，则计数器时钟为1MHz，每个计数单位是1微秒。但滴速很慢时（比如5滴/分钟），两滴间隔是12秒，即12,000,000微秒，超过了16位定时器最大值65535。所以我用了一个变量记录定时器溢出次数，在中断里拼接出完整的间隔时间：

volatile uint32_t timer_overflow_count = 0; volatile uint32_t last_capture_value = 0; volatile uint32_t last_capture_full = 0; volatile uint32_t current_capture_full = 0; void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_CC1) != RESET) { uint32_t current_capture = TIM_GetCapture1(TIM2); // 用当前捕获值 + 累计溢出次数 * 65536 拼出完整计数值 current_capture_full = current_capture + (timer_overflow_count << 16); last_capture_value = current_capture_full - last_capture_full; last_capture_full = current_capture_full; TIM_ClearITPendingBit(TIM2, TIM_IT_CC1); } }

3.3 PID控制在滴速调节中的应用

滴速控制是整个项目的灵魂。目标很明确：设一个目标滴速（比如40滴/分钟），系统通过步进电机不断调整输液管的挤压程度，让实际滴速稳定在目标值附近。

控制算法选了增量式PID，原因有两个：一是增量式PID计算的是本次控制量和上次控制量的差值，执行器（步进电机）只需要按差值转动，逻辑直观；二是不需要累加误差，不容易出现积分饱和导致的过冲问题。

typedef struct { float target_value; // 目标值 float current_value; // 当前值 float err; // 本次误差 float last_err; // 上次误差 float prev_err; // 上上次误差 float kp; // 比例系数 float ki; // 积分系数 float kd; // 微分系数 float output; // PID输出 } PID_TypeDef; void PID_Calc(PID_TypeDef *pid) { pid->err = pid->target_value - pid->current_value; // 增量式PID公式 float increment = pid->kp * (pid->err - pid->last_err) + pid->ki * pid->err + pid->kd * (pid->err - 2 * pid->last_err + pid->prev_err); pid->output += increment; // 输出限幅 if (pid->output > 100) pid->output = 100; if (pid->output < 0) pid->output = 0; // 更新历史误差 pid->prev_err = pid->last_err; pid->last_err = pid->err; }

参数整定我直接给一组能用的初始值：Kp = 0.5，Ki = 0.05，Kd = 0.1。

这组参数的整定过程可以分享一下：先把Ki和Kd设为0，只保留Kp，从小往大调。调到系统出现等幅振荡时，把Kp降一半作为基准Kp。然后加入Ki，Ki从0开始缓慢增大，观察实际滴速能否收敛到目标值，如果出现明显过冲就减小Ki。最后加入Kd抑制超调。这个流程是经典的Ziegler-Nichols法的简化版，实测从零开始调，半小时内能稳定。

有个细节：PID输出不是直接控制电机转速，而是映射到电机转角。我做了个线性映射：PID输出0~100对应电机转角0~90度。电机初始位置在最小角度（不挤压管道），每次PID计算后，电机增量转动对应角度。这样做的原因是步进电机本身有失步风险，如果让它连续高速转动去“追”滴速，很容易在长时间运行时累积误差。

3.4 多任务调度的裸机实现

有人会问，这个系统功能这么多，是不是必须上FreeRTOS？我的回答是：裸机状态机完全够用，而且更可控。

系统任务可以划分为四类：

1. 滴速检测：由TIM2输入捕获中断驱动，每检测到一个液滴就更新滴速值
2. PID控制：用SysTick定时器产生1ms时基，累计到500ms执行一次PID计算和电机控制
3. OLED刷新：用软件延时控制刷新频率，每秒刷新2次
4. 按键扫描与报警：在主循环里轮询

int main(void) { // 初始化各模块 System_Init(); uint32_t last_pid_time = HAL_GetTick(); uint32_t last_display_time = HAL_GetTick(); while (1) { // 任务1：按键扫描 Key_Scan(); // 任务2：PID控制 if (HAL_GetTick() - last_pid_time > 500) { last_pid_time = HAL_GetTick(); pid.current_value = Get_Current_Speed(); PID_Calc(&pid); Motor_Set_Angle((uint8_t)pid.output); } // 任务3：OLED显示 if (HAL_GetTick() - last_display_time > 1000) { last_display_time = HAL_GetTick(); Display_Update(); } } }

这里用时间片轮转的裸机方式，每个任务在自己的时间片内执行，任务之间通过全局变量传值。这种设计的好处是：单线程执行，不存在资源竞争和锁的问题，对新手极其友好。后期想升级RTOS时，每个任务对应的函数可以平滑迁移成独立任务。

3.5 异常检测与声光报警逻辑

异常检测是医疗项目的安全底线，代码上必须做到快速响应和可靠触发。我设置了三种异常状态：

typedef enum { ALARM_NONE = 0, ALARM_LOW_LIQUID, // 液位过低 ALARM_SPEED_ABNORM, // 滴速异常 ALARM_OVER_SPEED // 滴速过快 } Alarm_State;

判断逻辑如下：

• 液位过低：液位传感器检测到低液位信号，持续500ms确认后触发。用500ms的确认时间是为了防止传感器信号抖动造成误报。
• 滴速异常：当前滴速长时间偏离目标值（偏差超过30%持续10秒以上）。这里的“长时间”很关键，单纯一次偏离可能是患者动了一下手臂导致输液管受压，立即报警反而会制造恐慌。但持续10秒偏离就基本排除偶然因素了。
• 滴速过快：当前滴速超过目标值50%，可能的原因是输液管没有夹紧或者电机失步。这种情况要立即声光报警。

报警动作统一封装成函数：

void Alarm_Trigger(Alarm_State state) { switch (state) { case ALARM_LOW_LIQUID: // 蜂鸣器：连续“滴—滴—”声，每0.5秒一声 for (int i = 0; i < 10; i++) { HAL_GPIO_WritePin(BUZZER_GPIO_Port, BUZZER_Pin, GPIO_PIN_SET); HAL_Delay(100); HAL_GPIO_WritePin(BUZZER_GPIO_Port, BUZZER_Pin, GPIO_PIN_RESET); HAL_Delay(400); } // 指示灯：红色LED常亮 break; case ALARM_SPEED_ABNORM: // 蜂鸣器：每秒一声 break; case ALARM_OVER_SPEED: // 蜂鸣器：急促连响三次 break; } }

4. 仿真环境搭建与联调实践

4.1 Proteus仿真工程的构建要点

硬件做出来需要时间，但代码调试可以先用Proteus虚拟验证。很多人做STM32仿真时卡在第一步：Proteus里添加不了STM32F103C8T6模型。这里必须说明：Proteus 8.6及以上版本才自带STM32F103系列模型，老版本需要手动安装模型库，非常折腾，建议直接装8.15以上版本。

仿真工程搭建步骤：

1. 新建工程，在元件库搜索“STM32F103C8T6”并放置。
2. 添加LED、电阻、蜂鸣器，搭最小系统电路：8MHz晶振（两个20pF电容）、复位电路（10K上拉+0.1uF电容）、电源（VDD接5V，VBAT接5V）。
3. 添加虚拟终端（VIRTUAL TERMINAL），用于查看调试信息。
4. 关键点：Proteus里没有红外对射传感器模型，我用一个信号发生器（SIGNAL GENERATOR）代替，设定产生周期脉冲方波，模拟液滴检测信号。脉冲周期可以根据需要的滴速换算：如果是60滴/分钟，脉冲周期就是1秒；如果是40滴/分钟，周期就是1.5秒。

这个替代方案我在实际调试中觉得非常好用：信号发生器的频率可以随时调整，相当于模拟了不同滴速下的传感器输出，可以很方便地测试PID算法的响应速度。

4.2 Keil工程的配置与烧录流程

代码用Keil MDK5编写。新建工程时有几个配置容易踩坑，这里一次性说明：

1. 芯片选择：在Device选项卡里选择STM32F103C8T6，如果找不到，需要先安装Keil.STM32F1xx_DFP器件支持包。
2. 宏定义：在C/C++选项卡的Define栏里添加USE_STDPERIPH_DRIVER, STM32F10X_MD。USE_STDPERIPH_DRIVER是告诉编译器要调用标准外设库，STM32F10X_MD是告诉固件库当前芯片是中等容量型号，也就是Flash在64K到128K之间。这个宏不写，编译会报一堆函数未定义。
3. 仿真器设置：Keil5的Debug选项卡里选择“Use Simulator”，如果直接用ULINK2调试实物则选“Use ULINK2”，两者需要区分开。仿真联调Proteus时，建议先在Debug选项卡里选择“Use Simulator”，然后用Proteus的“Debug → Remote Debug”功能配合。
4. 烧录方式：最省心的是ST-Link V2，SWD四线接口，SWDIO、SWCLK、GND、3.3V，接好就能烧录。如果没有ST-Link，也可以用串口ISP烧录，但BOOT0要拉高，BOOT1拉低，麻烦一些。

4.3 仿真与实物联调的关键步骤

仿真和实物联调的整体流程是：先在仿真环境里验证逻辑，再在实物上复现，两者结合能省下大量排查硬件问题的时间。

在Proteus里双击STM32芯片，加载Keil编译生成的.hex文件（在Keil工程的Output选项卡里勾选“Create HEX File”才会生成），然后点运行。这时可以看到LED是否按预期闪烁、虚拟终端上是否打印滴速和PID输出。

仿真验证通过后，烧录到实物上。实物调试时我的习惯是先断开步进电机和传感器，用信号发生器直接给MCU输入方波信号。注意这里不是Proteus里的虚拟信号发生器，是真实信号发生器。先把滴速检测这条路调通，确认MCU能算出正确的滴速，再接上传感器验证红外检测，最后接上电机做闭环。逐级验证比全部接好后一起查问题要快得多。

4.4 联调时遇到的三个典型问题

问题一：OLED不显示或者显示乱码。排查要点是I2C地址是否正确。SSD1306驱动的OLED有0x3C和0x3D两种地址，取决于模块上地址电阻的焊接位置。如果你用我代码里的0x3C地址不显示，修改为0x3D再试。

问题二：步进电机不转但程序正常运行。第一步检查ULN2003的IN1~IN4引脚是否对应PB12~PB15，第二步检查电机供电是否独立接了5V电源。ULN2003虽然有续流二极管保护，但如果电机电源和MCU电源共用一个电源模块且功率不够，电机会拉低整个系统电压导致MCU复位。这个问题我在实物调试中遇到过，换成独立5V电源后彻底解决。

问题三：Proteus仿真运行速度极慢。这是因为Proteus仿真STM32需要模拟CPU内核，本身就比普通单片机仿真慢。解决办法：把不需要的显示器、LED指示灯等元件从电路中去掉，只保留必要的最小系统，仿真速度能提升一倍以上。另外，如果使用示波器等虚拟仪器，运行速度会更慢，建议用“图形模式”代替实时示波器。

5. 常见问题与调试经验速查

5.1 滴速检测不准的排查思路

滴速检测是问题重灾区，我把实际发生过的故障和排查路径整理成了一张清单，方便大家参考。

这里有个经验可以分享：判断是传感器问题还是软件问题时，先看比较器输出引脚波形。如果波形已经干净，问题一定在软件；如果波形抖动，先解决硬件整形。用示波器观察，问题定位很快。

5.2 PID效果差：振荡和稳态误差的调法

很多人在PID整定时会遇到两种恼人的情况：一种是滴速在目标值附近来回震荡，怎么也稳定不下来；另一种是最终稳定值离目标值差了一截，怎么都拉不上去。

震荡的本质是增益过高。这时候要做的是降低Kp，同时检查Ki是否过大。我遇到过一种典型情况：Kp=0.8时，滴速在目标值附近±10滴/分钟来回摆，把Kp降到0.4之后，波动缩小到±3滴/分钟，再加一点Kd（0.1），系统就平稳了。

稳态误差的本质是积分作用不足。如果实际滴速和目标值之间一直有固定偏差，优先增大Ki。但Ki也不能一步加太大，我习惯每次增加0.01，等系统稳定后再评估。

还有一种容易被忽视的情况：PID计算周期和滴速更新周期不匹配。如果滴速更新很快但PID每2秒才算一次，控制就会滞后。我最终把PID计算周期定为500ms，和滴速平均更新周期（约1秒）匹配。太频繁会导致电机频繁动作，反而加剧机械磨损。

5.3 实物装机的一些提醒

最后提几条实物装机时容易被忽略的细节：

红外对管安装位置要确保和输液管垂直，左右两侧对正，光路穿过滴管的中央位置。有些输液管是椭圆截面，安装时要让光路穿过最宽的截面，这样液滴遮光最完全。

电机凸轮和输液管的接触面不能有尖锐棱角，否则长时间运行会把输液管磨破。我在凸轮外面缠了两层生料带，增加摩擦力的同时保护管道。电机转速不要设太高，28BYJ-48本身转速就慢，强行拉高速会导致失步。

OLED屏幕的刷新不要在中断里做。OLED的I2C通信有等待时序，如果在中断里调用HAL_I2C_Mem_Write，里面带HAL_Delay，会把中断卡死，导致滴速检测中断丢失。正确做法是主循环里刷新OLED，中断里只更新数据。

5.4 复现项目的完整清单

项目代码、原理图和仿真工程都打包在开源仓库里。复现时需要注意，仓库里的代码是基于标准外设库V3.5版本写的，如果你的Keil是MDK5.36以上版本，第一次打开工程会提示缺少Device Family Pack，按提示在线安装即可。如果你用HAL库更顺手，也可以参考代码里各模块的逻辑自行移植，工作量不大。

原理图用立创EDA绘制，工程文件可以直接导入立创EDA在线版打开。仿真工程用的是Proteus 8.15版本，低版本打开提示高版本兼容性问题，建议统一用8.15及以上。

硬件元件清单我整理成表格放在仓库README里，包括型号、数量、参考价格，照着下单就行。整机BOM成本大约85元，这里面大头是OLED屏（约15元）和步进电机驱动模块（约10元），其余都是几毛几块的器件。

6. 写在最后的一点体会

这套系统我从立项到完整跑通，前后花了大概两周时间。回头看，最花时间的不是写代码，而是调试红外信号的整形阈值——光这个环节就占了三天。中间也想过放弃，换成纯软件滤波方案，但最终发现硬件整形一步到位才是最省事的，舍得在信号链路上花钱花时间，后面软件就轻松很多。

如果你是第一次做医疗电子相关的嵌入式项目，我的建议是：不要贪多，先把滴速检测这一路做扎实，这个环节通了，后面的PID控制、报警逻辑都是顺着水流的。等项目整体跑通了，可以试着在这个基础上扩展物联网远程监护功能——加一个ESP8266模块，把滴速和报警信息通过MQTT协议上传到云平台，就是一个完整的医疗物联网终端了。这个扩展方向的代码框架在仓库的扩展分支里也放了初版，感兴趣可以自行研究。做技术项目就是这样，一步通了，后面就是一路通。