企业官网建设流程全解析

我做的这个STM32智能输液监护调控系统，从第一版迭代到现在，前前后后改了差不多快两个月了。这版升级版重点解决了之前非常头疼的几个问题：输液速度控制不够线性、滴速检测容易受干扰、还有报警误报率偏高。这次干脆把代码、原理图和Proteus仿真工程全部整理开源出来，给正在做类似项目的朋友一个完整参考，尤其是那种课程设计、毕业设计卡在“原理图能画但仿真跑不通”阶段的，这份资料应该能帮你省下不少折腾时间。

1. 升级版整体架构与设计思路

1.1 从第一版到升级版：到底改了哪些东西

先说说为什么叫“升级版”。第一版功能其实比较简单，就是一个红外对管检测莫菲氏滴管里的液滴，然后用数码管显示滴速，超限了就蜂鸣器报警，整个系统属于“能跑但不好用”的状态。

升级版的关键变化在于加入了闭环控制。也就是说，系统不再只是“检测-报警”，而是真正做到了“检测-决策-执行”：通过红外对管实时采集滴速，STM32把实测滴速和目标滴速做PID运算，然后输出PWM信号控制蠕动泵的转速，从而动态调节输液速度。简单说，原来的系统是个只会喊“快超速了”的仪表，现在变成了一个会自己动手调速的“助手”。

另外几个重要的升级点：

• 通信能力增强：加入RS485总线接口，可以实现多床位联网监护，护士站那边能看到所有病床的输液状态。
• 人机交互升级：矩阵键盘可以设定目标滴速和报警阈值，相比原来拨码开关的方式友好太多。
• 数据记录能力：增加EEPROM存储，掉电后参数不丢失，这个在真实医疗场景里是刚需。
• 安全机制完善：新增气泡检测通路和电机堵转保护逻辑，虽然仿真里不好体现电机堵转，但代码层面已经做了防呆处理。

1.2 为什么选STM32F103C8T6而不是其他主控

主控选型上，我坚持用了STM32F103C8T6，这是颗非常经典的Cortex-M3内核芯片。市面上那些“兼容版”芯片（比如GD32、APM32）也试过，但最终还是换回ST原厂。原因主要是这几个：

第一，资料生态太成熟了。不管是标准外设库还是HAL库，教程一搜一大把，遇到问题基本都能查到解决方案。对于学生党或者刚入门的朋友来说，这点非常关键——调试遇到坑的时候，能查到的资料数量直接决定你能不能走出来。

第二，外设资源完全够用且不浪费。这个系统需要的外设包括：定时器输入捕获（滴速检测）、定时器PWM输出（电机控制）、ADC采样（压力传感器）、USART（调试串口和RS485）、I2C（EEPROM）、GPIO矩阵键盘和显示接口。STM32F103C8T6把这些全部包圆了，还有富余。

第三，价格和供货。在目前的市场行情下，这颗芯片的国产替代型号甚至能压到几块钱，整板打样成本非常低。如果你的预算更紧张，板子自己画的话，核心板加外围器件，全套原件成本控制在50块以内问题不大。

1.3 系统整体框图与工作流程

整个系统的工作流程是这样的：

1. 红外对管传感器安装在莫菲氏滴管两侧，液滴落下时遮挡红外光线，产生一个脉冲信号。
2. STM32的定时器工作在输入捕获模式，记录脉冲间隔时间，软件计算出实时滴速（滴/分钟）。
3. 与按键设定的目标滴速比较，经过PID控制器计算出PWM占空比调整量。
4. PWM信号驱动蠕动泵电机，改变输液管道的挤压频率，从而调节实际流速。
5. 压力传感器实时监测输液管道压力，超过阈值立即停止电机并声光报警。
6. 所有运行参数通过LCD显示，同时通过RS485上传到上位机。

这套闭环逻辑，参考的就是工业控制里特别经典的**“检测-控制-执行”**模型。跟实验室里常见的开环控制相比，好处在于系统能自动对抗扰动——比如病人翻身压到输液管了，管道阻力增大，滴速下降，这时候系统会主动加快电机，把滴速拉回设定值附近。

2. 硬件电路设计与原理图解读

2.1 电源电路设计：多路电压怎么分配

硬件设计摆在第一位的就是电源。整个系统需要的电压有几种：STM32和传感器需要3.3V，蠕动泵电机和继电器需要5V或12V，运放电路需要正负供电（我用的是单电源轨到轨运放，避免了负压）。

电源方案我采用的是外部5V适配器输入 + 板上LDO降压到3.3V。很多朋友喜欢直接上AMS1117-3.3，这个芯片便宜也好用，但有一点得提醒：AMS1117的最大压差其实不太适合输入电压过高的场景，输入5V时输出3.3V没问题；但如果你的适配器是12V的，建议先一级降压到5V，再进AMS1117，否则芯片发热会比较严重，长时间运行稳定性也差。

原理图上，电源部分我还加了几个关键细节：

• 输入端的防反接二极管（SS14），接反了不会烧板子。
• 每个电源引脚附近都放了0.1uF高频退耦电容和10uF钽电容，这个习惯我从做第一版就养成了，对ADC采样稳定性帮助很大。
• 模拟地和数字地单点连接，用0欧电阻或者磁珠隔开，减少数字开关噪声对模拟采样的干扰。

2.2 滴速检测电路：红外对管+比较器整形

滴速检测是本项目的灵魂模块，这块电路设计得好不好，直接决定系统能不能正常计数。

原理图上的设计是这样的：红外发射管（一般是940nm波长）串联一个限流电阻接到3.3V，红外接收管（光敏三极管）接成共射极电路。当液滴从莫菲氏滴管落下经过红外光束时，光线被遮挡，接收管导通状态改变，集电极电压产生一个从高到低的跳变。

但这个跳变信号直接进STM32的GPIO是不行的，因为信号边缘不够陡峭，且存在抖动。所以我在接收管输出端加了一级比较器整形，用的是LM393比较器，参考电压通过电位器分压设定。信号经过比较器后变成标准的方波，再送入STM32的PA0口（TIM2_CH1）做输入捕获。

这里有个仿真时容易踩的坑：Proteus里那套红外对管模型，光强和遮挡关系的模拟非常理想化，你直接照搬真实电路参数可能仿真正常、真实硬件反而失灵。所以我在原理图里特意用了一个电位器来调节比较器阈值，实际调试时要配合示波器观察波形，把阈值调到信号波形比较干净的那种状态。

2.3 电机驱动与PWM控制电路

蠕动泵电机我选的是12V直流减速电机，额定电流大概300mA左右。驱动方案用的是经典的ULN2003达林顿管阵列，虽然L298N或者TB6612更“高级”，但对于单个直流电机来说，ULN2003完全够用，电路还简单，价格也便宜。

不过ULN2003有一个特点必须注意：它是集电极开路输出，内部没有续流二极管到电源正极。驱动感性负载（电机）时，必须外部加上续流二极管，否则电机断电瞬间产生的反向电动势会把达林顿管击穿。原理图上，我在电机两端反向并联了1N4007二极管，这是驱动感性负载的标准做法，别省。

PWM信号从STM32的PA1（TIM2_CH2）输出，频率设定为10kHz。为什么选10kHz？因为音频范围大约在20Hz到20kHz，10kHz稍微低了一点其实还行，主要考虑到电机本身有机械惯性和线圈电感，太高的PWM频率会导致电流纹波小但开关损耗变大，太低又会听到明显的电机啸叫。10kHz是一个比较折中的选择，实测电机运行也比较平稳。

2.4 显示与按键电路

显示设备用的是1602LCD液晶屏，这是最经典的做法。1602需要8根数据线加3根控制线，占用的引脚比较多。为了省引脚，我用了I2C接口的LCD转接板（PCF8574芯片），这样只需要两根线（SCL、SDA）就能驱动屏幕。对STM32F103C8T6这种48脚芯片来说，引脚资源还是比较宝贵的。

按键部分用了4x4矩阵键盘，连接到GPIOB的低8位。矩阵键盘的扫描原理就是行列分时扫描，代码里用定时器中断做20ms消抖扫描，不会阻塞主循环。

3. 软件框架与核心代码实现

3.1 工程如何组织：模块化编程实战

这次开源的代码是按照模块化思路组织的，每个外设一个对应的文件和头文件，主函数只负责初始化各模块和调度主循环。整个工程结构可以列为：

Core/ ├── main.c // 主函数，系统初始化，主循环 ├── stm32f10x_it.c // 中断服务函数 Hardware/ ├── bsp_dripsensor.c // 滴速传感器驱动 ├── bsp_motor.c // 电机PWM控制 ├── bsp_key.c // 矩阵键盘扫描 ├── bsp_lcd1602.c // LCD显示驱动 ├── bsp_eeprom.c // AT24C02存储 └── bsp_rs485.c // RS485通信 Algorithm/ ├── pid.c // PID控制器 └── filter.c // 数字滤波 System/ ├── delay.c // 延时函数 ├── usart.c // 串口调试

这样组织的好处是，每个模块的耦合度很低。比如你不想用1602LCD想换OLED，只需要新写一个bsp_oled.c，把相关调用接口保持一致，其他模块不用大改。

3.2 滴速检测：定时器输入捕获+软件滤波

滴速检测的代码实现，核心是配置TIM2_CH1为输入捕获模式。一个液滴落下产生一个脉冲，定时器捕获到上升沿时记录当前的计数器值，两次上升沿之间的时间差就是液滴间隔。

void TIM2_IRQHandler(void) { if (TIM_GetITStatus(TIM2, TIM_IT_CC1) != RESET) { TIM_ClearITPendingBit(TIM2, TIM_IT_CC1); uint16_t capture = TIM_GetCapture1(TIM2); uint16_t interval = capture - last_capture; // 计算边沿间隔 last_capture = capture; // 丢弃明显无效的测量值（<50ms看做干扰，>3000ms看做停滴） if (interval > 50 && interval < 3000) { // 存到环形缓冲区，用于软件滤波 interval_buffer[filter_index] = interval; filter_index = (filter_index + 1) % FILTER_SIZE; } } }

这里有个非常关键的细节：测量值必须做滤波。因为实际环境中红外对管很容易受到环境光干扰，或者液滴因为表面张力产生不规则抖动，直接拿单次测量值计算滴速会跳得很厉害。

我采用的是中位值平均滤波：把最近10次的间隔值排序，去掉最大和最小，剩余8个求平均。这种滤波方式对抗脉冲干扰非常有效，比单纯滑动平均稳健得多。滴速的计算公式很简单：

speed_dpm = 60000 / average_interval_ms;

如果平均间隔是600ms，那么滴速就是100滴/分钟。

3.3 PID闭环算法：怎么让滴速稳定到设定值

这版升级版的核心卖点，就是这个PID控制器。PID控制说简单也简单，说复杂也复杂。关键点是参数整定，参数没调好，系统要么响应太慢，要么超调震荡。

我用的是增量式PID。为什么不用位置式？因为增量式输出的是控制量的增量，即使PID输出错误，也只是当前基础上的一个微小变化，不容易造成系统大幅跳变，安全性更好。公式是：

// 增量式PID计算 float PID_Calculate(PID_TypeDef *pid, float setpoint, float measured) { float error = setpoint - measured; pid->integral += error; // 积分限幅，防止积分饱和 if (pid->integral > pid->integral_limit) pid->integral = pid->integral_limit; if (pid->integral < -pid->integral_limit) pid->integral = -pid->integral_limit; float derivative = error - pid->last_error; float output = pid->Kp * error + pid->Ki * pid->integral + pid->Kd * derivative; pid->last_error = error; return output; }

参数整定上，我用的经验主义手工整定法：

1. 先把Ki和Kd设为0，只留Kp，从小到大慢慢加，观察滴速响应曲线，找到系统开始震荡的Kp值，取一半左右作为初始Kp。
2. 然后加入Ki，用来消除稳态误差。注意Ki不能太大，否则会产生低频震荡。
3. 最后加Kd，用来抑制超调。Kd对噪声非常敏感，如果滴速值滤波没做好，Kd反而会放大抖动，所以Kd一般给很小的值就可以了。

我调出来的结果大概在Kp=8.0，Ki=0.5，Kd=0.2这个水平。不过每个人的机械结构不一样，参数会有差异，尤其是油泵的管径、电机的响应速度都会影响，所以这批代码里我把PID参数定义成了宏，在pid.h里可以直接改。

需要注意的是，PID输出值（即PWM占空比）需要做输出限幅。我把PWM占空比限制在0到1000（对应0到100%），防止PID计算出界值导致电机突然全速运转，那在输液场景下是很危险的。

3.4 按键扫描与LCD显示更新逻辑

按键扫描放在1ms的定时器中断里，逻辑很简单：按键状态改变后开始计时，超过20ms且状态稳定才判定为有效按键。

LCD的更新频率不需要太高，我设定主循环每200ms刷新一次屏幕。因为1602LCD写数据本身比较耗时，如果频率太高反而浪费CPU时间。屏幕第一行显示“Set:xxx/min”,第二行显示“Now:xxx/min State:Normal/Alarm”。

4. Proteus仿真工程：从零搭建与常见坑

4.1 仿真工程包含哪些元件

Proteus仿真工程是我这次开源的重点之一。很多初学者卡在“代码写好了但仿真跑不通”这一步，多半是原理图连接或者元件参数设置有问题。

我这个仿真工程包含的元件清单如下：

• STM32F103C8T6（Proteus库里叫STM32F103C8）
• LM393比较器
• 红外发射管和光敏三极管模型（用LDR光敏电阻模拟液滴遮挡）
• ULN2003驱动芯片
• DC电机模型
• 1602LCD屏幕（LM016L）
• LED指示灯和蜂鸣器（报警）
• 按键矩阵
• 虚拟终端（Virtual Terminal）用于串口调试

关注仿真的朋友会问：液滴检测在仿真里怎么模拟？这个我用的办法是用一个按钮开关并联在光敏电阻两端，每按一次模拟一个液滴落下。也可以用一个方波信号发生器，设置频率等于滴速，接在比较器输入端，这样更加自动化，演示效果也更好。

仿真工程文件里我已经把比较器阈值调整好了，虚拟终端也能正常输出串口调试信息。打开Proteus工程，加载编译好的HEX文件（工程里附带了一个已经编译好的hex），点运行就能看到动态效果：屏幕显示当前滴速，调节按键设定目标值，电机会跟着转动。

4.2 仿真跑不通？排查思路分享

这几类问题是仿真新手最容易遇到的：

第一，程序下载不进去。Proteus里双击STM32芯片，在Program File属性里选择HEX文件。很多人下载不了是因为没有设置Crystal Frequency属性，默认是4MHz，和代码里的系统时钟配置不匹配，程序运行就会卡死。我建议设置成8MHz或者72MHz，代码里用的是外部8MHz晶振倍频到72MHz。

第二，LCD显示乱码。多半是I2C地址不对。PCF8574的I2C地址默认是0x27，如果原理图上A0-A2引脚接了上拉电阻，地址会变，需要在代码里对应修改。

第三，虚拟终端没有输出。虚拟终端的TX/RX和USART引脚的接法容易接反。虚拟终端的RXD接STM32的TX引脚（PA9），TXD接STM32的RX引脚（PA10），而且两个设备的地必须连接好。

第四，电机总是转个不停。检查PWM引脚是否正确配置。如果电机控制引脚悬空了，ULN2003输入端的下拉状态可能会导致输出端误导通。

4.3 仿真和实物的差异提醒

我必须强调一个事实：Proteus仿真通过不等于硬件就能正常工作。仿真环境的理想化和真实世界的差距主要体现在这几个地方：

• 仿真里没有接触电阻、没有导线压降、没有电磁干扰，所以信号质量永远是完美的。
• 仿真里的LM393、ULN2003都是理想模型，不涉及真实的传输延迟和饱和压降。
• 仿真里没法很好地模拟电机堵转、电源纹波这些现实问题。

所以如果你是课程设计需要做实物的，千万不要因为仿真跑通了就觉得万事大吉，硬件调试时该踩的坑一个都不会少。反过来，如果你只是为了交仿真作业，那这批代码和工程文件足够让你拿一个不错的分数。

5. 通信功能与上位机联动

5.1 RS485通信协议设计

RS485通信在医疗监护场景里非常重要，因为医院病房的传输距离可能超过50米，普通TTL串口的电平标准撑不住这么长距离的信号传输。RS485用差分信号传输，抗共模干扰能力强，布线也简单，所以仍然是工业现场和医疗设备里的主流选择。

协议方面，我定义了一个简单但健壮的数据帧格式：

帧头0xAA 0x55可以帮助接收端快速同步，即使前一个数据帧传输中途丢失，接收方也能重新对帧。

地址字段用于区分不同床位的输液终端，比如1号床地址是0x01，2号床是0x02，护士站电脑作为主机轮询各从机。

校验用异或比较简单，虽然强度比不上CRC16，但在这个应用场景下，配合帧头同步已经足够实用。

5.2 串口调试输出的经验

开发调试时，我习惯把关键状态信息通过USART1输出到电脑串口助手。波特率设定为115200，打印格式大概是：

[Drip] SPeed: 82 DPM, Set: 80 DPM, PWM: 43.2% [Alarm] Over speed! Current 85 DPM > Limit 80 DPM

这些打印信息帮助我快速定位了很多问题。比如PID参数整定的时候，光看电机的转动速度很难判断控制效果，但通过串口实时观察滴速变化曲线，就能很直观地看到超调量和稳态误差。我习惯配合SerialPlot这类工具把数据画成曲线，效果比看数字直观得多。

5.3 上位机部分

这次开源的是下位机源码和仿真，上位机软件我只提供了一个简单的Python演示脚本，主要是为了验证RS485通信协议的正确性。完整的上位机界面程序还在整理，后续会补发，请大家留意更新。

演示脚本的逻辑很简单：打开串口、发送读参数指令、解析返回帧并打印滴速信息。用pyserial库实现，大概几十行代码就能跑起来。

6. 关键功能调试与异常处理

6.1 报警系统：别等危险发生了才响

输液监护系统的报警机制，和普通电子制作里的“响了就行”完全不是一个级别。我把报警分了三个等级：

• 一级报警（提示）：滴速偏差在±15%以内，蜂鸣器每2秒短鸣一声，LED慢闪。
• 二级报警（警告）：滴速偏差超过±15%但低于±30%，蜂鸣器每500ms鸣叫一声，LED快闪。
• 三级报警（严重）：滴速偏差超过±30%，或者检测到输液完成（长时间无滴速），蜂鸣器连续鸣叫，LED常亮，同时自动停止电机并锁定执行机构，必须人工复位。

这个分级逻辑在代码里通过一个简单的状态机实现。每一级报警除了声光提示外，还会通过RS485上传报警帧到护士站，方便远程处理。

6.2 输液完成检测：怎么判断“滴完了”

输液完成检测是实际使用中一个很关键的功能。当输液瓶空了，不再有液滴落下，滴速降为0。但这里有个陷阱：单纯检测滴速为0不够，因为电机停转时滴速也会变成0。

我采用的双重判定逻辑是：

1. 滴速为0持续超过30秒。
2. 同时压力传感器检测到的管道压力低于某个阈值（说明不是堵管导致的停液）。

两个条件同时满足，才判定为“输液完成”，进入三级报警并锁定系统。这样能避免把“堵管”误判成“输完”的情况，提高报警准确性。

// 输液完成判定伪代码 if (speed_dpm == 0) { if (no_drip_time > 30s && pressure < PRESSURE_THRESHOLD) { alarm_level = LEVEL3; motor_stop(); system_locked = 1; } }

6.3 看门狗技术：程序卡死也能自救

嵌入式系统最怕的就是程序死循环或者跑飞了。尤其是医疗设备，如果设备在监护过程中死机了，后果不堪设想。我的代码里启用了独立看门狗（IWDG），在初始化时设置超时时间为1秒，然后主循环每200ms喂狗一次。如果程序卡死超过1秒，看门狗会强制复位系统重新运行。

这个功能在仿真里不容易体现，但实机上非常重要。我在代码的main函数里加了IWDG初始化，注释也写得比较详细，建议大家移植到自己的工程时一定保留这个功能。

7. 常见问题排查与优化记录

7.1 滴速检测不准，波动大，怎么排查

按照我的调试经验，滴速检测波动大通常从以下三个方向排查：

1. 光电传感器阈值设置不当。如果比较器阈值设置得太接近信号电平，微小干扰就能触发翻转。需要根据示波器观察到的信号幅值，把阈值设定在信号摆幅的50%左右。
2. 环境光干扰。红外接收管对阳光和室内照明中的红外分量有响应。解决办法是给传感器加上遮光罩，或者在软件上做窗口判决——只接受脉宽在一定范围内的信号。
3. 滤波算法参数不合适。如果滤波窗口太小，干扰信号没有被有效抑制；如果窗口太大，系统响应变慢。我最终用的10次中位值平均是在动态响应和抗干扰之间的平衡。

7.2 PID参数整定经验记录

PID参数整定我走了不少弯路。一开始参考的是位置式PID的经典整定流程，结果发现增量式PID的表现和位置式还是有些区别的。位置式对积分项的依赖更强，而增量式由于自带惯性，Kp可以给得比较激进一些。

实际调参过程中最有用的工具就是串口曲线可视化。我把设定值和实测滴速通过串口上传，用SerialPlot画成两条曲线，直观看到：

• Kp太小：实测值到达设定值的时间很长，曲线平缓上升，误差长时间存在。
• Kp太大：实测值在设定值附近大幅震荡，系统不稳定。
• Ki太大：曲线出现低频爬坡式震荡，电机转速时快时慢，听起来就是“嗡嗡”一阵一阵的。
• Kd合适：超调量明显减小，系统平稳接近设定值。

最后定的Kp=8.0、Ki=0.5、Kd=0.2，在仿真里和实物上都表现不错，不过仅供参考。

7.3 蜂鸣器误报警问题

升级版的报警逻辑加了延时确认机制，不太容易出现误报警了。但在第一版的时候，蜂鸣器会因为滴速的瞬时波动而频繁报警，非常烦人。

解决办法是加了一个报警持续时间门槛。检测到滴速超限后，不是立即触发报警，而是连续超限超过3秒才确认报警。如果只是单次干扰造成的瞬时超限，就会被过滤掉。这个思路在工业现场叫做“延迟确认”，实质上是利用时间维度做了一次滤波，效果立竿见影。

8. 开源资料清单与使用建议

8.1 这次开源了哪些文件

这次打包开源的资料包括以下内容：

• 源代码完整工程：基于MDK5（Keil uVision5）开发环境，使用标准外设库，注释覆盖率大概在60%左右，关键函数都有详细说明。
• Proteus仿真工程：版本为Proteus 8.11以上，包含完整的原理图连接和元件参数设置，加载固件后可直接运行演示。
• 原理图PDF版本：AD绘制的原理图导出，方便快速查阅和打印。
• PCB设计文件：这次一并开源了PCB工程，两层板设计，元件封装都已经调好，可以直接送去打样。
• 使用说明书：包含硬件连接、烧录步骤、按键操作说明，以及PID参数调整指南。
• BOM物料清单：所有元件的型号、数量、封装、参考价格，照着采购就能焊一套。

8.2 给初学者的上手路线建议

经常有人问我，拿到这些资料不知道从哪看起。我的建议是从仿真开始，然后看代码，最后做实物。

第一步，先打开Proteus仿真工程，跑起来看看效果，对系统有一个整体认识。

第二步，打开代码工程，对照原理图，先看main.c里的初始化流程，再看各个外设的驱动代码。重点是定时器输入捕获和PID部分，那两块是系统核心。

第三步，如果条件允许，再自己动手搭一套实物。根据自己的实际情况调整参数。

8.3 后续可以扩展的方向

这个项目的扩展空间其实很大，这里列几个我最近在思考的方向：

• LoRa无线传输：替代RS485实现无线组网，解决病房布线困难的问题。
• 触摸屏界面：用串口屏替代1602LCD，人机交互体验会好非常多。
• RTOS移植：把裸机程序改成FreeRTOS，用任务管理来处理不同优先级的功能，系统的实时性会更好维护。
• 边缘AI：用简单的机器学习算法（比如异常流量检测）来预测输液反应风险，这个方向比较前沿，适合想挑战自己的朋友。

8.4 最后的体验分享

做完这套系统，我最深的感触是，嵌入式项目最花时间的地方往往不是写代码，而是调试和验证。尤其是在硬件和软件交界的地方——信号调理、电机驱动、传感器校准，这些地方出了问题，光看代码是找不出原因的，必须结合原理图和波形去分析。

另外有个小经验想分享给做毕设的朋友：做实物的时候，尽量买两个滴速传感器模块。红外对管这类器件比较脆弱，焊接时高温容易损坏，静电也可能打坏。我调试过程中就烧了两个传感器，幸好备份充足才没有耽误进度。如果你也想做医疗相关方向，这套系统是一个非常合适的起点，不仅能学到完整的嵌入式开发流程，还能深入理解闭环控制在实际应用中的价值。

有问题欢迎在评论区交流，我会尽量抽空回复大家。项目文件已经上传，下载后如果仿真跑不起来或者代码有编译问题，先对照说明文档排查一遍，还不行就留言说吧。