企业官网建设流程全解析

1. 从临床痛点出发：这套系统到底要管哪些事

1.1 输液监护最常见也是最折磨人的三个问题

我最早接触输液监护这个方向，是因为陪家人住院时亲眼看到护士站的忙碌程度。输液快完了要按铃，滴速不合适要调整夹子，夜间患者睡着了没人盯着药液是否走空——这些看似琐碎的事情，在医院里却是实打实的安全隐患。药液走空后回血、空气进入静脉、滴速过快导致心脏负荷骤增，这些都是真实存在过的临床事故。而传统的解决方案，要么靠护士频繁巡视，要么靠家属瞪大眼睛盯着，本质上都属于"人肉监护"，效率和可靠性都有限。

于是就有了做一套智能输液监护调控系统的想法：把药液滴速的实时检测、自动调节、余量监控和异常报警整合到一个嵌入式设备里，让输液过程从"人工盯防"变成"机器自动管理"。相比市面上那些只能报警不能调速的单功能输液监护仪，这套系统的核心差异点在于闭环控制——检测到滴速偏差后，系统不需要人工干预，直接通过电机调节输液管的挤压程度，把滴速拉回到目标值。这就是标题里"监护+调控"两个词的真正含义。

1.2 升级版在基础版之上补了哪几块短板

说一下"升级版"这三个字的分量。最早的基础版我做过一版，功能很简单：红外对管检测滴速，LCD显示数字，滴速超过上下限就蜂鸣器报警，本质上还是一个"带显示的报警器"。但实际使用后发现几个尴尬问题：滴速检测窗口期的抖动会导致显示数字乱跳；环境光一强，红外对管的误触发率直线上升；报警之后只能等护士来手动处理，没有自动纠偏能力。

升级版针对这些问题做了系统性重构：滴速检测信号链路增加了比较器整形和软件滤波，彻底解决了计数抖动问题；引入步进电机驱动蠕动泵，让调速从"手动掰夹子"变成"闭环PID自动调节"；增加了药液余量检测和OLED实时曲线显示；同时预留了无线模块接口，方便后续接入护士站呼叫系统。另外原理图和仿真工程全部重画，补上了电源稳压、电机隔离驱动、按键消抖这些基础版忽略的细节。整个项目的代码、原理图、Proteus仿真三件套都是完整开源状态，直接拿来改就能用。

1.3 适合谁读、能获得什么

如果你是正在做课程设计的电子信息类学生，或者刚接触STM32想找一个"既有传感器又有执行机构还有控制算法"的完整项目，又或者是医疗电子方向想了解输液设备实现原理的工程师，这篇内容应该都对你胃口。接下来我会按照硬件选型、原理图设计、滴速闭环控制、代码架构、仿真调试这条线，把整个系统的设计思路和踩坑过程完整过一遍。

2. 硬件选型与原理图设计：关键决策点都在这里

2.1 主控选型：STM32F103C8T6为什么依然是首选

先回答一个很多人会问的问题：现在STM32价格波动、国产芯片崛起，为什么这套系统还选STM32F103C8T6？原因很实际：C8T6这颗芯片的生态太成熟了，无论是标准外设库、HAL库还是各种开源例程，资料密度在MCU领域属于天花板级别。对做项目的人来说，选一颗资料最多的芯片，意味着遇到问题时搜索一下就能找到答案，开发效率完全不在一个量级。

从资源角度分析，C8T6内置64KB Flash、20KB RAM，主频72MHz，外设接口包含3个USART、2个SPI、2个I2C、4个16位定时器、1个12位ADC。这套输液监护系统需要同时处理滴速检测（定时器输入捕获）、电机PWM调速（定时器输出比较）、OLED显示（I2C或SPI）、按键输入（GPIO外部中断）、蜂鸣器报警（PWM输出）和可选的无线通信（USART），资源占用大约在50%左右，属于"够用但有余量"的舒服状态。如果换成C8T6的小兄弟C6T6，Flash砍半，后续扩展无线通信协议栈时就会捉襟见肘。

还有一点容易被忽视：C8T6是LQFP48封装，手工焊接非常友好。我做过那么多项目，LQFP48的引脚间距0.5mm，拖焊熟练的话一片成功率在95%以上。相比之下，如果选了BGA封装的芯片，学生党没有热风枪基本只能放弃手工打样。

2.2 滴速传感器：红外对管加比较器整形的完整信号链

滴速检测是整个系统的感知核心，原理不复杂：输液器的滴壶是一个透明腔体，药液一滴一滴落下时会经过一个固定位置，用红外对管（发射管+接收管）横跨滴壶两侧，液滴经过时红外光被折射和遮挡，接收管上的光强发生变化，产生一个脉冲信号。测量单位时间内有多少个脉冲，就能算出一分钟滴多少滴。

但理论归理论，实际做的时候最大的坑是信号质量。红外接收管直接输出的信号是一个缓慢变化、带有大量噪声的模拟量，环境光一变、液滴下落的位置稍微偏一点，波形就会乱七八糟。如果直接把这样的信号送到MCU的GPIO做外部中断计数，结果就是一边输液一边疯狂误触发，显示滴速从20跳变到200，完全没法用。

解决方案是加一级比较器整形。我用的是LM393双电压比较器，红外接收管的输出接比较器同相输入端，反相输入端接一个可调电位器设置阈值电压。当接收管信号低于阈值时，比较器输出翻转，输出干净的方波脉冲。这个方案的妙处在于：阈值可以现场调节，适应不同品牌的输液器和不同的环境光强度；同时比较器工作电压可以做到3.3V，和STM32直接电平匹配，不需要额外做电平转换。

2.3 执行机构：步进电机驱动蠕动泵实现精准调速

如果说滴速检测是系统的"眼睛"，那么调速机构就是"手"。最常见的调速方案是步进电机挤压输液管。具体做法是把输液管卡在一个蠕动泵的槽位里，步进电机带动一个偏心轮或凸轮旋转，挤压输液管改变管内截面积，从而控制流速。电机转动的角度越大、挤压越深，流速越慢；反之流速加快。

这里选步进电机而不是普通直流电机，原因在于位置控制精度。闭环调速需要电机能够精确地停在某个挤压位置，如果直流电机停了之后还会惯性转动，挤压量就不可控。步进电机是脉冲驱动、开环定位的，给多少个脉冲就走多少步，天然适合这种需要精确位置控制的应用场景。

驱动芯片选的是ULN2003。虽然这颗芯片技术很老，但胜在便宜、皮实、驱动电流足够。28BYJ-48这种常见的5V步进电机，四相五线制，ULN2003正好是达林顿管阵列，7路输入输出，能直接吸收电机绕组的电流。要注意的是ULN2003内部没有续流二极管的话，电机绕组断电时会产生反向电动势，所以原理图上必须在电机端并联续流二极管或者选择内部集成的型号。我用的是内部自带续流二极管的ULN2003，省了外围器件。

2.4 外围电路细节：显示、按键、报警与电源

显示模块我用了0.96寸OLED，I2C接口，4个引脚就能搞定，显示滴速、目标速度、药液余量和剩余时间。选择I2C版本而不是SPI版本是因为它能省两个GPIO，而且刷新率对于这种低频数据展示场景完全够用。OLED对比度高、视角宽，放在输液架旁边从侧面也能看清，这一点比LCD1602强不少。

按键部分设计了三个物理按键：设置键、加键、减键。功能逻辑是短按设置键切换配置项（目标滴速、报警上下限），加/减键调整数值，长按设置键进入或退出设置模式。按键消抖是两个层面：硬件上每个按键并联0.1uF电容，软件上做20ms消抖延时。这里特别提醒一下，单纯靠软件延时消抖会阻塞主循环，我的做法是用定时器扫描按键 + 状态机判定，具体后面代码部分再说。

报警部分用有源蜂鸣器，GPIO给高电平就响，低电平就停，不需要PWM驱动。有源蜂鸣器内部自带振荡源，价格便宜，声音尖锐，比较适合医疗报警场景。电源部分则做了两级处理：外部输入12V适配器（输液架附近取电方便），经LM2596降压到5V给步进电机和比较器电路供电，再用AMS1117-3.3把5V降到3.3V给STM32和OLED供电。这样设计是为了让电机电源和逻辑电源分开，避免电机启动时的电压跌落导致MCU复位。

3. 滴速检测与闭环控制：工程里最难啃的部分

3.1 滴速测量原理：从红外信号中断到滴/分钟换算

滴速检测的软件实现走的是外部中断加定时器计数配合的路线。红外对管经过比较器整形后，输出方波接入STM32的一个GPIO引脚（比如PA0），配置为外部中断模式，上升沿触发。每来一个液滴脉冲，中断服务函数里做一次计数加一。

关键在于滴速的换算窗口。直接统计1分钟的脉冲数当然最精确，但响应太慢——如果输液过程中滴速突然异常，等60秒才能报警，黄花菜都凉了。我采用的做法是滑动窗口法：每3秒统计一次该窗口内的液滴数，然后乘以20换算为每分钟滴速。代码实现上就是用定时器3产生一个3秒的中断，中断里读取外部中断的计数值，然后清零重新计数。

这样做的好处是响应速度快。举个例子，目标滴速为40滴/分钟，3秒窗口内理论应该检测到2滴，如果实际检测到5滴，说明滴速已经飙到100滴/分钟，系统在第3秒就能触发报警和自动减速。3秒窗口当然也有实时性代价，液滴速度不均匀的时候显示值会有轻微跳变，但后续通过软件滤波可以把这部分抖动压下来。

3.2 信号抖动处理：滤波、去抖与临界状态处理

信号抖动是滴速检测里最令人生气的问题。你以为比较器整形之后就干净了，其实不然。输液管挂得不够垂直、滴壶侧壁挂着药液水珠、步进电机振动导致整个输液架晃动，都会让红外光路产生随机遮挡，在脉冲前后沿附近产生毛刺。

我踩过这个坑之后，总结出三层处理策略。第一层是硬件去抖：比较器输出端对地并联一个0.1uF电容，和输出电阻形成一个低通滤波器，把纳秒级的毛刺直接滤掉。第二层是MCU端的软件去抖：外部中断触发后，延时20微秒再读一次电平，如果电平状态已经恢复就不计数，只有两次读到的电平一致才算有效跳变。第三层是滴速窗口内的异常值剔除：单次窗口计数如果超过一个上限（比如3秒内超过15滴，对应滴速300滴/分钟，这在临床上是绝对不可能的），直接判定为干扰，整个窗口丢弃，滴速沿用上一窗口数值。

还有一个容易忽略的场景：滴速为零时怎么处理。系统设置了一个判断逻辑，在连续两个3秒窗口都计数为零、且蜂鸣器报警状态已经触发的情况下，才判定为"疑似输液完毕或管路阻塞"。为什么要连续两个窗口？因为单次窗口内可能恰好一滴都没落到检测位置，但管子深处还在缓慢补液，如果太激进会造成误报。

3.3 PID调速的整定过程与防过冲处理

调速控制的"大脑"是增量式PID算法。我用的是位置式PID的变体，每次计算控制量的增量，累加到当前步进电机的目标位置上。控制对象是步进电机的挤压深度：滴速偏快，就增加挤压；滴速偏慢，就减少挤压。简单说，PID的作用就是把"检测到的滴速"和"目标滴速"之间的误差，转化为"步进电机应该走的步数增量"。

增量式PID的计算公式：

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

其中e(k)是当前滴速偏差（目标值减实际值），u(k)是电机步数输出。增量式的优势在于输出是步进增量，即使计算出现微小错误也不会让电机位置产生跳跃，安全性更高。

参数整定我走的是工程上最实用的试凑法。先把Ki和Kd设为0，只留Kp，从0.5开始逐步增加，观察滴速响应曲线。发现Kp在3左右时，系统能在一个窗口内把滴速拉回目标值附近，但会有一点超调——滴速冲到目标值上方又回落，来回振荡。接着加Kd做阻尼，Kd从0.5开始试，到1.2左右时振荡明显减弱。最后加Ki消除稳态误差，Ki取值0.8，用来修正因为输液管老化或电机磨损导致的长期偏差。

防过冲方面还有一个关键技巧：对PID输出做限幅。步进电机每次调节的最大步数限制在200步，防止滴速偏差大的时候电机一步到位挤死输液管。同时步进电机的加速和减速过程也做了斜坡控制，启动时逐渐加速到目标速度，减速时反向逐渐减速，避免电机丢步。这套组合拳打下来，实测滴速从35滴/分钟调节到40滴/分钟，稳定时间大约在9秒以内，满足输液场景的要求。

4. 代码架构与关键模块实现

4.1 代码目录结构与分层思想

代码整体采用了三层架构：硬件抽象层（BSP）、应用逻辑层（APP）、服务层（SVC）。很多刚入门的朋友写STM32代码喜欢把全部逻辑堆在main.c里，几百行下来自己都找不到北。这个项目因为涉及传感器、电机、显示、按键、报警多个模块，不分层的话基本没法维护。

实际的目录结构如下：

Project/ ├── BSP/ │ ├── bsp_oled.c // OLED显示驱动 │ ├── bsp_key.c // 按键扫描与消抖 │ ├── bsp_buzzer.c // 蜂鸣器驱动 │ ├── bsp_ir_detect.c // 红外滴速检测 │ └── bsp_motor.c // 步进电机驱动 ├── APP/ │ ├── app_infusion.c // 输液业务逻辑主状态机 │ ├── app_control.c // PID控制计算 │ └── app_alarm.c // 报警判定与处理 ├── SVC/ │ ├── timer_manage.c // 定时器统一管理 │ └── filter.c // 滤波算法 └── main.c

BSP层只负责和硬件寄存器打交道，向上提供简单的接口函数，比如ir_get_drop_count()、motor_set_target_position()。APP层是核心业务逻辑，不关心硬件细节，只处理数据。SVC层提供通用的服务函数。这样的好处是：换一块开发板或者换一个电机驱动芯片，只需要改BSP层，APP层完全不动。

4.2 主状态机设计：正常运行、报警、暂停与配置

主程序不是简单的轮询循环，而是一个状态机，共有五个状态：INFUSION_IDLE（待机）、INFUSION_RUNNING（正常运行）、INFUSION_ALARM（报警）、INFUSION_PAUSE（暂停）、INFUSION_CONFIG（参数配置）。状态转换的逻辑集中在一个函数里，各个状态都有独立的进入和退出处理。

typedef enum { INFUSION_IDLE = 0, INFUSION_RUNNING, INFUSION_ALARM, INFUSION_PAUSE, INFUSION_CONFIG } InfusionState; static InfusionState current_state = INFUSION_IDLE; void infusion_state_machine(void) { switch (current_state) { case INFUSION_IDLE: if (start_flag) current_state = INFUSION_RUNNING; break; case INFUSION_RUNNING: if (alarm_flag) current_state = INFUSION_ALARM; if (pause_flag) current_state = INFUSION_PAUSE; break; case INFUSION_ALARM: if (!alarm_flag && !pause_flag) current_state = INFUSION_RUNNING; break; case INFUSION_PAUSE: if (!pause_flag) current_state = INFUSION_RUNNING; break; case INFUSION_CONFIG: // 配置界面禁止执行调速逻辑 break; } }

状态机的好处是避免了标志位混乱。比如在配置模式下，每次按键调整目标滴速时不会触发调速逻辑；在暂停模式下，电机保持当前位置不动，避免拔针时挤压输液管导致回血。报警状态一旦进入，蜂鸣器持续鸣响，OLED显示红色大字报警原因，直到人工按消音键或者系统自动恢复才会退出。

4.3 定时器与外部中断的任务分工

定时器资源的分配在代码架构里是重头戏。项目用了4个定时器，分工如下：

• TIM1：产生PWM信号驱动步进电机，输出频率控制电机转速
• TIM2：外部中断滴速计数的时间基准，产生3秒窗口中断
• TIM3：系统心跳时钟，1ms产生一次中断，驱动按键消抖和显示刷新
• TIM4：蜂鸣器报警的节奏控制，用于产生间歇式报警音

这种分工方式有个核心原则：让硬件外设各司其职，主循环只做状态机状态获取和业务逻辑判断。所有实时性要求高的任务（滴速计数、电机脉冲、按键消抖）全部在中断里完成，主循环不做任何阻塞操作，保证了系统的实时性。

需要注意的是中断优先级配置。滴速检测的外部中断优先级最高，设置为0；TIM2的3秒窗口中断优先级次之，设置为1；TIM3的1ms心跳中断设置为2。因为滴速计数是最敏感的数据源，如果它被其他中断打断，可能会导致液滴脉冲丢失，直接影响滴速计算的准确度。

4.4 关键代码片段解析

重点说两个核心片段。第一个是滴速窗口统计与滤波的实现：

// 外部中断服务函数 void EXTI0_IRQHandler(void) { if (EXTI_GetITStatus(EXTI_Line0) != RESET) { // 软件去抖：延时20us后重新读取电平 volatile uint32_t delay = 0; for (delay = 0; delay < 20; delay++); if (GPIO_ReadInputDataBit(GPIOA, GPIO_Pin_0) == SET) { drop_count_local++; } EXTI_ClearITPendingBit(EXTI_Line0); } } // TIM2 3秒窗口中断 void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_Update) != RESET) { uint16_t count = drop_count_local; drop_count_local = 0; // 异常值剔除：3秒内超过15滴视为干扰 if (count > 15) { current_drop_speed = last_valid_speed; } else { last_valid_speed = (uint16_t)(count * 20); current_drop_speed = last_valid_speed; } TIM_ClearITPendingBit(TIM2, TIM_IT_Update); } }

第二个是增量式PID的完整函数：

void pid_control(int16_t target_speed, int16_t real_speed) { static int16_t error_prev = 0; static int16_t error_prev2 = 0; static int32_t output_sum = 0; int16_t error; int32_t output_increment; error = target_speed - real_speed; output_increment = KP * (error - error_prev) + KI * error + KD * (error - 2 * error_prev + error_prev2); output_sum += output_increment; // 输出限幅防过冲 if (output_increment > MAX_STEP_CHANGE) { output_increment = MAX_STEP_CHANGE; } else if (output_increment < -MAX_STEP_CHANGE) { output_increment = -MAX_STEP_CHANGE; } motor_set_target_position(motor_get_position() + output_increment); error_prev2 = error_prev; error_prev = error; }

注意一个细节：限幅放在增量累加之前。如果放在累加之后，电机已经执行了超大规模的变化才被截断，实际位置已经被错误地改变了。先限幅再累加，保证每一步的实际输出增量都不超过安全范围。

5. Proteus仿真搭建要点与硬件实测的差异

5.1 仿真工程搭建步骤和模型选择

Proteus仿真工程我用了重画后的原理图直接导入，过程比从零开始画省了不少事。搭建的关键是模型选择：STM32F103C8T6在Proteus里的模型名称通常是STM32F103C8或者直接搜STM32F103；步进电机模型用MOTOR-STEPPER；OLED因为Proteus的I2C OLED模型不太好用，仿真阶段改用了LM016L（LCD1602）替代显示，毕竟仿真只是为了验证逻辑，显示细节差异可以接受。

红外对管在Proteus里没有现成的光路仿真模型，我采用了一个变通方案：用按钮开关手动模拟液滴脉冲。按下一次按钮，相当于产生一个脉冲，同时在按钮电路中串联一个方波信号源，设置频率模拟连续滴液。虽然手动模拟达不到真实光路的动态效果，但对于验证滴速换算、PID控制逻辑、报警状态转换这些核心功能，完全够用了。

5.2 仿真中容易卡壳的几个问题

先说一个让我卡了一晚上的问题：仿真中STM32的程序烧录不进芯片。Proteus加载hex文件后点击运行，芯片完全没有反应，后来发现是ST-LINK调试器模型没有正确配置。在Proteus的芯片属性里必须选择对应的调试器模型，并且晶振频率要和实际硬件一致，否则芯片时钟配置错乱，程序一启动就死掉。

第二个常见问题是仿真运行速度。Proteus的模拟器跑STM32这种复杂MCU本来就很吃力，如果把PID调节周期设定得太快，仿真里能看到电机像抽风一样来回抖动，实际上是因为仿真器时钟跟不上导致控制周期错乱。解决办法是在仿真模式下把PID计算周期放宽到500ms一次，只验证控制方向和稳定性，真实硬件上再恢复为3秒窗口周期。

第三个问题是步进电机模型的旋转方向。Proteus里电机模型默认的相位顺序和真实28BYJ-48不一定一致，如果发现仿真里电机反转，把四相的控制时序反向输出即可，不用改硬件电路。

5.3 仿真通过后转到真实硬件的三个差异项

仿真通过只能说明逻辑正确，实际硬件的坑比仿真多得多，重点说三个差异。

第一个差异是信号噪声。仿真环境里按键信号、红外信号都是理想波形，真实硬件上导线就是天线，稍微布局不规范就会引入干扰。我在硬件实测时发现OLED显示偶尔闪烁，排查下来是OLED数据线和步进电机驱动线在PCB上平行走线过长，产生了串扰。解决方法是把I2C数据线从电机驱动线旁边拉开，并且增加0.1uF去耦电容。

第二个差异是电源跌落。仿真环境下电源是理想的，真实步进电机启动瞬间电流可能达到500mA，如果电源跟不上，STM32会复位。这就是为什么我在原理图设计中特别强调12V输入、LM2596降压、5V和3.3V分路供电的架构。实测中如果电机启动时OLED闪一下或者蜂鸣器误响，大概率是电源跌落导致MCU瞬间欠压，需要检查滤波电容容量，至少需要220uF以上的电解电容并联在5V输出端。

第三个差异是传感器灵敏度。Proteus里用按钮模拟液滴，不存在环境光问题。真实红外对管在阳光直射下接收管会饱和，输出一直是低电平，系统会误判为滴速为零。解决措施是把红外对管的安装位置设计成遮光结构，同时在比较器阈值上预留手动调节电位器，方便现场适应不同环境。

6. 从实际测试到最终调优：几个值得说细的环节

6.1 滴速显示跳变的追查过程

硬件打样回来后，第一波测试就遭遇了滴速显示跳变的问题——目标40滴/分钟，实际显示稳定在38到43之间跳动，偶发显示到50以上又跳回来。这个现象根本不可能是输液器本身的问题，我第一反应是红外信号上叠加了干扰。

排查链路是这样的：先用示波器直接看比较器输出波形，发现波形本身还是有毛刺，尤其在步进电机转动瞬间，脉冲宽度会突然变化。但电机怎么可能影响到滴速检测？我用另一台示波器同时抓电机驱动引脚和红外接收管输出，发现电机转动时，红外接收管的信号线上出现了周期性的噪声尖峰。问题根源找到了：电机地线和传感器地线共用了同一条模拟地线，电机电流突变在地线上产生了压降，抬高了传感器的参考地电平。

解决方法是把地线改成星型拓扑：电源地分别走到电机驱动、传感器、MCU三路，在地线节点处单点汇合。同时把传感器的电源从5V独立引一路，不经过电机驱动的供电走线。改完板之后再次测，滴速显示稳定在39到41之间，跳变问题基本消失。

6.2 电机的丢步误差与累计漂移校准

步进电机的丢步问题属于开环控制的经典难题。虽然28BYJ-48在正常负载下丢步概率不高，但输液管在不同温度下硬度会变化，冬天管子硬、挤压阻力大，电机偶尔会丢步，导致实际挤压位置和系统认为的位置产生偏差。

针对这个问题我做了两步处理。第一步是在滴速闭环上做了偏差报警阈值：如果PID持续输出超过最大调节量，说明电机一直在调节但滴速没有回到目标，系统判定为"调节失效"，触发报警并停止电机，防止电机堵转烧毁。第二步是加了一个位置零点校准机制：每次系统上电初始化时，电机先反向转动直到触发限位开关，把当前物理位置确认为绝对零点，再缓慢前进到预设的初始位置。这样即使上次运行产生了丢步误差，重启后也会被清零。

还有一个经验是电机驱动时序的微调。标准四相八拍时序在低速时扭力足够，但高速时容易丢步。实测发现把步进脉冲之间的间隔减小到800us时，电机在高速区间丢步明显减少。这个值不建议随便抄，因为不同品牌电机的共振区间不同，需要实际调试找到最优值。

6.3 后续扩展方向与医疗级升级思路

这套系统做到现在，基础功能和闭环控制已经稳定运行了一段时间。后续如果要往产品级方向推，有几个值得投入的方向。

第一是安全冗余设计。医疗设备对安全性的要求极高，至少需要双MCU互检、看门狗、硬件过压过流保护这些机制。目前的蜂鸣器报警还比较初级，工业级输液泵需要至少两级报警：一级提醒护士站，一级直接切断输液通路并保持当前挤压位置不变，防止空气进入。

第二是通信和信息化。代码里预留了USART接口，可以直接接ESP8266或LoRa模块接入护士站管理系统。输液完成、滴速异常这些事件实时同步到护理大屏，护士不需要逐间病房巡查，效率会大幅提升。

第三是液滴图像识别方案。用摄像头配合轻量级图像识别算法替代红外对管，可以更精确地识别液滴大小和落点位置，甚至能判断药液是否有结晶析出。当然这个方向的功耗和算力要求会明显提高，STM32F103已经不够用，得考虑带摄像头的MCU或者外加AI加速芯片。

最后说个实际的体会：做这类医疗方向的开源项目，真正难的地方不在代码，而在于对"可靠性"的敬畏。仿真跑通很容易，实验室跑通也不算难，但从实验室到真实病房使用，中间差着十个"环境光干扰"和二十个"电源跌落"。每次踩坑、每次对着示波器抓波形，都是对系统理解加深的过程。这个项目现在完整开源了代码、原理图和仿真，如果你也在做类似方向，建议先从仿真把逻辑跑通，再做硬件联调，最后重点折腾传感器信号链路的抗干扰——这块打通了，整个项目就稳了。