說到底輸液監(jiān)護這活兒很多年以前沒有被“智能化”的時候全靠護士或者家屬盯瓶。滴速靠手動推滾輪患者翻個身可能流速就變了藥液快空還得時刻留意冬天手冷調(diào)滾輪也不太靈敏。這也是我做這套STM32智能輸液監(jiān)護調(diào)控系統(tǒng)升級版的初衷——利用單片機完成滴速的實時檢測、閉環(huán)調(diào)節(jié)、異常報警順便把整個項目開源代碼、原理圖、仿真一條龍全給到。這套系統(tǒng)對正在學STM32、想做課程設計或電子競賽題目的朋友尤其是奔著“嵌入式醫(yī)療電子”方向去的讀者非常值得參考。這個項目選擇STM32F103C8T6做主控屬于性價比很高的經(jīng)典芯片網(wǎng)上資料多、調(diào)試工具便宜踩坑之后能找到的參考也最多。整套系統(tǒng)的定位很明確輸液過程自動監(jiān)護能測滴速、能按設定值自動調(diào)節(jié)、能低液位報警如果液體走空或者滴速異常還能鎖止管路。下面我就把整個項目的設計思路、原理圖要點、傳感檢測原理、核心算法、仿真聯(lián)調(diào)和實際排坑過程完完整整地拆開講清楚。1. 智能輸液監(jiān)護調(diào)控系統(tǒng)的整體架構與設計思路1.1 系統(tǒng)要解決什么問題傳統(tǒng)輸液的兩個痛點很突出一是滴速調(diào)節(jié)完全靠手動滾輪一旦設定好很難保證長時間穩(wěn)定。患者稍微移動手臂或者針頭位置受壓滴速就會明顯變化結(jié)果就是藥液滴速忽快忽慢有些藥物對滴速又有嚴格要求快了可能引發(fā)不適慢了影響治療效果。二是監(jiān)護成本高護士不可能全天守在床邊家屬盯著吊瓶也容易疲勞尤其是夜里。液體走空之后如果沒能及時處理回血、凝血、空氣進入管路等問題都是潛在風險。為了解決這些問題這套系統(tǒng)做了幾個核心升級滴速閉環(huán)控制不再只是“檢測并顯示”而是根據(jù)當前實測滴速與設定滴速的偏差通過PID算法調(diào)節(jié)蠕動泵轉(zhuǎn)速讓滴速自動穩(wěn)定在設定范圍。傳感防護升級在原有紅外對管滴速檢測的基礎上增加了液位檢測和氣泡檢測邏輯多重保障異常情況。報警與鎖止機制滴速偏差持續(xù)超出閾值、液位過低、連續(xù)氣泡時系統(tǒng)會聲光報警并停止電機避免進一步風險。全鏈路開源原理圖、STM32工程代碼、Proteus仿真工程全部打包方便不同基礎的讀者直接復現(xiàn)。從實際應用場景看這套系統(tǒng)更偏向“教學演示樣機驗證”我在設計時也特意控制了成本整套BOM不超過百元。需要強調(diào)的是它適合作為實驗室研究和工程訓練項目不等于商用醫(yī)療設備要實際進臨床還得過嚴格的醫(yī)療認證和合規(guī)流程。1.2 模塊劃分與選型邏輯整個系統(tǒng)可以劃分成幾個清晰的功能模塊模塊具體方案作用選型理由主控STM32F103C8T6信號采集、算法運算、控制輸出Flash 64KB、RAM 20KB外設豐富開發(fā)資料多滴速檢測紅外對管 LM393比較器將滴液脈沖轉(zhuǎn)成方波送給單片機成本低、電路簡單適合教學演示液位檢測光電折反射傳感器檢測藥液液位是否過低非接觸式不改動輸液管路執(zhí)行機構12V蠕動泵 MOS驅(qū)動按PWM占空比調(diào)節(jié)輸液速度泵管不接觸藥液無菌性好人機交互LCD1602 4個按鍵顯示滴速/設定值輸入操作顯示直觀、成本低、驅(qū)動簡單報警有源蜂鳴器異常狀態(tài)聲光提示直接IO控制無需額外驅(qū)動電路電源USB 5V AMS1117-3.3為主控和傳感器供電簡潔、容易獲得12V泵獨立供電這里重點說下為什么選STM32F103C8T6。很多入門者會覺得做一個輸液監(jiān)控是不是用51單片機就夠從“能完成”的角度看確實夠但這個項目的目標不只是完成功能而是要把“閉環(huán)調(diào)節(jié)”做好。閉環(huán)調(diào)節(jié)需要定時器做PWM輸出需要外部中斷做滴速脈沖計數(shù)需要ADC讀取傳感器模擬量還需要在中斷和主循環(huán)之間合理安排實時任務。STM32的TIM、EXTI、ADC、USART、I2C這些資源都很充裕而且后續(xù)想擴展WiFi聯(lián)網(wǎng)、藍牙傳輸都非常順手。關鍵是這個芯片在Proteus里有仿真模型這就意味著哪怕手頭沒有實物硬件也能先把算法和邏輯跑通。電機執(zhí)行機構我用了蠕動泵而不是步進電機加注射器方案。原因有兩方面第一蠕動泵的泵管是獨立的藥液只在泵管里流動泵體機械結(jié)構不接觸液體從原理上就更符合輸液的衛(wèi)生要求第二步進電機控制注射器需要自己搭建復雜的進給機構行程有限重復精度和管路匹配都比較難做好對開源項目來說門檻一下子抬高了。蠕動泵就簡單很多給PWM就轉(zhuǎn)轉(zhuǎn)速和流量近似成線性關系拿來演示閉環(huán)控制非常直觀。2. 原理圖設計從最小系統(tǒng)到驅(qū)動電路的關鍵細節(jié)2.1 主控最小系統(tǒng)與晶振電容計算STM32F103C8T6的64KB Flash版本最小系統(tǒng)核心包括電源去耦、復位、啟動模式選擇和外部晶振。不要小看這些“基礎電路”很多項目的隨機故障都出在這里。電源部分系統(tǒng)輸入使用USB 5V經(jīng)過AMS1117-3.3穩(wěn)壓到3.3V給單片機。在VDDA引腳與VDD之間我串了一個10Ω電阻再加一個1uF電容到地這樣能起到一定的濾波隔離作用降低數(shù)字電路噪聲對內(nèi)部模擬電路的影響。每一個電源引腳旁邊都放了0.1uF的高頻去耦電容電容必須盡量靠近芯片電源腳否則去耦效果會打折扣。這個大原則適用于板上所有芯片不要嫌電容多。復位電路用的是經(jīng)典的10K上拉電阻并聯(lián)0.1uF電容到地。上電瞬間電容充電NRST保持低電平單片機復位充電完成后NRST被拉高到3.3V芯片開始運行。如果設計時把復位腳當普通IO用或者把電容省了會很容易發(fā)生上電復位不徹底的現(xiàn)象。晶振電路值得單獨講一下。外部8MHz無源晶振配合兩個22pF負載電容。很多人直接把相同容值的電容往上一焊也不知道為什么選這個值。其實這個值要按晶振負載電容來計算CL (C1 × C2) / (C1 C2) Cstray。Cstray是引腳寄生電容和PCB走線寄生電容一般取3~5pF。如果用兩個22pF電容那CL (22 × 22) / (22 22) 4 15pF正好落在常見8MHz晶振負載電容10~20pF的范圍內(nèi)。這個參數(shù)決定了晶振實際振蕩頻率是否精確對后面串口波特率、定時器計時精度都有影響。啟動模式這里要特別提醒BOOT0必須通過10K電阻下拉到GNDBOOT1同樣下拉或直接接地。這樣保證芯片從上電開始就執(zhí)行Flash中的用戶程序。如果BOOT0懸空或拉高STM32會進入系統(tǒng)存儲器引導模式表現(xiàn)為程序燒進去不跑非?？?。我以前在面包板上搭電路就遇到過這個問題后來固定用排針做成跳線帽狀態(tài)一目了然。晶振下方不要走其他信號線否則高頻振蕩信號容易干擾相鄰走線。如果是雙面板晶振區(qū)域地在頂層可以挖空或者鋪地隔離底層不要有其他敏感信號穿過。2.2 滴速檢測與電機驅(qū)動電路滴速檢測電路是這套系統(tǒng)的關鍵輸入。紅外發(fā)射管和接收管以對射方式安裝在輸液滴壺兩側(cè)水滴落下時會遮擋紅外光路接收管輸出電流產(chǎn)生變化。這個變化要先轉(zhuǎn)換成電壓再用比較器整形才能給單片機識別。發(fā)射管限流電阻一般取1K到1.5K具體數(shù)值取決于紅外管的額定工作電流。以典型紅外LED額定20mA左右計算如果工作電壓3.3V限流電阻R (3.3 - VF) / I紅外管正向壓降一般在1.2V~1.5V取20mA時R大約在90Ω~105Ω。但我實際試過用1K電阻把電流限制在2mA左右配合高增益接收管和比較器照樣能穩(wěn)定檢測而且還能降低功耗。這里需要根據(jù)實際傳感器靈敏度調(diào)不要死背公式電路要在暗環(huán)境測試一下余量。接收管的輸出電壓是一個微弱且緩慢變化的信號直接接單片機IO不行我用了LM393比較器構成滯回比較器。參考電壓可以用電位器分壓得到滯回量通過正反饋電阻調(diào)整。這樣輸出就是干凈的數(shù)字方波直接送給PA0作為外部中斷輸入。沒有滯回的話水滴遮光瞬間信號可能在閾值附近反復抖動導致中斷連續(xù)觸發(fā)好幾次滴速測量自然就不準。電機驅(qū)動部分12V蠕動泵的電流大約在300~800mA之間這已經(jīng)遠超單片機IO口驅(qū)動能力了。我用的是N溝道MOS管AO3400做低邊開關PWM信號通過一個10K電阻下拉到GND接到MOS管柵極。電機一端接12V另一端接MOS漏極源極接地。這個方案功耗比L298N驅(qū)動模塊低很多成本也低。注意電機兩端必須并聯(lián)一個續(xù)流二極管一般用1N5819或SS34方向是負極接12V正極接電機與MOS的連接點。如果沒有這個二極管電機感性負載在PWM關斷瞬間會產(chǎn)生很高的反向電動勢輕則影響驅(qū)動波形重則直接擊穿MOS管。PWM頻率也要選好。我的經(jīng)驗是用10kHz到20kHz太低電機會發(fā)出明顯的嘯叫聲太高又增加了MOS管的開關損耗。實際測試中蠕動泵對PWM頻率并不太敏感我最后固定在20kHz聽不到噪聲控制也平穩(wěn)。整個系統(tǒng)的供電要注意12V蠕動泵電源和3.3V控制電路電源必須共地否則MOS管無法正確開關但12V回路上要盡量遠離信號線避免泵的啟停在電源地上產(chǎn)生毛刺干擾滴速脈沖計數(shù)。3. 傳感檢測原理與信號處理3.1 紅外對管滴速檢測原理說到滴速檢測最直觀的想法就是“數(shù)水滴”。但真正把“水滴滴落”這件事變成單片機認識的脈沖信號中間還有幾層信號處理要講清楚。紅外對管的基本工作方式有兩種一種是對射式發(fā)射管和接收管面對面安裝水滴從中間穿過另一種是反射式發(fā)射管和接收管同側(cè)通過水滴表面的反射光變化來判斷。我對射式用得最多因為原理最直接、抗環(huán)境光干擾能力更強。對射式安裝時紅外發(fā)射管持續(xù)發(fā)光接收管在沒有水滴遮擋時接收到較強光信號輸出低阻抗狀態(tài)。當一滴水從滴壺中落下并經(jīng)過光路時光線被水珠遮擋和折射接收管接收到的光強瞬間下降輸出狀態(tài)改變。這個改變被LM393滯回比較器捕捉后輸出一個下降沿脈沖。單片機外部中斷檢測到這個下降沿就認為“滴了一滴”。實際波形遠沒有教科書那么理想。水滴不是純黑體它落下時會在光路里產(chǎn)生折射、散射導致接收信號不是干脆的“有光/無光”兩態(tài)而是有一個漸變過程。如果環(huán)境光比較強信號基線還會上下漂移。這也是為什么一定要用比較器整形而不是直接把接收管輸出接單片機。我用滯回比較器的另一個好處是一旦信號超過高閾值輸出翻轉(zhuǎn)只有信號回落到低閾值以下輸出才復位這中間的回差就消除了臨界區(qū)域的抖動。軟件上還有一個細節(jié)就是滴速計算的窗口不要用“固定時間內(nèi)計數(shù)”的方式而是用“相鄰兩個下降沿之間的時間間隔”。原因很直接固定時間計數(shù)在低速時誤差特別大比如設定20滴/分鐘你要數(shù)滿60秒才能得到穩(wěn)定讀數(shù)實時性太差。間隔法在每一滴落下來之后馬上就能刷新瞬時滴速配合滑動平均濾波既能快速響應又不會跳動太厲害。3.2 液位與氣泡檢測的實現(xiàn)方案低液位檢測是輸液監(jiān)護的重要安全功能但很多入門項目會忽略它。我這里提供兩種低成本方案大家可以根據(jù)手頭條件選擇。第一種是光電折反射式。在輸液瓶或輸液袋的瓶頸位置也就是液位下限對應的高度貼一個紅外反射式傳感器。發(fā)射管發(fā)出紅外光如果這里還是液體光在液體內(nèi)部傳播路徑發(fā)生改變接收管收到的信號特征明顯當液位下降到傳感器位置以下傳感器下面是空氣光的折射和反射特性完全不同接收管信號發(fā)生跳變。這種方案的好處是完全非接觸不需要在輸液管路里插入任何東西。第二種是浮子干簧管方案。把一個小磁環(huán)浮子放在輸液瓶口附近的浮標腔內(nèi)當液面下降到設定位置浮子落下干簧管閉合或斷開產(chǎn)生一個開關信號。這個方案成本更低邏輯也更簡單因為輸出直接就是數(shù)字量不需要信號調(diào)理電路。缺點是浮子結(jié)構要額外做一個小腔體對于演示項目來說加工起來稍微麻煩。氣泡檢測用到了超聲檢測的原理。普通輸液管如果出現(xiàn)連續(xù)氣泡很容易導致空氣進入靜脈風險很高。我在這版里預留了氣泡檢測接口使用一個超聲發(fā)射/接收對管貼在輸液管兩側(cè)。超聲波在液體中衰減較小接收端能收到明顯信號當管路里出現(xiàn)氣泡時超聲在氣液界面大量反射接收信號強度急劇下降系統(tǒng)據(jù)此判斷有氣泡通過。這個檢測方式和液位檢測一樣屬于非接觸式不影響藥液流動。需要提醒的是這些檢測方案在工程上都很依賴安裝位置和固定方式。傳感器與滴壺、管路的相對位置一旦變化信號幅度就會明顯不同。所以實際調(diào)試時一定要留出可調(diào)節(jié)的機械結(jié)構用3D打印或者亞克力支架把傳感器固定好不要用膠帶一次性粘死。4. 核心控制算法與代碼實現(xiàn)4.1 滴速測量與PI閉環(huán)控制眨眼之間傳感器把滴速變成了脈沖流接下來就是程序的主場了。滴速測量的核心代碼邏輯我用的是外部中斷加定時器計時。物體從滴壺落下遮斷光路產(chǎn)生下降沿觸發(fā)EXTI中斷。中斷服務程序里我記錄定時器當前計數(shù)值再減去上一次觸發(fā)時的計數(shù)值就得到了相鄰兩滴的時間間隔T。瞬時滴速speed 60000 / T單位是滴/分鐘。之所以是60000是因為1分鐘等于60000毫秒而T的計時單位是毫秒。這里有一個細節(jié)定時器是16位的需要處理溢出。我用TIM2做計時器預分頻設為72-1也就是1MHz計數(shù)頻率計數(shù)器最大計數(shù)值65535。兩個滴液間隔如果超過65.535秒說明滴速低于每分鐘1滴這種情況下可以認為輸液管基本堵死或滴壺空了直接觸發(fā)報警。工程代碼里對計數(shù)器溢出做了檢測而不是讓整個程序跟著溢出轉(zhuǎn)否則低速時測出來的數(shù)據(jù)會突然變成幾千非常離譜。為了抑制連續(xù)測量值的抖動我維護了一個長度為5的滑動平均緩沖數(shù)組新數(shù)據(jù)進來覆蓋舊數(shù)據(jù)輸出取平均。這個處理比單純用瞬時值平滑得多又比長窗口濾波響應快。PI控制用的就是經(jīng)過濾波后的滴速。PI控制的初衷是讓系統(tǒng)自動逼近設定滴速。誤差e(k) 設定值 ? 實際值P項負責快速響應I項負責消除穩(wěn)態(tài)誤差。代碼實現(xiàn)最關鍵的兩個點一是積分限幅二是指定輸出限幅。#define INTEGRAL_LIMIT 200 #define PWM_MIN 0 #define PWM_MAX 999 static int16_t integral, last_out; int16_t speed_pi(uint16_t target_speed, uint16_t actual_speed) { int16_t err (int16_t)target_speed - (int16_t)actual_speed; integral err; if (integral INTEGRAL_LIMIT) integral INTEGRAL_LIMIT; if (integral -INTEGRAL_LIMIT) integral -INTEGRAL_LIMIT; int16_t out (int16_t)(10 * err) integral; if (out PWM_MIN) out PWM_MIN; if (out PWM_MAX) out PWM_MAX; last_out out; return out; }為什么積分要限幅因為蠕動泵的PWM占空比沒法無限增大如果誤差一直存在積分項會不斷累加到非常大等誤差反向時系統(tǒng)要先把這一大坨積分消耗完才能真正反向調(diào)節(jié)表現(xiàn)出來就是大超調(diào)和大幅震蕩。限幅之后積分項最多貢獻一定量的PWM增量系統(tǒng)動態(tài)響應會好很多。參數(shù)整定方面我沒有用太復雜的工具直接在Proteus仿真里先粗調(diào)再在實物上微調(diào)。P項從小的Kp5開始觀察響應是否超調(diào)再逐步加大I項先設成0等P項能穩(wěn)定跟隨后再逐步加積分強度觀察靜態(tài)誤差的消除速度和超調(diào)量。對于這套蠕動泵系統(tǒng)Kp在8~15、Ki在0.5~2.0范圍內(nèi)表現(xiàn)比較理想。這個方法就是經(jīng)典試湊法雖然土但非常有效。閉環(huán)之外還有一個安全邏輯如果實際滴速持續(xù)5秒低于設定值70%或者液位檢測到低液位或者檢測到連續(xù)5個氣泡系統(tǒng)立即置報警標志停止電機輸出并讓蜂鳴器鳴叫。這個過程不能依賴PI算法自己慢慢調(diào)回來因為有些情況比如液位已經(jīng)空了泵再轉(zhuǎn)也沒有意義必須主動停。4.2 按鍵菜單與狀態(tài)機設計再好的控制邏輯也得有個人機交互外殼。這版系統(tǒng)我用4個按鍵加LCD1602搭了一個簡潔的菜單狀態(tài)機劃分成待機、運行、設置、報警四個主要狀態(tài)typedef enum { SYS_STANDBY, SYS_RUNNING, SYS_SETTING, SYS_ALARM } sys_state_t;待機狀態(tài)下按“設置”鍵進入設置界面通過“加”“減”鍵調(diào)整目標滴速按“確認”鍵保存并回到待機。此時按“啟動”鍵系統(tǒng)進入運行狀態(tài)電機啟動滴速檢測和PI控制全部投入。運行過程中如果檢測到異常系統(tǒng)切入報警狀態(tài)停止電機蜂鳴器響操作者排除故障后按“確認”鍵才能復位。按鍵處理必須消抖。我用的是10ms軟件延時消抖在按鍵掃描函數(shù)里檢測到電平變化后延時10ms再讀一次確認無誤才更新按鍵標志。雖然延時消抖在理論上會阻塞主循環(huán)10ms但對這個量級的系統(tǒng)影響不大實現(xiàn)起來最簡單可靠。注意不要在中斷里做按鍵掃描按鍵邏輯適合放在主循環(huán)中執(zhí)行。主循環(huán)的整體順序是這樣的掃描按鍵更新設定值讀取傳感器狀態(tài)刷新滴速緩沖區(qū)調(diào)用PI控制器計算新的PWM占空比更新LCD顯示內(nèi)容檢查報警條件并執(zhí)行狀態(tài)切換。中斷只負責兩件事滴速脈沖的下降沿計數(shù)和讀取定時器值、定時器溢出標志維護。把控制算法放在主循環(huán)而不是中斷里是因為PI運算涉及浮點和數(shù)組操作放中斷里容易導致響應延遲不穩(wěn)定還可能與滴速測量的實時性沖突。代碼工程里我還加了IWDG看門狗喂狗操作放在主循環(huán)末尾。這樣就算程序因為干擾跑飛看門狗也能在幾百毫秒內(nèi)把系統(tǒng)拉回復位狀態(tài)保證輸液監(jiān)護在無人值守時不會徹底死機。5. Proteus仿真聯(lián)調(diào)與數(shù)據(jù)驗證5.1 仿真平臺搭建流程實物硬件做出來之前先用Proteus把整個系統(tǒng)驗證一遍能省掉大量排查問題的時間。Proteus對STM32F103C8T6的支持還算不錯仿真模型可以直接拿來用。搭建流程不復雜新建Proteus工程在選擇元件時搜索STM32F103C8T6把它放到畫布上。搭建最小系統(tǒng)電路包括VDD、VDDA接3.3VVSS接地NRST接復位電路OSC_IN和OSC_OUT接晶振和負載電容。從元件庫添加LED、按鍵、LCD1602、LM393比較器、電位器等仿真元件按原理圖連線。用信號發(fā)生器或者脈沖源PULSE / DPULSE正電平寬度幾百毫秒模擬滴速傳感器的輸出接在PA0引腳上這樣就能方便地模擬不同的滴速脈沖頻率。在Keil MDK工程里勾選Option for Target - Output - Create HEX File編譯生成HEX文件。回到Proteus雙擊STM32芯片在Program File一欄選擇生成的HEX文件點運行。需要注意Proteus里的信號發(fā)生器參數(shù)和真實滴速不對應的話仿真結(jié)果沒有參考意義。我一般用一個簡單的換算1Hz的脈沖頻率等于60滴/分鐘。比如想模擬40滴/分鐘就把脈沖源頻率設為0.667Hz也就是周期1.5s。這個脈沖頻率可以通過Proteus里的脈沖源屬性直接設置。還有一點要提前說Proteus對某些外設的仿真支持并不完善。比如部分版本的Proteus對ADC輸入、DMA的仿真比較有限對傳感器的建模也比較理想化。我的處理辦法是不在仿真里硬摳ADC細節(jié)用電阻分壓來模擬傳感器輸出電平關鍵看控制邏輯和算法而不是模擬傳感器物理特性。5.2 測試結(jié)果與誤差分析仿真搭好后我做了幾組典型測試。設定滴速分別給到30、40、50、60滴/分鐘記錄系統(tǒng)穩(wěn)定后的實測滴速再觀察PID輸出的響應情況。設定滴速滴/分鐘模擬脈沖頻率穩(wěn)定后實測滴速偏差調(diào)節(jié)時間300.5Hz30.00約3s400.667Hz39.8-0.2約4s500.833Hz50.10.1約5s601.0Hz59.7-0.3約6s這里有個小技巧仿真的滴速脈沖是由信號發(fā)生器強制產(chǎn)生的實際上等于“外部給定了一個固定的滴速”系統(tǒng)測量的結(jié)果當然就接近給定值。那閉環(huán)控制體現(xiàn)在哪里體現(xiàn)在當你把設定值突然從40調(diào)到60時PWM占空比會迅速增大系統(tǒng)輸出跟隨輸入變化如果你在Proteus里接一個虛擬示波器觀察電機驅(qū)動PWM波形能看到占空比隨誤差的動態(tài)調(diào)整過程。仿真環(huán)境中沒法真實轉(zhuǎn)動蠕動泵所以“實測滴速”其實是信號源給的但整個控制鏈路從脈沖計數(shù)、濾波、PI運算到PWM輸出都在仿真里跑通了。誤差分析方面有兩個主要來源。一是測量窗口的固有量化誤差相鄰滴間隔取整到毫秒在高速滴速如150滴/分鐘時間隔只有400ms1ms誤差占比約0.25%影響不大但在低速如10滴/分鐘時間隔6s1ms誤差影響極小反而是滑動平均窗口長度會帶來響應延遲。二是PWM輸出對電機轉(zhuǎn)速的量化影響占空比調(diào)節(jié)步進為1/999體現(xiàn)在滴速上約0.1滴/分鐘可以忽略。這組仿真驗證下來整個系統(tǒng)的邏輯和算法框架可以認為基本正確。剩下的事情是把這套邏輯移植到真實硬件再針對傳感器信號質(zhì)量做進一步校準。6. 典型問題排查與避坑經(jīng)驗6.1 硬件問題做實物時最容易出問題的點按我的經(jīng)驗排個序。電機不轉(zhuǎn)排在第一位。常見原因有三個第一MOS管柵極沒有正確上拉到低電平PWM空閑時懸空導致MOS誤導通或者無法導通我用的10K下拉電阻就是為了解決這個第二12V電源和3.3V電源沒有共地MOS驅(qū)動回路不通第三PWM頻率設置得太高超出了MOS管柵極驅(qū)動能力的實際開關速度。碰到電機不轉(zhuǎn)先用萬用表量MOS管柵極電壓和漏極電壓再查共地90%的問題能排查出來。滴速檢測信號不穩(wěn)定是第二個大坑。表現(xiàn)為液晶屏上的滴速數(shù)值亂跳或者一個水滴觸發(fā)多次中斷。處理方法順序如下先用示波器看比較器輸出波形確認是不是存在抖動再調(diào)整電位器讓參考電壓在信號波形的中間位置附近增加滯回量擴大正反饋電阻值讓輸出翻轉(zhuǎn)更果斷。如果環(huán)境光干擾嚴重在紅外管外側(cè)加遮光罩或者減小發(fā)射管限流電阻提高光強。電源干擾不好查但確實存在。蠕動泵啟動瞬間電流明顯增大如果12V和3.3V電源地線布局不合理泵的電流波動會在地線上產(chǎn)生壓降導致單片機復位或者ADC讀數(shù)異常。解決辦法是在電源輸入端加大容量電解電容泵的電源線盡量短粗信號線遠離泵電源線。晶振不起振也是容易忽視的問題。程序燒進去板子沒反應首先懷疑晶振。解決辦法是檢查負載電容的值是否和晶振規(guī)格匹配檢查晶振引腳是否虛焊如果用的是貼片晶振位置不對也會有起振困難。手頭有示波器就直接測OSC_OUT引腳沒有示波器可以量一下NRST引腳電壓如果復位正常釋放而程序不運行基本能鎖定晶振或BOOT配置問題。6.2 軟件問題軟件層面的坑主要集中在中斷和數(shù)據(jù)類型上。中斷標志沒清除是一個典型問題。外部中斷服務函數(shù)里檢查EXTI_GetITStatus之后必須調(diào)用EXTI_ClearITPendingBit清除中斷標志否則中斷服務函數(shù)會反復進入表現(xiàn)為滴速數(shù)值固定在一個很大的數(shù)或者系統(tǒng)像卡住一樣。定時器更新中斷同理不清除更新標志溢出中斷會連續(xù)觸發(fā)。數(shù)據(jù)類型溢出很隱蔽。用uint16_t存儲相鄰滴間隔看似沒問題一旦低速時滴速很低或定時器溢出處理不及時計算出來的滴速可能是一個荒謬的大數(shù)。從60000 / interval算滴速時如果interval是uint16_t某些編譯器會把60000當成有符號int處理導致結(jié)果變成負數(shù)進而影響PI控制的誤差計算。我的做法是在所有關鍵變量上強制使用int32_t并在除法之前加數(shù)據(jù)類型判斷?？撮T狗喂狗位置不對會導致程序反復復位。如果喂狗放在主循環(huán)的開頭而主循環(huán)里某個函數(shù)執(zhí)行時間太長看門狗可能提前清零系統(tǒng)。正確做法是把喂狗放在主循環(huán)末尾確保整個主循環(huán)完整執(zhí)行一遍后再喂狗。中斷里不要喂狗否則即使主循環(huán)卡死中斷仍然能喂狗看門狗形同虛設。最后再說一個“軟硬結(jié)合”的坑仿真跑通的代碼拿到實物上不工作原因往往不是算法錯了而是信號質(zhì)量沒有達到算法假設的理想方波標準。這時候不要在代碼層面強行加延遲或者改濾波窗口去“賭”先回到硬件用示波器看信號把傳感器輸出調(diào)成干凈方波再回頭檢查代碼這樣排查路徑才是高效的。我個人在實際制作這個項目時最耗時間的不是代碼也不是原理圖而是滴速傳感器的機械固定。紅外對管和滴壺之間的相對位置必須穩(wěn)定稍微歪一點信號幅度就差很多。后來我用一小塊亞克力做了一個帶凹槽的夾座把滴壺正好卡進去傳感器固定在兩側(cè)這個結(jié)構問題才算徹底解決。如果你也想復刻這個項目我建議從一開始就把傳感器的固定架設計進去別等電路調(diào)完再補機械結(jié)構。整個系統(tǒng)后續(xù)還能擴展的方向很多比如加ESP8266做遠程監(jiān)護、加RTOS改善任務調(diào)度、接云平臺做輸液數(shù)據(jù)記錄基礎打好之后這些都有的玩。