最近剛把手頭這臺“能聯(lián)網(wǎng)的智能貓眼”完整跑通從硬件焊接到代碼調(diào)通前前后后折騰了大概兩個周末。這里把整個項目從選型到實現(xiàn)的完整過程整理出來包括所有踩過的坑和最終能直接跑的代碼給想做類似東西的朋友一個參考。這套系統(tǒng)用的是ESP32-S3做主控搭配OV2640攝像頭模塊和ILI9488屏幕。核心做的事情其實就三件攝像頭上電后持續(xù)采集門口畫面畫面在室內(nèi)端的ILI9488屏幕上實時顯示同時通過WiFi把畫面以視頻流的形式推送到手機或電腦瀏覽器做到人在客廳甚至不在家也能看到門口情況。相比市面上成品智能貓眼DIY這套的成本大概在一百五到兩百塊之間而且代碼完全可控想加什么功能自己改就行。這套方案適合有基礎(chǔ)單片機經(jīng)驗、能看懂基本電路、愿意動手焊線的朋友。如果你只是想把代碼燒進去能亮屏出畫面那花一個小時就能搞定如果想做成一款真正能日常使用、穩(wěn)定不重啟的成品那這篇文里的供電、接線、內(nèi)存分配這些問題都得認真看。1. 整體設(shè)計思路為什么是這三顆芯片的組合1.1 選型邏輯每一顆芯片在系統(tǒng)中扮演的角色先說ESP32-S3。很多人會問為什么不用經(jīng)典的ESP32-CAM或者ESP32-CAM-MB那玩意兒連攝像頭都集成了焊上就能用。ESP32-CAM確實便宜三十幾塊錢一塊板子OV2640攝像頭直接排線接好但這塊板子的短板太明顯了一是PSRAM頻率和帶寬有限在較高分辨率下采集JPEG再通過WiFi推流幀率很難超過15幀實際使用中卡頓明顯二是ESP32-CAM板載的PCB天線在金屬外殼或者門體附近信號衰減非常厲害三是IO口太少想接門鈴、PIR傳感器、補光燈、喇叭這些外設(shè)基本就沒引腳可用了。而ESP32-S3這顆芯片在ESP32系列里屬于“偏科但偏得特別準”的一顆。它的兩個核心最高跑到240MHz內(nèi)置的向量指令對圖像處理有幫助但真正讓它適合做智能貓眼的是它最高支持16MB的Quad SPI PSRAM而且PSRAM和主頻之間的通信帶寬比老款ESP32高了不少。攝像頭采集出來的原始圖像數(shù)據(jù)量巨大一張480x320的RGB565圖像就是300KB如果沒有PSRAM根本存不下幾幀緩沖而把圖像以JPEG格式壓縮后一張圖大概30-60KB但對MCU來說壓縮過程本身就需要大量臨時內(nèi)存。S3的大PSRAM意味著我可以同時開多個幀緩沖一個用于屏幕顯示一個用于網(wǎng)絡(luò)推流互相不干擾。再說OV2640。這個傳感器在DIY圈子里用的時間非常久200萬像素支持UXGA1600x1200輸出也能直接輸出JPEG壓縮格式。選擇它而不是更新的OV5640首要原因是資料多、坑少、驅(qū)動成熟esp32-camera庫對它的支持非常完善幾乎插上就能出圖像。另一個重要原因是功耗和發(fā)熱OV2640在正常工作時的電流在60mA左右而OV5640動輒上百毫安在貓眼這種要7x24小時通電的場景里穩(wěn)定性和發(fā)熱控制更重要。最后是ILI9488屏幕。480x320的分辨率在MCU直驅(qū)的屏幕里已經(jīng)算大尺寸了作為貓眼室內(nèi)端的顯示設(shè)備能比較清楚地看到門外人臉和身體輪廓。ILI9488是SPI接口四線制接線非常簡單而且這顆驅(qū)動IC非常成熟幾乎所有主流GUI庫都原生支持。另外ILI9488的可視角度比普通IPS略差但貓眼的使用場景是固定角度觀看影響不大而且它的價格便宜一塊3.5寸屏大概三十塊上下性價比很高。1.2 系統(tǒng)三條核心數(shù)據(jù)鏈路這個項目的系統(tǒng)架構(gòu)本質(zhì)上可以拆成三條獨立的數(shù)據(jù)鏈路所有代碼和硬件設(shè)計都是圍繞這三條鏈路展開的。第一條是采集鏈路OV2640攝像頭通過DVP并行接口把圖像數(shù)據(jù)傳給ESP32-S3。DVP是一條8位并行數(shù)據(jù)總線加上PCLK像素時鐘、VSYNC幀同步、HREF行同步等控制信號。ESP32-S3的硬件外設(shè)中有專門的LCD_CAM接口可以直接對接這類并行圖像傳感器據(jù)說比用IO模擬時序要穩(wěn)定得多。數(shù)據(jù)進入芯片后DMA控制器會直接把數(shù)據(jù)搬運到PSRAM中的幀緩沖區(qū)域整個過程不占用CPU核心CPU只需要在幀完成時收到一個中斷通知。第二條是顯示鏈路ESP32-S3從PSRAM中取出圖像數(shù)據(jù)經(jīng)過縮放和格式轉(zhuǎn)換后通過SPI接口寫入ILI9488屏幕。這里的關(guān)鍵是SPI速度盡量拉高同時必須開啟DMA傳輸否則SPI傳輸一個大尺寸圖像會長時間阻塞CPU。如果直接把一整塊480x320的RGB565數(shù)據(jù)刷到屏幕上數(shù)據(jù)量是300KB在40MHz SPI時鐘下單次傳輸也需要約60ms所以顯示刷新率做到15-20幀是合理范圍實際肉眼看完全夠用不會覺得特別卡。第三條是網(wǎng)絡(luò)鏈路ESP32-S3把JPEG格式的圖像幀通過WiFi發(fā)送出去瀏覽器端用MJPEG格式解碼顯示。MJPEG本質(zhì)就是把一組JPEG圖片按順序播放每一幀是獨立的完整JPEG文件所以接收端解碼邏輯非常簡單瀏覽器原生支持手機端也不需要裝任何App打開網(wǎng)頁就能看。這條鏈路的關(guān)鍵在于WiFi的帶寬和TCP/IP協(xié)議棧的處理能力決定了能推多高的幀率而S3在局域網(wǎng)內(nèi)實際測試推VGA分辨率640x480的MJPEG流可以穩(wěn)定跑在20幀以上。這三條鏈路核心的矛盾點在于內(nèi)存和帶寬的分配。采集鏈路要占一塊幀緩沖顯示鏈路再占一塊網(wǎng)絡(luò)推流還要一塊如果不提前規(guī)劃好PSRAM的分區(qū)和使用策略后面調(diào)試必然后悔。2. 硬件選型與接線避坑從板子到屏幕的完整清單2.1 開發(fā)板怎么選帶PSRAM是硬性條件ESP32-S3的模組和開發(fā)板市面上非常多選擇的時候最核心的一條就是必須選帶PSRAM的型號而且最好是Octal PSRAM。因為之前在ESP32-CAM上吃過沒內(nèi)存的虧這次我直接選了ESP32-S3-WROOM-1-N16R8這個模組的開發(fā)板其中16表示16MB FlashR8表示8MB的Octal PSRAM。在實際選擇開發(fā)板時需要注意幾個細節(jié)。第一看板子是否引出了完整的攝像頭FPC排線座有些S3開發(fā)板雖然芯片支持攝像頭接口但板上沒有焊接攝像頭座子需要自己飛線或者轉(zhuǎn)接板非常痛苦。第二看引腳是否兼容常見庫的默認配置esp32-camera庫在GitHub上針對S3開發(fā)板有專門的引腳定義文件選板時盡量選那些已知配置的板子能省很多調(diào)試時間。第三看板上有沒有USB轉(zhuǎn)串口芯片S3原生支持USB CDC可以直接通過USB口燒錄和打印日志但有些低端板子偷工減料USB電路做得不穩(wěn)定燒錄時經(jīng)常掉線。我買的是合宙ESP32-S3開發(fā)板帶8MB PSRAM攝像頭FPC座子直接焊好引出IO也基本兼容官方示例配置。這塊板子看起來比較簡陋也沒有金屬屏蔽罩但實際測試WiFi信號和PSRAM穩(wěn)定性都還不錯價格大概六十塊出頭。當然如果預(yù)算充足用樂鑫官方的DevKitC也是好選擇做工和穩(wěn)定性更有保障。2.2 接線表與引腳說明照著接就行OV2640攝像頭采用DVP并行接口總共需要將近15根信號線。我在實際接線時沒有直接用跳線飛線而是讓攝像頭模塊通過FPC排線連到一個轉(zhuǎn)接板再從轉(zhuǎn)接板引出插針到開發(fā)板。這樣做的原因是DVP的數(shù)據(jù)線D0-D7頻率較高如果全部用杜邦線懸空飛線信號串擾會導(dǎo)致圖像出現(xiàn)彩虹紋和噪點這種問題排查起來非常頭疼。以下是本次項目的完整接線表攝像頭信號GPIO說明SIODI2C數(shù)據(jù)GPIO8攝像頭寄存器配置用I2CSIOCI2C時鐘GPIO9攝像頭寄存器配置用I2CVSYNC幀同步GPIO6一幀圖像開始/結(jié)束的標志HREF行同步GPIO7一行像素開始/結(jié)束的標志PCLK像素時鐘GPIO13每個像素的同步時鐘XCLK主時鐘GPIO15由ESP32輸出的攝像頭工作時鐘D0-D7數(shù)據(jù)線GPIO11, 12, 14, 16, 17, 18, 48, 478位并行像素數(shù)據(jù)PWDN電源控制GPIO10低電平使能攝像頭RESET復(fù)位GPIO5攝像頭復(fù)位控制可懸空屏幕接線相對簡單就是標準的SPI屏屏幕信號GPIO說明CS片選GPIO3SPI片選低電平有效DC數(shù)據(jù)/命令選擇GPIO40表示寫命令1表示寫數(shù)據(jù)SCKSPI時鐘GPIO1最高建議不超過40MHzMOSI主出從入GPIO2屏幕數(shù)據(jù)線RST復(fù)位GPIO42屏幕復(fù)位低電平有效BLK背光GPIO41高電平點亮背光支持PWM調(diào)光這里有幾個值得注意的點。首先攝像頭和屏幕共用SPI或者I2C總線會互相干擾嗎我的方案是兩者各自占用獨立的GPIO和總線攝像頭走專用并行接口屏幕走SPI互不干擾。其次背光引腳不要直接接3.3V高電平最好接一個GPIO這樣在代碼里可以控制屏幕休眠時熄滅背光能明顯降低整機功耗。第三如果板子上的GPIO定義和上面這張表不一致一定要先查開發(fā)板的原理圖再接線不要盲目照抄否則可能燒壞傳感器。2.3 供電設(shè)計貓眼死機重啟的第一大元兇智能貓眼是7x24小時通電設(shè)備供電穩(wěn)定性決定了整個項目的成敗。很多人DIY的時候直接用USB線接一個手機充電頭結(jié)果發(fā)現(xiàn)設(shè)備每隔幾分鐘就重啟一次或者WiFi一推流就重啟大概率都是供電問題。先算一下整套系統(tǒng)的功耗。ESP32-S3在WiFi開啟且CPU全速運行時的電流大約300-400mA攝像頭工作電流約60-80mAILI9488屏幕點亮背光時約100-150mA三個加起來正常工作電流在500mA左右峰值瞬間電流甚至能到800mA。所以供電方案至少要能持續(xù)提供1A以上的電流。普通的USB充電頭大多能輸出1-2A問題不大但連接線一定要短線徑要粗我實測過某些劣質(zhì)MicroUSB線在1A電流下的壓降居然有0.5V以上直接導(dǎo)致3.3V電壓跌落MCU當場復(fù)位。另外如果打算把這塊貓眼做成一個壁掛裝置強烈建議用5V 2A的電源適配器供電而不是用鋰電池。鋰電池方案在ESP32-S3這種高負載場景下需要非常精細的電源管理否則電池很快饋電反而影響使用體驗。當然如果門邊有預(yù)留86盒電源線直接接一個5V降壓模塊是最理想的。還有一個非常關(guān)鍵的細節(jié)攝像頭模塊的AVDD和DOVDD通常由板載LDO提供但如果使用獨立攝像頭模組要注意它的供電是否和主控共地。如果地線接觸不良畫面會出現(xiàn)嚴重的橫紋干擾這種問題用萬用表量電壓是量不出來的只能重新整理地線解決。3. 軟件框架與代碼實現(xiàn)從初始化到推流的完整閉環(huán)3.1 開發(fā)環(huán)境直接用PlatformIO別用Arduino IDE代碼層面我使用的是PlatformIO ESP-IDF框架。這里先說明一下為什么不用Arduino IDEESP32-S3的攝像頭、WiFi推流、大屏顯示都需要精細化控制內(nèi)存和時序Arduino IDE雖然配置簡單但出了問題尤其是內(nèi)存分配和編譯優(yōu)化相關(guān)的問題排查起來非常麻煩而且它對多個文件的工程管理很弱。PlatformIO底層用的是ESP-IDF編譯出來的固件更高效內(nèi)存管理更透明而且生態(tài)里的庫管理非常方便一條配置命令就能搞定依賴。在platformio.ini配置文件里核心配置如下[env:esp32s3] platform espressif32 board esp32-s3-devkitc-1 framework arduino board_build.flash_mode qio board_build.f_flash 80000000L board_build.psram_type qio board_build.f_psram 80000000L build_flags -DARDUINO_USB_CDC_ON_BOOT1 -DBOARD_HAS_PSRAM -mfix-esp32-psram-cache-issue lib_deps me-no-dev/ESP32-Camera1.0.0 moononournation/GFX Library for Arduino1.4.8 moononournation/TFT_eSPI2.5.0這里有三個關(guān)鍵點。第一PSRAM類型和頻率必須和模組實際參數(shù)一致如果是Octal PSRAM這里要改配置如果配置錯了系統(tǒng)會在啟動時檢測到內(nèi)存異常攝像頭初始化必失敗。第二-mfix-esp32-psram-cache-issue這個標志位很重要早期S3芯片在PSRAM和Cache協(xié)同工作時存在bug編譯時必須帶上這個修復(fù)選項否則運行一兩個小時就會隨機死機。第三TFT_eSPI這個庫是屏幕顯示的核心它支持SPI DMA傳輸而且針對ILI9488有非常成熟的驅(qū)動直接用它比自己寫寄存器初始化要穩(wěn)定得多。TFT_eSPI庫在首次使用前需要修改它的User_Setup.h文件配置屏幕型號、引腳、SPI頻率。我使用的是以下配置#define ILI9488_DRIVER #define TFT_MISO -1 #define TFT_MOSI 2 #define TFT_SCLK 1 #define TFT_CS 3 #define TFT_DC 4 #define TFT_RST 42 #define TFT_BL 41 #define SPI_FREQUENCY 40000000 #define SPI_READ_FREQUENCY 20000000 #define SPI_TOUCH_FREQUENCY 2500000注意TFT_MISO設(shè)成了-1因為ILI9488屏幕實際上不需要回傳數(shù)據(jù)給主控我們只需要單向?qū)憟D像數(shù)據(jù)這樣能省一根線。SPI頻率設(shè)為40MHz這是ILI9488在3.3V供電下比較穩(wěn)妥的上限再高可能因為信號完整性導(dǎo)致花屏。3.2 攝像頭初始化內(nèi)存布局和幀率的平衡攝像頭的初始化是整個項目里最容易出問題的一步99%的“初始化失敗”“白屏”都出在內(nèi)存配置上。以下是我最終調(diào)通的初始化代碼#include esp_camera.h #define CAM_PIN_PWDN 10 #define CAM_PIN_RESET 5 #define CAM_PIN_XCLK 15 #define CAM_PIN_SIOD 8 #define CAM_PIN_SIOC 9 #define CAM_PIN_D7 11 #define CAM_PIN_D6 12 #define CAM_PIN_D5 14 #define CAM_PIN_D4 16 #define CAM_PIN_D3 17 #define CAM_PIN_D2 18 #define CAM_PIN_D1 48 #define CAM_PIN_D0 47 #define CAM_PIN_VSYNC 6 #define CAM_PIN_HREF 7 #define CAM_PIN_PCLK 13 void camera_init() { camera_config_t config; config.ledc_channel LEDC_CHANNEL_0; config.ledc_timer LEDC_TIMER_0; config.pin_d0 CAM_PIN_D0; config.pin_d1 CAM_PIN_D1; config.pin_d2 CAM_PIN_D2; config.pin_d3 CAM_PIN_D3; config.pin_d4 CAM_PIN_D4; config.pin_d5 CAM_PIN_D5; config.pin_d6 CAM_PIN_D6; config.pin_d7 CAM_PIN_D7; config.pin_xclk CAM_PIN_XCLK; config.pin_pclk CAM_PIN_PCLK; config.pin_vsync CAM_PIN_VSYNC; config.pin_href CAM_PIN_HREF; config.pin_sccb_sda CAM_PIN_SIOD; config.pin_sccb_scl CAM_PIN_SIOC; config.pin_pwdn CAM_PIN_PWDN; config.pin_reset CAM_PIN_RESET; config.xclk_freq_hz 20000000; config.pixel_format PIXFORMAT_JPEG; config.frame_size FRAMESIZE_VGA; config.jpeg_quality 10; config.fb_count 2; esp_err_t err esp_camera_init(config); if (err ! ESP_OK) { Serial.printf(攝像頭初始化失敗: 0x%x\n, err); return; } }這段代碼里最核心的配置項是這幾個xclk_freq_hz設(shè)為20MHz。XCLK是ESP32輸出給攝像頭的時鐘信號OV2640最高支持24MHz但實測在20MHz時畫面最穩(wěn)定超過之后偶爾會出現(xiàn)花屏和數(shù)據(jù)錯位。20MHz下OV2640的輸出幀率已經(jīng)足夠。pixel_format設(shè)為PIXFORMAT_JPEG。這一點非常關(guān)鍵OV2640內(nèi)置了JPEG編碼器可以直接輸出壓縮后的JPEG流。如果這里設(shè)置成PIXFORMAT_RGB565一幀VGA畫面是614400字節(jié)640x480x2而JPEG格式可能只有20-50KB差距有十幾倍。對于網(wǎng)絡(luò)推流場景必須用JPEG格式否則WiFi帶寬根本不夠。fb_count設(shè)為2這是雙緩沖模式。雙緩沖的意思是在攝像頭采集完一幀寫入一個緩沖區(qū)的同時CPU可以處理上一幀的數(shù)據(jù)不會出現(xiàn)采集和顯示互相等待的死鎖。如果沒有雙緩沖畫面會明顯卡頓幀率至少下降一半。jpeg_quality設(shè)為10這個值范圍是0-63數(shù)值越小畫質(zhì)越好但文件越大。10是經(jīng)過測試的平衡點畫面細節(jié)足夠看清楚人臉五官單幀大小在30-50KB在局域網(wǎng)推流時流暢度和清晰度都能兼顧。3.3 屏幕顯示把攝像頭畫面搬到ILI9488上的關(guān)鍵代碼攝像頭采集到JPEG數(shù)據(jù)后屏幕顯示需要先把JPEG解碼成RGB565格式再縮放并繪制到屏幕上。這里有一個非常重要的優(yōu)化點不要直接使用JPEG數(shù)據(jù)往屏幕上傳ILI9488不認JPEG格式必須解碼成像素數(shù)據(jù)。TFT_eSPI庫提供了一個高效的JPEG解碼接口配合PNGdec庫使用。但我的項目中用的是更輕量的方法直接調(diào)用esp32-camera庫自帶的fmt2rgb888函數(shù)把JPEG幀解碼成RGB888格式再轉(zhuǎn)換成TFT_eSPI需要的RGB565格式。核心代碼如下void display_frame(camera_fb_t *fb) { uint8_t *rgb888 (uint8_t *)ps_malloc(fb-width * fb-height * 3); if (rgb888 NULL) return; fmt2rgb888(fb-buf, fb-len, PIXFORMAT_JPEG, rgb888); uint16_t *rgb565 (uint16_t *)ps_malloc(320 * 240 * 2); if (rgb565 NULL) { free(rgb888); return; } // 將RGB888轉(zhuǎn)換為RGB565并縮放到240P for (int y 0; y 240; y) { for (int x 0; x 320; x) { int src_x x * fb-width / 320; int src_y y * fb-height / 240; int src_idx (src_y * fb-width src_x) * 3; uint16_t r rgb888[src_idx] 3; uint16_t g rgb888[src_idx 1] 2; uint16_t b rgb888[src_idx 2] 3; rgb565[y * 320 x] (r 11) | (g 5) | b; } } tft.pushImage(0, 0, 320, 240, rgb565); free(rgb888); free(rgb565); }這段代碼里有幾個關(guān)鍵決定。第一這里把顯示分辨率設(shè)成了320x240而不是ILI9488的全分辨率480x320因為攝像頭輸出的是4:3比例的VGA畫面而屏幕也是4:3等比縮放后320x240剛好占滿屏幕的中間區(qū)域不需要裁剪。如果想要480x320全屏顯示需要把縮放目標改成480x320但這樣每幀的轉(zhuǎn)換和傳輸時間會翻倍幀率會降到10幀以下不太劃算。第二臨時內(nèi)存全部用ps_malloc分配在PSRAM而不是普通的malloc這一點至關(guān)重要。普通的heap內(nèi)存只有幾百KB如果用來存放RGB888幀緩沖直接就把內(nèi)部RAM榨干了系統(tǒng)會因為內(nèi)存不足不斷重啟。而PSRAM有8MB放兩個幀緩沖綽綽有余。第三這里實現(xiàn)了一個簡單的雙線性縮放——當然嚴格來說不是雙線性是等比例采樣效果在實際使用中夠用。如果對畫面質(zhì)量要求高可以換成真正的雙線性插值但MCU的處理速度會變慢幀率損失大約3-5幀貓眼場景下沒必要。這個功能在實際測試中的顯示幀率大約15-18幀橫豎方向都流暢看門口的人走動完全不會覺得卡。3.4 聯(lián)網(wǎng)推流瀏覽器直接看實時畫面聯(lián)網(wǎng)部分是整個項目名稱里“能聯(lián)網(wǎng)”三個字的核心。用esp32-camera庫自帶的httpd組件實現(xiàn)MJPEG流服務(wù)器這是最成熟穩(wěn)定的方案而且這個庫本身就內(nèi)置了對應(yīng)示例代碼只需要綁定一下URL路由就行。#include esp_http_server.h static esp_err_t stream_handler(httpd_req_t *req) { esp_camera_fb_t *fb NULL; esp_err_t res ESP_OK; httpd_resp_set_type(req, multipart/x-mixed-replace; boundaryframe); while (true) { fb esp_camera_fb_get(); if (!fb) { res ESP_FAIL; } else { char part[64]; snprintf(part, sizeof(part), --frame\r\nContent-Type: image/jpeg\r\nContent-Length: %u\r\n\r\n, fb-len); httpd_resp_send_chunk(req, part, strlen(part)); httpd_resp_send_chunk(req, (const char *)fb-buf, fb-len); httpd_resp_send_chunk(req, \r\n, 2); } esp_camera_fb_return(fb); if (res ! ESP_OK) break; } return res; } void start_camera_server() { httpd_config_t config HTTPD_DEFAULT_CONFIG(); config.server_port 80; config.max_uri_handlers 4; config.stack_size 8192; httpd_handle_t server NULL; if (httpd_start(server, config) ESP_OK) { httpd_uri_t stream_uri { .uri /stream, .method HTTP_GET, .handler stream_handler, .user_ctx NULL }; httpd_register_uri_handler(server, stream_uri); } }MJPEG流的網(wǎng)絡(luò)協(xié)議本質(zhì)上是一個普通的HTTP長連接服務(wù)器每隔一段時間就發(fā)一張JPEG圖片客戶端瀏覽器收到后按順序刷新顯示就達到了“視頻”的效果。瀏覽器端訪問http://設(shè)備IP/stream就能看到實時畫面。我用手機和電腦各測了一遍局域網(wǎng)內(nèi)延遲大約200-300ms這個延遲對看門口夠用畢竟貓眼場景不需要像游戲那樣低延遲。這里有幾個需要特別說明的工程化細節(jié)第一httpd_resp_send_chunk使用分塊傳輸編碼每幀JPEG數(shù)據(jù)作為一個獨立的chunk發(fā)送。這樣做的原因是MJPEG流本身數(shù)據(jù)量不穩(wěn)定單幀大小會隨著畫面復(fù)雜度變化如果一次性把一個巨大的數(shù)據(jù)包發(fā)給瀏覽器緩沖壓力很大容易出現(xiàn)畫面延遲越來越大的情況。分塊發(fā)送可以讓瀏覽器邊收邊顯示。第二config.stack_size設(shè)成了8192。HTTP流處理是在一個獨立的任務(wù)中運行的這個任務(wù)需要足夠的?？臻g來處理網(wǎng)絡(luò)協(xié)議棧和JPEG幀讀取如果棧設(shè)太小推流一段時間后會發(fā)生棧溢出表現(xiàn)為設(shè)備重啟或者流被切斷。8192是一個經(jīng)過實測比較安全的數(shù)值。第三幀率控制。這段代碼沒有主動做幀率限制攝像頭的幀率是多少就推多少。如果發(fā)現(xiàn)推流占用帶寬過高可以在每次循環(huán)里加一個vTaskDelay(pdMS_TO_TICKS(30))把幀率限制在30幀以內(nèi)。對貓眼場景來說15-25幀已經(jīng)非常流暢再高只會增加帶寬和發(fā)熱。3.5 完整代碼流程三大任務(wù)如何協(xié)同工作整個固件的main函數(shù)采用的是多任務(wù)框架void setup() { Serial.begin(115200); camera_init(); tft.begin(); tft.setRotation(0); tft.fillScreen(TFT_BLACK); WiFi.begin(你的WiFi名稱, 你的WiFi密碼); while (WiFi.status() ! WL_CONNECTED) { delay(500); Serial.print(.); } Serial.println(\nWiFi連接成功IP地址: WiFi.localIP().toString()); start_camera_server(); xTaskCreatePinnedToCore(display_task, display, 8192, NULL, 1, NULL, 0); } void loop() { vTaskDelay(pdMS_TO_TICKS(1000)); } void display_task(void *param) { while (true) { camera_fb_t *fb esp_camera_fb_get(); if (fb) { display_frame(fb); esp_camera_fb_return(fb); } } }整體任務(wù)劃分是這樣的loop()主循環(huán)只做心跳保活攝像頭采集在esp_camera_fb_get的調(diào)用中自動完成display_task這個任務(wù)專門負責(zé)把采集到的幀顯示到屏幕上網(wǎng)絡(luò)推流則由httpd服務(wù)器的獨立任務(wù)處理。三個任務(wù)可以并行運行互不阻塞這是SPI屏幕和WiFi推流能同時工作的基礎(chǔ)。這里還有一個容易踩的坑不要在主循環(huán)里同時做推流和屏幕刷新因為WiFi推流的網(wǎng)絡(luò)I/O會阻塞CPU屏幕刷新的時間也會被拉長兩邊都會變卡。把不同功能拆到不同任務(wù)里綁定到不同的CPU核心上ESP32-S3是雙核才是真正能長期穩(wěn)定運行的結(jié)構(gòu)。4. 整機裝配與功能擴展從“能跑”到“好用”4.1 外殼設(shè)計與鏡頭角度完成電路和代碼之后剩下的就是整機裝配。智能貓眼和普通開發(fā)板項目的不同之處在于它需要長期掛在門上所以外殼設(shè)計、鏡頭安裝角度和散熱都必須考慮進去。我用FreeCAD設(shè)計了一個簡單的兩件式外殼外層是固定在門外側(cè)的鏡頭面板開一個12mm的圓孔正好卡住OV2640攝像頭的鏡頭鏡頭視場角約120度安裝時需要把鏡頭略微朝下傾斜10度左右這樣能同時拍到人臉和胸前區(qū)域視野比較合理。內(nèi)層是室內(nèi)側(cè)的屏幕面板ILI9488屏幕卡在一個凹槽里四周用熱熔膠固定。兩個外殼通過一條約1厘米寬的排線連接排線中間開槽穿門。外殼材料我用的PLA3D打印參數(shù)0.2mm層高、20%填充打印時間大約4小時。PLA的耐熱性雖然一般但門內(nèi)環(huán)境溫度不會太高完全夠用。如果有條件PETG更耐潮濕和高溫但打印難度會高一些。如果沒有3D打印機也可以用亞克力板做框架或者直接用萬能盒加開孔器改裝。重點是攝像頭和屏幕都要固定牢靠不要晃動否則畫面會抖。4.2 夜間與弱光場景優(yōu)化智能貓眼如果沒有夜視功能晚上基本就是瞎子。OV2640本身對光線的靈敏度一般在微弱光線下畫面噪點非常嚴重。我的方案分兩步解決第一步是加補光燈。在攝像頭鏡頭旁邊并排安裝兩顆白光LED由GPIO控制光照不足時自動打開?？刂七壿媽懺谥餮h(huán)里每隔10秒讀取一次攝像頭畫面的平均亮度如果亮度低于閾值就開燈。但這里要注意白色補光燈在夜間從門外看非常顯眼容易暴露自家門口裝了智能貓眼如果有隱私顧慮建議改用850nm紅外補光燈配合去掉紅外截止濾鏡的攝像頭可以實現(xiàn)真正的黑白夜視。第二步是調(diào)節(jié)攝像頭的曝光和增益。OV2640的傳感器寄存器支持下發(fā)自動曝光和自動增益控制參數(shù)#include sensor.h sensor_t *sensor esp_camera_sensor_get(); sensor-set_brightness(sensor, 1); sensor-set_contrast(sensor, 1); sensor-set_saturation(sensor, 0); sensor-set_quality(sensor, 10); sensor-set_gain_ctrl(sensor, 1); // 自動增益 sensor-set_exposure_ctrl(sensor, 1); // 自動曝光這些參數(shù)在夜間會自動拉高增益和曝光時間畫面會變亮一些但噪點也會增加。實際使用中如果門口有樓道感應(yīng)燈或者有夜燈OV2640基本能看清人形輪廓如果要看清楚人臉建議還是加紅外補光。4.3 功能擴展方向門鈴聯(lián)動、PIR觸發(fā)、SD卡本地存儲基礎(chǔ)版本能出畫面、能聯(lián)網(wǎng)看已經(jīng)算是一個完整產(chǎn)品了。但如果想讓這套貓眼進一步滿足日常使用需求還有幾個性價比很高的擴展方向。第一個是門鈴聯(lián)動。在門外側(cè)加一個按鈕按下后觸發(fā)GPIO中斷ESP32-S3在中斷中拍一張照片同時播放一段門鈴音效通過I2S接一個小喇叭再把這個事件推送到手機。實現(xiàn)起來并不難GPIO中斷拍照HTTP推送幾個功能拼在一起就行。第二個是PIR人體感應(yīng)聯(lián)動。在門上方安裝一個PIR傳感器比如HC-SR505檢測到有人靠近時自動喚醒屏幕開始錄像或拍照人走之后屏幕休眠這樣可以大幅降低平均功耗讓屏幕不用7x24小時點亮。第三個是SD卡本地存儲。ESP32-S3支持SDMMC和SPI兩種方式讀寫SD卡如果接上SD卡可以把門鈴觸發(fā)時的照片或視頻片段存到本地即使斷網(wǎng)也能保留證據(jù)。這個功能在安防場景下很有意義。這些擴展方向的核心邏輯都是復(fù)用已經(jīng)跑通的“采集-顯示-網(wǎng)絡(luò)”鏈路只是在特定事件上增加觸發(fā)條件沒有想象中的復(fù)雜。后面我計劃把PIR觸發(fā)和SD卡存儲加上做一個真正能當安防設(shè)備使用的完整版。5. 常見問題排查與調(diào)試實錄5.1 一張實用的故障速查表在整個項目調(diào)試過程中我遇到了不少問題把最有代表性的幾個列在下面供大家參考?，F(xiàn)象可能原因解決方案攝像頭初始化失敗返回0x10005PSRAM未正確啟用或內(nèi)存不足檢查platformio.ini的PSRAM配置確認BOARD_HAS_PSRAM已定義攝像頭初始化成功但畫面全白XCLK頻率過高或攝像頭供電不足把XCLK從24MHz降為20MHz檢查攝像頭供電線直徑畫面有彩虹紋或花屏DVP數(shù)據(jù)線信號干擾改用FPC排線連接縮短數(shù)據(jù)線長度確認地線可靠連接屏幕白屏不顯示SPI引腳配置錯誤或屏幕初始化失敗檢查User_Setup.h中的引腳定義是否和接線一致測試SCK是否有波形屏幕畫面撕裂屏幕刷新和攝像頭采集之間沒有同步使用fb_count2雙緩沖模式確認代碼中使用esp_camera_fb_get返回后及時釋放WiFi推流卡頓嚴重緩沖區(qū)太小或SPI刷新占用CPU過高網(wǎng)絡(luò)推流任務(wù)和屏幕刷新任務(wù)分核運行增大httpd配置中stack_size設(shè)備運行幾小時后重啟供電不足或PSRAM Cache bug檢查電源線壓降編譯時加-mfix-esp32-psram-cache-issue標記手機瀏覽器打不開/streamWiFi連接不穩(wěn)定或端口被占用確認設(shè)備IP地址正確電腦和手機在同一網(wǎng)段路由器關(guān)閉AP隔離表格里的這些現(xiàn)象前四個是硬件層面的后四個是軟件層面的。在實際調(diào)試時我建議先解決硬件問題再調(diào)軟件否則軟件怎么調(diào)都看不到正確結(jié)果。特別是白屏、花屏這類問題如果攝像頭輸出信號不對后面所有的圖像處理代碼都是白搭。5.2 幀率提升的真實調(diào)優(yōu)過程項目初期這套系統(tǒng)的實際幀率只有8-9幀看起來非常卡。通過三步優(yōu)化最終穩(wěn)定到了20幀以上。整個過程很有參考價值。第一步確認瓶頸在CPU還是在內(nèi)存帶寬。在代碼里加一個簡單的幀率計數(shù)器用millis()計算每秒處理的幀數(shù)。結(jié)果顯示在屏幕刷新和WiFi推流同時開啟時幀率只有8幀而單獨關(guān)閉屏幕刷新后幀率能到20幀這說明瓶頸在屏幕刷新這條鏈路上。第二步優(yōu)化屏幕刷新的傳輸方式。TFT_eSPI庫默認是阻塞式傳輸即每次發(fā)送一幀數(shù)據(jù)都要等SPI發(fā)送完成才能做別的。我改成了DMA方式把圖像數(shù)據(jù)先放到DMA緩沖區(qū)然后啟動DMA傳輸CPU不等待繼續(xù)做下一幀的解碼和縮放。這一步優(yōu)化之后幀率提升到了14幀左右雖然有效果但還不夠。第三步也是最關(guān)鍵的一步降低縮放分辨率。原來我把VGA畫面縮放到了480x320屏幕全屏每幀要傳輸300KB數(shù)據(jù)。改成縮放至320x240后每幀傳輸數(shù)據(jù)量降為150KBSPI傳輸時間直接減半。同時我在display_frame函數(shù)里加了一個判斷如果上一幀還沒傳完就跳過當前幀保證每幀都是完整顯示而不是覆蓋顯示。這一步完成后幀率直接到了20幀以上。這三步的優(yōu)化思路其實很通用先找熱點再優(yōu)化傳輸方式最后降低數(shù)據(jù)量。5.3 一個容易忽略的坑WiFi信號穩(wěn)定性最后一個想重點提醒的坑是WiFi信號在金屬門體上的衰減。我一開始直接把開發(fā)板裸奔放在室內(nèi)側(cè)手機在同一個房間看畫面很流暢。但裝進外殼、掛到門上之后發(fā)現(xiàn)推流經(jīng)?？DWiFi信號強度從-45dBm降到了-70dBm。原因是金屬門對WiFi信號有很強的屏蔽作用而ESP32-S3的PCB天線方向是可變的裝進外殼后天線位置剛好被金屬門遮擋。解決方法是把開發(fā)板天線端朝下安裝同時外殼內(nèi)部避免使用金屬支撐柱盡量用塑料螺絲。如果門體是全金屬的信號衰減非常嚴重這時候只能把WiFi天線外置——部分S3開發(fā)板自帶IPEX天線座可以外接一根2.4G天線貼到門框內(nèi)側(cè)信號問題就徹底解決了。這個問題的排查思路是在設(shè)備上打印出當前WiFi信號強度WiFi.RSSI()然后不斷調(diào)整設(shè)備位置觀察數(shù)值變化。如果RSSI低于-65dBm推流就會出現(xiàn)明顯的卡頓和斷流。總的來說這個項目做下來我自己最大的收獲并不是“做出了一個智能貓眼”這個結(jié)果而是完整走通了一條“傳感器采集-本地顯示-網(wǎng)絡(luò)推流”的嵌入式開發(fā)鏈路。ESP32-S3的大PSRAM、高速SPI和WiFi能力剛好在一個非常合適的點上把這三件事同時做好。如果你也照著這個方案做了一臺遇到問題歡迎在評論區(qū)交流我看到的都會回復(fù)。最后分享一個小技巧在調(diào)試階段把攝像頭的幀率、屏幕刷新幀率、WiFi信號RSSI這三個數(shù)據(jù)通過串口定時打印出來每5秒一次可以快速定位整條鏈路到底哪一環(huán)是瓶頸。很多“畫面卡頓”問題看了這三個數(shù)據(jù)之后基本就能確定是CPU太慢、傳輸太慢還是網(wǎng)絡(luò)太慢接下來針對性優(yōu)化就行不用瞎猜。