1. 雙攝到底解決什么問題門鎖場(chǎng)景的三段式需求拆解先交代一下背景。智能門鎖這兩年卷得厲害單攝方案已經(jīng)撐不住用戶對(duì)“看得清、看得全、看得懂”的要求了。我去年開始用君正T23ZN做雙攝方案在門鎖上同時(shí)掛兩顆攝像頭一顆朝外、一顆朝內(nèi)配合STM32F103C8T6做主控整套系統(tǒng)從畫原理圖到跑通第一版固件前后折騰了三個(gè)多月。這篇把整個(gè)設(shè)計(jì)鏈路、關(guān)鍵代碼和調(diào)試經(jīng)驗(yàn)整理出來給正在做或者準(zhǔn)備做類似項(xiàng)目的朋友一個(gè)參考。1.1 門外主攝人臉識(shí)別與訪客留痕的核心場(chǎng)景門外這顆攝像頭是絕對(duì)的主角。它要干的活比大多數(shù)人想象的復(fù)雜白天要能看清人臉細(xì)節(jié)晚上要能靠紅外補(bǔ)光看清輪廓逆光環(huán)境下要能壓住強(qiáng)光拉回暗部細(xì)節(jié)還要能抓拍到快遞員放下包裹的動(dòng)作而不是只拍到一個(gè)頭頂。T23ZN這顆SoC有一顆不錯(cuò)的ISP圖像信號(hào)處理器支持2路sensor輸入這是它能在門鎖雙攝方案里站穩(wěn)腳跟的根本原因。很多方案是用兩顆攝像頭兩顆獨(dú)立編碼芯片去做成本和功耗都?jí)翰幌聛?。而T23ZN的定位就是IPC主控自帶的H.264/H.265硬編碼能力可以同時(shí)處理兩路視頻流省掉了一顆編碼芯片的錢和PCB面積。門外主攝的實(shí)際測(cè)試場(chǎng)景我建議至少覆蓋三類正午強(qiáng)光下的人臉逆光、夜晚全黑環(huán)境下的紅外成像、樓道復(fù)雜光源下的白平衡穩(wěn)定性。這三個(gè)場(chǎng)景占了用戶投訴的八成以上后面調(diào)試章節(jié)我會(huì)細(xì)說怎么調(diào)ISP參數(shù)。1.2 門內(nèi)副攝防尾隨、兒童寵物看護(hù)與異常告警門內(nèi)副攝是這兩年才被重視起來的需求。核心場(chǎng)景是防尾隨——有人跟著進(jìn)門的時(shí)候門外主攝只能拍到前一個(gè)人后面的人被擋住或者只拍到一個(gè)側(cè)臉這時(shí)候門內(nèi)攝像頭就能補(bǔ)上第二視角記錄完整的前后關(guān)系。另外就是看護(hù)需求家里有老人小孩或者寵物的時(shí)候內(nèi)攝可以記錄室內(nèi)動(dòng)態(tài)手機(jī)App能實(shí)時(shí)查看這是一個(gè)很實(shí)際的賣點(diǎn)。內(nèi)攝的性能需求比外攝低一些我用的是一顆低成本的1MP sensorVGA640×480分辨率30fps就夠用。為什么不上2MP因?yàn)閮?nèi)攝的應(yīng)用場(chǎng)景決定了它不需要那么高的分辨率——室內(nèi)光線相對(duì)可控觀看距離近VGA的畫面在手機(jī)屏幕上足夠辨認(rèn)“是誰、在干什么”。而且分辨率越低編碼碼率越低存儲(chǔ)和云端的成本都省下來了。1.3 雙攝的三工作模式同時(shí)錄、切換錄、事件觸發(fā)錄雙攝系統(tǒng)的軟件邏輯不是簡(jiǎn)單地把兩路視頻都開著那樣功耗和發(fā)熱都扛不住。我最終落地的是三種工作模式按場(chǎng)景動(dòng)態(tài)切換同時(shí)錄像模式門外有人按門鈴或者檢測(cè)到人臉時(shí)外攝高分辨率1080P內(nèi)攝標(biāo)清VGA同時(shí)錄像生成兩份時(shí)間戳對(duì)齊的文件。這里有一個(gè)容易被忽略的坑兩顆sensor采集到的畫面起始時(shí)間不可能完全一致SDK的錄像文件是按sensor收幀時(shí)間打時(shí)間戳的如果不做對(duì)齊處理回放時(shí)兩路畫面會(huì)有幾百毫秒的偏差。我用的方案是以外攝的PTS顯示時(shí)間戳為主時(shí)鐘內(nèi)攝收到第一幀后記錄與外攝的時(shí)間偏移量回放時(shí)做補(bǔ)償。切換錄像模式默認(rèn)只開外攝做低碼率待機(jī)錄像內(nèi)攝休眠。檢測(cè)到“開鎖成功”事件后切換到內(nèi)攝錄像記錄進(jìn)屋后的一段時(shí)間。這個(gè)模式的好處是省電——內(nèi)攝的sensor和ISP管線占用的功耗可不少。事件觸發(fā)模式人體紅外PIR傳感器觸發(fā)或者門鎖狀態(tài)變化時(shí)兩顆攝像頭同時(shí)抓拍一張JPEG快照App推送告警。這個(gè)模式對(duì)延遲要求最高從PIR觸發(fā)到兩張照片到達(dá)App端我壓到了800ms以內(nèi)。三種模式的切換由STM32F103C8T6通過串口下發(fā)命令給T23ZN完成。MCU管邏輯SoC管視頻這套職責(zé)劃分貫穿了整個(gè)項(xiàng)目后面細(xì)說。2. T23ZN與STM32F103C8T6的異構(gòu)分工為什么這么拆2.1 SoC與MCU的職責(zé)邊界怎么劃最合理這個(gè)方案里有兩顆芯片很多人一開始搞不清楚到底誰聽誰的。我的劃分原則是誰擅長(zhǎng)什么誰就干什么。T23ZN擅長(zhǎng)的是視頻采集、ISP處理、H.264/H.265編碼、網(wǎng)絡(luò)傳輸和本地存儲(chǔ)。但它不擅長(zhǎng)做什么呢不擅長(zhǎng)跑復(fù)雜的門鎖業(yè)務(wù)邏輯——比如按鍵掃描、電機(jī)驅(qū)動(dòng)、指紋模組通信、藍(lán)牙配網(wǎng)。這些事需要大量的GPIO操作和實(shí)時(shí)性要求很高的控制邏輯用Linux系統(tǒng)去做反而別扭。STM32F103C8T6擅長(zhǎng)的是實(shí)時(shí)控制中斷響應(yīng)快、GPIO操作直接、外設(shè)豐富、功耗低。這塊MCU雖然算力不咋地但做門鎖主控綽綽有余。按鍵、指紋頭、電機(jī)鎖體、PIR傳感器、門磁這些全部都掛在STM32上由它統(tǒng)一管理。兩者之間的交互只有一個(gè)通道UART串口。通信協(xié)議我自己定義了一套核心就幾條命令// 幀結(jié)構(gòu)定義幀頭(2字節(jié)) 長(zhǎng)度(1字節(jié)) 命令字(1字節(jié)) 數(shù)據(jù)(N字節(jié)) CRC8(1字節(jié)) typedef struct { uint8_t header[2]; // 0xAA 0x55 uint8_t length; // 除幀頭外總字節(jié)數(shù) uint8_t cmd_id; // 命令字 uint8_t data[64]; // 數(shù)據(jù)段 uint8_t crc8; // CRC校驗(yàn) } protocol_frame_t; // 常用命令字定義 #define CMD_START_DUAL_RECORD 0x01 // 開啟雙錄 #define CMD_START_INNER_RECORD 0x02 // 只開內(nèi)攝錄 #define CMD_START_OUTER_RECORD 0x03 // 只開外攝錄 #define CMD_DUAL_SNAPSHOT 0x04 // 雙攝抓拍 #define CMD_SET_WDR_MODE 0x05 // 設(shè)置寬動(dòng)態(tài)模式 #define CMD_GET_RECORD_STATUS 0x06 // 查詢錄像狀態(tài)這里有一個(gè)設(shè)計(jì)要點(diǎn)命令字是單向的但狀態(tài)反饋需要雙向。STM32給T23ZN下發(fā)命令后T23ZN必須回一條ACK幀帶命令字和狀態(tài)碼。比如開啟雙錄后T23ZN要回0x01 0x00表示成功或者0x01 0x01表示失敗。沒有這套ACK機(jī)制MCU側(cè)就只能瞎等出了問題無從排查。2.2 通信鏈路的可靠性保障UART通信看著簡(jiǎn)單實(shí)際用起來坑不少。門鎖這個(gè)場(chǎng)景里STM32和T23ZN之間走的是板內(nèi)串口線距很短理論上不太容易出錯(cuò)但實(shí)際調(diào)試時(shí)還是遇到了幾類問題。第一是啟動(dòng)時(shí)序問題T23ZN跑的系統(tǒng)是嵌入式Linux啟動(dòng)時(shí)間比STM32的裸機(jī)程序長(zhǎng)很多大概要3到5秒才能把視頻服務(wù)拉起來。如果STM32在這期間就發(fā)命令T23ZN的串口服務(wù)還沒起命令就丟了。解決辦法很雞賊STM32上電后先等T23ZN主動(dòng)發(fā)一條READY幀收到這個(gè)幀之后STM32才開始下發(fā)業(yè)務(wù)命令。// T23ZN側(cè)應(yīng)用啟動(dòng)完成后主動(dòng)上報(bào)READY void notify_ready(void) { uint8_t frame[5] {0xAA, 0x55, 0x03, CMD_READY, 0x00}; uint8_t crc calc_crc8(frame, 4); frame[4] crc; uart_send(frame, 5); }第二是粘包問題T23ZN上跑Linux串口驅(qū)動(dòng)是標(biāo)準(zhǔn)的一個(gè)read一個(gè)字節(jié)如果MCU連續(xù)發(fā)多條命令Linux側(cè)可能一次收到兩個(gè)幀粘在一起。我處理的辦法是狀態(tài)機(jī)拆幀——按幀頭0xAA 0x55定位讀到完整長(zhǎng)度后再等CRC通過才認(rèn)為是一條完整命令。// T23ZN側(cè)串口收幀狀態(tài)機(jī) int uart_parse_byte(uint8_t byte, protocol_frame_t *out) { static uint8_t rx_buffer[128]; static uint8_t rx_index 0; static enum { WAIT_HEAD1, WAIT_HEAD2, WAIT_LEN, WAIT_DATA, WAIT_CRC } state WAIT_HEAD1; switch (state) { case WAIT_HEAD1: if (byte 0xAA) state WAIT_HEAD2; break; case WAIT_HEAD2: if (byte 0x55) { state WAIT_LEN; rx_index 0; } else state WAIT_HEAD1; break; case WAIT_LEN: rx_buffer[rx_index] byte; out-length byte; state WAIT_DATA; break; case WAIT_DATA: rx_buffer[rx_index] byte; if (rx_index out-length) state WAIT_CRC; break; case WAIT_CRC: uint8_t calc calc_crc8(rx_buffer, out-length - 1); if (calc byte) { memcpy(out, rx_buffer, out-length); state WAIT_HEAD1; return 1; } state WAIT_HEAD1; break; } return 0; }第三是數(shù)據(jù)量控制不要把大量圖片數(shù)據(jù)走串口傳。有人想省事讓T23ZN把抓拍到的JPEG通過串口發(fā)給STM32再讓STM32走4G模塊上傳。我的經(jīng)驗(yàn)是千萬不要這么干——一張100KB的JPEG按115200bps波特率傳要傳將近10秒效率低到離譜。正確做法是T23ZN這邊直接走網(wǎng)絡(luò)上傳STM32只負(fù)責(zé)通過串口告訴T23ZN“現(xiàn)在抓拍一張”T23ZN抓完自己傳云端。2.3 電源與功耗預(yù)算的平衡智能門鎖是電池供電設(shè)備通常是4節(jié)或者8節(jié)AA電池也有用鋰電池的功耗是整個(gè)方案能不能落地的關(guān)鍵。T23ZN這顆SoC的功耗特性和MCU完全不是一個(gè)量級(jí)運(yùn)行狀態(tài)整機(jī)功耗大概在1.5W到2.5W之間看分辨率、幀率和碼率設(shè)定而STM32F103C8T6跑起來只有幾十毫瓦待機(jī)時(shí)更是只有微安級(jí)別。所以整個(gè)系統(tǒng)的功耗策略是平時(shí)讓T23ZN深度睡眠M(jìn)CU保持低功耗待機(jī)有事件時(shí)再喚醒SoC。// STM32側(cè)PIR觸發(fā)進(jìn)入中斷喚醒T23ZN void EXTI2_IRQHandler(void) { if (EXTI_GetITStatus(EXTI_Line2) ! RESET) { // PIR檢測(cè)到人體喚醒T23ZN GPIO_SetBits(GPIOB, GPIO_Pin_12); // T23ZN的Power Enable腳拉高 uart_send_wakeup_cmd(); // 發(fā)送喚醒命令 EXTI_ClearITPendingBit(EXTI_Line2); } }T23ZN睡過去之后喚醒時(shí)間大概要2到3秒Linux系統(tǒng)啟動(dòng)。這個(gè)時(shí)間對(duì)于門鎖場(chǎng)景來說可以接受——PIR檢測(cè)到人走到門口到真正站在門前按指紋通常有2秒以上的時(shí)間差。但如果用更快的喚醒方案比如RTC定時(shí)喚醒可以做到1秒內(nèi)出圖像不過功耗會(huì)增加。功耗實(shí)測(cè)數(shù)據(jù)我記錄過一組雙攝同時(shí)在錄的整機(jī)功耗約2.2W只開外攝錄像約1.6WT23ZN深度睡眠M(jìn)CU待機(jī)時(shí)整機(jī)功耗約0.35W。這組數(shù)據(jù)在選電池容量時(shí)很有參考價(jià)值——用4節(jié)2500mAh的鎳氫電池串聯(lián)按一天觸發(fā)30次、每次錄像30秒估算能用兩個(gè)多月。如果用鋰電池加充電電路續(xù)航壓力就小多了。3. 攝像頭選型與圖像調(diào)優(yōu)的實(shí)戰(zhàn)路徑3.1 兩顆sensor怎么選、怎么搭選sensor的時(shí)候要同時(shí)考慮三個(gè)維度分辨率、感光能力和接口兼容性。T23ZN的ISP支持多款sensor但不是什么sensor都能直接驅(qū)動(dòng)要看SDK里的sensor驅(qū)動(dòng)列表。外攝我用的是一款2MP的CMOS sensor1/2.9英寸靶面支持IR-CUT切換。選它的原因有三個(gè)一是低照度性能好0.01Lux下還能出彩色的畫面二是支持雙曝光寬動(dòng)態(tài)WDR能應(yīng)對(duì)逆光場(chǎng)景三是T23ZN的SDK里有現(xiàn)成的驅(qū)動(dòng)調(diào)起來省事。內(nèi)攝選1MP sensor同樣要求支持IR-CUT但低照度要求可以放寬因?yàn)槭覂?nèi)通常有燈光。這里有個(gè)關(guān)鍵點(diǎn)兩顆sensor的時(shí)鐘和復(fù)位最好分開控制。T23ZN有多個(gè)MIPI或者并行接口通道但時(shí)鐘線是共享的。如果兩顆sensor用同一個(gè)時(shí)鐘源那啟動(dòng)時(shí)必須按順序操作——先上電并復(fù)位sensor A再上電并復(fù)位sensor B。同時(shí)操作容易出現(xiàn)初始化競(jìng)態(tài)導(dǎo)致其中一顆sensor的寄存器配置丟失。// sensor初始化的正確順序示例 void dual_sensor_power_on(void) { // 先給外攝上電并復(fù)位 sensor_ext_power_on(); sensor_ext_reset(); usleep(20000); // 等待sensor穩(wěn)定 sensor_ext_init(); // 寫入sensor寄存器 // 再給內(nèi)攝上電并復(fù)位 sensor_int_power_on(); sensor_int_reset(); usleep(20000); sensor_int_init(); }3.2 寬動(dòng)態(tài)、紅外切換與白平衡三大人像清晰度殺手圖像調(diào)優(yōu)是整個(gè)項(xiàng)目里最消耗時(shí)間的部分沒有之一。我總結(jié)了三個(gè)最大的坑每個(gè)都讓人抓狂?？右粚拕?dòng)態(tài)開過頭導(dǎo)致畫面發(fā)灰。T23ZN的ISP支持2D/3D降噪和WDR。WDR開啟后明暗對(duì)比強(qiáng)烈的場(chǎng)景比如人站在窗戶前可以同時(shí)保留窗外和人物的細(xì)節(jié)但WDR是拿兩幀不同曝光時(shí)間的圖像合成的合成后畫面會(huì)損失一部分色彩飽和度和對(duì)比度看起來灰蒙蒙的。我試過把WDR強(qiáng)度拉到最大結(jié)果是畫面倒是“亮”了但人臉顏色發(fā)白、發(fā)灰比不開還難看。調(diào)試WDR的合理路徑是先關(guān)掉WDR用固定曝光把畫面的基礎(chǔ)亮度調(diào)準(zhǔn)然后逐步增加WDR強(qiáng)度每加一檔就拍一張測(cè)試圖對(duì)比人臉的辨識(shí)度而不是看整體亮度。我最終把WDR強(qiáng)度設(shè)在中等偏下保證逆光時(shí)人臉能看清順光時(shí)色彩不發(fā)灰?？佣t外切換瞬間的圖像撕裂。外攝配IR-CUT雙濾光片白天用紅外截止濾光片擋住紅外光夜晚自動(dòng)切換成允許紅外光通過。切換的執(zhí)行機(jī)構(gòu)是一個(gè)電磁馬達(dá)T23ZN的GPIO控制它。問題是切換的瞬間sensor還在出圖圖像會(huì)有一兩幀的彩色異常通常表現(xiàn)為整體偏紅或偏紫。處理辦法有兩個(gè)一是切換前先暫停sensor輸出切換完成后再恢復(fù)二是切換完成后強(qiáng)制丟幀2~3幀再開始正常編碼。我用的是第二種簡(jiǎn)單粗暴// 切換IR-CUT后丟幀 void ircut_switch_done(void) { for (int i 0; i 3; i) { wait_vsync(); skip_current_frame(); // 取出sensor的數(shù)據(jù)但不送編碼器 } }坑三混合光源下的白平衡亂跳。樓道里經(jīng)常是“熒光燈自然光LED指示燈光”混在一起白平衡算法容易來回跳畫面一會(huì)兒偏暖一會(huì)兒偏冷。T23ZN的ISP有自動(dòng)白平衡AWB默認(rèn)模式在單光源下沒問題混合光源下就不穩(wěn)。我的處理是在夜間固定白平衡色溫比如4000K不做自動(dòng)調(diào)整因?yàn)橐归g的紅外補(bǔ)光本身就是850nm的紅外光彩色信息本來就弱自動(dòng)白平衡的意義不大。白天再切回自動(dòng)白平衡。3.3 編碼參數(shù)與存儲(chǔ)策略T23ZN的硬編碼支持H.264和H.265我最終用了H.265原因無他同畫質(zhì)下碼率比H.264低30%到40%對(duì)電池供電設(shè)備來說是實(shí)打?qū)嵉睦m(xù)航優(yōu)勢(shì)。外攝主流的參數(shù)組合我建議這樣設(shè)參數(shù)設(shè)置說明編碼格式H.265碼率低跟H.264比明顯省空間和流量分辨率1920×1080門外場(chǎng)景看細(xì)節(jié)夠用幀率15fps門鎖場(chǎng)景不需要60fps15幀足夠看清動(dòng)作碼率2Mbps1080P15fps的常見碼率畫質(zhì)可接受I幀間隔30每2秒一個(gè)關(guān)鍵幀便于秒開播放這里有個(gè)容易被忽略的點(diǎn)I幀間隔要跟App端的播放器配合。如果App用的是HLS或者FLV直播I幀間隔太長(zhǎng)會(huì)導(dǎo)致開播首幀延遲變大。我一開始把I幀間隔設(shè)成604秒結(jié)果App上點(diǎn)開直播要卡2秒多才出畫面后來改成30問題解決。4. 核心代碼框架與雙攝控制狀態(tài)機(jī)4.1 T23ZN側(cè)的雙線程模型T23ZN上跑的是嵌入式Linux基于君正提供的SDK二次開發(fā)。SDK里給的示例程序通常是單sensor的雙攝需要自己改造成多通道。我的做法是開兩個(gè)線程一個(gè)管外攝一個(gè)管內(nèi)攝每個(gè)線程內(nèi)部是一個(gè)獨(dú)立的“采集→編碼→存儲(chǔ)”管線。// 雙攝視頻線程的簡(jiǎn)化框架 void *outer_camera_thread(void *arg) { // 初始化外攝sensor和編碼通道 sensor_ops_t *sensor get_sensor_by_id(SENSOR_OUTER); encoder_init(CH_ENCODE_OUTER); while (g_running) { frame_t *frame sensor_capture(sensor); // 抓一幀 if (frame) { encoder_send_frame(CH_ENCODE_OUTER, frame); handle_storage_out(frame); // 寫存儲(chǔ) } } } void *inner_camera_thread(void *arg) { sensor_ops_t *sensor get_sensor_by_id(SENSOR_INNER); encoder_init(CH_ENCODE_INNER); while (g_running) { frame_t *frame sensor_capture(sensor); if (frame) { encoder_send_frame(CH_ENCODE_INNER, frame); handle_storage_inner(frame); } } }雙線程帶來的一個(gè)直接問題是內(nèi)存帶寬壓力1080P15fps VGA30fps同時(shí)編碼每個(gè)像素在ISP→編碼器之間的搬運(yùn)要占用DDR帶寬。T23ZN內(nèi)部DDR帶寬有限如果發(fā)現(xiàn)畫面卡頓或者編碼器丟幀要先懷疑這個(gè)而不是先懷疑CPU。解決辦法是降低內(nèi)攝幀率VGA從30fps降到15fps或者把內(nèi)攝的編碼通道關(guān)掉只在需要時(shí)打開。4.2 雙攝控制狀態(tài)機(jī)的設(shè)計(jì)STM32F103C8T6這一側(cè)的代碼核心是一個(gè)門鎖狀態(tài)機(jī)它根據(jù)外部輸入按鍵、指紋、PIR、門磁決定當(dāng)前應(yīng)該處于什么模式然后向T23ZN下發(fā)對(duì)應(yīng)的視頻命令。typedef enum { LOCK_STATE_IDLE 0, // 空閑內(nèi)攝關(guān)、外攝低功耗待機(jī) LOCK_STATE_APPROACH, // 有人靠近外攝全速錄像 LOCK_STATE_UNLOCKING, // 正在開鎖雙攝同時(shí)錄 LOCK_STATE_UNLOCKED, // 已開鎖內(nèi)攝錄像 LOCK_STATE_ALARM, // 告警雙攝抓拍錄像 } lock_state_t; lock_state_t lock_state LOCK_STATE_IDLE; void lock_state_machine_run(void) { switch (lock_state) { case LOCK_STATE_IDLE: // PIR觸發(fā)進(jìn)入APPROACH if (pir_triggered) { lock_state LOCK_STATE_APPROACH; uart_send_cmd(CMD_START_OUTER_RECORD); uart_send_cmd(CMD_SET_WDR_MODE, WDR_AUTO); } break; case LOCK_STATE_APPROACH: // 指紋驗(yàn)證成功進(jìn)入U(xiǎn)NLOCKING if (fingerprint_matched) { lock_state LOCK_STATE_UNLOCKING; uart_send_cmd(CMD_START_DUAL_RECORD); motor_unlock(); // 驅(qū)動(dòng)電機(jī)開鎖 } // 超時(shí)沒人操作回IDLE if (approach_timeout) { lock_state LOCK_STATE_IDLE; uart_send_cmd(CMD_STOP_RECORD); } break; case LOCK_STATE_UNLOCKING: // 鎖體到位后延遲10秒切內(nèi)攝 if (motor_done delay_10s_done) { lock_state LOCK_STATE_UNLOCKED; uart_send_cmd(CMD_START_INNER_RECORD); } break; // ... 其他狀態(tài)處理 } }這里的關(guān)鍵是狀態(tài)的遷移條件必須和硬件事件嚴(yán)格綁定。比如“門磁檢測(cè)到門被打開”這個(gè)事件一定要經(jīng)過濾波去抖我用了50ms的去抖才能觸發(fā)狀態(tài)遷移否則門鎖抖動(dòng)會(huì)導(dǎo)致狀態(tài)機(jī)瘋跳視頻模式反復(fù)切換功耗飆升。4.3 低功耗喚醒與快速啟動(dòng)T23ZN深度睡眠后用GPIO喚醒但Linux系統(tǒng)的啟動(dòng)時(shí)間是個(gè)硬傷。我優(yōu)化了三處一是裁剪系統(tǒng)服務(wù)SDK自帶的系統(tǒng)鏡像里有一堆用不到的服務(wù)藍(lán)牙、WiFi配網(wǎng)、telnet等全部關(guān)掉只保留核心視頻應(yīng)用和網(wǎng)絡(luò)管理啟動(dòng)時(shí)間從5秒壓到3秒以內(nèi)。二是用RTC鬧鐘做定時(shí)喚醒在門口沒人但門鎖需要定時(shí)巡檢的場(chǎng)景下比如每天早上8點(diǎn)拍一張門口照片用T23ZN內(nèi)部的RTC喚醒可以避免PIR漏檢導(dǎo)致的盲區(qū)。三是快速出圖T23ZN的ISP支持“快速啟動(dòng)模式”可以跳過sensor的自動(dòng)曝光收斂過程直接用上一次的曝光參數(shù)出圖。這個(gè)模式下從Linux起來到App端看到第一幀畫面我實(shí)測(cè)最快能到1.2秒左右但代價(jià)是曝光參數(shù)是舊的如果環(huán)境光線變化大首幀畫面可能偏亮或偏暗要等下一幀自動(dòng)曝光收斂回來。// 快速啟動(dòng)模式的SDK調(diào)用示意 isp_fast_boot_config_t config { .enable 1, .backup_exposure 1, // 備份上次的曝光參數(shù) .max_fast_frames 3, // 最多出3幀快速幀 }; isp_ioctl(ISP_CMD_SET_FAST_BOOT, config);5. 聯(lián)調(diào)階段的三大高頻問題與定位思路標(biāo)題里寫了“調(diào)試技巧”這部分我就把實(shí)際調(diào)試中最常遇到的三個(gè)問題以及我如何一步步定位和解決的完整過程寫出來。這比直接給結(jié)論有價(jià)值得多。5.1 畫面偏色不是sensor壞是白平衡基準(zhǔn)錯(cuò)了現(xiàn)象外攝畫面整體偏藍(lán)室內(nèi)燈光下人臉發(fā)青。排查過程第一步我先懷疑sensor驅(qū)動(dòng)里的白平衡寄存器配置錯(cuò)了。檢查了T23ZN SDK里sensor的初始化序列對(duì)比了數(shù)據(jù)手冊(cè)上的推薦值沒有發(fā)現(xiàn)問題。第二步懷疑是鏡頭模組的IR-CUT沒有切到位導(dǎo)致紅外光進(jìn)入sensor。檢查GPIO控制邏輯發(fā)現(xiàn)IR-CUT切換的GPIO在系統(tǒng)啟動(dòng)后被復(fù)用成了別的功能導(dǎo)致馬達(dá)沒有動(dòng)作。這個(gè)通過排查設(shè)備樹的pinctrl配置解決了。第三步問題復(fù)現(xiàn)偏色仍然存在。這時(shí)候我換了一個(gè)思路用T23ZN的ISP調(diào)試工具直接抓取當(dāng)前AWB的統(tǒng)計(jì)值。發(fā)現(xiàn)R/Gain和B/Gain的數(shù)值偏離正常范圍很大。進(jìn)一步排查發(fā)現(xiàn)是sensor的AWB窗口配置不對(duì)——窗口選在了畫面左上角而那個(gè)位置剛好有一塊深色門框AWB算法把門框的深色當(dāng)成了場(chǎng)景主色調(diào)導(dǎo)致藍(lán)通道增益被拉高。解決辦法在SDK的ISP配置里把AWB統(tǒng)計(jì)窗口改到畫面中央?yún)^(qū)域人臉通常出現(xiàn)在那里或者開啟全畫面逐像素統(tǒng)計(jì)。這個(gè)問題的根源在于“統(tǒng)計(jì)窗口選錯(cuò)位置”而不是sensor本身有問題。這是我第一次被這個(gè)坑絆倒后來凡是遇到偏色問題第一步先看AWB窗口而不是盲目調(diào)增益。5.2 串口丟命令不是波特率不對(duì)是緩沖區(qū)溢出現(xiàn)象STM32給T23ZN發(fā)送“開啟雙錄”命令有時(shí)候生效有時(shí)候不生效?？瓷先ハ袷敲顏G包。排查過程串口參數(shù)我確認(rèn)過波特率1152008N1配對(duì)沒問題。邏輯分析儀抓波形確定MCU發(fā)出的數(shù)據(jù)在物理層是完整的。問題出在T23ZN側(cè)的應(yīng)用層接收上。再查T23ZN的串口接收邏輯。SDK的示例代碼用的是簡(jiǎn)單的打開串口→read循環(huán)read每次讀一個(gè)字節(jié)。問題就在這里L(fēng)inux的串口驅(qū)動(dòng)默認(rèn)有緩沖區(qū)如果應(yīng)用層處理速度跟不上緩沖區(qū)滿了后續(xù)字節(jié)就會(huì)被丟棄。MCU連發(fā)一批命令時(shí)單字節(jié)讀取的方式極容易丟數(shù)據(jù)。解決辦法一是增大串口的緩沖區(qū)在打開串口后用ioctl設(shè)置更大的buffer二是修改讀取邏輯改成批量讀取// 優(yōu)化后的串口讀取每次盡量多讀 int uart_read_batch(int fd, uint8_t *buf, int max_len) { int len read(fd, buf, max_len); // 對(duì)buf中的每個(gè)字節(jié)調(diào)用狀態(tài)機(jī)解析 for (int i 0; i len; i) { uart_parse_byte(buf[i], frame); } return len; }三是在MCU側(cè)做命令合并多條命令之間留出10ms以上間隔避免一次性擊穿緩沖區(qū)。這三件事一起做了之后丟命令的問題徹底消失。5.3 錄像文件時(shí)間戳錯(cuò)亂DDR帶寬不夠的隱蔽表現(xiàn)現(xiàn)象雙攝同時(shí)錄像時(shí)內(nèi)攝的錄像文件回放起來每隔幾秒卡一下外攝正常。最初懷疑是內(nèi)攝的SD卡寫入速度不夠。測(cè)試發(fā)現(xiàn)單獨(dú)給內(nèi)攝錄像時(shí)外攝關(guān)閉寫入完全正常。這說明SD卡不是瓶頸。接著懷疑是內(nèi)攝編碼器的幀率設(shè)置問題。把內(nèi)攝幀率從30fps降到15fps還是會(huì)卡。最后用T23ZN的性能監(jiān)控工具查看DDR帶寬占用發(fā)現(xiàn)雙攝同時(shí)錄像時(shí)DDR帶寬已經(jīng)跑到了90%以上。ISP處理、雙路編碼、內(nèi)存拷貝同時(shí)進(jìn)行把DDR帶寬吃滿了導(dǎo)致內(nèi)攝的幀在緩沖區(qū)排隊(duì)時(shí)間戳亂掉。解決辦法一是關(guān)掉不必要的內(nèi)存拷貝。SDK默認(rèn)的sample代碼為了演示方便很多地方做了多余的數(shù)據(jù)拷貝從sensor buffer拷到編碼器 buffer再拷到網(wǎng)絡(luò)buffer我改成直接引用內(nèi)存的方式。二是內(nèi)攝降到VGA15fps減少編碼器的內(nèi)存帶寬消耗。三是把內(nèi)攝的GOP關(guān)鍵幀間隔從30改成60減少I幀編碼帶來的突發(fā)帶寬占用。改完之后DDR帶寬從90%降到75%左右內(nèi)攝錄像恢復(fù)正常。提示如果你也遇到“只有一路畫面卡、另一路正?！钡碾p攝錄像問題先去看DDR帶寬占用而不是忙著換SD卡或者改分辨率。DDR帶寬不足是雙攝方案特有的隱形殺手單攝方案根本碰不到這個(gè)問題。6. 從樣機(jī)到量產(chǎn)還差的那幾步樣機(jī)跑通了只是第一步。我把自己走過的彎路整理出來給后面的人提個(gè)醒。6.1 鏡頭模組的個(gè)體差異比想象中大同一批鏡頭的sensor寄存器配置參數(shù)會(huì)有細(xì)微差別。如果樣機(jī)使用的sensor A參數(shù)直接批量復(fù)制到量產(chǎn)的sensor B上可能出現(xiàn)部分模組偏色或者低照度下噪點(diǎn)明顯。量產(chǎn)前必須做一件事用T23ZN SDK的sensor調(diào)試工具對(duì)每個(gè)批次抽檢模組生成對(duì)應(yīng)的ISP參數(shù)文件。然后把這個(gè)參數(shù)文件燒進(jìn)生產(chǎn)固件里。如果不做這一步售后會(huì)因?yàn)椤爱嬅姘l(fā)紅”“晚上看不清”收到一堆退貨你拆開看sensor又找不出硬件毛病——問題就出在ISP參數(shù)沒有逐臺(tái)校準(zhǔn)。6.2 老化測(cè)試不能省門鎖是7×24小時(shí)通電的設(shè)備溫度波動(dòng)大冬天樓道可能零下、夏天暴曬后外殼溫度60度以上。我在老化測(cè)試階段踩過的坑是T23ZN在高溫下偶發(fā)死機(jī)后來發(fā)現(xiàn)是DDR供電紋波過大導(dǎo)致的。這個(gè)問題靠代碼調(diào)不出來必須通過硬件改版或者調(diào)整DDR電壓的PMIC配置來解決。所以我的建議是一定要做至少兩輪、每輪7天以上的連續(xù)運(yùn)行測(cè)試而且測(cè)試環(huán)境要能模擬溫度變化。不然發(fā)貨之后用戶遇到死機(jī)只能拆機(jī)返修成本高到懷疑人生。6.3 跟課程設(shè)計(jì)/畢設(shè)相比的差距在哪里熱詞里提到“智能門鎖stm32f103c8t6課程設(shè)計(jì)報(bào)告”我猜有不少人是拿這套方案做課設(shè)或者畢業(yè)設(shè)計(jì)。如果只做到MCU控制電機(jī)、LED燈亮滅、OLED屏幕顯示那當(dāng)然也能交差但和真正能落地的產(chǎn)品相比還差著幾層功夫一是通信協(xié)議要有完善的錯(cuò)誤處理。課設(shè)里通?！拔野l(fā)你收”就算完事但真實(shí)系統(tǒng)里要有超時(shí)重傳、錯(cuò)誤重發(fā)、狀態(tài)查詢這些機(jī)制。我上面的協(xié)議幀里定義了CRC8就是為了處理數(shù)據(jù)被干擾或者解析錯(cuò)誤的情況。二是低功耗設(shè)計(jì)是門鎖的靈魂。課設(shè)用USB供電可以隨便跑但使用電池的門鎖如果功耗控制不好用戶幾十天就要換一次電池這種產(chǎn)品是沒法賣的。三是圖像質(zhì)量調(diào)優(yōu)是SoC方案的護(hù)城河。同樣的sensorISP參數(shù)調(diào)得好和調(diào)不好出圖質(zhì)量天差地別。這里沒有捷徑只能拿著測(cè)試卡一張一張拍一個(gè)參數(shù)一個(gè)參數(shù)試。7. 個(gè)人對(duì)這套方案的評(píng)價(jià)與幾點(diǎn)心得我用T23ZN這顆SoC做雙攝門鎖整體評(píng)價(jià)是夠用但需要花時(shí)間調(diào)順。它的優(yōu)勢(shì)在于雙sensor集成度高、編碼能力強(qiáng)、SDK功能覆蓋全面ISP調(diào)試、網(wǎng)絡(luò)、存儲(chǔ)都有現(xiàn)成接口但代價(jià)是功耗比專用的低功耗MCU方案高且Linux系統(tǒng)的啟動(dòng)穩(wěn)定性需要額外打磨。如果目標(biāo)是做低功耗單攝門鎖CMOS sensor 低功耗MCU的組合會(huì)更省電但如果要做雙攝本地存儲(chǔ)云端交互的完整產(chǎn)品T23ZN的性價(jià)比是很有吸引力的。幾個(gè)最后想強(qiáng)調(diào)的心得第一雙攝方案的難點(diǎn)不在“塞兩顆攝像頭”而在“如何讓兩顆攝像頭協(xié)同工作不互相干擾”。這里的管理者是STM32F103C8T6的狀態(tài)機(jī)而不是T23ZN。把業(yè)務(wù)邏輯和視頻邏輯分開架構(gòu)才會(huì)清晰。第二調(diào)試工具鏈要提前搭好。T23ZN SDK提供了串口命令行的ISP調(diào)試工具可以動(dòng)態(tài)修改sensor參數(shù)而不需要反復(fù)燒固件。一定要用熟這個(gè)工具它能讓圖像調(diào)試速度提升好幾倍。我第一次調(diào)色彩時(shí)反復(fù)燒固件燒了十幾次后來才發(fā)現(xiàn)有這個(gè)工具浪費(fèi)了一天時(shí)間。第三遇到問題時(shí)按“硬件→驅(qū)動(dòng)→應(yīng)用→工具驗(yàn)證”的順序排查先確認(rèn)物理層沒毛病再往上層查。門鎖這種設(shè)備拆起來費(fèi)勁能通過日志和工具解決的問題就不要靠拆機(jī)來解決。最后分享一個(gè)提高效率的小技巧在T23ZN的應(yīng)用代碼里加一個(gè)“調(diào)試模式”開關(guān)開啟后通過串口命令可以提供實(shí)時(shí)打印包括sensor幀率、編碼器幀數(shù)、DDR帶寬、網(wǎng)絡(luò)吞吐量。聯(lián)調(diào)階段這個(gè)開關(guān)能幫你省下大量時(shí)間。量產(chǎn)固件里再關(guān)掉就行。我的調(diào)試模式代碼大概加了100多行但它幫我在聯(lián)調(diào)階段解決了不少隱蔽問題——特別是那個(gè)DDR帶寬瓶頸如果沒有實(shí)時(shí)帶寬監(jiān)控我可能還在傻乎乎地?fù)QSD卡。