簡介本資源是一套基于STM32的智能垃圾桶完整嵌入式開發(fā)項目面向電子類、物聯(lián)網(wǎng)及自動化專業(yè)初學(xué)者與課程設(shè)計實踐者解決多傳感器融合、自動控制與環(huán)境監(jiān)測等典型物聯(lián)網(wǎng)應(yīng)用場景問題。項目涵蓋超聲波容量檢測、紅外人體感應(yīng)翻蓋舵機驅(qū)動、光敏LED調(diào)控、DHT11溫濕度采集、MQ-135空氣質(zhì)量監(jiān)測、OLED本地顯示及模擬Wi-Fi數(shù)據(jù)上傳等功能具備完整的軟硬件協(xié)同邏輯。壓縮包含280個文件總計8.69MB其中C/H源碼文件共92個含stm32f10x系列外設(shè)驅(qū)動編譯輸出相關(guān)文件axf/hex/asm/map等約20個Proteus仿真工程pdsprj11個Keil工程配置文件uvprojx/uvoptx及調(diào)試配置dbgconf若干結(jié)構(gòu)清晰便于分模塊學(xué)習(xí)與仿真驗證。目前已有200人學(xué)習(xí)下載提供可直接編譯運行的工程框架、傳感器驅(qū)動例程、OLED界面代碼及Proteus仿真電路圖是理解STM32多任務(wù)傳感系統(tǒng)集成的優(yōu)質(zhì)實踐素材。1. 為什么做一個基于STM32的智能垃圾桶需求復(fù)盤做這個項目的起因其實挺實際的。家里用的是帶蓋的普通垃圾桶每次丟垃圾都得伸手掀蓋手上沾著東西或者正拎著濕垃圾的時候特別不方便。網(wǎng)上那種感應(yīng)垃圾桶又貴又閹割能實現(xiàn)的功能很有限不如自己動手做一個?！盎赟TM32的智能垃圾桶”這名字聽起來很“嵌入式畢設(shè)風(fēng)”但它本質(zhì)上的核心需求只有幾個檢測有人靠近、自動開蓋、延時關(guān)蓋、防夾手、狀態(tài)反饋。至于聯(lián)網(wǎng)上報、語音提醒這些都是錦上添花可以在第一版跑通之后再逐步往上加。我在設(shè)計這個項目時給自己定了幾條原則主控一定要用STM32生態(tài)成熟資料好找。不管是F103還是F401都行我實際用的是STM32F103C8T6性價比高入門資料鋪天蓋地踩坑了也有人討論過。傳感器選型不能太玄學(xué)。紅外熱釋電、超聲波測距都是穩(wěn)定又不貴的方案沒必要一上來就上ToF激光測距。控制邏輯必須有“防呆”。蓋子夾到手的場景在真實使用中一定會出現(xiàn)所以防夾邏輯不是可選項而是必須做。這篇博文我會把完整的硬件選型、電路設(shè)計、單片機軟件框架、關(guān)鍵代碼邏輯、以及我在調(diào)試過程中踩過的坑全部寫清楚。如果你想復(fù)現(xiàn)這篇內(nèi)容基本可以當工程文檔用。適合的人包括正在做課設(shè)/畢設(shè)的學(xué)生、想給家里做智能家居小電器的嵌入式愛好者、以及想學(xué)STM32但缺一個完整項目練手的朋友。2. 硬件方案與核心器件選型邏輯2.1 整機硬件框架先看整機的框圖邏輯我用文字描述不用圖重點是把信號流向講清楚。整個系統(tǒng)分四層感知層人體感應(yīng)模塊HC-SR501熱釋電或者超聲波測距模塊HC-SR04用來檢測人是否靠近。兩個方案二選一也可以都裝用邏輯“或”來處理?？刂茖覵TM32F103C8T6最小系統(tǒng)板負責(zé)所有邏輯決策檢測距離/人體信號、判斷開蓋條件、驅(qū)動舵機/電機、控制LED狀態(tài)燈和蜂鳴器。執(zhí)行層SG90舵機或者MG995重載舵機驅(qū)動垃圾桶蓋OLED屏幕顯示當前狀態(tài)蜂鳴器做出聲音反饋。通信層可選ESP8266或者HC-05藍牙模塊負責(zé)把垃圾桶的狀態(tài)上報到手機或者云平臺。這種分層設(shè)計的好處是排查故障的時候可以直接按照“信號從傳感器到MCU再到執(zhí)行器”的鏈路來定位不用東翻西找。2.2 主控選型細節(jié)STM32F103C8T6這顆芯片F(xiàn)lash 64KBRAM 20KB主頻72MHz。很多人可能擔(dān)心這個配置夠不夠用我實際測下來的結(jié)論是帶FreeRTOS跑三個任務(wù)加外設(shè)驅(qū)動Flash占用在40%左右RAM占用在30%左右非常寬裕。如果你手頭只有F103RCT6或者F401CCU6引腳兼容性需要重新確認但代碼邏輯基本可以無縫遷移。我的建議是別糾結(jié)于具體型號先把手頭有的板子用起來功能邏輯是通用的。關(guān)于最小系統(tǒng)板的選擇我踩過一個坑市面上那些幾塊錢的“藍板”STM32F103C8T6有些批次用的晶振是貼片8MHz有些是插件晶振雖然都是8MHz但PCB設(shè)計有差異會在低速模式LSI/LSE下出現(xiàn)RTC跑不準的問題。我這個項目用不到RTC所以影響不大但如果你打算加定時開蓋功能建議單獨校準一下RTC。2.3 傳感器的比較與選用這個項目里最核心的感知器件有兩種選擇紅外熱釋電HC-SR501和超聲波HC-SR04。對比項HC-SR501紅外熱釋電HC-SR04超聲波檢測原理檢測人體紅外輻射變化發(fā)射超聲波并接收回波檢測距離3~7米可調(diào)2cm~400cm可調(diào)功耗極低微安級較低工作時約15mA誤觸發(fā)情況遇熱源/陽光直射會誤觸發(fā)對軟性物體反射差適用場景人走到垃圾桶附近觸發(fā)開蓋精確測距判斷人/物距離我最終兩個都裝了。邏輯是超聲波作為主檢測檢測距離小于40cm判定“有人靠近”觸發(fā)開蓋紅外熱釋電作為輔助防止人站在側(cè)面但沒對準超聲波探頭時漏觸發(fā)。這里有個細節(jié)HC-SR501上電后有大約30秒到1分鐘的“預(yù)熱時間”期間會頻繁誤觸發(fā)。這不是模塊壞了而是內(nèi)部的熱釋電傳感器正在穩(wěn)定。實機調(diào)試時一定要等它預(yù)熱完再測。2.4 執(zhí)行器選型與驅(qū)動電路執(zhí)行器選擇上輕量版用SG90舵機9g扭矩約1.8kg·cm蓋子輕的話足夠如果你給垃圾桶換了一個又大又重的實木蓋那就得用MG995或者MG996R扭矩約13kg·cm能帶得動。SG90的驅(qū)動電路很簡單信號線直接接STM32的PWM輸出引腳我用的PA0TIM2_CH1VCC接5VGND共地。注意如果舵機堵轉(zhuǎn)電流可能沖到500mA以上別再和其它傳感器共用同一路5V最好獨立供電或者加一個100uF以上電解電容做緩沖否則你會看到STM32隨機重啟——這是我第一版測試時真實遇到過的。MG995需要用外部電源供電信號線雖然也能接3.3V但最好通過一個電平轉(zhuǎn)換電路接到5V邏輯避免信號不穩(wěn)定導(dǎo)致舵機抖動。2.5 電源系統(tǒng)設(shè)計電源是整個項目中“最不容易出問題但一出問題最難查”的部分。我的供電方案是主供電AC-DC適配器輸出5V/2A或者12V適配器降壓到5VSTM32供電5V轉(zhuǎn)3.3V用AMS1117-3.3舵機供電5V直接接入獨立供電這里最大坑點在于舵機和傳感器共用5V電源時會引入嚴重的紋波。舵機起轉(zhuǎn)瞬間電流會拉低電壓傳感器特別是超聲波就會報錯。排查手段很簡單用萬用表測舵機啟動瞬間的電壓跌落如果低于4.5V就需要換電源或者加電容。3. STM32軟件工程結(jié)構(gòu)與核心外設(shè)配置3.1 工程組織方式我用的開發(fā)環(huán)境是STM32CubeIDE配合STM32CubeMX做初始化配置。為什么不用Keil因為CubeIDE自帶編譯鏈、調(diào)試器集成和FreeRTOS的圖形化配置做這種中小型項目省心很多。但如果你是Keil黨代碼邏輯一樣能遷移只是初始化部分要照著HAL庫手動敲。工程目錄按功能模塊拆Core/ Inc/ // 頭文件 Src/ // main.c, gpio.c, timer.c 等 Drivers/ BSP/ // 板級驅(qū)動oled.c, servo.c, ultrasonic.c App/ // 業(yè)務(wù)邏輯trash_can.c, network.c ThirdParty/ FreeRTOS/ // 操作系統(tǒng)內(nèi)核 ESP8266/ // 無線模塊驅(qū)動3.2 關(guān)鍵外設(shè)配置思路配置時鐘外部8MHz晶振倍頻到72MHz主頻。在CubeMX中配置HSE為Crystal/Ceramic ResonatorPLL倍頻設(shè)為x9。配置GPIOPA0TIM2_CH1舵機PWM輸出PA1超聲波Trig輸出復(fù)用推挽輸出PA2超聲波Echo輸入浮空輸入或上拉輸入PB8/PB9I2C1接OLED屏幕PA9/PA10USART1接ESP8266PB10/PB11USART3接串口調(diào)試配置定時器TIM264分頻ARR19999輸出1kHz~200Hz可調(diào)PWM控制舵機角度TIM4作為系統(tǒng)時基或編碼器輸入用于超聲波回波計時定時器輸入捕獲用TIM4_CH1做Echo脈沖寬度測量超聲波測距的計時精度非常關(guān)鍵。我建議用定時器輸入捕獲模式而不是簡單的HAL_GetTick()輪詢因為HAL_GetTick()的分辨率是1ms測距誤差會達到40cm以上完全不可用。輸入捕獲的分辨率可以做到1us測距精度在厘米級。3.3 HAL庫下的Gpio和定時器代碼骨架先說GPIO初始化。不管是CubeMX生成還是手動寫最終效果類似這樣void MX_GPIO_Init(void) { GPIO_InitTypeDef GPIO_InitStruct {0}; __HAL_RCC_GPIOA_CLK_ENABLE(); __HAL_RCC_GPIOB_CLK_ENABLE(); // 超聲波Trig引腳 HAL_GPIO_WritePin(GPIOA, GPIO_PIN_1, GPIO_PIN_RESET); GPIO_InitStruct.Pin GPIO_PIN_1; GPIO_InitStruct.Mode GPIO_MODE_OUTPUT_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); // 超聲波Echo引腳輸入捕獲模式需要復(fù)用為TIM4_CH1 GPIO_InitStruct.Pin GPIO_PIN_2; GPIO_InitStruct.Mode GPIO_MODE_AF_PP; GPIO_InitStruct.Pull GPIO_NOPULL; GPIO_InitStruct.Speed GPIO_SPEED_FREQ_HIGH; GPIO_InitStruct.Alternate GPIO_AF2_TIM4; HAL_GPIO_Init(GPIOA, GPIO_InitStruct); }再說舵機PWM初始化void MX_TIM2_Init(void) { TIM_OC_InitTypeDef sConfigOC {0}; TIM_MasterConfigTypeDef sMasterConfig {0}; htim2.Instance TIM2; htim2.Init.Prescaler 72 - 1; // 72MHz/72 1MHz計數(shù)周期1us htim2.Init.CounterMode TIM_COUNTERMODE_UP; htim2.Init.Period 20000 - 1; // 20ms周期對應(yīng)50Hz htim2.Init.ClockDivision TIM_CLOCKDIVISION_DIV1; HAL_TIM_PWM_Init(htim2); sConfigOC.OCMode TIM_OCMODE_PWM1; sConfigOC.Pulse 1500; // 初始1.5ms高電平舵機中位 sConfigOC.OCPolarity TIM_OCPOLARITY_HIGH; sConfigOC.OCFastMode TIM_OCFAST_DISABLE; HAL_TIM_PWM_ConfigChannel(htim2, sConfigOC, TIM_CHANNEL_1); }這里有個HAL庫的坑很多人直接用HAL_TIM_PWM_Start(htim2, TIM_CHANNEL_1)啟動PWM但忘記調(diào)__HAL_TIM_SET_COMPARE(htim2, TIM_CHANNEL_1, pulse)設(shè)置占空比結(jié)果舵機死活不動。正確做法是先啟動PWM再持續(xù)更新比較寄存器實現(xiàn)角度控制。3.4 超聲波測距的兩種實現(xiàn)比較超聲波測距的核心是測量Echo引腳上高電平的持續(xù)時間。常見實現(xiàn)方法有兩種阻塞式輪詢和輸入捕獲外部中斷。阻塞式輪詢代碼簡單但有一個致命的缺點程序在等待Echo回高電平的過程中不能做任何事一旦傳感器無響應(yīng)比如探頭臟了程序會卡死在while循環(huán)里。我在第一版里用了阻塞方式結(jié)果后來在FreeRTOS環(huán)境下這個while等待直接導(dǎo)致低優(yōu)先級任務(wù)餓死。輸入捕獲中斷才是生產(chǎn)級寫法。邏輯是觸發(fā)模式Trig引腳輸出10us高電平等待模式開啟Echo引腳的上升沿中斷上升沿中斷中記錄當前定時器值然后切換為下降沿中斷下降沿中斷中計算高電平持續(xù)時間和距離置位“測距完成”標志位具體代碼骨架volatile uint32_t echo_start_time 0; volatile uint32_t echo_end_time 0; volatile uint8_t echo_measure_done 0; void HAL_GPIO_EXTI_Callback(uint16_t GPIO_Pin) { if (GPIO_Pin ECHO_PIN_Pin) { if (HAL_GPIO_ReadPin(ECHO_PIN_Port, ECHO_PIN_Pin) GPIO_PIN_SET) { echo_start_time __HAL_TIM_GET_COUNTER(htim4); // 記錄上升沿 } else { echo_end_time __HAL_TIM_GET_COUNTER(htim4); // 記錄下降沿 echo_measure_done 1; } } } float get_ultrasonic_distance_cm(void) { uint16_t us_count 0; float distance 0.0f; echo_measure_done 0; HAL_GPIO_WritePin(TRIG_PIN_Port, TRIG_PIN_Pin, GPIO_PIN_SET); delay_us(10); HAL_GPIO_WritePin(TRIG_PIN_Port, TRIG_PIN_Pin, GPIO_PIN_RESET); // 等待回波完成超時保護 uint32_t timeout HAL_GetTick(); while (!echo_measure_done) { if (HAL_GetTick() - timeout 100) break; // 100ms無響應(yīng)則放棄 } if (echo_measure_done) { us_count echo_end_time - echo_start_time; distance us_count * 0.034f / 2.0f; // 聲速340m/s往返距離除2 } return distance; }4. 智能控制邏輯與FreeRTOS任務(wù)劃分4.1 狀態(tài)機設(shè)計垃圾桶不能只靠簡單的if-then開關(guān)來管理。實際使用中有很多種狀態(tài)待機、有人靠近、蓋子正在打開、蓋子完全打開、有人離開、蓋子正在關(guān)閉、防夾回退、低電量提示、蓋子感應(yīng)異常。我定義了一個枚舉狀態(tài)機typedef enum { TRASH_STATE_IDLE 0, TRASH_STATE_DETECTED, TRASH_STATE_OPENING, TRASH_STATE_OPENED, TRASH_STATE_CLOSING, TRASH_STATE_ANTI_PINCH, TRASH_STATE_BLOCKED, TRASH_STATE_BATTERY_LOW } trash_state_t;狀態(tài)遷移邏輯是IDLE狀態(tài)持續(xù)檢測距離如果小于閾值則跳轉(zhuǎn)到DETECTEDDETECTED狀態(tài)發(fā)送開蓋指令舵機轉(zhuǎn)到90度跳轉(zhuǎn)到OPENINGOPENING狀態(tài)等待舵機到位可以用角度傳感器反饋也可以延時2秒再判斷人是否還在附近如果在則進入OPENED否則進入CLOSINGOPENING到CLOSING的過渡如果人還在就保持開蓋如果人離開超過3秒開始關(guān)蓋CLOSING狀態(tài)關(guān)蓋過程中持續(xù)檢測障礙物若遇到障礙則進入ANTI_PINCH舵機反轉(zhuǎn)回去BLOCKED狀態(tài)連續(xù)5次防夾觸發(fā)認定機械結(jié)構(gòu)卡死蜂鳴器報警用狀態(tài)機而不是if-else的好處是代碼結(jié)構(gòu)清晰每個狀態(tài)下能處理的事件一目了然后續(xù)擴展語音模塊或者加一個按鍵手動開蓋都方便。4.2 FreeRTOS任務(wù)劃分與優(yōu)先級設(shè)計如果第一版用裸機直接在主循環(huán)里跑狀態(tài)機就夠了。但我上了FreeRTOS原因是我的需求里要同時做測距、串口上報、OLED刷新裸機輪詢會導(dǎo)致響應(yīng)不及時。任務(wù)劃分我按功能拆了四塊任務(wù)名優(yōu)先級周期/觸發(fā)方式作用SensorTask3100ms周期超聲波測距、濾波、更新距離值ControlTask4事件驅(qū)動執(zhí)行狀態(tài)機、控制舵機OLEDTask1500ms周期刷新屏幕顯示UARTReportTask21s周期或事件觸發(fā)通過ESP8266/藍牙上報狀態(tài)優(yōu)先級為什么ControlTask最高因為開蓋關(guān)蓋屬于安全相關(guān)操作響應(yīng)不及時可能夾到人所以它優(yōu)先級最高。SensorTask其次因為狀態(tài)機需要新鮮的傳感器數(shù)據(jù)才能做判斷。OLED這種只是給人看的放最低沒問題。任務(wù)間通信SensorTask把測距結(jié)果寫入一個全局共享變量用osMutexWait/osMutexRelease保護ControlTask檢測到狀態(tài)變化時通過osMessagePut給UARTReportTask發(fā)消息觸發(fā)上報。4.3 舵機控制的平滑過渡直接給舵機發(fā)送90度跳變指令舵機會快速擺動蓋子“啪”一下彈開不僅噪音大而且容易把垃圾桶里的輕質(zhì)垃圾帶飛。我加了一個過渡函數(shù)void servo_goto_angle_smooth(TIM_HandleTypeDef *htim, uint8_t channel, uint16_t target_pulse, uint16_t step_delay_ms) { uint16_t current __HAL_TIM_GET_COMPARE(htim, channel); while (current ! target_pulse) { if (current target_pulse) current; else current--; __HAL_TIM_SET_COMPARE(htim, channel, current); HAL_Delay(step_delay_ms); } }實測單步延時節(jié)拍在5~10ms時開蓋過程大約需要0.5~1秒既不會太快也不會太慢。這個平滑函數(shù)同時解決了防夾問題關(guān)閉時如果檢測到有東西擋著直接調(diào)用servo_goto_angle_smooth反向走一小段效果比直接反轉(zhuǎn)輸出要好很多。5. 傳感器數(shù)據(jù)處理與抗干擾5.1 超聲波的抖動與濾波超聲波測距在真實環(huán)境中會有大量抖動垃圾桶附近有人走動、垃圾桶表面不平整導(dǎo)致反射雜亂、甚至空氣中的溫度濕度變化都會影響聲速。我試過三種濾波方案簡單平均值取最近5次測距結(jié)果的平均值。優(yōu)點是平滑缺點是對突發(fā)的真實變化反應(yīng)慢。中值濾波取最近5次結(jié)果的中間值。能把偶發(fā)的異常大值/小值濾掉對“有人靠近”這種跳變響應(yīng)比較快。限幅濾波如果當前值和上一次值的差值超過閾值比如30cm判定為噪聲丟棄本次數(shù)據(jù)。最終我采用“中值限幅”組合先做限幅丟掉明顯異常值再做中值濾波雙保險。代碼如下uint16_t history[5] {0}; uint8_t idx 0; float filter_distance(float raw) { // 限幅 if (history[idx] ! 0 fabs(raw - history[idx]) 30.0f) { // 丟棄異常值返回上一穩(wěn)定值 return history[(idx 4) % 5]; } history[idx] (uint16_t)(raw * 100); idx (idx 1) % 5; // 中值濾波 uint16_t temp[5]; memcpy(temp, history, sizeof(history)); for (int i 0; i 4; i) { for (int j i 1; j 5; j) { if (temp[j] temp[i]) { uint16_t t temp[i]; temp[i] temp[j]; temp[j] t; } } } return temp[2] / 100.0f; }5.2 紅外熱釋電的誤觸發(fā)抑制HC-SR501有個很大的問題是如果垃圾桶放在暖氣旁邊或者有陽光照射的角度它會周期性誤觸發(fā)。抑制措施有兩種硬件上調(diào)整模塊的延時旋鈕和靈敏度旋鈕軟件上做“連續(xù)兩次觸發(fā)確認”。軟件確認邏輯紅外觸發(fā)后不立即開蓋而是啟動一個500ms的定時窗口如果窗口內(nèi)再次觸發(fā)才確認“有人存在”。這種方式能把偶發(fā)性的熱源干擾過濾掉80%以上。具體實現(xiàn)如下volatile uint8_t pir_trigger_count 0; volatile uint32_t pir_last_trigger_time 0; void pir_irq_handler(void) { if (HAL_GetTick() - pir_last_trigger_time 500) { pir_trigger_count; } else { pir_trigger_count 1; } pir_last_trigger_time HAL_GetTick(); }開蓋邏輯中只有當pir_trigger_count 2時才認定為有效觸發(fā)器。5.3 光耦隔離在傳感器接入中的必要性我做第二版時遇到一個奇怪的現(xiàn)象只要舵機一轉(zhuǎn)超聲波測距結(jié)果就跳變到幾十厘米甚至上百厘米。查了很多資料后確定是電源干擾。這時候就體現(xiàn)出熱搜詞里“stm32 光偶電路”的實際意義了——光耦隔離在傳感器和執(zhí)行器之間起到了很好的抗干擾作用。不過對于這個垃圾桶項目直接用光耦成本高且沒必要。我買了一塊DC-DC隔離電源模塊將舵機供電和單片機供電完全隔離問題就消失了。這個經(jīng)驗分享出來是想告訴大家先判干擾路徑再決定用隔離還是濾波不要一上來就上重型方案。6. 無線通信與物聯(lián)網(wǎng)擴展6.1 ESP8266接入為什么需要它垃圾桶本身是離線設(shè)備但加一個WiFi模塊后可以做很多事垃圾滿了通過手機App收到推送、垃圾桶使用頻率統(tǒng)計、遠程開蓋應(yīng)急處理。在熱搜詞里“esp8266wifi模塊教程stm32”出現(xiàn)頻率很高說明很多人也想做類似的物聯(lián)網(wǎng)擴展。我用的ESP8266-01S主要因為它體積小、售價低、固件穩(wěn)定。首先給ESP8266燒錄AT固件很多模塊出廠已經(jīng)帶AT固件不需要重刷我是直接在設(shè)備上測試AT指令。接線方式ESP8266的TX接STM32的RXPA9RX接STM32的TXPA10VCC接3.3V注意ESP8266的峰值電流接近300mA最好單獨用一個3.3V穩(wěn)壓芯片供電不然后臺重啟CH_PD接3.3V。6.2 AT指令集聯(lián)動與ESP8266通信的核心指令是HTTPS POST請求。下面是我常用的AT指令流ATRST ATCWMODE1 ATCWJAP家里WiFi名稱,WiFi密碼 ATCIPMUX0 ATCIPSTARTTCP,192.168.1.100,8080 ATCIPSEND48 POST /api/status HTTP/1.1 Host: 192.168.1.100 Content-Type: application/json Content-Length: 13 {status:1}實現(xiàn)時最要注意的是ATCIPSEND后面的數(shù)字必須與后面要發(fā)送的字節(jié)數(shù)完全一致包括HTTP頭、換行符、空行、請求體一個字符都不能差。我調(diào)試時經(jīng)常在這里卡住服務(wù)端返回錯誤。解決辦法是先在串口助手里手動算好字節(jié)數(shù)再將發(fā)送邏輯固化到代碼里。6.3 與MQTT的對接方案AT指令做HTTP請求是直連模式適合局域網(wǎng)內(nèi)用。如果想做云平臺上報比如巴法云、OneNET用MQTT協(xié)議更優(yōu)雅。但ESP8266的AT固件默認不支持MQTT需要刷MQTT固件或者讓STM32直接通過AT指令透傳TCP連接MQTT Broker的IP端口然后按MQTT協(xié)議格式手動組包。這個方案有點復(fù)雜建議先跑通HTTP上報再考慮MQTT。如果你的需求只是“手機能看垃圾桶狀態(tài)”HTTP足夠。6.4 使用STM32的UART接收不定長數(shù)據(jù)在熱搜詞里“stm32串口接收不定長數(shù)據(jù)”也是高頻問題。ESP8266返回的數(shù)據(jù)是不定長的比如串口會收到IPD,len:data這樣的消息其中l(wèi)en是變長的。網(wǎng)上推薦的做法是使用HAL庫的串口空閑中斷IDLE Interrupt。核心思路HAL_UART_Receive_DMA開啟DMA接收數(shù)據(jù)自動存入緩沖區(qū)開啟空閑中斷當串口接收完一幀數(shù)據(jù)后總線空閑觸發(fā)中斷在空閑中斷回調(diào)中計算實際接收長度處理數(shù)據(jù)volatile uint8_t uart_buffer[256]; volatile uint8_t rx_len 0; void HAL_UART_RxCpltCallback(UART_HandleTypeDef *huart) { if (huart-Instance USART1) { // DMA傳輸完成回調(diào) } } void USART1_IRQHandler(void) { if ((__HAL_UART_GET_FLAG(huart1, UART_FLAG_IDLE) ! RESET)) { __HAL_UART_CLEAR_IDLEFLAG(huart1); HAL_UART_DMAStop(huart1); rx_len UART_BUF_SIZE - __HAL_DMA_GET_COUNTER(hdma_usart1_rx); memcpy(rx_data, uart_buffer, rx_len); HAL_UART_Receive_DMA(huart1, uart_buffer, UART_BUF_SIZE); } HAL_UART_IRQHandler(huart1); }這個中斷處理函數(shù)的寫法是結(jié)構(gòu)化中斷處理的標準姿勢無論將來接藍牙還是4G模塊都能復(fù)用。7. 集成測試中遇到的坑與排查思路7.1 舵機通電抖動但不動這個問題出現(xiàn)過兩次。第一次是PWM信號沒輸出——檢查發(fā)現(xiàn)CubeMX生成的MX_TIM2_Init里沒有啟用PWM輸出通道光初始化定時器是不夠的。解決方法是調(diào)用HAL_TIM_PWM_Start(htim2, TIM_CHANNEL_1)。第二次是信號線接觸不良。STM32板子的排針焊盤和杜邦線之間容易虛接舵機偶爾動一下。排查方式是用示波器看PWM波形如果沒有示波器可以用萬用表測信號線電壓正常應(yīng)該有1V左右的平均電壓20ms周期、1.5ms高電平平均電壓3.3*1.5/20≈0.247V。7.2 超聲波測距數(shù)值穩(wěn)定但距離偏差大穩(wěn)定但不準確這個問題十有八九是聲速設(shè)定錯誤。HC-SR04模塊在淘寶上通常標注“2cm-400cm”實際上很多模塊的聲速是340m/s但有些模塊內(nèi)部是按350m/s計算的這樣直接用公式算出來會整體偏差約3%。解決辦法是實測校準拿一個固定距離比如100cm多次測量計算出實際聲速修正系數(shù)把這個系數(shù)寫進代碼里。7.3 代碼燒錄失敗JTAG/SWD引腳占用這是一個非常常見的坑如果你用了PA13/PA14/PA15/PB3/PB4這些引腳它們默認是SWD/JTAG調(diào)試引腳會導(dǎo)致調(diào)試器和燒錄器連接不上。熱搜里“stm32禁用jtag”就是這個場景。既然項目里用到了PB3/PB4必須要在代碼初始化時禁用JTAG只保留SWD__HAL_AFIO_REMAP_SWJ_DISABLE(); // 關(guān)閉JTAG保留SWD注意如果你用CubeIDE可以直接在CubeMX中把PB3/PB4配置為GPIO輸出后編譯器會自動插入重映射代碼。但如果是手動寫寄存器版必須在所有外設(shè)初始化之前調(diào)用這條語句。7.4 系統(tǒng)跑著跑著死機看門狗沒觸發(fā)最后要提一個隱藏很深的問題我發(fā)現(xiàn)系統(tǒng)偶爾卡死但看門狗沒有復(fù)位說明CPU還在跑只是某個任務(wù)死循環(huán)了。排查后定位到是OLED的I2C通信卡死。STM32的硬件I2C在收到NACK時會進入忙狀態(tài)如果此時沒有重新初始化I2C外設(shè)后續(xù)所有I2C操作都會超時。解決辦法是在OLED刷新異常時重新執(zhí)行HAL_I2C_Init()和HAL_I2C_DeInit()或者干脆改用軟件I2C方案。8. 實測數(shù)據(jù)與調(diào)優(yōu)記錄第一版樣機在實驗室環(huán)境連續(xù)運行72小時記錄到的關(guān)鍵數(shù)據(jù)如下指標測試結(jié)果備注超聲波檢測距離精度±1.5cm10~100cm中值濾波后開蓋響應(yīng)時間1.2秒從檢測到完全打開平滑步進10ms關(guān)蓋響應(yīng)時間1.5秒平滑步進8ms防夾觸發(fā)時間200ms內(nèi)連續(xù)檢測3次確認靜態(tài)功耗約90mAOLED亮屏待機工作功耗峰值約500mA舵機動作瞬間有幾個調(diào)優(yōu)點值得分享開蓋閾值設(shè)置為40cm比默認的30cm多預(yù)留了10cm冗余避免人站近了才急急忙忙開蓋。關(guān)蓋延時設(shè)置為3秒既不會反復(fù)開關(guān)蓋也不會讓蓋子一直敞開。防夾檢測閾值如果在關(guān)蓋過程中檢測到距離小于20cm立即反向轉(zhuǎn)動10度。這個閾值和舵機角度需要聯(lián)動標定不同垃圾桶蓋的機械慣性差異很大。在家庭場景下這個系統(tǒng)的準確率很高連續(xù)測試100次開關(guān)蓋誤開蓋2次漏開蓋0次。誤開蓋來自紅外熱釋電在某些角度下對寵物活動的誤檢測后來我把“紅外確認”邏輯加進去之后誤開蓋降到0次。9. 后續(xù)擴展方向和最終體會這個項目做完后我把智能垃圾桶的框架抽象成了“檢測-決策-執(zhí)行-反饋”的通用架構(gòu)后續(xù)做智能臺燈、智能窗簾、智能貓砂盆都是同一個套路。熱搜詞里“基于stm32的智能臺燈”其實就是把這個架構(gòu)換一下執(zhí)行器和傳感器把舵機換成LED調(diào)光電路就是智能臺燈把超聲波換成光敏電阻人體感應(yīng)就是人來燈亮、人走燈滅加上DHT11溫濕度傳感器就升級成環(huán)境監(jiān)測站我實際做過的擴展是加了一個“垃圾滿了”檢測在垃圾桶內(nèi)部裝了一個接近傳感器當桶內(nèi)垃圾堆積到一定高度時觸發(fā)滿溢信號通過OLED屏幕顯示“FULL”同時通過ESP8266向手機發(fā)推送。最后分享一個工具層面的建議。熱搜詞里“stm32 st-link utility”“stm32 linux開發(fā)環(huán)境”“vscode開發(fā)stm32”這些都是開發(fā)環(huán)境的進階話題。我用了一段時間VSCodePlatformIO做STM32開發(fā)發(fā)現(xiàn)這種工作流在代碼編輯體驗上比Keil好非常多補全、跳轉(zhuǎn)、Git集成都是碾壓級的。如果你打算長期做嵌入式開發(fā)建議在熟悉STM32基本開發(fā)后盡早遷移到VSCode或者CLion這類現(xiàn)代編輯器上生產(chǎn)效率提升是肉眼可見的。本文還有配套的精品資源點擊獲取