STM32智能臺燈這個題目說新不新說舊也不算舊。但我在幫人審過幾十套類似畢業(yè)設(shè)計或者競賽方案之后發(fā)現(xiàn)真正能把“光感”“WiFi”“云平臺”三條線擰成一股繩、而且每一環(huán)都經(jīng)得起追問的項目其實不多。大部分方案要么是本地PWM調(diào)光做得不錯云平臺只是個擺設(shè)要么是APP能亮能滅但光照采集和自動控制邏輯一塌糊涂。這篇文章就從這個經(jīng)典題目出發(fā)把我認(rèn)為一套合格的“STM32智能臺燈光感WiFi云平臺控制系統(tǒng)”該有的設(shè)計思路、硬件選型、通信協(xié)議、核心代碼和踩坑經(jīng)驗完整拆開來講。內(nèi)容更適合正在做課程設(shè)計、畢業(yè)設(shè)計或者想拿一個完整物聯(lián)網(wǎng)項目練手的嵌入式初學(xué)者。我不會只羅列原理圖也不會直接甩給你一堆源碼而是盡量把每個關(guān)鍵選擇背后的“為什么”講清楚。1. 項目整體設(shè)計與思路拆解1.1 這套系統(tǒng)到底解決什么問題先別急著寫代碼想明白產(chǎn)品需求比什么都重要。所謂智能臺燈表面上要解決的是“自動開關(guān)”和“自動調(diào)亮度”的問題但做一個帶云平臺的項目需求其實可以拆成三個層次。第一層是本地自動控制。臺燈根據(jù)環(huán)境光照強(qiáng)度自動調(diào)節(jié)LED亮度環(huán)境光暗了燈就亮起來環(huán)境光充足時燈自動降低亮度甚至關(guān)燈。這個層次只需要單片機(jī)、光敏傳感器和LED驅(qū)動電路就能完成也是整個系統(tǒng)最底層、最核心的功能。第二層是遠(yuǎn)程手動控制。用戶不在家或者躺在床上不想動可以通過手機(jī)APP或者網(wǎng)頁遠(yuǎn)程開關(guān)臺燈、調(diào)節(jié)亮度。這一層要在本地自動控制之上引入WiFi模塊和云平臺實現(xiàn)設(shè)備聯(lián)網(wǎng)、指令下發(fā)。第三層是狀態(tài)監(jiān)控與場景聯(lián)動。臺燈定時上報當(dāng)前的光照強(qiáng)度和燈的狀態(tài)云平臺端可以記錄歷史數(shù)據(jù)、繪制趨勢曲線。更進(jìn)一步還可以設(shè)定定時任務(wù)比如每天早上7點自動開燈或者讓燈根據(jù)外界光照變化實時調(diào)整亮度。把這三個層次拆開之后你會發(fā)現(xiàn)這個項目表面上是做一盞燈實際上是從“感知層—網(wǎng)絡(luò)層—平臺層—應(yīng)用層”完整走了一遍物聯(lián)網(wǎng)的經(jīng)典架構(gòu)。所以它非常適合作為嵌入式物聯(lián)網(wǎng)方向的學(xué)習(xí)項目技術(shù)棧覆蓋了傳感器采集、嵌入式控制、無線通信、云平臺接入、APP開發(fā)等多個環(huán)節(jié)。1.2 為什么選STM32而不是51、Arduino或者ESP32這是我在知乎和CSDN后臺被問得最多的問題。先說結(jié)論如果你是為了快速做個demoArduino或者ESP32確實更省事但如果是為了系統(tǒng)學(xué)習(xí)嵌入式、或者按畢業(yè)設(shè)計的標(biāo)準(zhǔn)來做STM32仍然是更合適的平臺。STM32的優(yōu)勢在于它的資源對于這個項目來說“剛剛好”。以最常用的STM32F103C8T6為例64KB Flash、20KB RAM主頻72MHz片上集成12位ADC、多路定時器、多路USART、I2C、SPI。實現(xiàn)光敏采樣、PWM調(diào)光、串口通信、按鍵掃描、狀態(tài)機(jī)管理這些資源綽綽有余。相比51單片機(jī)STM32的性能余量讓你可以跑RTOS、做復(fù)雜的濾波算法而不必在資源邊緣瘋狂試探。有人可能覺得ESP32自帶WiFi和藍(lán)牙直接一把梭不更香嗎這個說法在工程上確實有道理但從學(xué)習(xí)和練手的角度看會丟掉兩個關(guān)鍵技能點一是MCU通過串口AT指令控制WiFi模塊的經(jīng)典物聯(lián)網(wǎng)架構(gòu)二是主控與外設(shè)模塊分離時的調(diào)試能力。你現(xiàn)在用STM32ESP8266把AT指令這套流程走通了之后工作中遇到任何不帶協(xié)議棧的通信模組都能很快上手。1.3 三種整體架構(gòu)方案對比我在設(shè)計這套系統(tǒng)時在頂層架構(gòu)上其實糾結(jié)過幾個方案這里一并列出來供參考。第一種是“STM32 光敏電阻 ESP8266 云平臺”這也是我最終采用的方案。光敏電阻通過ADC采樣得到光照強(qiáng)度STM32根據(jù)光照數(shù)據(jù)自動調(diào)節(jié)PWM占空比控制LED同時通過ESP8266以MQTT協(xié)議接入云平臺。這個方案兼顧了硬件成本和教學(xué)價值每一步都看得見摸得著非常適合教學(xué)和畢設(shè)展示。第二種是“STM32 BH1750數(shù)字光感 ESP8266 云平臺”。與第一種的區(qū)別在于BH1750通過I2C接口直接輸出數(shù)字光照值單位是勒克斯lux精度更高也省去了ADC校準(zhǔn)的麻煩。但相應(yīng)地I2C調(diào)試和驅(qū)動代碼會比讀一個ADC值復(fù)雜一些。如果你的題目要求里明確提到要顯示具體光照度數(shù)值建議優(yōu)先考慮這個方案。第三種是“ESP32/ESP8266直驅(qū) 云平臺”。省掉STM32直接用ESP32的ADC采集光照、用PWM驅(qū)動LEDWiFi也內(nèi)建了一套芯片搞定所有事情。優(yōu)點是成本最低、開發(fā)最快缺點是整個系統(tǒng)的“嵌入式含量”變低了在畢業(yè)設(shè)計答辯時容易被質(zhì)疑技術(shù)深度不夠。三種方案沒有絕對的好壞關(guān)鍵看你手上有什么器件、題目要求什么深度。如果已經(jīng)買了這塊板子那塊板子就按手頭的資源來定。下面全部內(nèi)容默認(rèn)按照“STM32F103C8T6 光敏電阻 ESP8266 云平臺”的方案來展開。2. 硬件選型與電路設(shè)計要點2.1 主控最小系統(tǒng)與引腳規(guī)劃STM32F103C8T6這顆芯片現(xiàn)在已經(jīng)是國內(nèi)嵌入式圈子的“國民MCU”了價格便宜、資料海量、開發(fā)板遍地都是。我做這個項目時直接用手頭的核心板因為沒有必要自己畫最小系統(tǒng)板核心板集成了晶振、復(fù)位電路、USB轉(zhuǎn)串口、LED指示燈拿過來就能用。在引腳規(guī)劃上建議把功能模塊分開布局避免相互干擾。我的分配方案是這樣的PB0-PB1光敏電阻分壓電路經(jīng)ADC1的通道8和通道9采樣。PB0做環(huán)境光采樣PB1留作備用通道可以接一個手動電位器模擬“手動設(shè)定亮度”的場景。PA8TIM1的CH1輸出PWM用于驅(qū)動LED。用高級定時器TIM1是因為它的PWM分辨率和穩(wěn)定性都比較好實測在1kHz的頻率下調(diào)光無閃爍。PA9-PA10USART1接ESP8266模塊PA9為TX、PA10為RX。串口波特率在調(diào)試期用115200穩(wěn)定運(yùn)行后也可以降到9600以減少干擾。PA0-PA3接3個獨立按鍵分別實現(xiàn)手動開關(guān)、亮度加、亮度減。上拉輸入模式利用GPIO的片上上拉電阻省掉外部上拉。PB12-PB15預(yù)留的一組SPI/I2C引腳如果后續(xù)要把光敏電阻換成BH1750數(shù)字傳感器可以直接掛在這組引腳上。電源方面核心板通常自帶3.3V穩(wěn)壓芯片輸出電流大概在300mA級別。STM32本身功耗不大但ESP8266在WiFi發(fā)射瞬間電流可以達(dá)到200-300mA如果直接從核心板的3.3V引腳取電容易造成電壓跌落導(dǎo)致重啟。我當(dāng)時實測了好幾次都是這個原因后來改成獨立供電才徹底解決。這部分我在“常見問題”里會專門說。2.2 光照檢測光敏電阻還是數(shù)字光感這個選擇直接決定你的數(shù)據(jù)質(zhì)量。我默認(rèn)方案用的是光敏電阻也就是光敏電阻與固定電阻串聯(lián)分壓中間節(jié)點接到STM32的ADC引腳。電路連接其實很簡單。光敏電阻一端接3.3V另一端與一個10kΩ電阻串聯(lián)到GND兩個電阻連接點引出到ADC引腳。光照越強(qiáng)光敏電阻阻值越低ADC采到的電壓就越低所以ADC數(shù)值與光照強(qiáng)度是反比關(guān)系。這里有一個很多新手會忽略的細(xì)節(jié)光敏電阻的阻值范圍非常大暗態(tài)下可能到1MΩ以上強(qiáng)光下可能只有幾百歐姆如果用10kΩ固定電阻去分壓在暗態(tài)環(huán)境下輸出電壓變化非常平緩分辨率很差。比較合理的做法是先測一下你手頭光敏電阻在“暗”和“亮”兩種場景下的實際阻值然后選擇中間阻值附近的固定電阻。比如測到暗態(tài)200kΩ、亮態(tài)2kΩ那么固定電阻選10kΩ到20kΩ之間的值會比較合適。當(dāng)然因為光敏電阻本身一致性差、響應(yīng)曲線非線性它只適合做“相對光照強(qiáng)度”檢測不適合直接換算成勒克斯單位的絕對照度。如果你要精確的照度數(shù)值建議直接用BH1750模塊。這顆傳感器是I2C接口測量范圍1-65535 lux分辨率最高能到1 lux直接讀出數(shù)值不用校準(zhǔn)不需要換算價格也就幾塊錢。我在后面的代碼部分會給一套適用于BH1750的驅(qū)動思路你把I2C讀寫函數(shù)配好就能用。2.3 LED驅(qū)動與PWM調(diào)光方式LED驅(qū)動我見過最省事的接法是把LED和限流電阻直接串在GPIO上但這樣有兩個問題一是GPIO驅(qū)動能力有限帶不動大功率LED二是無法做PWM調(diào)光只能開關(guān)。所以推薦用三極管或者M(jìn)OS管驅(qū)動。我用的是一顆S8050三極管做低端驅(qū)動。具體接法是LED正極接5VLED負(fù)極串一個限流電阻然后接到三極管的集電極三極管發(fā)射極接GND基極通過1kΩ電阻接STM32的PA8引腳。這樣STM32輸出PWM波控制三極管的導(dǎo)通程度從而控制LED的平均電流實現(xiàn)亮度調(diào)節(jié)。限流電阻的選擇要根據(jù)LED的額定電流來算。比如LED最大額定電流是20mA5V供電減去LED壓降約3V再減去三極管飽和壓降約0.2V那么限流電阻就是(5-3-0.2)/0.02 90Ω取標(biāo)準(zhǔn)值100Ω。如果LED比較亮刺眼實際PWM占空比上限也不要給到100%80%左右足夠還留了余量。我實際用的時候發(fā)現(xiàn)PWM頻率低于1kHz時LED在低亮度檔位能明顯感覺到頻閃尤其是在手機(jī)攝像頭下看更明顯。所以我默認(rèn)把PWM頻率設(shè)在1kHz以上。系統(tǒng)里做了10級亮度調(diào)節(jié)每一級對應(yīng)10%的占空比步進(jìn)夠用且體感平滑。2.4 WiFi模塊選型與供電注意事項WiFi模塊的選擇我建議直接用ESP8266系列的ESP-01S或者ESP-12F。ESP-01S便宜、體積小、引腳少適合做AT指令控制ESP-12F引腳更多如果以后想刷NodeMCU固件或者直接寫MicroPython擴(kuò)展性更強(qiáng)。兩個模塊的AT指令集基本通用代碼不用大改。這里鄭重提醒一個電源問題ESP8266的瞬態(tài)功耗非常大。你可以拿示波器測一下它啟動瞬間的電流波形峰值到300mA很正常。USB轉(zhuǎn)串口的3.3V輸出通常撐不住所以最穩(wěn)妥的做法是用AMS1117-3.3從5V降壓給ESP8266單獨供電。要注意的是AMS1117的輸入輸出壓差必須大于1V5V輸入完全沒問題但3.3V輸入再降3.3V就廢了。在ESP8266的VCC和GND之間加一個470μF的電解電容和0.1μF的陶瓷電容并聯(lián)用于緩解瞬態(tài)電流沖擊。STM32核心板與ESP8266模塊之間的串口要共地不然信號電平參考點不一致通信必然亂碼。另外需要留意電平匹配問題。STM32F103的IO口是5V容忍的但作為輸出時高電平是3.3VESP8266的UART RX引腳也是3.3V邏輯所以兩者之間不需要額外的電平轉(zhuǎn)換電路。不過反過來如果ESP8266的TX輸出高電平也是3.3V直接進(jìn)STM32的RX沒有問題。好在這兩個芯片在電平上天然兼容省了轉(zhuǎn)接板。3. 云平臺接入與通信協(xié)議設(shè)計3.1 平臺選型OneNET / 巴法云 / 阿里云IoT云平臺是這個項目的“第三只眼”也是讓評分老師眼前一亮的部分。市面上可選的平臺很多我在不同項目里用過OneNET、巴法云、阿里云IoT和騰訊云IoT這里說說選型心得。如果你的目的是快速跑通整個鏈路優(yōu)先考慮巴法云。它的優(yōu)點是接入極其簡單不需要復(fù)雜的設(shè)備模型定義MQTT連接只需要服務(wù)器地址、端口、topic和設(shè)備ID就能通信。APP端可以用微信小程序快速搭一個控制界面整個聯(lián)調(diào)過程基本不需要看長篇文檔社區(qū)資料也很多。如果你想做得更規(guī)范、有數(shù)據(jù)可視化和歷史曲線功能OneNET是比較好的選擇。OneNET的多協(xié)議接入文檔很詳細(xì)有完整的產(chǎn)品、設(shè)備、數(shù)據(jù)流、觸發(fā)器體系。它的數(shù)據(jù)流可以自動保存最近一定量的歷史點配合平臺的圖表組件可以展示光照趨勢曲線。我記得有些省份的畢業(yè)設(shè)計題目就要求“基于OneNET平臺”說明它已經(jīng)被廣泛認(rèn)可。阿里云IoT平臺在設(shè)備管理、權(quán)限控制、規(guī)則引擎方面做得最成熟但配置流程也最繁瑣要創(chuàng)建產(chǎn)品、定義物模型、生成設(shè)備證書、配置規(guī)則引擎寫設(shè)備端代碼時還要按照Alink JSON格式封裝報文。如果項目周期緊不建議第一次做就選阿里云容易在配置上花掉大量時間。我現(xiàn)在之所以平時喜歡用OneNET就是因為它在“規(guī)范”和“效率”之間取得了平衡夠用又不復(fù)雜。3.2 MQTT協(xié)議為什么物聯(lián)網(wǎng)設(shè)備幾乎都在用它這個項目里STM32與云平臺之間走的是MQTT協(xié)議。MQTT是一種輕量級發(fā)布/訂閱消息傳輸協(xié)議專為低帶寬、高延遲、網(wǎng)絡(luò)不穩(wěn)定的物聯(lián)網(wǎng)環(huán)境設(shè)計。理解MQTT只需要抓住三個關(guān)鍵詞broker、topic、payload。broker就是消息服務(wù)器它負(fù)責(zé)接收所有客戶端發(fā)來的消息并轉(zhuǎn)發(fā)給訂閱者。在OneNET平臺里broker地址是183.230.40.39端口1883。STM32通過ESP8266建立TCP連接后就可以在這個broker上進(jìn)行發(fā)布和訂閱操作。topic是消息的主題可以理解為一個“頻道”。設(shè)備發(fā)布消息到某個topic所有訂閱了這個topic的設(shè)備或應(yīng)用都能收到消息。在OneNET的MQTT接入中topic格式一般是類似這樣$dp用于上傳數(shù)據(jù)點下行指令則走$sys/{pid}/{device-name}/dp/post/json這類系統(tǒng)主題。為了讓代碼可讀性更強(qiáng)我通常自己再定義兩個業(yè)務(wù)主題/device/status用于上報狀態(tài)/device/command用于接收云端指令。payload就是消息內(nèi)容本身。我統(tǒng)一用JSON格式封裝因為在云平臺上處理與轉(zhuǎn)發(fā)JSON最方便APP端解析也不費力。比如上報一個數(shù)據(jù)點的payload長這樣{datastreams:[{id:light,datapoints:[{value:325}]}]}這個格式是OneNET數(shù)據(jù)流的標(biāo)準(zhǔn)寫法APP端拿到之后按固定字段解析即可。3.3 一鍵配網(wǎng)SmartConfig還是手工輸入WiFi信息對于這種單設(shè)備項目最省事的聯(lián)網(wǎng)方式是在STM32的代碼里寫死WiFi的SSID和密碼然后ESP8266上電自動連接。缺點很明顯換一個WiFi環(huán)境就要重新燒錄固件極其麻煩。稍微高級一點的做法是用ESP8266的SmartConfig功能也叫做一鍵配網(wǎng)。手機(jī)APP把WiFi的SSID和密碼通過UDP廣播發(fā)送出去ESP8266在混雜模式下監(jiān)聽并解析出這些信息然后自動連接到路由器。這個功能在ESP8266的官方AT指令里有現(xiàn)成支持指令是ATCWSTARTSMART。我在實際項目里最終用了“Airkiss”方式也就是OneNET平臺配套的配網(wǎng)方案。整體流程是ESP8266進(jìn)入配網(wǎng)模式后用手機(jī)上的OneNET APP發(fā)送WiFi賬號密碼模塊自動解析并連接路由器然后主動上報自己的設(shè)備ID到平臺。這樣整個系統(tǒng)就實現(xiàn)了“去串口化”任何環(huán)境下都能獨立部署演示場景下尤其加分。我不建議在這個環(huán)節(jié)做得太復(fù)雜比如用按鍵組合進(jìn)入配網(wǎng)模式再配合狀態(tài)指示燈提示。這些功能是產(chǎn)品化的方向但對畢設(shè)來說不是必須項。有一鍵配網(wǎng)能演示就足夠了把時間留給更核心的調(diào)光邏輯和云平臺功能。3.4 云平臺設(shè)備注冊與數(shù)據(jù)流設(shè)計以O(shè)neNET為例創(chuàng)建一個接入MQTT協(xié)議的設(shè)備需要幾個步驟。第一步注冊賬號并登錄開發(fā)者中心創(chuàng)建一個產(chǎn)品。產(chǎn)品類型選“智能家居”聯(lián)網(wǎng)方式選“移動網(wǎng)絡(luò)”或“WiFi”這里技術(shù)參數(shù)隨便選都行影響不大。關(guān)鍵是記下產(chǎn)品ID。第二步在產(chǎn)品下添加設(shè)備填寫設(shè)備名稱和設(shè)備編號。設(shè)備編號通常是自定義字符串比如“smart_lamp_01”。創(chuàng)建后平臺會生成APIKey和設(shè)備IDAPIKey是后續(xù)APP端或腳本調(diào)用HTTP接口時用的鑒權(quán)憑證設(shè)備ID是MQTT連接時的用戶名。MQTT連接時密碼通常填A(yù)PIKey。第三步定義數(shù)據(jù)流。在設(shè)備詳情頁可以添加數(shù)據(jù)流模板我這里定義了三個數(shù)據(jù)流light光照強(qiáng)度原始ADC值范圍0-4095dim當(dāng)前PWM占空比百分比范圍0-100switch燈開關(guān)狀態(tài)0或1這三個數(shù)據(jù)流基本覆蓋了系統(tǒng)的所有狀態(tài)。云端和APP端展示數(shù)據(jù)都從這三個流里取不需要額外設(shè)計復(fù)雜的數(shù)據(jù)結(jié)構(gòu)。MQTT連接參數(shù)的格式是固定的注意這里的password有時不是APIKey本身而是APIKey的完整形式。建議先去平臺控制臺找一個能跑通的示例或者直接用MQTT客戶端軟件測試一下能否連接成功再回來調(diào)STM32側(cè)代碼。我在做這個項目時很多通信問題都是先用PC端的MQTT客戶端調(diào)試排除了平臺問題后才回來查設(shè)備端這樣能省很多時間。4. 核心代碼實現(xiàn)剖析4.1 光照采集與滑動平均濾波光敏電阻采樣看起來簡單就是ADC讀一個值但裸讀出來的數(shù)據(jù)在真實環(huán)境里跳動非常大。因為室內(nèi)燈光大多使用50Hz交流供電燈具亮度本身就有100Hz的脈動光敏電阻對這種脈動很敏感ADC采樣值直接讀出來是在一個范圍內(nèi)來回跳的。我采用的方案是“定時采樣滑動平均濾波”。起一個1ms的定時器中斷每中斷一次就觸發(fā)一次ADC采樣實際上可以放寬到每10ms采一次然后把最近10次采樣值存入環(huán)形緩沖區(qū)每次計算平均后作為當(dāng)前光照值。這樣既能濾掉100Hz的脈動噪聲又不會因為平均窗口過大而讓系統(tǒng)的響應(yīng)變遲鈍。核心代碼結(jié)構(gòu)大概是這樣#define FILTER_SIZE 10 uint16_t adc_buf[FILTER_SIZE]; uint8_t adc_index 0; uint32_t adc_sum 0; void ADC_Sample_Handler(void) { // 減去將要覆蓋的舊值 adc_sum - adc_buf[adc_index]; // 采樣新值 adc_buf[adc_index] ADC_GetValue(); // 加上新值 adc_sum adc_buf[adc_index]; // 更新環(huán)形索引 adc_index (adc_index 1) % FILTER_SIZE; } uint16_t ADC_GetAverage(void) { return (uint16_t)(adc_sum / FILTER_SIZE); }這段代碼的關(guān)鍵在于“加減法維護(hù)總和”而不是每次重新遍歷累加。省掉了大量for循環(huán)在低主頻MCU上也能跑得很輕。4.2 自動調(diào)光控制邏輯從閾值比較到遲滯比較硬件層采集上來了光照數(shù)據(jù)接下來要解決“怎么根據(jù)光照值決定燈的亮度”這個核心算法問題。最簡單的是閾值比較光照值低于某個閾值就開燈高于某個閾值就關(guān)燈。但這種寫法有一個致命問題——在閾值附近光照稍微波動燈就會在亮滅之間反復(fù)切換體驗非常差。就像家用空調(diào)溫度設(shè)在26度室溫在26度附近波動壓縮機(jī)就會頻繁啟停既費電又傷機(jī)器。解決辦法是加入“遲滯比較”或者說“滯回比較”的思想。設(shè)置兩個閾值一個開燈閾值和一個關(guān)燈閾值開燈閾值低于關(guān)燈閾值。舉個例子環(huán)境光照ADC值在0最暗到4095最亮之間我設(shè)LIGHT_ON_THRESHOLD 800LIGHT_OFF_THRESHOLD 1500。當(dāng)光照值從暗變亮、超過1500時才關(guān)燈當(dāng)光照值從亮變暗、低于800時才開燈。因為中間有700的差值緩沖光照值在邊界附近小范圍波動時燈的狀態(tài)不會抖動了。如果需要自動連續(xù)調(diào)光可以用線性映射。把環(huán)境光照映射到目標(biāo)PWM占空比大概思路是// 環(huán)境越暗target_pwm越高 if (avg_light 800) target_pwm 100; else if (avg_light 2000) target_pwm 0; else target_pwm (uint8_t)((2000 - avg_light) * 100 / 1200);但這里有個陷阱直接讓實際PWM瞬間跳到目標(biāo)值燈光的突變會讓人感覺很突兀尤其是環(huán)境光緩慢變化時燈會“一格一格地跳”。所以我在目標(biāo)PWM和實際PWM之間加了一個簡單的一階慣性環(huán)節(jié)也就是每次控制周期只向目標(biāo)值逼近一小步類似于軟件上的“軟啟動”。// 每100ms執(zhí)行一次 if (current_pwm target_pwm) current_pwm 2; else if (current_pwm target_pwm) current_pwm - 2;這樣亮度變化就是平滑漸變的觀感好了很多。這里的步進(jìn)值2和周期100ms可以根據(jù)實際效果調(diào)整。系統(tǒng)默認(rèn)有10級亮度每一級對應(yīng)10%的PWM一個漸變過程大概500ms左右完成不會太慢也不會跳變。4.3 ESP8266串口處理與AT指令狀態(tài)機(jī)ESP8266的AT指令處理是整個項目里最容易寫爛的部分。很多人直接在主循環(huán)里阻塞等待串口返回一旦數(shù)據(jù)延遲或者返回格式變化整個系統(tǒng)就卡死了。正確做法是搭一個狀態(tài)機(jī)把“發(fā)送指令—等待應(yīng)答—超時重試—進(jìn)入下一步”這個流程管理起來。先初始化串口接收用中斷方式把ESP8266返回的數(shù)據(jù)逐字節(jié)存入接收緩沖區(qū)。然后在主循環(huán)里輪詢緩沖區(qū)根據(jù)當(dāng)前狀態(tài)判斷是否收到期待的應(yīng)答。比如連接WiFi的AT指令流程typedef enum { WIFI_STATE_RESET, WIFI_STATE_SET_MODE, WIFI_STATE_JOIN_AP, WIFI_STATE_CONNECT_MQTT, WIFI_STATE_ONLINE } wifi_state_t; wifi_state_t wifi_state WIFI_STATE_RESET; void WiFi_Task(void) { static uint32_t last_cmd_time 0; static uint32_t timeout_cnt 0; switch (wifi_state) { case WIFI_STATE_RESET: ESP8266_SendCmd(ATRST\r\n); wifi_state WIFI_STATE_SET_MODE; last_cmd_time HAL_GetTick(); break; case WIFI_STATE_SET_MODE: if (ESP8266_CheckResponse(ready)) { // 等復(fù)位完成后設(shè)置Station模式 ESP8266_SendCmd(ATCWMODE1\r\n); wifi_state WIFI_STATE_JOIN_AP; last_cmd_time HAL_GetTick(); } break; case WIFI_STATE_JOIN_AP: if (ESP8266_CheckResponse(WIFI CONNECTED)) { ESP8266_SendCmd(ATCIPSTART\TCP\,\183.230.40.39\,1883\r\n); wifi_state WIFI_STATE_CONNECT_MQTT; } break; default: break; } // 超時判斷 if (HAL_GetTick() - last_cmd_time 5000) { // 超時未收到預(yù)期應(yīng)答重發(fā)當(dāng)前指令 wifi_state WIFI_STATE_RESET; } }這個狀態(tài)機(jī)的精髓是一個全局“超時重置”機(jī)制只要5秒沒有等到期望的應(yīng)答就把WiFi模塊復(fù)位重來。這在調(diào)試和演示場景下非常有用因為WiFi模塊偶爾抽風(fēng)是很正常的事有這套機(jī)制設(shè)備就能自恢復(fù)不用反復(fù)斷電重啟。判斷應(yīng)答的函數(shù)ESP8266_CheckResponse做的事情也不復(fù)雜在接收緩沖區(qū)里用字符串查找函數(shù)匹配關(guān)鍵詞比如“OK”“WIFI CONNECTED”“MQTTCONNECTED”等匹配成功就返回1并清空緩沖區(qū)。這樣做比grep整行文本要穩(wěn)因為AT固件版本不同返回格式也會有差異匹配關(guān)鍵詞更通用。4.4 數(shù)據(jù)上報與指令下發(fā)雙向通信的代碼結(jié)構(gòu)設(shè)備與云平臺的雙向通信是MQTT最大的價值。STM32側(cè)要做兩件事定時上報狀態(tài)實時處理云端指令。上報邏輯放在主循環(huán)里用一個計時器控制周期。我設(shè)置的是每5秒上報一次。如果云平臺只是用于展示5秒足夠了頻率太高浪費流量也沒有意義。void MQTT_Report_Status(void) { static uint32_t last_report_time 0; char buf[128]; uint16_t light_value ADC_GetAverage(); if (HAL_GetTick() - last_report_time 5000) { sprintf(buf, ATMQTTPUB0,\$dp\,1,0,\{\\\datastreams\\\:[{\\\id\\\:\\\light\\\,\\\datapoints\\\:[{\\\value\\\:%d}]}]}\\r\n, light_value); ESP8266_SendCmd(buf); last_report_time HAL_GetTick(); } }ESP8266的MQTT AT指令中ATMQTTPUB后面的參數(shù)依次是連接ID、主題名、QoS、retain標(biāo)志、消息長度和消息內(nèi)容。轉(zhuǎn)義引號很容易寫錯我建議先在串口助手里面把要發(fā)送的完整指令測一遍確認(rèn)返回OK之后再寫進(jìn)代碼里。下行指令的處理稍微復(fù)雜一點。當(dāng)APP端下發(fā)指令時ESP8266會先收到MQTTSUBRECV: 連接ID, 主題名, 消息長度\r\n緊接著下一行才是具體的消息內(nèi)容。所以代碼里的處理要分兩步先識別MQTTSUBRECV前綴提取消息長度然后等后續(xù)數(shù)據(jù)進(jìn)入緩沖區(qū)。void MQTT_Parse_Command(void) { char *p ESP8266_GetBuffer(); if (p NULL) return; if (strstr(p, MQTTSUBRECV) ! NULL) { // 提取消息正文通常緊跟兩行后出現(xiàn) char *body strstr(p, {); if (body ! NULL) { if (strstr(body, \dim\:80)) { current_pwm 80; } else if (strstr(body, \switch\:1)) { lamp_on 1; } else if (strstr(body, \switch\:0)) { lamp_on 0; } } ESP8266_ClearBuffer(); } }4.5 按鍵與手動模式的狀態(tài)管理云平臺是方便但實體按鍵不能砍。我在系統(tǒng)里加入了一個“自動/手動模式”的切換邏輯。默認(rèn)上電是自動模式臺燈根據(jù)光照自己決定亮度。此時按一下手動按鍵就切換到手動模式之后亮度檔位完全由按鍵控制。此時如果APP下發(fā)指令也按手動指令處理。再按一次模式鍵回到自動模式。這個邏輯聽起來簡單但狀態(tài)管理上有個細(xì)節(jié)值得注意。由于需要同時處理本地按鍵、云端指令、自動調(diào)光三種“亮度來源”我在代碼里定義了一個變量mode值為MODE_AUTO或MODE_MANUAL所有亮度變更邏輯都在統(tǒng)一的入口函數(shù)里先檢查模式再決定是否執(zhí)行。凡是寫入PWM寄存器的代碼都必須經(jīng)過這個入口避免出現(xiàn)“自動模式剛把PWM調(diào)到100手動模式的指令又來改PWM”這類互相打架的問題。void Lamp_SetPWM(uint8_t duty, uint8_t source) { if (source SOURCE_AUTO mode MODE_MANUAL) return; // 手動模式下忽略自動調(diào)光 if (source SOURCE_CMD mode MODE_AUTO) { // 云端指令在自動模式下是否生效這里看產(chǎn)品需求 // 我的做法是云端指令優(yōu)先并切換到手動模式 } TIM1-CCR1 duty; }在這個項目里我采取的策略是云端遠(yuǎn)程指令具有最高優(yōu)先級一旦收到云端控制指令就自動切入“手動模式”直到用戶在本地按模式鍵切回“自動模式”。這種設(shè)計更貼合真實用戶的使用習(xí)慣——我在手機(jī)上都點了一鍵開燈了你臺燈還在那邊自動判斷說“環(huán)境光夠亮不開燈”那不太符合直覺。5. 常見問題排查與避坑實錄5.1 經(jīng)典故障現(xiàn)象速查表這部分是干貨中的干貨。我結(jié)合自己和身邊人做類似項目時踩過的坑整理成了一個診斷表?，F(xiàn)象可能原因排查與解決ESP8266不響應(yīng)AT指令供電不足或串口接線錯誤先檢查VCC和GND電壓必須在3.0-3.6V之間再確認(rèn)TXRX交叉連接最后用USB轉(zhuǎn)串口單獨測試模塊串口輸出亂碼波特率不匹配或共地失敗確認(rèn)ESP8266與STM32波特率一致檢查兩地是否可靠連接ADC采集值一直為4095引腳浮空未接好用萬用表量引腳電壓確認(rèn)分壓電路連接正確PWM輸出為0但LED常亮三極管驅(qū)動方式接錯檢查LED是否接在集電極而非發(fā)射極確認(rèn)GPIO模式為推挽輸出云平臺收不到數(shù)據(jù)設(shè)備ID或APIKey錯誤在PC上用MQTT客戶端測試連接確認(rèn)主題名與數(shù)據(jù)流定義一致設(shè)備連上WiFi但MQTT連不上服務(wù)器端口或設(shè)備鑒權(quán)有問題確認(rèn)TCP連接地址和端口正確OneNET用1883檢查MQTT用戶名密碼與產(chǎn)品設(shè)備對應(yīng)掉線后無法自動重連狀態(tài)機(jī)缺少超時重置機(jī)制加入5秒超時重置邏輯如上文所述5.2 燒錄和調(diào)試時的第二個常見問題ADC參考電壓噪聲這個坑非常隱蔽當(dāng)時讓我排查了很久?，F(xiàn)象是這樣的光感數(shù)據(jù)在屏幕上像心電圖一樣跳動濾波算法加了好幾層都壓不住。后來用萬用表量STM32的3.3V供電發(fā)現(xiàn)紋波達(dá)到了200mV以上。因為ESP8266的瞬態(tài)電流導(dǎo)致供電電壓波動而STM32內(nèi)部ADC的參考電壓VREF在F103芯片上是直接接在VDDA上的供電電壓一跳ADC采集值自然跟著跳。解決方案有兩個。硬件上在STM32核心板的3.3V和GND之間加一個100μF的電解電容和0.1μF的陶瓷電容穩(wěn)住電源紋波軟件上用內(nèi)部參考電壓通道做校準(zhǔn)。如果項目對測量精度有更高要求建議外部單獨用一顆高精度基準(zhǔn)源比如TL431給VDDA供電或者選用帶獨立VREF引腳的STM32型號。就本項目的精度需求來說把電源穩(wěn)住就夠用了。5.3 WiFi模塊坑192.168.x.x連不上云平臺這個情況很多人剛做的時候都會遇到。ESP8266連接路由器成功了但TCP連接云平臺服務(wù)器一直超時。這個時候要先排查是不是路由器開了“AP隔離”功能。很多公共場所或者部分家用路由器默認(rèn)會開啟AP隔離使得同一WiFi下的設(shè)備之間無法互通。具體表現(xiàn)就是手機(jī)能上網(wǎng)但手機(jī)連不上局域網(wǎng)里的ESP8266或者ESP8266連不上外網(wǎng)服務(wù)器。排查方法很簡單用電腦連同一個WiFi命令行ping一下云平臺的服務(wù)器IP能通再查TCP層。還有一種情況是路由器啟用了“僅允許已綁定設(shè)備上網(wǎng)”的白名單功能新設(shè)備的MAC地址不在白名單里就算拿到了IP也上不了外網(wǎng)。這時候去路由器管理頁面把ESP8266的MAC地址加進(jìn)去就好了。還有一個小細(xì)節(jié)值得提一下如果你的云平臺服務(wù)器用的不是默認(rèn)端口1883需要在路由器上確認(rèn)一下是否放行了該端口。個別校園網(wǎng)或者公司網(wǎng)會封鎖非常用端口導(dǎo)致本地調(diào)試一切正常一上現(xiàn)場網(wǎng)絡(luò)就失敗。所以做演示之前最好先確認(rèn)現(xiàn)場網(wǎng)絡(luò)的策略。5.4 實測數(shù)據(jù)與波形調(diào)優(yōu)記錄在項目收尾階段我用邏輯分析儀抓了一組PWM波形來做調(diào)優(yōu)。分別記錄占空比10%、50%、90%三組觀察三極管驅(qū)動LED的波形上升沿和下降沿。實測在10%占空比時LED亮度已經(jīng)能夠明顯感知到但用手機(jī)攝像頭看仍然有輕微頻閃50%時波形光滑占空比誤差在1%以內(nèi)90%時三極管有輕微發(fā)熱但溫度穩(wěn)定在45度左右。這個結(jié)果說明1kHz的PWM頻率配S8050三極管完全夠用。我還測過光敏電阻在不同環(huán)境下的ADC讀數(shù)。室內(nèi)日光燈下約1500-2000室外陰天約2800-3200用手完全遮住約50-200。這些數(shù)據(jù)對后續(xù)設(shè)定閾值很有參考價值。不同批次的光敏電阻參數(shù)差異挺大的所以每個人的閾值都需要根據(jù)自己實測數(shù)據(jù)重新標(biāo)定不要直接照抄別人的參數(shù)。寫在最后的一點心得整套系統(tǒng)做下來最大的體會是這個項目真正的難點不在STM32本身也不在ESP8266怎么用AT指令而在于把“采集—控制—聯(lián)網(wǎng)—上云—應(yīng)用端展示”這整條鏈路串起來之后任何一個環(huán)節(jié)的故障都可能讓系統(tǒng)表現(xiàn)得很“玄學(xué)”。沒有示波器就看PWM波形沒有邏輯分析儀就看串口日志一步步縮小排查范圍比一次性把全部代碼寫完更重要。另外分享一個小技巧云平臺的“設(shè)備影子”功能非常值得用。OneNET和阿里云都有類似機(jī)制可以在設(shè)備離線時緩存云端下發(fā)的指令等設(shè)備上線后自動同步。如果項目有時間余量建議在APP端和云平臺規(guī)則引擎上稍微折騰一下做個定時開關(guān)燈功能答辯演示效果會比單純的點亮關(guān)燈好很多。做系統(tǒng)設(shè)計時留好擴(kuò)展位這個項目的上限其實比你想的要高。