基于STM32的智能输液监护调控系统设计与仿真实现

1. 项目概述：输液监护系统到底在解决什么问题

做嵌入式这些年，医院场景相关的项目我接触过不少，但像这套智能输液监护调控系统这样“从需求到成品一次打通”的完整方案，确实值得单独拿出来聊聊。它的核心功能说白了就两件事：实时监测输液速度和药液余量，并且根据设定值自动调节输液速度——不是那种实验室里跑个流水灯级别的玩具，而是真正对着临床痛点去设计的整套系统。

先给不熟悉这个领域的朋友拆解一下场景。传统输液靠护士手动调节滚轮，患者输液过程中药液滴速会随着液位下降、静脉压力变化、输液管受压等情况发生漂移，护士需要反复巡房观察。而智能输液监护调控系统要做的就是把这个“人肉闭环”变成“传感器+MCU+执行器”的自动闭环：用红外对射传感器或者重力传感器捕捉滴壶里的液滴信号，STM32 对脉冲计数换算出当前的滴速，再通过步进电机或者蠕动泵挤压输液管调整流速，一旦出现滴速异常、气泡、阻塞或者液位过低，立刻声光报警并通过屏幕展示状态。

这次开源的“升级版”相比基础版多做了几件事：一是增加了多路传感器接入的冗余设计，滴速检测不依赖单一信号源；二是完善了人机交互，OLED 屏幕配合按键就能完成参数设定，不需要上位机介入；三是给出了完整的 Proteus/Wokwi 仿真工程，让没有硬件条件的初学者也能先把逻辑跑通。交付的内容包含可直接编译的 STM32 工程代码、原理图（AD 格式）、仿真文件，以及配套的接线说明和调试指南。

哪些人适合参考这套方案？正在做毕业设计的本科生、想拿医疗电子方向参赛的赛队、或者刚入手 STM32F103C8T6 想找一个“够复杂但又够清晰”综合项目练手的开发者——这套系统在难度梯度上卡得很准。代码层面用标准外设库和 HAL 库双版本都提供了，主控芯片也做了向下兼容设计，换型号不用大改。下面我按实际开发的推进顺序，把硬件设计、代码架构、仿真调试这些环节的要点和踩坑经历逐一写清楚。

2. 系统整体设计与方案选型思路

2.1 为什么主控选 STM32F103C8T6 而不是别的芯片

这个项目在选型阶段其实纠结过好几个方案：51 单片机成本够低但资源太紧张，一个滴速检测加电机控制加显示交互就把定时器占用得七七八八，后续扩展想加个无线模块根本没有富裕的串口和中断引脚；ESP32 性能和无线能力都强，但模拟量的采集精度和上手的门槛跟“医疗场景需要的稳定可控”调性不太匹配；最后还是回到 STM32F103C8T6 这颗经典芯片上。

选择它的理由非常朴素：主频 72MHz 对滴速检测这种毫秒级实时任务绰绰有余；内置 3 个 USART、2 个 SPI、2 个 I2C、多个定时器，传感器、电机驱动、显示模块、报警模块可以同时挂载而不用做引脚复用打架；20KB RAM 和 64KB Flash 放下整个工程加调试信息完全够用。更关键的一点是它的资料生态太成熟了——Keil 环境配置、固件库模板搭建、Bootloader 下载这些问题在中文社区里已经被聊烂了，初学者遇到编译报错随便一搜就能找到完整解决方案，这对一个开源项目来说是最重要的“可复现性”保障。

如果手头只有 C8T6 最小系统板，可以直接沿用这套设计；如果换成 STM32F103RCT6 或者 STM32F407，引脚兼容性需要重新核对，但代码层面的逻辑几乎可以无缝迁移。这是这套方案在选型上比较划算的地方。

2.2 系统架构：感知层、控制层、执行层怎么分工

整个系统的功能模块可以分成三层来理解，这样后续写代码也好、排查问题也好，思路都会清晰很多。

感知层负责收集输液过程中的关键状态信号，主要包括三路输入：滴速传感器（红外对射式，检测滴壶内液滴下落）、液位传感器（放在输液管末端或者滴壶上限位置，判断药液是否快输完）、阻塞/气泡检测（通过压力传感器或者第二路红外对射配合判断）。感知层的信号统一经过整形电路处理后送进 STM32 的 GPIO/定时器输入引脚。

控制层是 STM32 本身，它承担的核心任务是：对滴速传感器的脉冲信号进行定时计数换算成实际滴速（滴/分钟），与用户设定的目标滴速做 PID 运算，得到控制量；同时对液位、阻塞这类开关量信号做阈值判断，触发对应的报警状态。控制层还负责 OLED 显示刷新和按键输入的解析。

执行层是步进电机驱动的蠕动泵结构。步进电机通过一个偏心凸轮或者挤压结构对输液管产生周期性挤压，挤压频率越高，液体流速越快。PID 运算输出的控制量在这里被映射成电机的转速/步进频率，由此做到闭环调节。

这三层之间的信号通路看着简单，但实际开发中每一层都有各自的坑：感知层的传感器信号抖动会导致计数错误，控制层的 PID 参数整定不好会引发输出振荡，执行层的步进电机低频振动会产生干扰脉冲反过来影响传感器计数。这些我在后文会逐个展开讲。

2.3 升级版在功能上做了哪些实质性增强

既然叫“升级版”，就得说清楚相比基础版多了什么。基础版通常只做到了滴速检测加显示，也就是断断续续的“监护”而没有“调控”。这套升级版在结构上做了三个比较实在的改进。

第一，滴速检测支持双传感器轮询，一路主检测一路校验，当两路计数的偏差超过设定阈值时自动判定为传感器异常并报警，避免因为一滴药液挂壁没被检测到就导致滴速显示误差过大。第二，供电设计做了优化，电机驱动单独从主控电源隔离，避免步进电机启动瞬间的电流跌落把 STM32 拉复位——这个问题在基础版和很多 DIY 项目里非常常见，电机一启动单片机就重启，原理图里如果没有做电源分区设计后期改板特别痛苦。第三，新增了无药液自动停机和短信/云端报警预留接口，医院场景下护士站远程监护是刚需，虽然这次开源没把物联网模块做到主板上，但串口和 IO 引脚都预留了。

3. 硬件设计核心：原理图里那些容易忽视的细节

3.1 主控最小系统与电源电路的坑

整套电路以 STM32F103C8T6 为核心，最小系统包含晶振电路（8MHz 主晶振加 32.768kHz 低速晶振）、复位电路、SWD 下载接口和 3.3V 电源电路。这部分的原理图在网上一搜一大把，但很多初学者照着画还是会遇到问题，主要是三点。

第一，电源的去耦电容不是随便放的。C8T6 的每个 VDD/VSS 引脚旁边都应该就近放一个 100nF 的陶瓷电容，如果布局空间紧张至少也要保证靠近主电源引脚放一个 4.7uF 到 10uF 的钽电容做低频滤波。我在调试过程中遇到过开机偶尔正常偶尔跑飞的情况，最后排查到就是去耦电容离引脚太远、等效串联电感过大导致的电源噪声。

第二，复位电路的上电时序。STM32 的 NRST 引脚通常接一个 100nF 电容到地，没有特殊需求不需要外部复位芯片。但要注意的是，如果你的电源上升时间比较快，这个电容太小会导致上电瞬间复位不完全。实际测试中，0.1uF 在大多数线性稳压器下都没问题，但换到某些 DC-DC 方案时建议加大到 1uF 再实测。

第三，BOOT0 引脚的默认处理。下载调试用 SWD 接口时 BOOT0 必须拉低，这个很多人知道；但 BOOT1 在程序里如果配置成普通 IO 使用，原理图上不用额外处理。需要提醒的是，我见过有人把 BOOT0 直接悬空，结果芯片偶尔进入不了下载模式，报“no stm32 target found”错误。对 STM32 来说，悬空引脚的电位是不确定的，下载口认不到芯片十有八九是这类问题。

3.2 滴速传感器信号调理电路设计

滴速检测是本项目的感知层核心。常用的方案有两种：红外对射式和红外反射式。对射式是把红外发射管和接收管分别放在滴壶两侧，药液滴落时经过光束路径会造成接收管输出电平的短暂变化；反射式则是把发射和接收做在同一侧，利用液滴表面反射信号。

原理图里我采用的是对射式方案加一级 LM393 电压比较器整形。红外接收管（光敏三极管）接收到红外光时导通，输出低电平；没有光时截止，输出高电平。但传感器的原始输出波形并不是理想的方波——液滴下落时边缘还有拖尾和抖动，直接送进 STM32 的定时器计数脚会导致一次液滴被计成多次。所以硬件上必须做比较器整形：把光敏管的输出电压跟一个可调阈值电压比较，输出经过上拉电阻后接到 STM32 的 PA0/PA1 引脚。

比较器参考电压的设定有个经验值。用万用表实测滴壶空载时接收管输出电压大概在 2.8V 左右，液滴经过时跌到 1.2V 左右，所以阈值电压取 2.0V 比较合理。原理图上我用了一个 10K 电位器分压给比较器的反相输入端，方便现场调节。如果省略了这个整形电路直接用 ADC 采样判断，程序也能跑，但实时性和抗干扰能力会差不少，而且 MCU 的 CPU 占用率会明显升高。

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

执行机构这部分，我实测下来有两种可靠的驱动方式。一种是 28BYJ-48 步进电机加 ULN2003 驱动板，便宜、简单、引脚直连，缺点是转速慢、扭矩偏小，对于输液管这种液阻比较大的场景，转速上限可能不够用。另一种是 42 步进电机加 A4988 驱动模块，需要额外提供 12V 电源，但精度和扭矩都够，调节响应也更灵敏。

原理图设计里用的是后一种方案，因为 PID 闭环调节需要执行器有足够的动态响应范围。A4988 驱动模块和 STM32 之间只需要接四个信号：STEP、DIR、ENABLE、以及共地线。STEP 引脚接 STM32 的定时器 PWM 输出或者普通 GPIO 翻转信号，DIR 用来控制转向。注意 STM32 是 3.3V 逻辑电平，A4988 的逻辑输入可以直接兼容，但有些国产 A4988 兼容板的逻辑阈值偏高，实测 3.3V 高电平可能识别不了，稳妥起见可以在信号线上加一级 74HC245 缓冲或者去掉模块上的逻辑电源跳线帽改用 5V 供电。

电源方面，电机驱动电源和主控电源必须独立。12V 电源经过 LM2596 降压到 5V 给 A4988 的逻辑部分供电，另外一路经过 AMS1117-3.3 给 STM32 供电。两块电源地用 0 欧电阻单点连接，避免电机回路上大的地电流串扰进 MCU。

3.4 报警电路与显示模块的选型细节

报警电路用无源蜂鸣器加 S8050 三极管驱动。无源蜂鸣器需要 MCU 输出方波才能发声，好处是可以通过程序控制不同频率组合出不同的报警音。三极管基极串联 1K 电阻，蜂鸣器接在集电极和 5V 之间，发射极直接接地。注意蜂鸣器线圈两端一定要反向并联一个 1N4148 续流二极管，否则三极管关断瞬间的反向电动势很容易把它击穿。

显示模块的选择上，我用的是 0.96 寸 I2C 接口的 OLED（SSD1306 驱动），四根线（VCC、GND、SCL、SDA）接起来就能用，屏幕上可以显示当前滴速、目标滴速、累计滴数、报警状态和菜单设置信息。OLED 在实时性和功耗上都比 LCD1602 合适，而且 I2C 只占两个 IO，剩下的引脚可以留给传感器和电机控制。如果追求更大显示面积，也可以换成 1.3 寸或者 2.4 寸 TFT 屏，但原理图和驱动库都需要对应调整。

4. 代码架构与核心逻辑实现

4.1 工程模板和初始化流程

代码工程我同时提供了标准外设库和 HAL 库两个版本，但底层逻辑是一模一样的。初次接触这个项目的朋友，我建议先用标准外设库版本把流程读懂，再对照 HAL 库版本理解抽象层的封装思路。

系统初始化流程按下面的顺序执行：

1. 时钟初始化：使用外部 8MHz 晶振，通过 PLL 倍频到 72MHz 系统主频，APB1 分频到 36MHz、APB2 到 72MHz。
2. GPIO 初始化：配置滴速传感器输入引脚为浮空输入，按键为上拉输入，电机控制引脚为推挽输出，蜂鸣器引脚为推挽输出。
3. 定时器初始化：TIM2 配置为 1ms 时基中断，用于滴速计数窗口和系统 tick；TIM3 配置为 PWM 输出，用于驱动步进电机的 STEP 信号。
4. I2C 初始化：用于 OLED 屏幕显示。
5. 中断优先级配置：滴速计数中断优先级高于系统 tick 中断，确保在极端情况下不丢脉冲。

初始化完成后进入主循环：读取按键输入判断是否需要进入参数设置菜单；调用显示刷新函数；检查报警状态是否触发；执行 PID 运算并更新电机 PWM 占空比。

4.2 滴速检测算法：定时器外部时钟模式

滴速检测最核心的代码逻辑是“在固定时间窗口内统计脉冲数量”。这里有个性能优化方案：不需要把外部脉冲接到 EXTI 中断引脚然后在中断服务函数里做自增计数——那样会让 CPU 频繁进中断，对 72MHz 主频来说虽然不至于跑不动，但会带来不可控的中断延迟。更优雅的做法是利用定时器的外部时钟模式，把滴速传感器的脉冲信号直接作为 TIM4 的时钟源，硬件自己完成计数，MCU 只需要每秒钟读取一次 CNT 寄存器的值。

配置核心代码如下：

void Drip_Sensor_Init(void) { GPIO_InitTypeDef GPIO_InitStructure; TIM_TimeBaseInitTypeDef TIM_TimeBaseStructure; // 使能TIM4和GPIOA时钟 RCC_APB1PeriphClockCmd(RCC_APB1Periph_TIM4, ENABLE); RCC_APB2PeriphClockCmd(RCC_APB2Periph_GPIOA, ENABLE); // PA3引脚复用为TIM4_CH2 / ETR模式 GPIO_InitStructure.GPIO_Pin = GPIO_Pin_3; GPIO_InitStructure.GPIO_Mode = GPIO_Mode_IN_FLOATING; GPIO_Init(GPIOA, &GPIO_InitStructure); // TIM4使用外部时钟模式1，计数来自TI2 TIM_TimeBaseStructure.TIM_Period = 0xFFFF; TIM_TimeBaseStructure.TIM_Prescaler = 0; TIM_TimeBaseStructure.TIM_ClockDivision = 0; TIM_TimeBaseStructure.TIM_CounterMode = TIM_CounterMode_Up; TIM_TimeBaseInit(TIM4, &TIM_TimeBaseStructure); TIM_ETRClockMode2Config(TIM4, TIM_ExtTRGPSC_OFF, TIM_ExtTRGPolarity_NonInverted, 0); TIM_SelectInputTrigger(TIM4, TIM_TS_TI2FP2); TIM_SelectSlaveMode(TIM4, TIM_SlaveMode_External1); TIM_Cmd(TIM4, ENABLE); }

这里把 PA3 配置成 TIM4 的外部触发输入，TIM4 的计数器值就是滴速传感器的累计脉冲数。在 1 秒定时中断里，读取当前计数器的值减去上一次读取的值，就得到了这一秒内的滴数，乘以 60 就是滴/分钟。这种硬件计数的方案在精度和 CPU 资源消耗上，都远优于普通的中断计数方式。

计算滴速的核心代码在定时器中断里：

uint16_t pulse_count = TIM4->CNT; speed_current = (pulse_count - pulse_last) * 60; // 滴/分钟 pulse_last = pulse_count;

4.3 PID 调控算法：从公式到代码落地

自动调节输液的执行逻辑是本项目“调控”二字的灵魂。我采用的是增量式 PID 算法，相比位置式 PID，增量式只需要输出控制量的变化量，对执行器（步进电机）的冲击更小，而且即使某一次运算出错也只是影响当前一步，不会造成大范围振荡。

PID 的输入是滴速误差 e(t) = 目标滴速 - 当前滴速，输出是步进电机的脉冲频率增量。公式展开：

typedef struct { float kp; float ki; float kd; float error_now; float error_last; float error_prev; float output; } PID_TypeDef; float PID_Control(PID_TypeDef *pid, float target, float current) { float delta_output; pid->error_now = target - current; // 增量式PID delta_output = pid->kp * (pid->error_now - pid->error_last) + pid->ki * pid->error_now + pid->kd * (pid->error_now - 2 * pid->error_last + pid->error_prev); pid->error_prev = pid->error_last; pid->error_last = pid->error_now; pid->output += delta_output; // 输出限幅 if (pid->output > MAX_MOTOR_FREQ) pid->output = MAX_MOTOR_FREQ; if (pid->output < MIN_MOTOR_FREQ) pid->output = MIN_MOTOR_FREQ; return pid->output; }

PID 参数的整定是个反复试探的过程。我最初使用经验值 kp=2.0、ki=0.1、kd=0.5，在仿真和实物上分别调试，结果都出现了不同程度的超调和振荡。步进电机的响应本来就不是线性的，挤管深度和流速之间也不是简单的比例关系，所以纯理论计算参数不可靠，必须配合实际的阶跃响应测试来调整。

一个相对靠谱的整定手法是：先把 ki 和 kd 设为 0，只保留 kp，从小往大调直到系统出现等幅振荡，记录此时的 kp 为临界振荡增益；然后按 Ziegler-Nichols 经验公式整定。不过医疗场景下我更推荐保守一点：把超调量控制在 5% 以内、稳态误差在 ±2 滴/分钟以内就足够了，毕竟输液流速不是需要追求极限响应的场合，稳比快更重要。

4.4 报警与异常处理机制

整个系统的状态机设计也比较关键。我定义了三种异常状态：滴速偏差过大、液位过低、管路阻塞。状态机的核心思想是防抖——传感器信号本身会抖动，如果检测到一次电平变化就立刻报警，那系统会被噪音信号淹没。我在代码里对每个报警条件都加了持续确认计数，连续检测到异常超过 3 次才真正触发报警。

滴速偏差报警的逻辑：目标滴速设为 40 滴/分钟，实际滴速低于 30 或高于 60 持续超过 5 秒，触发报警并启动蜂鸣器，同时屏幕显示对应的异常代码。液位过低报警通过液位传感器实现，当检测到液面低于预设位置时立即声光报警，同时停止电机运转，防止空输液管继续挤压造成患者不适。阻塞报警则通过滴速异常间接判断，如果电机 PWM 输出不断增加但滴速始终为零，基本可以判定管路堵塞或者针头阻塞。

报警触发后蜂鸣器由定时器 PWM 控制，可以通过改变 PWM 频率输出不同风格的警报音，比如持续滴速异常用低频“嘀——嘀——嘀”的间歇音，而液位过低用连续高频“嘀嘀嘀”的急促音，方便护士远距离区分。

5. 仿真环境的搭建与常见踩坑

5.1 Proteus 仿真工程的注意事项

仿真部分我给了两套环境，Proteus 和 Wokwi，方便不同习惯的开发者选择。Proteus 仿真最大的价值是不用硬件就能验证核心逻辑——包括滴速脉冲的输入、OLED 的显示、蜂鸣器的报警响应，以及按键输入的状态机切换。

但 Proteus 仿真 STM32 有几个细节要注意。首先，Proteus 默认不带 STM32F103C8T6 的模型，需要手动添加元件库或者使用 STM32F103R6 替代。能够替代的条件是引脚功能基本一致，对于纯逻辑仿真足够了。其次，Proteus 中的晶振时钟源最好设为 8MHz，否则代码里基于 72MHz 主频的延时函数全部会跑偏。再次，OLED 显示模块在 Proteus 里没有现成的 SSD1306 模型，需要下载第三方库或者用一个虚拟终端替代显示功能，这对验证 I2C 通信逻辑非常有帮助。

5.2 Wokwi 仿真平台的新玩法

Wokwi（wokwi.com）是最近两三年比较流行的在线仿真平台，支持 ESP32、STM32 和树莓派 Pico 等型号，好处是打开浏览器就能用，不需要装本地开发环境。它最大的优势是编辑简单、支持代码一键加载，尤其适合给学员做快速原型演示。

Wokwi 的 STM32 仿真方式是：在代码里包含完整的 STM32 固件，它会在浏览器里建立一个虚拟的芯片模型，外设通过虚拟接线连到对应的引脚本上。滴速传感器的脉冲信号可以用一个函数发生器的组件来模拟，也可以写一个简单的 Arduino 代码片段生成脉冲方波喂给 STM32 的 PA3 脚。

用 Wokwi 做这个项目的调试，我能想到的用途有两个：一是验证滴速计数的逻辑正确性，用不同频率的方波模拟不同滴速，确认显示和报警阈值是否生效；二是跑 PID 算法的软件仿真，输入一个模拟的“被控对象”模型，观察输出曲线是否收敛。Wokwi 的缺点是外设库没有 Proteus 那么丰富，复杂的 OLED 驱动和步进电机模型目前支持有限，所以它更适合代码逻辑验证，不适合做完整的系统级仿真。

5.3 stm32 st-link utility 烧录和常见错误

仿真验证完成后，肯定要往实物上烧录程序。这里遇到的典型问题值得说道说道，因为这几乎是每个新手都会撞上的墙。

最常见的烧录报错是“error: no stm32 target found! if your product embeds debug authentication, please check its configuration”——这句话看着就很吓人，但其实原因多半不复杂。经过我们多次排查，这类错误 90% 是以下三种情况造成的：

1. SWDIO/SWCLK 接线错误或者接触不良。SWD 接口只有 4 根线（SWDIO、SWCLK、GND、3.3V），但不少人图省事不接 GND 或者接了但接触不好，就会导致连接不稳定。
2. BOOT0 引脚被意外拉高。如果 BOOT0 接高电平，芯片上电后进入系统存储器模式，SWD 虽然能连上但无法正常调试运行，也会报 target not found。
3. 板子供电不足。如果目标板由 ST-LINK 的 3.3V 供电，而整个系统外设比较多（OLED、传感器、蜂鸣器）、电流需求超过 300mA，ST-LINK 的供电能力可能不够，导致芯片电压跌落，目标芯片无法正常上电初始化。

遇到目标难连的情况，我的排查顺序是先测 BOOT0 电平，再用万用表确认 3.3V 电压稳定，最后才怀疑 ST-LINK 本身。如果 ST-LINK 是山寨版本，有时候重新拔插或者换个 USB 口也能解决，这是因为 Windows 的 USB 驱动枚举出问题导致 COM 口被占用。

6. 实物调试实录与问题排查技巧

6.1 电机启动导致单片机复位的血泪教训

这是我在系统联调时花时间最多的问题。现象是：单独跑显示和传感器功能一切正常，但只要步进电机一转，OLED 屏幕立刻闪烁、系统自动重启，伴随 ST-LINK 断连。第一反应是程序 bug，看了半天代码也没发现内存溢出或者指针异常。后来用示波器抓 3.3V 电源轨，发现电机启动瞬间电压跌落到了 2.1V——原因找到了，主板电源没有分区设计，电机驱动的大电流直接把主控电源拉垮了。

解决措施说起来简单但当时改板改得痛苦：电机驱动电源和 MCU 电源彻底分开，12V 直接给步进电机驱动板供电，MCU 用一个独立的 5V 输入经过 AMS1117 稳压到 3.3V，两地通过 0 欧电阻单点接地。升级版的原理图已经把这个设计固化了，后来的调试没有再出现过这个问题。

6.2 滴速传感器计数不稳定的排查流程

另一个比较头疼的问题是滴速计数跳变。实际输液时滴速设定 40 滴/分钟，显示却是 38 到 55 之间剧烈跳动，根本无法稳定调节。用示波器看传感器引脚的波形，发现存在大量毛刺，尤其是在步进电机运转的时候，毛刺更加密集。这其实是电磁干扰进入传感器信号的典型表现。

排查和处理分为三步：第一步，传感器信号线改用屏蔽线，屏蔽层单端接地；第二步，在 STM32 的脉冲输入引脚和地之间并联一个 100nF 滤波电容，同时把比较器输出的上拉电阻从 10K 降到 4.7K，提高信号的驱动能力；第三步，在步进电机驱动板的电源入口加一个大容量的电解电容（1000uF/25V），吸收电机启停带来的电流冲击。三轮改动做完，计数误差从 ±15% 缩小到了 ±2 滴/分钟以内，符合医疗场景的精度要求。

6.3 常见问题速查表

6.4 升级版的预留扩展接口说明

做完上述全部功能后，系统还有富余的 IO 引脚和外设资源。我在原理图上预留了两组扩展接口。

一组是 USART1 的串口接口，引出到排针，方便连接蓝牙模块（如 HC-05）或者 WiFi 模块（如 ESP8266），实现无线数据上报。接上 ESP8266 后，可以把滴速、液位、报警状态实时推送到云平台或者手机 MQTT 客户端，这就是物联网化的一步。

另一组是 I2C 总线的级联接口，OLED 屏幕和扩展传感器（比如温度传感器 DS18B20 就不走 I2C，但 BME280 走 I2C）可以挂载在同一条总线上。实际上我后续已经在做一个连续监测患者体温的版本，传感器可以直接并联接入这套系统而不用改硬件。

7. 开源资源的使用方法和总结心得

代码仓库里包含以下目录结构：

• Firmware_StdPeriph：标准外设库版本完整工程，Keil5 直接打开编译
• Firmware_HAL：HAL 库版本完整工程，适用于 STM32CubeMX 用户
• Hardware/ Schematic：AD 格式原理图源文件
• Hardware/ PCB：PCB 布局文件（配套改版）
• Simulation/ Proteus：Proteus 仿真工程
• Simulation/ Wokwi：Wokwi 在线仿真配置和代码
• Docs：接线图、物料清单、调试说明

拿到工程后的推荐阅读顺序是：先看 Docs 里的接线图理清硬件连接，然后打开 Proteus 仿真把代码跑通，确认逻辑无误后再照着原理图焊板（或者直接用开发板飞线搭一个验证环境）。硬件板子焊接调试时，从简到繁分段验证：先单独验证最小系统和下载器，再逐模块焊接和测试。

用这套方案做毕设或比赛的话，有几个可以深挖的扩展点供参考。第一个方向是加入称重模块（HX711 加压力传感器），通过实时监测输液瓶重量变化来计算累计输液量和剩余时间，和滴速检测互为冗余，提高系统的容错能力。第二个方向是加入 NB-IoT 模块，实现低功耗广域通信，护士站大屏实时显示整个病区的输液状态。第三个方向是增加语音播报模块（SYN6288 或者语音合成 IC），输液完成时语音播报床号和异常信息，对于护士忙碌的场景更加实用。

编程和调试这套智能输液监护调控系统的过程，最大的经验收获不是某个具体的驱动代码，而是理解了嵌入式的“实时闭环”思维——先用传感器把物理量变成数字信号，再用算法做决策，最后通过执行器改变物理系统本身，而这个改变又会反过来影响传感器读数，形成一个完整的反馈回路。这种闭环思路放到智能家居、工业控制、机器人运动控制里都是相通的。项目里每一步的“为什么这么设计”，背后都有实打实调试踩坑的经验在支撑，原理图里每一个去耦电容、代码里每一段防抖逻辑，都很值得反复品味。