1. 这个开源项目到底解决的是什么问题先从一个病房里的真实场景说起。输液是一件看起来简单、实际上极度消耗护士精力的事情。一个护士管五六个床位每过几分钟就要抬头看一眼输液瓶还剩多少、滴速有没有变慢、针头有没有回血堵塞。到了夜间患者家属也得轮流盯着生怕液体输完没及时发现导致回血凝固甚至空气进入血管。我在医院陪床时观察过这个场景当时就在想这种事情明明可以交给单片机来做。红外对射传感器数滴速压力传感器称重量液面低于阈值就报警甚至直接控制蠕动泵把速度稳住——硬件成本不到几十块钱逻辑也不复杂为什么市面上那么多所谓“智能输液系统”都是大几万块的独立终端因为医疗设备要走注册、过认证、做可靠性测试成本下不来。但作为工程项目、毕业设计、或者病房监护的辅助原型做一个开源版的智能输液点滴系统是完全可行且非常有价值的。这个STM32智能医疗输液点滴系统的核心价值就是一套从传感器选型到上位机联调的完整参考实现。它不是只给你一段代码然后让你自己猜硬件怎么接而是把代码、原理图、仿真工程全部打包装好。你拿来改一改就能变成自己的项目你从头造轮子它就是你最好的参考坐标系。说人话这个东西适合三类人。第一类是嵌入式相关专业的学生拿它当课设、毕设的框架比从零开始啃手册高效太多第二类是正在做医疗电子、监护设备预研的工程师可以参考它的传感器信号调理和低功耗策略第三类是自己想动手做一套家用输液监护原型的创客硬件成本可控焊接难度也不大。后面我会把这个项目从系统框架到核心代码从仿真到避坑完整拆一遍。特别是那些在项目文档里不会写、但实际调试时一定会踩的坑我会把排查思路和修正方法一并讲清楚。2. 从医院需求到硬件方案这套系统的架构取舍很多人拿到这种开源项目第一反应是看代码、看原理图但我建议先别急。你先搞清楚它为什么这么设计后面调bug的时候才会知道去哪里查。2.1 系统最上层到底要干几件事智能输液系统不管怎么变落到功能上都逃不开四件事测得到、算得准、控得住、报得出。“测得到”靠传感器把物理量变成电信号。当前主流方案有两种——红外对射管检测滴壶里的液滴下落或者用压力传感器秤整瓶液体的重量变化。“算得准”指的是把传感器输出的脉冲信号转换成滴速再换算成每小时输液量。“控得住”通常用蠕动泵或者电磁夹管阀调节管路开度形成闭环。“报得出”包括本地声光报警、屏幕显示以及通过无线模块把数据送到护士站或者手机App。这个开源项目的硬件架构基本就是围绕这四条线展开的。2.2 为什么主控选STM32F103C8T6而不是更“高级”的芯片先说主控。项目用的是STM32F103C8T6也就是大家常说的“蓝丸”核心板标配芯片。这颗芯片用过的人都知道72MHz主频、64KB Flash、20KB RAM资源不大但足够。有一个问题是很多人会问的既然要做医疗相关的项目为什么不用STM32F407甚至H7系列我的理解是这个项目的定位是原理验证和教学参考不是量产医疗设备。F103的TIM定时器输入捕获、外部中断、ADC采集、USART通信这些外设应付滴速检测和液位监控绰绰有余。更关键的是F103的资料密度极高你随便搜一个问题都有答案这对新手来说比多出来的性能重要得多。另外从成本角度讲C8T6的核心板零售价也就十来块钱配合一个OLED屏、一个红外对射模块、一个蜂鸣器、一个继电器或者电机驱动模块整套硬件的BOM成本可以控制在50元以内。这一点对做课设和DIY的朋友非常友好。2.3 滴速检测红外对射方案为什么是首选输液滴速检测是整个系统的感知核心。目前市面上成熟的做法几乎都是红外对射——一个红外发射管和一个接收管分别放在滴壶两侧液滴下落经过光路时红外光被遮挡接收管输出电平发生变化单片机通过检测这个变化的边沿来计数。这个方案最大的好处是非接触、无污染、响应快。液滴不接触传感器不会交叉感染液滴下落速度很快红外对射的响应时间是微秒级的完全跟得上。相比之下重量传感器方案虽然也能测但它受输液管摆动、患者手臂移动的影响很大需要做复杂的滤波处理响应还慢。有一个细节需要注意红外对射管不能裸露着用环境光里的红外成分会严重干扰接收管。项目原理图里应该在接收管前面加了一小块遮光结构实际做的时候可以用热缩管或者黑色胶带把对射管包起来只留光路方向。2.4 流速控制从开环到闭环的简单路径如果只是检测滴速然后报警这只能叫“监护系统”还不够“智能”。这个项目既然叫智能输液系统就一定包含了流速闭环控制。执行机构最常见的两种选择电磁夹管阀和蠕动泵。电磁夹管阀的优点是便宜、结构简单通电夹紧断电松开但它只能做通断控制做不到连续调节。蠕动泵则通过步进电机挤压硅胶管转速和流量基本成正比适合做精确控制。项目里用的方案我不太确定是哪种但从通用性和可复现性考虑我建议优先选蠕动泵加步进电机。计算逻辑是电机转速乘以每转排量等于流量再结合滴壶液滴体积估算通常1mL约等于15到20滴就能算出目标转速。这个映射关系后面我会详细讲先记住一个大方向。2.5 无线通信给数据找个“出口”本地显示只是基础真正意义上的智能输液系统需要把数据送出去。这个开源项目如果只是用串口线连电脑那仿真和调试都方便但做成实物后就有局限性。建议的升级路径有两种。预算充足的直接上ESP8266用串口AT指令把滴速数据通过Wi-Fi发到局域网写个简单的上位机或者对接巴法云这类IoT平台手机就能看。预算紧张或者室内场景固定的用蓝牙串口模块HC-05/HC-06也行手机装个串口助手就能直接收数据。这里有一个设计层面的权衡项目原始版本如果包含无线模块功耗和代码复杂度会上去如果只是本地控制那整个项目会清爽很多。我个人的倾向是先用有线串口把核心逻辑跑通再考虑加无线——先做减法再做加法这是嵌入式项目的通用节奏。3. 原理图剖析每个模块背后的设计理由原理图是硬件项目的地图。我拿到一套开源原理图习惯是先看电源树再看传感器接口最后看执行机构和通信接口。下面按这个顺序拆一遍。3.1 电源树设计模拟部分和数字部分的“隔离”意识STM32F103C8T6需要3.3V供电外部传感器模块通常是5V或者3.3V蠕动泵或者继电器需要5V甚至12V。所以这个系统的电源拓扑大概率是外部USB或者DC头输入5V一路直接给5V外设另一路通过AMS1117-3.3稳压给MCU和传感器。有一个常见的坑AMS1117的最大输入电压是12V但如果直接用12V供电它的压差太大发热会比较明显。更稳的做法是输入9V以下或者直接用5V让1117只承担5V到3.3V的压降发热量就很小了。原理图上如果用了AMS1117就建议在实际供电时保持输入不超过5.5V。如果项目里还涉及到称重传感器应变片式那就需要关注模拟电源的纹波。称重传感器的毫伏级差分信号对电源噪声非常敏感最好在AVCC和DVCC之间加一个10μH磁珠或者10Ω电阻做隔离。这是很多抄原理图容易忽略但实际影响很大的细节。3.2 红外对射传感器接口上拉电阻和施密特整形红外对射模块的接口设计是整个模拟前端的核心。多数红外对射模块输出的是开漏或者集电极开路信号必须在输出端接上拉电阻到VCC。原理图里如果直接连着MCU的GPIO通常是因为模块内部已经集成上拉了。真正考验原理图设计水平的是信号整形部分。液滴边缘经过光路时接收管输出不是一个干净的方波而是缓慢变化的模拟信号如果直接送MCU的GPIO做边沿检测很容易因为信号抖动产生多次触发。成熟的方案是在比较器或者整形电路后面加一个施密特触发器或者直接用带施密特触发的GPIO输入模式。STM32的GPIO输入确实有施密特触发特性但触发阈值是固定不可调的。如果现场调试时发现滴速计数倍率飘忽不定一下显示180滴/分一下显示320滴/分大概率就是信号没有整形干净需要在传感器输出和MCU之间加一级LM393比较器参考电压调到传感器静态输出电压和中值附近。这部分在原理图上不一定能直接看到但如果你自己改版这是必须补上的一环。3.3 电机驱动部分续流二极管和隔离是底线控制蠕动泵的步进电机或者直流电机不能直接接MCU引脚。常见做法是ULN2003达林顿管阵列驱动步进电机或者用L298N/L9110S驱动直流电机。原理图设计时最容易漏的是电机两端的续流二极管。电机是感性负载断电瞬间会产生反向电动势如果不加续流二极管反向高压直接打到驱动芯片或者MCU上轻则复位重则烧片子。ULN2003内部自带续流二极管所以用它的方案相对安全如果用L9110S这类芯片要确认数据手册里是否已经集成了续流保护。另外电机驱动部分的电源地GND和MCU的数字地DGND最好单点连接避免电机启停时的大电流在地线上产生压降干扰MCU。原理图上如果只有一个统一地网络实际打板时也要在布局上让电机回路远离MCU和传感器。3.4 报警和显示GPIO复用要提前规划蜂鸣器建议用有源蜂鸣器一个GPIO置高就能响省掉PWM驱动代码。OLED屏用I2C接口只占SCL和SDA两个引脚。这里要特别提醒I2C的SDA和SCL在F103的PB6和PB7上如果你同时要用I2C接其他传感器得提前规划好地址避免冲突。还有一个非常隐蔽的坑很多I2C OLED模块的地址默认是0x78但有些厂家用的是0x7A。如果屏幕不亮先别怀疑代码用I2C扫描程序跑一遍确认实际地址再说。这个排错经验在调试阶段能帮你省半小时以上。4. 核心代码逻辑拆解滴速计算、闭环控制、状态机设计代码部分我按功能模块拆开讲。不是逐行贴代码而是讲清楚每个模块的“逻辑骨架”和“关键参数怎么来”这样你拿到代码后能改得动、调得通。4.1 滴速计算的原理和实现要点先明确一个概念滴速的单位是“滴/分钟”drops per minute简称DPM。测量的核心思路是两次下降沿之间的时间间隔就是一滴的时间然后换算成每分钟滴数。滴速DPM 60000 / 两次下降沿间隔时间(ms)假如两次下降沿间隔是500ms那滴速就是120DPM。假如间隔是400ms滴速就是150DPM。这个换算本身不复杂但实际实现时有两个细节很容易被忽略。第一个细节是过滤抖动。液滴经过红外光路时如果信号没有做施密特整形一个液滴可能触发两次甚至三次下降沿导致计算的DPM值忽大忽小。软件层面的缓解办法是记录下降沿时间戳后先判断与前一个下降沿的间隔是否小于某个阈值比如50ms小于则认为是同一次液滴的重复触发忽略掉。第二个细节是平均窗口。单次间隔计算的滴速跳动很大尤其是输液刚开始时液滴速度不稳定。更稳的做法是连续记录最近3到5滴的时间戳用平均间隔计算滴速。平均窗口太短则不够平滑太长则反应迟钝。经过实测取4滴平均每滴更新一次是响应速度和稳定性的较好折中。平均间隔 (第n滴时间戳 - 第n-4滴时间戳) / 4 滴速DPM 60000 / 平均间隔这里顺带说明一个输液领域的基础换算成人输液常用的滴速范围是40到60DPM儿童一般是20到40DPM。滴壶里的液滴体积大约为0.05mL/滴即1mL约等于20滴。但不同品牌输液器的滴系数会略有差异常见的有15滴/mL、20滴/mL两种规格。项目里如果要做“滴速转每小时输液量”的换算需要把这个滴系数做成可配置参数不要写死。4.2 滴定闭环控制从比例控制到PID的升维流量控制是这个项目里最有“智能感”的部分也是代码里最值得研究的地方。最简单的控制方式是阈值开关滴速低于下限就提速高于上限就减速中间不动。这个逻辑实现简单但有个致命问题——电机调节存在惯性容易出现震荡速度低了加大转速转速上去后液体流速增加滴速又偏高于是再降速反复波动。更平滑的做法是增量式PID控制。控制量是步进电机的转速被控量是实时滴速目标值是设定的滴速。我建议新手先跑一遍纯P控制试试效果比例系数从小往大调观察滴速响应曲线的超调量。如果超调太大再加一点微分项抑制。积分项用在电机控制上要小心积分饱和会导致系统反应迟钝需要做限幅处理。另外有一个医疗场景的特殊性蠕动泵挤压输液管时管的形变和回弹会导致流量非线性。也就是说电机转速和滴速之间不是严格的线性关系在低转速段尤其明显。解决办法是在PID输出端加一个静态补偿表——前期先花十几分钟标定不同PWM占空比下的实际滴速做一个线性插值补偿表把死区和饱和区尽量修正。这一步做完闭环控制的体验会有一个质的提升。4.3 整个系统的主状态机这个系统的代码组织建议按状态机来写而不是一坨while循环里堆逻辑。核心状态可以这样划分待机态IDLE系统上电自检显示当前温度湿度之类的环境信息等待启动指令。运行态RUNNING红外传感器持续采集滴速PID闭环控制电机转速OLED刷新实时数据。报警态ALARM滴速超限、液位过低、或者检测不到液滴超过一定时间触发蜂鸣器和远程报警。暂停态PAUSE人为暂停输液电机停止但传感器保持监测防止意外。状态机的转移条件要写清楚。比如从运行态转到报警态不仅包括滴速超过上下限还包括“120秒内没有检测到新液滴”这种失联判断。后者在实际场景中对应的是针头堵塞、输液管打折或者液体已经输完。这个超时值不能设太短因为换瓶或者患者换姿势时短暂无滴是正常的。4.4 余量估算算法用重量和时间做双保险除了检测滴速和液位这个系统如果增加了称重传感器还能实现一个很实用的功能——剩余液体量和预计输完时间。用重量传感器计算的基础公式是已输液体量 (初始总重量 - 当前重量) / 液体密度 剩余液体量 初始液体量 - 已输液体量 预计剩余时间 剩余液体量 / (滴速DPM / 滴系数)这个算法在代码里实现起来非常容易但有一个重量传感器绕不开的问题漂移。应变片称重传感器的零点会随温度和机械应力缓慢漂移所以代码里要做周期性的零点校准。建议在输液开始前泵蠕动之前记录一次皮重输液过程中每5分钟自动校正一次零点前提是输液瓶没有被人为触碰。如果项目没有称重传感器那也可以用“滴速积分法”估算剩余量每次检测到一滴就把累计滴数加1再用累计滴数除以滴系数就得累计体积。这个方式误差比较大因为滴速本身在变化且滴系数并不恒定但做个大致提示够用了。4.5 一个关键的实时性问题滴速测量的时间戳精度滴速计算依托中断里记录时间戳。这里特别提醒一下不要在中断回调函数里做浮点运算和OLED刷新。浮点除法和I2C刷屏耗时长会干扰下一次中断的及时响应导致时间戳记录不准。正确做法是中断里只记录滴落发生的计数值和时间戳然后置一个标志位在主循环的某个固定周期去计算滴速和更新显示。如果用了RTOS可以用消息队列把滴落事件发给处理任务。如果裸机就一个全局结构体加标志位就行。这个设计虽然简单但直接决定了滴速测量是否准确是我写嵌入式代码多年最看重的习惯之一。5. 仿真工程Proteus能帮你验证到什么程度开源资料里包含仿真工程这是很多人下载这个项目的主要原因。毕竟不是每个人都有现成的硬件和传感器先跑仿真理解逻辑再动手焊板子是一条很稳妥的学习路径。5.1 Proteus仿真的正确打开方式这个项目的仿真大概率是在Proteus 8.x以上版本完成的。打开仿真文件先做两件事第一确认单片机型号被正确加载为STM32F103C8T6第二检查固件路径是否指向工程编译生成的hex文件。这里有一个Proteus仿真STM32的经典问题Proteus默认不带STM32的外设库需要安装扩展包。如果你打开仿真文件后发现MCU是空白的或者提示找不到器件多半就是扩展包版本不对。另外Proteus对STM32的仿真支持远不如对51和AVR成熟GPIO翻转、外部中断这些基本功能仿真没问题但ADC的采样速率、定时器的捕获分辨率这些“硬实时”特性跟真实芯片差别不小。所以我的建议是仿真用于验证逻辑流程不要用于验证时序精度。仿真里PID控制能收敛只能证明控制算法代码逻辑上没有死循环、没有数组越界但真实红外对射传感器输出的信号长什么样、驱动电机时会不会干扰MCU这些必须上硬件才能知道。5.2 仿真工程里能学到什么如果设计者把仿真做得比较细你会在Proteus里看到几样东西值得仔细研究虚拟示波器上的滴速脉冲波形、OLED虚拟显示器的数据刷新、按键调整目标滴速时电机转速的跟随变化。我建议你在仿真工程里做一个实验把“滴速测量周期”从单滴改成多滴平均观察速度显示的稳定度和对阶跃变化的响应速度。这个实验在硬件上做要改代码烧录但在仿真里就是改几个参数的事对理解滤波器的时间常数概念非常有帮助。6. 从开店到调试复现项目时的完整步骤和避坑指南拿到开源资料后从零复现一个硬件项目的完整流程我按步骤梳理一遍。这个流程适用于绝大多数嵌入式小项目但具体的坑是围绕这个输液系统展开的。6.1 环境搭建Keil MDK和标准外设库STM32的开源项目里代码风格基本分为两类标准外设库和HAL库。这个项目如果时间比较早大概率是标准库如果是近两年的项目可能是HAL库。我个人建议如果代码基于标准库而你手头又是F103系列那直接用标准库就好代码更直观中断响应更快。如果你计划把代码移植到F4或者G0系列那HAL库更合适因为硬件抽象层帮你做了大量跨芯片适配。编译环境用Keil MDK 5即可。这里有一个非常常见的坑编译器版本不同导致语法错误。老项目可能是用AC5编译器写的新的Keil MDK默认是AC6两者对C语言的语法检查严格程度不一样AC6会更严格可能导致旧代码编译报错。解决办法是在Keil的Options for Target - Target页签下把ARM Compiler切换成AC5或者手动修复报错代码。烧录工具推荐ST-Link V2便宜好用兼容性也最好。如果你电脑是Win10以上系统需要安装ST-Link驱动。插上ST-Link后如果设备管理器里出现感叹号多半是驱动签名问题用驱动精灵或者去官网下最新驱动一般都能解决。6.2 硬件连接检查清单在烧录之前先对照原理图把硬件连接检查一遍。重点检查以下几条线红外对射模块的VCC和GND是否接反输出是否接到了正确的GPIOOLED的I2C引脚是否接对SDA-PB7SCL-PB6注意主板丝印上SDA和SCL的位置偶尔会标反电机驱动模块的IN1/IN2/ENA是否对应代码里的GPIO配置蜂鸣器是否通过三极管或者ULN2003驱动绝对不能直接接GPIO5V和3.3V的电压是否正常地线是否共地新手最容易犯的错误是传感器模块和MCU之间没共地。如果红外模块用5V供电、MCU用3.3V供电两个电源的地必须连在一起否则电平参考点不一致信号乱跳。6.3 上电调试的三段式排查法上电调试建议按“电源 - 最小系统 - 外设”三个层次来排查千万不能一上来就怀疑算法。第一步确认MCU能跑起来。用LED闪烁程序先验证GPIO输出和时钟配置。如果LED不亮先从电源和复位电路查起。第二步验证传感器信号链路。把红外对射模块拿在手里用手指在发射管和接收管之间快速划过串口打印GPIO的电平变化。如果串口有数据跳动说明信号链路通了。第三步验证执行机构。单独写一个测试程序让电机动一下、停一下听声音是否正常看转速是否有明显变化。如果电机没反应先查驱动芯片的供电和使能引脚再查代码里的PWM配置。6.4 经典故障现场红外传感器“乱跳”的排查链路我把这个项目里最经典、最高频的一个故障现场完整还原出来你照着这个链路排查即可。故障现象滴速数值在0和350之间反复横跳完全不合理。OLED上显示的滴速像抽风一样。第一步排查观察传感器的原始信号。注释掉滴速计算逻辑把GPIO电平直接通过串口输出波特率调到115200。发现下降沿非常密集而且间隔不均。第二步排查怀疑传感器灵敏度太高。红外对射模块上如果有个电位器往低灵敏度方向调一点让它在没有液滴时保持稳定输出高电平有液滴时干净地拉低。调整后串口数据有所改善但依然有少量毛刺。第三步排查在代码里加入抖动过滤——两次下降沿间隔小于80ms的直接忽略。加完过滤后滴速显示稳定在了60到65DPM之间问题解决。这个排查链路我想强调的是软件过滤不能替代硬件整形但可以兜底。如果你改完硬件有条件加一级LM393施密特整形电路效果会比只靠软件扛好得多。6.5 烧录时报“no stm32 target found”怎么处理“error: no stm32 target found”是STM32开发最经典的报错几乎每个用ST-Link的人都会遇到。遇到这个报错不要慌按顺序排查ST-Link和板子之间的SWDIO、SWCLK、GND三根线必须接好接线柱松了是最常见的原因目标板必须有独立供电ST-Link的3.3V输出电流很小带不动整板检查BOOT0引脚是否接地。如果BOOT0拉高芯片会进入系统存储器模式不执行Flash里的程序也连不上调试接口如果以上都正常按住板子上的复位键不放点击烧录等进度条出现后再松开复位键有时候能救回来微库和宏定义配置在Keil里如果用了printf重定向到串口需要勾选MicroLib否则会报__stdout相关的链接错误。如果是HAL库还需要在魔法棒里添加USE_HAL_DRIVER和STM32F103xB这两个宏定义。6.6 滴速检测不准的排查清单滴速显示稳定了但和实际人工数的不一致这个问题也很多人遇到。我整理一个速查表方便你对照排查。现象可能原因排查方法显示滴速是实际值的两倍一个液滴触发两次下降沿信号抖动检查传感器模块是否装了遮光结构加大软件抖动过滤阈值显示滴速是实际值的一半光线被异物遮挡或液滴经过光路时间过长调整对射管位置检查滴壶里是否有水雾附着增强抗干扰处理显示滴速偶发跳零液滴间隔时间超过统计窗口被判定为无滴区分“无滴状态”和“正常但不滴”调整超时判断逻辑滴速显示滞后严重平均窗口设置太长缩短平均窗口或者改成滑动平均算法结论滴速检测误差第一来源永远是传感器安装位置。对射管必须正对滴壶中间的液体下落通道而且滴壶要垂直于地面不能歪。很多“代码没问题但数据不对”的案例最后查到底都是机械安装的问题。7. 资料包里到底有什么开源内容的完整盘点很多朋友下载开源资料后面对一堆文件夹和文件有点懵。我根据这个项目的常见组织方式帮你梳理一下典型的结构。项目根目录/ ├── Code/ # STM32工程源码 │ ├── User/ # 主函数、中断、状态机等核心代码 │ ├── Hardware/ # 各外设驱动红外对射、OLED、电机、蜂鸣器等 │ ├── SYSTEM/ # 延时、串口、GPIO等基础封装 │ └── Project/ # Keil工程文件打开即用 ├── Hardware/ │ ├── 原理图.pdf # 原理图PDF版本方便查看 │ └── 原理图工程 # 如果包含立创EDA或Altium工程源文件 ├── Simulation/ # Proteus仿真工程 │ └── 输液系统.pdsprj # Proteus工程文件 ├── 说明文档.md # 项目说明和使用指南 └── README.txt # 快速上手说明拿到手以后我强烈建议你先打开README或者说明文档把这几件事确认清楚烧录的芯片型号是不是F103C8T6、OLED的I2C地址是多少、电机驱动用的哪个GPIO、仿真工程需要Proteus哪个版本。这些信息如果文档里没写全就去源码的main函数和头文件里翻一定找得到。如果你打算在这个项目基础上二次开发我建议你把代码按模块拆开读。先读主函数掌握整体流程再读中断处理函数了解滴速采集最后读电机控制部分理解闭环逻辑。这三个文件读完整个项目的骨架就清晰了。8. 这个项目还能怎么改三条升级路径开源项目最大的价值是当跳板。基于这套系统至少有三条比较有价值的升级路径。8.1 升级一LORA远程监护组网单台设备只能解决一个床位的问题但医院的需求往往是整个病区的集中监护。把无线模块从Wi-Fi换成LORA每张床位一个节点护士站放一个LORA网关就能实现多床位的滴速集中监控。对应到代码上主要改动在通信协议层。用LORA模块一般是串口透传所以要注意自定义帧格式帧头、设备ID、滴速、剩余量、报警标志、校验位。设备ID很重要没有它护士站根本分不清哪个数据是哪个床位的。8.2 升级二从滴速控制到多参数生命体征扩展既然单片机、屏幕、无线模块这些“基础设施”都搭好了改造成多参数监护仪就很顺理成章。加上MAX30102模块就能测血氧和心率加上DS18B20测体温再加上刚才说的称重传感器一个床旁监护终端就诞生了。升级的时候优先考虑传感器模块的I2C地址冲突问题。MAX30102默认地址是0x57OLED是0x78DS18B20走单总线不占I2C三者可以共存但要注意总线上拉电阻的阻值选择。I2C总线挂的设备越多上拉电阻要适当调小。8.3 升级三低功耗改造做便携式设备如果想把设备做成电池供电的穿戴式或者便携式低功耗设计就躲不开。F103本身不是超低功耗芯片但可以通过这几个手段把功耗压下来STOP模式下把主频停掉保留RTC唤醒OLED平时熄灭按键唤醒了再显示红外对射管可以改成周期性供电采样每个取样周期只工作几十毫秒。低功耗调试的难点在于测电流。用万用表电流档测平均电流不直观更好的是用串联电阻法测压降换算电流或者直接上INA219这类电流传感器模块。目标功耗控制在5mA以下两节18650电池能撑一天一夜便携之路就走通了。9. 实际测试中我最想告诉你的一组数据说了这么多结构和逻辑最后分享一组我在复现类似项目时实测的数据供你参考。红外对射模块在雨雾天气、空调出风口直吹、或者滴壶内壁起雾时红外光会被散射或折射导致灵敏度下降甚至完全检测不到液滴。解决方法是把传感器抬高一点让光路尽量接近滴壶中轴线的液滴下落通道同时软件里加一个“连续X秒无滴”提示避免误判。PID闭环调节的实测参考目标滴速50DPM纯P控制比例系数Kp8时超调量约40%稳定时间约15秒加入微分项Kd2后超调量降到15%稳定时间缩短到8秒左右。这个参数在不同蠕动泵上会有差异但量级可以作为初始参考。最后关于滴速报警阈值的设置我的经验是上下限不要设得太紧比如目标50DPM时报警下限设40、上限设65比较合理。太紧的话患者转个身、抬下手导致的滴速波动就会误报警反而让护士失效。写到这里这个项目的技术细节基本已经拆得比较透了。从硬件选型到闭环算法从仿真验证到实物调试每个环节能讲的坑我都尽量讲到了。希望这份拆解能帮你少走点弯路快速把代码烧进去、让滴速稳定下来然后在这个基础上做出你自己的东西。毕竟开源项目的意义从来不是让你直接复制而是让你站在别人的肩膀上看得更远。