STM32智能输液监护系统：滴速检测与PID闭环控制实战

引言：从“盯滴速”到“管滴速”，一个输液监护系统的升级之路

这个开源项目的标题是“STM32项目开源：智能输液监护调控系统-升级版（代码+原理图+仿真）”。简单说，这就是一套基于STM32单片机的输液监护设备：它能自动检测输液滴速、实时显示数据，在滴速异常或输液结束时报警，并且能通过步进电机自动调节输液管上的滚轮夹，把滴速稳定在医护人员设定的范围内。项目的“升级版”主要体现在两点：一是控制方式从原来的“手动设定+报警提示”升级为“闭环自动调节”，二是硬件设计上加入了更稳定的滴速检测电路和电源管理模块。

这套系统解决的是输液场景里的两个核心痛点：第一，护士不可能每分钟都盯住每一床的滴速，传统滚轮夹调好之后容易受患者手臂位置变化影响，滴速会慢慢漂移；第二，输液结束时如果没有及时处理，回血风险不言而喻。用单片机加上传感器和执行机构，把“监控”和“调控”闭环起来，是非常典型的小型医疗电子项目。

这个项目适合三类人：正在做课程设计或毕业设计的电子、自动化、生物医学工程专业学生；想系统梳理STM32外设（定时器输入捕获、I2C、PWM、ADC）综合应用的嵌入式开发者；以及想做一个带实战意义的完整项目来充实简历的入门工程师。标题里已经说明打包了代码、原理图和仿真文件，所以就算你手上暂时没有实物板子，也能通过Proteus仿真把整套流程跑通。接下来我会把这个项目的设计思路、硬件原理、代码逻辑、仿真方法和调试经验一一拆开讲透。

1. 整体设计思路与方案选型拆解

1.1 项目要解决什么问题

做项目第一步不是打开STM32CubeMX画引脚，而是先把需求边界划清楚。我在设计这套系统时，给自己定了三个必须满足的需求，再往后才谈功能扩展。

第一个需求是“能测准”。输液滴速的正常范围一般是每分钟20到60滴（成人常用静脉输液），儿科和某些特殊药液会更低。所以滴速检测的分辨率至少要精确到“1滴”，而且不能因为外部光线变化、药液颜色差异导致漏检或误检。第二个需求是“能调稳”。手动调节滚轮夹是输液滴速漂移的主要原因，系统必须能根据实时滴速自动调整滚轮的压紧程度，形成一个负反馈闭环。第三个需求是“能报警”。无论是滴速过快、过慢、阻塞还是输液完毕，设备都要在第一时间通过声光提示护士，最好还能通过无线模块把状态上报，方便集中看护。

把这三个需求拆成硬件模块，就对应了传感器采集单元、电机执行单元、报警通信单元和主控处理单元。整套系统的技术栈并不复杂，难的是各模块之间的协作：滴速采样要实时、PID调节要稳定、报警响应要及时、显示界面要清晰，这四个维度同时工作才是“监护”和“调控”这两个关键词的真正含义。

1.2 主控选型与模块分工

单片机我选了STM32F103C8T6，也就是大家常说的“C8T6核心板”，原因很直接：性能足够、资料极多、成本低廉。72MHz的主频在这套系统里完全够用，定时器有输入捕获功能可以精确测滴速，I2C接口接OLED显示屏，ADC采集温度或者信号强度，USART还能接ESP8266之类的WiFi模块。更关键的是，ST官方的标准外设库和HAL库资料非常丰富，网上随便一搜就是大批例子，非常适合作为开源项目的基础平台。

各模块的分工是这样的：主控负责所有逻辑调度，传感器模块负责把物理滴速变成单片机认识的数字信号，执行机构负责调整输液管通径，按键和屏幕负责本地交互，音频报警电路和无线模块负责对外通知。模块之间通过GPIO、I2C、UART、PWM等常规接口互联，没有用到任何冷门协议，这也是我能把全国产元件做开源的重要原因。

1.3 升级版相比基础版“升级”在哪里

很多人在网上能找到“输液监控系统”的老版本设计，那类项目通常只有光电检测加LCD显示，滴速超标了只会响蜂鸣器，至于调节滴速，仍然靠护士手动去拧滚轮夹。这套“升级版”最大的变化就是把“监”和“控”打通了：主控根据实时滴速与目标滴速的误差，通过PID算法计算电机动作量，让步进电机带动一个偏心凸轮机构压迫输液管，相当于把人工调节滚轮夹的动作交给机器自动执行。

另外升级点还包括：加了下位机状态机处理异常逻辑（比如排气前药液空检测、电机堵转保护）、增加了滴速采集的软件滤波和自适应阈值，避免药液颜色变化导致信号质量变差；电源部分从单5V供电改为5V和3.3V双路供电，避免电机大电流拉低单片机电压引起复位。这些升级会让整个系统的可靠性和用户体验明显上一个台阶。

2. 硬件核心细节与原理图解析

2.1 滴速检测模块的设计与信号调理

滴速检测是整个系统的感觉器官，原理不复杂：输液滴壶两侧放一组红外对射传感器，一端是红外发射管，另一端是红外接收三极管。药液滴落时会遮挡红外光，接收管输出的电平就会产生一个脉冲，单片机根据脉冲间隔算出滴速。

原理图里需要注意的点是发射管的驱动方式和接收管的信号调理。我建议红外发射管用PWM方式驱动，频率十几kHz左右，这样可以在保持平均功耗不变的前提下提高瞬间发射光强，抗环境光干扰能力更强。接收管一侧接一个几十kΩ的上拉电阻到3.3V，光路通畅时三极管导通、输出低电平，有液滴遮挡时三极管截止、输出高电平。

上拉电阻的取值要稍微算一下。接收三极管在导通状态下的饱和压降大约0.2V到0.3V，如果外部干扰较大，这个低电平的噪声余量比较小。我实测选用10kΩ上拉配合2kΩ限流，低电平约0.25V，高电平3.3V,逻辑电平判定的余量是足够的。如果上拉电阻取100kΩ，高电平不变，但低电平时三极管输出端的灌电流能力不足，容易在强光干扰下发生误判。

信号处理上，我强烈建议在比较器输入前端加一个RC低通滤波，截止频率设置在几百Hz即可。因为滴速正常最高也就每秒两三滴，脉冲频率几百Hz，RC滤掉的是周围灯光50Hz/100Hz频闪以及高频红外干扰。用运放搭一个滞回比较器，把模拟信号整形成干净的数字方波，再送到STM32的定时器输入捕获引脚。这样比直接接光敏三极管到MCU稳定得多，实测在没有外壳遮光的情况下也能可靠工作。

2.2 步进电机执行机构：为什么选“夹管”而不是“推注射器”

执行机构我选的是28BYJ-48步进电机，配合ULN2003驱动板。药液流速调节用的是偏心凸轮机构：电机旋转带动凸轮改变对输液管的压迫程度，凸轮压得越紧，硅胶管通径越小，滴速越慢。这种“夹管式”方案的好处是执行机构不接触药液，不存在污染风险，而且对现有输液器几乎零改造，直接卡上去就能用，非常契合医院场景。

可能有同学会问：为什么不用微型蠕动泵或者注射器推块？原因有三个：一是蠕动泵成本高，泵体本身也不便宜，作为教学级开源项目不现实；二是注射器推块结构上需要适配特定规格的注射器，通用性差；三是蠕动泵的专利结构不好绕开，自己做出来不仅精度很难保证，还可能牵扯合规问题。夹管凸轮方案结构简单、成本极低、控制线只有四根，性价比是最高的。

驱动电路用ULN2003达林顿管阵列就够了，四个输入端接STM32通用GPIO。28BYJ-48是四相五线电机，步距角5.625°/64，减速比1/64，意味着给驱动板一个完整脉冲序列，输出轴转一圈需要2048个步进脉冲。这套系统的调节不需要很高的角分辨率，每次PID输出的动作量我用“步数”作为单位，一次微调最少走8步，对应凸轮转角大约1.4度，实测对滴速的修正已经非常细了。

电源部分要特别讲一句：28BYJ-48的空载电流大约100mA，堵转或负载时电流能到250mA以上。我实测过如果把电机驱动和单片机共用一个LDO降压，电机一转，主控电压就往下掉，严重时直接复位。所以升级版原理图里我专门把电源拆成两路：一路5V先给ULN2003供电，另一路5V经过AMS1117-3.3给单片机和其他低压器件供电，两个地再到电源入口单点汇接。这样电机引起的电压波动基本传不到MCU侧。

2.3 显示、按键与报警电路的其他硬件细节

显示我用0.96寸I2C接口OLED，四根线（VCC、GND、SCL、SDA）接STM32的PB6和PB7。I2C上拉电阻通常板载已经做了，如果自己画板子，记得在SCL和SDA上分别接4.7kΩ上拉到3.3V，否则通信不稳定。OLED可以显示目标滴速、实际滴速、电机步进位置、系统状态四行信息，没有使用复杂的中文字库，只用了ASCII字库和少量自定义图标，这样固件体积小，刷新速度也快。

按键我用三个：一个是“目标滴速+”按键，一个是“目标滴速-”按键，还有一个是“启停/确认”按键。按键电路采用独立GPIO输入，每个按键并联一个10nF电容做硬件消抖，软件里再加上5次连续采样确认的滤波逻辑。消抖电容值不能太大，否则按键按下时波形上升沿太缓，反而影响判断。

报警部分是无源蜂鸣器加一颗NPN三极管驱动。这里有个经验：无源蜂鸣器需要给一个2kHz到4kHz的方波才会发声，响度跟频率关系很大。我实测发现3kHz左右人耳听起来最刺耳穿透力最强，适合作为医疗报警音。报警逻辑分三种：滴速偏差超过±20%持续3秒触发“偏差报警”，输液滴速为零持续5秒触发“完成/阻塞报警”，电机连续动作超过设定限位触发“执行机构故障报警”。三种报警的蜂鸣器节奏各不相同，护士不用看屏幕也能通过声音区分故障类型。

3. 代码实现与核心控制逻辑

3.1 工程架构与代码组织方式

代码我采用的是“裸机前后台+简易状态机”架构，没有引入FreeRTOS，原因是这套系统的实时性要求并没有高到必须上操作系统的程度，而裸机架构的可读性和可调试性对开源项目而言更友好。代码整体分成四个源文件，各司其职，层次清晰：

• main.c：负责初始化外设、主循环调度、按键扫描和状态机跳转。
• dripspeed.c：滴速采集、滤波、滴速换算。
• motor.c：步进电机驱动、PID控制器、夹管位置管理。
• display.c：OLED显示、菜单界面渲染。
• alarm.c：蜂鸣器控制、报警状态判断。

主循环采用固定时基调度，系统节拍定为1ms，用SysTick中断置一个全局标志位。每1ms扫描一次按键，每10ms刷新一次OLED的低频区域数据，每50ms执行一次滴速更新运算，每200ms执行一次PID计算和电机控制输出。这种分时调度避免了每个任务都频繁抢占CPU，逻辑也更容易排查。

3.2 滴速采集：定时器输入捕获与滤波算法

滴速检测是核心中的核心。我的做法是把光电传感器的输出方波接到STM32的TIM2_CH1（PA0），配置为上升沿输入捕获。每次捕获到上升沿时，读取当前计数值，与上一次捕获值相减，得到两次滴落之间的时间间隔，单位是定时器计数个数。TIM2的预分频值设置为72-1，计数频率正好1MHz，也就是1个计数代表1微秒。滴速的换算公式很简单：

滴速（滴/分）= 60,000,000 × 预分频系数 /（捕获间隔计数 × 定时器时钟频率）

把具体常数代进去，预设分频72-1、时钟72MHz、计数频率1MHz，那滴速 = 60,000,000 / 捕获间隔（微秒），这样算出来就是每分钟滴数。比如两次滴落间隔是1.5秒，即1,500,000微秒，那滴速就是40滴/分，正好在正常输液范围内。

但直接拿相邻两次滴落的间隔算滴速会有个问题：液滴下落不是严格均匀的，而且微小的气泡或振动会带来瞬时干扰。所以我加了一个环形缓冲队列，保存最近10次滴落间隔，每次计算滴速时取中间6个值的平均值。这样处理之后，滴速显示值变得非常平稳，数值波动的幅度从±5滴/分缩小到±1滴/分以内。

为了进一步应对环境光缓慢变化带来的直流漂移，我还在信号进入比较器之前加了一级软件自适应阈值寄存器：每500ms记录一次信号模拟量的基线电平，如果检测到高电平持续时间过长，说明可能有异物遮住了光路或发射管老化，此时提高阈值并触发报警提示“检测信号异常”，防止设备在失效状态下误报正常。

3.3 闭环控制：增量式PID算法与参数整定

滴速控制的执行周期我定在200ms，也就是每200ms计算一次目标滴速与实际滴速的偏差，然后决定步进电机走多少步。控制算法用增量式PID，它的输出是电机步数的增量，而不是绝对值。增量式的好处是一来不会产生积分饱和的麻烦，二来电机每次动作量小，系统不容易振荡。

控制公式是：

Δu(k) = Kp × [e(k) - e(k-1)] + Ki × e(k) + Kd × [e(k) - 2e(k-1) + e(k-2)]

其中e(k)是当前偏差，e(k-1)、e(k-2)是前两次偏差。Δu是本次需要调整的步进量，正数表示电机继续压紧，负数表示电机往回松一点。

PID参数整定我采用的是工程上最常用的试凑法：先把Ki和Kd都设成0，只保留Kp，从很小的值开始往上加，直到系统出现等幅振荡，然后取Kp为临界值的45%到60%。我实测下来，Kp取1.2左右，系统开始出现持续振荡，所以最终Kp取0.6。接着加Ki，Ki的作用是消除静差，我一步步调到0.08时，稳态滴速和目标值之间基本在±1滴/分以内。Kd取0.15，主要目的是在滴速快速变化时抑制超调。

调参过程中有个经验值得分享：不要一开始就把目标滴速设成40滴/分，然后在现实设备上调。先在仿真软件里把PID模型跑通，记录一组稳定的参数，再迁移到实物上。因为仿真环境里没有机械摩擦、没有流体惯性，参数迁移到实物后一定会出现偏差，但至少给了你一个合理的起点。

3.4 状态机设计：正常运行、异常报警与安全保护

为了让系统在复杂工况下不出乱子，我写了一个非常简单的四状态状态机：初始化态、运行态、报警态、待机态。平时系统处于运行态，滴速正常、电机位置在有效范围内；一旦触发报警条件，进入报警态，蜂鸣器按对应节奏响铃，OLED显示故障代码，电机会自动退回安全位置，防止长时间压迫输液管导致药液不滴或管路损坏；护士处理完故障后按确认键，系统回到运行态。

这里有一个安全保护细节要特别提一下：电机每次动作前都会先读取“位置传感器”的值。这个位置传感器其实就是一个霍尔开关加一块贴在凸轮背面的小磁铁，用来判断凸轮是否回到了零位。开机时系统先执行“找零”动作，让电机往松开方向转到触发霍尔信号为止，然后把这个位置设为步进零点。之后每次PID输出都在这个零点的正负范围内计算，一旦计算出越界，说明电机可能已经压死输液管或者凸轮机构出了机械问题，系统直接停机报警。这个设计让整个闭环控制不会出现“越调越紧、最后管子里一滴都不滴”的尴尬局面。

代码里还有个防抖逻辑：报警状态至少持续500ms才判定为有效报警，这样短暂的一两滴检测异常不会触发误报。我实测过用手轻轻碰一下输液管造成的瞬时干扰，持续时间一般不超过100ms，远小于500ms阈值，所以这个设计很有效地削减了误报警率。

4. 仿真验证与实物联调实操记录

4.1 Proteus仿真环境搭建与元件选配

项目附带的仿真文件是用Proteus 8.10及以上版本做的，打开工程后可以看到完整的原理图，包括STM32F103C8T6、Liquid Crystal Display（OLED模型）、虚拟终端、按键、步进电机模型和滴速发生器模拟源。

仿真里最有意思的地方是“滴速发生器”这个虚拟设备：它本质上是一个PWM信号源，输出频率对应滴速（比如30滴/分就设置输出频率为0.5Hz），把这个信号接到STM32的输入捕获引脚，就相当于模拟了一滴一滴落下的红外遮断脉冲。你可以实时改变PWM频率，观察PID控制逻辑是否能驱动“虚拟电机模型”输出正确的调节方向。不过要提醒一下，Proteus自带的电机模拟比较粗糙，不会真实模拟夹管机构的非线性，所以仿真主要验证代码逻辑，而不是执行机构的精确机械特性。

仿真运行起来之后，按一下开发板上的启动按键，OLED（仿真里用虚拟终端或者图形LCD代替）就会显示当前滴速和目标值。把滴速发生器的频率从正常值突然调高到60滴/分，你能在虚拟终端上看到PID输出变负，虚拟电机模型显示“反转松开”，滴速在几秒后重新回落到目标值附近。这就是闭环控制的最直观演示。

4.2 仿真调试中容易踩的坑

我调试仿真时遇到过一个特别坑的问题：仿真能编译能运行，但STM32就是输出不出来，OLED屏上什么都看不到。排查了很久发现是Proteus的STM32模型默认不加载固件，需要在单片机属性里手动指定.hex文件路径。如果你用的是Keil编译，记得在Output选项卡勾选“Create HEX File”，否则没有.hex文件可以加载。

另一个常见的坑是定时器输入捕获引脚没有正确映射。STM32的TIM2_CH1默认在PA0，但如果你在CubeMX里把某个外设重映射到了其他引脚，仿真里还接着PA0，那当然捕获不到信号。建议仿真时先打开虚拟终端打印一下捕获值，如果一直是0，八成是引脚映射或者GPIO复用配置的问题。

还有一个很容易忽略的点：Proteus里的WOKWI等平台对STM32仿真支持并不好，默认库中没有真实的OLED I2C模型，只能用虚拟终端替代。我的做法是写一个调试宏，在编译时把OLED驱动的刷新内容同时输出到UART虚拟终端上，这样即使OLED模型显示不出来，你也能在虚拟终端里看清当前状态值。这套“双输出”调试方法从仿真阶段一直沿用到了实物验证，省了我大量时间。

4.3 实物联调流程与整机测试记录

仿真跑通后，我焊了一套实物并进行了完整的联调。联调流程我建议按“模块分级、先分后合”的方式来：先单独调滴速采集模块，用示波器看传感器输出是否有标准的方波；再单独调电机模块，用简单的开环程序让电机正反转，检查凸轮角度与步进数之间的关系；然后调OLED显示和按键输入；最后再跑整个闭环系统。

整机联调时我先设目标滴速为40滴/分，用标准的医用输液器配合纯净水进行测试。初始状态电机完全不压管，实际滴速大约是65滴/分，PID开始动作后大约4秒左右滴速降到接近40滴/分，最终稳定在39到41滴/分之间，超调量很小。之后我模拟了一个常见场景：用手轻微捏住输液管下游的管路增加阻力，模拟患者弯曲手臂，滴速突降到20滴/分，系统检测到偏差后电机自动松开，大约5秒滴速恢复到了39滴/分左右。这套动作完成得非常自然，说明PID参数和电机步进量匹配得还是比较舒服的。

不过我首次联调也走了一段弯路：一开始我把PID执行周期设得太快了，50ms计算一次，电机的机械响应跟不上这个频率，导致电机反复过冲和振荡，滴速在35到45滴/分之间大幅波动。后来把执行周期延长到200ms，并加入一个最小动作量死区（误差小于1滴/分时不动作），系统才稳定下来。这说明PID控制中“控制频率”和“执行机构响应速度”必须匹配，不是算得越快越好。

5. 常见问题与排查技巧实录

5.1 编译下载与调试工具链问题

很多同学第一次接触STM32项目，卡在的最早一个坑就是编译没问题、下载却报错。我把常见的问题和解决方法整理成了一张速查表，方便大家直接对照排查：

这里专门说一下“no STM32 target found”这个报错。它看起来吓人，但九成情况不是芯片坏了，而是调试器连接问题。常见原因是：目标板被外接5V电源供电，而调试器又通过SWD口给3.3V供电，两边电压不一致导致SWD通信失败。解决办法是先拔掉目标板的独立电源，只保留调试器的供电，让目标板完全由调试器供电后再连接。如果还不行，就把BOOT0引脚拉高，复位一下芯片（上电瞬间芯片进入ISP模式），再用STM32CubeProgrammer把整片Flash擦除，烧写后再把BOOT0拉回低电平。这一步可以解决绝大多数“芯片内部程序干扰调试接口”的问题。

5.2 滴速测量不准、误报警的排查思路

滴速测量是最容易被干扰的环节。如果你的系统显示的滴速值上下乱跳，先不要急着改代码，用示波器看传感器输出波形才是正确姿势。我遇到的几个典型故障和排查经验如下：

一是波形是“毛刺+方波”，主要原因是对射传感器位置没有对准，或者外界红外光干扰严重。对策是给传感器加一个遮光罩，并把发射管驱动方式从常亮改为PWM驱动。

二是波形正常但滴速偶尔跳成双倍值。这是典型的液滴在滴落过程中碎裂成两滴，或者前一滴的余液还没有完全离开检测区、下一滴已经到来，接收管连续输出两次下降沿。对策是在软件里把滴落间隔小于150ms的数据样本丢弃，因为正常输液滴速最快不会超过每秒4滴，对应间隔不可能低于250ms。

三是OLED显示的滴速始终为0。这种时候先检查传感器有没有输出脉冲，再看定时器的CH捕获中断有没有使能，再看捕获值的处理有没有溢出。我遇到过TIM2的ARR设置太小，计数溢出后捕获值全是错的，最后把ARR改为0xFFFF（最大范围）才解决。

四是报警误报频繁。我之前把“滴速偏差”报警阈值设为±10%，实测中患者只要轻轻翻个身，滴速就可能瞬间掉15%，误报非常烦人。后来改成了“偏差达到20%且持续时间超过3秒”才报警，效果好得多。这个经验说明：报警器的设计原则不是“敏感”，而是“稳健”，宁可晚报2秒，也不能频繁误报让护士产生“狼来了”心理。

5.3 电机控制中的隐蔽问题

电机模块有两个隐蔽问题，不实测基本发现不了。第一个是28BYJ-48电机在特定位置的保持力矩特别小，如果凸轮恰好停在一个“死点”上，电机会被输液管内压力顶回去一两步，导致滴速缓慢漂移。解决办法有二：一是让PID的死区稍微放宽一些（比如允许±1滴/分），防止因为微小误差反复调整刺激电机；二是在电机不动作时给四相绕组输出一个“全锁定”电平，让电机真正锁死。这个“锁定电平”不是简单地关闭驱动，而是要让四个输入引脚都保持在高电平或低电平，由驱动板来维持电机磁场。

第二个问题是电机在连续动作几十步之后，会因为步进丢步导致凸轮实际位置与软件记录位置出现偏差。虽然霍尔零位可以解决开机偏差，但运行中累积偏差无法简单消除。我给的方案是每隔15分钟执行一次“回零校准”，也就是让电机快速往松开方向转直到触发霍尔传感器，然后再回到上一次记录的位置。校准过程全部在系统后台自动完成，因为回零只需要不到2秒，对输液监护没有实质影响。这个“软校准”机制让系统连续运行一整天后，滴速仍然能稳定在目标值附近，是我个人非常满意的一个设计。

6. 项目扩展方向与资料使用建议

如果你拿到这套代码和原理图之后，不只是想交个作业，还想把它变成一个拿得出手的作品，有几个扩展方向性价比非常高。

第一个方向是加无线联网。ESP8266或者ESP32模块通过串口与STM32通信，把滴速、报警状态上传到TCP服务器或者MQTT平台，护士站就能集中管理多个床位的数据。这部分难点不在硬件，而在于通信协议设计：一条消息该包含哪些字段、多久发一次、断线重连怎么处理，这些都是很实际的问题。做好的话，这个项目就从单机设备直接升维成物联网应用。

第二个方向是数据记录与回放。现在很多病房管理系统希望能回溯输液过程数据，比如滴速变化曲线、报警事件时间戳。STM32内部Flash空间只有64KB，不够存大量历史数据，可以外挂一个SPI接口的Flash芯片，或者直接通过串口把数据发给上位机存成CSV文件。配合Python写个简单的可视化脚本，你就能画出滴速控制曲线，这对展示项目效果非常加分。

第三个方向是升级传感器方案。红外对射方案成本低但对安装位置要求高，如果想让设备维护更方便，可以试试CCD线性传感器或者光电反射式方案，检测液滴边缘变化。精度更高，成本也更高，适合作为进阶版本。

关于资料使用，我的建议是不要直接拿来就跑，先把原理图和芯片手册对着看一遍，把每个引脚的走向理清楚，再打开代码去对应各个外设的功能模块。开源项目的意义不是让你无脑复制，而是给你一个可以快速上手的参考基准，在这个基础上改造和优化，才是对自己能力最大的锻炼。

最后再分享一个我自己调试这类项目时的小技巧：永远不要一次性把所有模块都调通才去测试，而是先把每个模块单独调好，再逐步集成。每一次集成测试只改动一个变量，出了问题就回退，这样看起来慢，实际上总时间最短。做嵌入式项目，稳，比快重要得多。

这套系统说到底是一个软硬结合的综合练习，它把信号采集、数据处理、闭环控制、人机交互和故障保护串在了一个完整场景里。你在原理图里画下的每一根线、在代码里写下的每一个状态机，都会在实物运行起来的那一刻得到最直观的反馈。希望你在这套开源资料的基础上，做出属于你自己的、更稳定、更智能的输液监护方案。