簡介OV7725 CMOS圖像傳感器驅(qū)動源碼包面向嵌入式Linux開發(fā)者適用于需要移植或調(diào)試攝像頭驅(qū)動、或基于V4L2框架學(xué)習(xí)傳感器驅(qū)動的場景。壓縮包內(nèi)共2個文件主體由.c驅(qū)動實現(xiàn)和.h頭文件組成整體僅7KB結(jié)構(gòu)精簡便于快速對照閱讀。驅(qū)動源碼基于V4L2框架實現(xiàn)了設(shè)備探測、I2C寄存器讀寫、視頻流開啟與關(guān)閉等核心邏輯并封裝了曝光、增益等圖像參數(shù)的控制接口。通過這份源碼開發(fā)者可以掌握OV7725傳感器的初始化流程、驅(qū)動注冊方式以及用戶空間通過標準V4L2接口訪問圖像數(shù)據(jù)的完整過程同時也可作為自定義CMOS傳感器驅(qū)動開發(fā)的實際參考模板。目前已有358人學(xué)習(xí)下載適合正在研究V4L2驅(qū)動開發(fā)或計劃在ARM平臺接入OV7725的工程師參考。1. OV7725 這包驅(qū)動源碼兩個文件背后是一條完整的 V4L2 鏈路嵌入式攝像頭調(diào)試現(xiàn)場最怕的不是 sensor 不亮而是拿到一份驅(qū)動源碼后不知道它到底跑沒跑起來。ov7725.rar 里只有 ov7725.c 和 ov7725.h 兩個文件看起來簡單但 OV7725 這個 CMOS 傳感器要真正在 Linux 下出圖牽扯到 I2C 設(shè)備注冊、v4l2-subdev 節(jié)點、video_device 字符設(shè)備、vb2 緩沖區(qū)隊列這一整條鏈路。這篇筆記用我調(diào)過的一塊 OV7725 攝像頭模組的實際經(jīng)驗把這包源碼拆開講清楚V4L2 框架怎么搭、兩個文件怎么讀、編譯加載和寄存器配置整套怎么走、以及最常踩的幾個坑。適合手里正好有 OV7725 模組要往 Linux 里塞的嵌入式工程師也適合第一次接觸 sensor 驅(qū)動、想找一份能跑通的參考代碼入手的同學(xué)。2. 先把框架立起來V4L2 底下 OV7725 怎么掛進內(nèi)核2.1 sensor 不是獨立外設(shè)I2C 從設(shè)備、v4l2-subdev 與 video_device 的關(guān)系很多第一次寫 sensor 驅(qū)動的朋友會有一個誤解只要把 ov7725.c 編進內(nèi)核/dev/video0就自動出來了。實際上在 V4L2 框架里OV7725 承擔(dān)的角色只是一個掛在 I2C 總線上的從設(shè)備。它負責(zé)的是寄存器配置、曝光增益調(diào)整、幀同步信號的產(chǎn)生而真正被應(yīng)用層 open 的/dev/videoX字符設(shè)備是由另一側(cè)的接口控制器驅(qū)動注冊的——比如并口橋接芯片、CSI 控制器或者平臺自帶的 camera 接口。這套源碼里ov7725_probe、ov7725_remove的命名風(fēng)格和ov7725_video_init/ov7725_video_cleanup這種直白的視頻流開關(guān)函數(shù)明顯是內(nèi)核 3.x 時代甚至更早的寫法。那個年代的 sensor 驅(qū)動經(jīng)常自己申請video_device把注冊 subdev、創(chuàng)建節(jié)點、維護 buffer queue 全揉在一個驅(qū)動里?，F(xiàn)在主流內(nèi)核4.19 以上更推薦 v4l2-subdev v4l2_async_notifier 的異步注冊方式sensor 驅(qū)動只做 subdev等接口控制器驅(qū)動準備好之后兩者通過 media controller 的拓撲圖綁在一起。理解這個區(qū)別你就明白為什么在舊板子 BSP 里改一個ov7725_probe就能出圖的代碼換到新內(nèi)核上 insmod 之后ls /dev/video*還是空的。我一般建議拿到這種老驅(qū)動源碼后第一件事不是看寄存器表而是在文件里搜索v4l2_async_register_subdev和video_register_device。前者是正兒八經(jīng)的 subdev 驅(qū)動后者說明這套代碼自己創(chuàng)建了設(shè)備節(jié)點。ov7725.c 的常見版本里兩種寫法都存在如果你手里的版本是后者移植到新內(nèi)核時要把 video 部分剝離出來只保留 I2C 寄存器和 subdev 回調(diào)函數(shù)。2.2 ov7725_probe 完整旅程設(shè)備樹匹配、復(fù)位時序與 ID 校驗probe 函數(shù)是驅(qū)動和硬件第一次握手的地方。內(nèi)核在 I2C 總線上掃描到地址匹配的設(shè)備后會回調(diào)這個函數(shù)。我拆過的 ov7725.c 里probe 的標準動作一般是這樣static int ov7725_probe(struct i2c_client *client) { struct ov7725_device *dev; int ret; /* 1. 分配私有數(shù)據(jù)結(jié)構(gòu)存 I2C client、v4l2 subdev 和運行狀態(tài) */ dev devm_kzalloc(client-dev, sizeof(*dev), GFP_KERNEL); if (!dev) return -ENOMEM; dev-client client; i2c_set_clientdata(client, dev); /* 2. 上電復(fù)位時序先把 RESET 拉低再拉高等時鐘穩(wěn)定 */ ret ov7725_power_on(dev); if (ret) return ret; /* 3. 讀 0x0a/0x0b 兩個 ID 寄存器確認總線上掛的是 OV7725 */ ret ov7725_detect(dev); if (ret) { dev_err(client-dev, ov7725 detect failed\n); return ret; } /* 4. 注冊 v4l2 subdev掛到媒體控制器拓撲上 */ ret ov7725_v4l2_register(dev); if (ret) return ret; dev_info(client-dev, ov7725 probe success\n); return 0; }這段代碼的核心邏輯有三個。第一是分配私有數(shù)據(jù)結(jié)構(gòu)把 I2C client 指針存進dev-client后面所有寄存器讀寫都依賴這個指針第二是上電復(fù)位OV7725 的復(fù)位時序要求 RESET 引腳拉低至少 1ms 再拉高拉高之后還要等 1ms 左右的時鐘穩(wěn)定時間否則第一筆 I2C 讀操作大概率超時第三是讀 ID 寄存器0x0a 固定讀 0x770x0b 讀版本號這個校驗?zāi)芊乐?I2C 總線上同一個地址掛的是別的芯片導(dǎo)致后面所有寄存器表全寫錯。配套的設(shè)備樹節(jié)點和 id_table 匹配表也要對齊。常見寫法是這樣static const struct i2c_device_id ov7725_id[] { { ov7725, 0 }, {} }; MODULE_DEVICE_TABLE(i2c, ov7725_id); static const struct of_device_id ov7725_of_match[] { { .compatible ovti,ov7725 }, {} }; MODULE_DEVICE_TABLE(of, ov7725_of_match); static struct i2c_driver ov7725_i2c_driver { .driver { .name ov7725, .of_match_table ov7725_of_match, }, .probe ov7725_probe, .remove ov7725_remove, .id_table ov7725_id, }; module_i2c_driver(ov7725_i2c_driver);老內(nèi)核用i2c_device_id匹配新內(nèi)核走設(shè)備樹compatible ovti,ov7725。兩顆最容易翻車的雷我都踩過一是 I2C 地址OV7725 的 7 位地址由 SID 引腳電平?jīng)Q定多數(shù)模組是 0x21但有些國產(chǎn)模組把地址拉到 0x20設(shè)備樹 reg 寫錯直接 probe 不到二是 i2c_driver 的 id_table 里如果沒加MODULE_DEVICE_TABLEmodprobe 時熱插拔事件匹配不上insmod 也會靜默跳過 probe。2.3 數(shù)據(jù)流鏈路s_stream 打開 sensorvb2 把幀從 sensor 搬給 /dev/video0probe 成功只是萬里長征第一步真正的數(shù)據(jù)流從用戶態(tài)應(yīng)用打開/dev/video0才開始。V4L2 的標準流程是open設(shè)備節(jié)點VIDIOC_S_FMT設(shè)置輸出分辨率和像素格式VIDIOC_REQBUFS申請緩沖區(qū)VIDIOC_QBUF把緩沖區(qū)交給驅(qū)動VIDIOC_STREAMON正式開流。應(yīng)用層這一套 ioctl 下來驅(qū)動里最關(guān)鍵的s_stream回調(diào)才會被調(diào)用。ov7725 驅(qū)動里 s_stream 的典型實現(xiàn)長這樣static int ov7725_s_stream(struct v4l2_subdev *sd, int enable) { struct ov7725_device *dev v4l2_get_subdevdata(sd); if (enable) { /* 每次開流都把寄存器表重新刷一遍保證狀態(tài)干凈 */ ov7725_video_init(dev); /* COM4: 打開 PCLK 輸出sensor 開始出圖 */ ov7725_write_reg(dev, 0x0f, 0x00); } else { /* 關(guān)流時先停掉像素時鐘再關(guān)電源 */ ov7725_write_reg(dev, 0x0f, 0x01); ov7725_power_off(dev); } return 0; }注意這里有個細節(jié)enable分支里每次開流都重新執(zhí)行ov7725_video_init。這個習(xí)慣很關(guān)鍵。如果你在應(yīng)用層反復(fù)STREAMON/STREAMOFF寄存器狀態(tài)可能因為上次異常關(guān)閉殘留在奇怪的值上重新刷一遍寄存器表是最穩(wěn)妥的恢復(fù)手段。我見過有人為了省這幾毫秒把這段去掉結(jié)果就是應(yīng)用層重啟預(yù)覽時圖像顏色一次一個樣這種玄學(xué)問題定位起來比老老實實刷寄存器費時間得多。s_stream 打開之后sensor 通過并口輸出 PCLK、HSYNC、VSYNC 和 8 位像素數(shù)據(jù)這個數(shù)據(jù)流由接口控制器接收寫入 vb2 buffer。vb2 框架負責(zé)管理 buffer 的生命周期應(yīng)用層DQ出一幀處理完再Q(mào)回來一輪一輪循環(huán)。這套代碼里雖然沒有完整實現(xiàn) vb2 的ops但理解這條鏈路對你調(diào)驅(qū)動非常有用出圖慢先看 s_stream 有沒有被調(diào)用沒有說明流程沒走到 sensor 這一層問題在接口控制器驅(qū)動而不是 ov7725.c。3.1 ov7725.h 里的設(shè)備結(jié)構(gòu)體與寄存器宏ov7725.h 是理解整個驅(qū)動的一把鑰匙。頭文件里定義了設(shè)備結(jié)構(gòu)體、寄存器地址宏以及內(nèi)部函數(shù)的聲明。很多新手讀驅(qū)動喜歡一頭扎進 ov7725.c 的函數(shù)體里實際上先把頭文件捋一遍后面看代碼會順很多。我把常見版本里的核心內(nèi)容整理一下#ifndef __OV7725_H__ #define __OV7725_H__ #include linux/i2c.h #include media/v4l2-subdev.h /* 7 位 I2C 地址部分模組高地址是 0x20 */ #define OV7725_I2C_ADDR 0x21 /* 核心寄存器地址 */ #define OV7725_REG_GAIN 0x00 /* 模擬增益 */ #define OV7725_REG_PID 0x0a /* 產(chǎn)品 ID固定 0x77 */ #define OV7725_REG_VER 0x0b /* 版本號 */ #define OV7725_REG_COM3 0x0c /* 輸出格式、鏡像控制 */ #define OV7725_REG_COM4 0x0f /* PCLK 分頻控制 */ #define OV7725_REG_CLKRC 0x11 /* 幀率與 PLL 配置 */ #define OV7725_REG_HTS 0x2c /* 行總長高字節(jié) */ #define OV7725_REG_VTS 0x2d /* 幀總長高字節(jié) */ #define OV7725_REG_EXH 0x43 /* 曝光時間高字節(jié) */ #define OV7725_REG_EXL 0x44 /* 曝光時間低字節(jié) */ struct ov7725_win_size { unsigned short width; unsigned short height; }; struct ov7725_device { struct i2c_client *client; struct v4l2_subdev sd; struct v4l2_rect crop; unsigned int xclk_freq; unsigned int fps; bool power_on; }; #endif寄存器宏這塊沒什么玄學(xué)就是 datasheet 里寄存器地址的常量聲明。重點說一下struct ov7725_device里那幾個字段crop保存裁剪區(qū)域V4L2 協(xié)議允許應(yīng)用層通過VIDIOC_S_CROP改取景范圍xclk_freq是外部輸入時鐘頻率傳感器默認值是 24MHz這個值直接影響幀率計算power_on是一個軟件狀態(tài)位避免重復(fù)上電或者重復(fù)關(guān)電導(dǎo)致引用計數(shù)混亂。3.2 video_init / video_cleanup視頻流開關(guān)的完整時序這兩個函數(shù)是整個 ov7725.c 里最值得逐行讀的部分。ov7725_video_init做的是 sensor 的上電初始化和寄存器配置ov7725_video_cleanup反過來把 sensor 置于節(jié)電狀態(tài)。static int ov7725_video_init(struct ov7725_device *dev) { int i, ret; /* 1. 軟復(fù)位寄存器恢復(fù)默認值 */ ov7725_write_reg(dev, 0x12, 0x80); msleep(10); /* 2. 寫基礎(chǔ)配置表YUV422 輸出、VGA 640x480、默認時序 */ static const struct regval ov7725_defaults[] { { 0x12, 0x00 }, /* COM7: YUV 輸出VGA 模式 */ { 0x11, 0x00 }, /* CLKRC: PLL 關(guān)閉外部時鐘直通 */ { 0x0c, 0x08 }, /* COM3: RGB565 格式鏡像關(guān) */ { 0x3d, 0x03 }, /* COM9: PCLK 上升沿采樣 */ { 0x2c, 0x0f }, /* HTS 高字節(jié)行總長 0x02f0 */ { 0x2d, 0x01 }, /* VTS 高字節(jié)幀總長 0x01f4 */ { 0x2a, 0xf0 }, /* HTS 低字節(jié) */ { 0x2b, 0x01 }, /* VTS 低字節(jié) */ { 0x00, 0x00 }, /* 增益默認 */ }; for (i 0; i ARRAY_SIZE(ov7725_defaults); i) { ret ov7725_write_reg(dev, ov7725_defaults[i].addr, ov7725_defaults[i].val); if (ret) { dev_err(dev-client-dev, write reg 0x%02x failed\n, ov7725_defaults[i].addr); return ret; } } return 0; }提示代碼里第二個參數(shù)0x12, 0x80是軟復(fù)位寄存器。寫完這個值后 sensor 內(nèi)部所有寄存器回到 datasheet 默認值但這個過程需要幾毫秒所以后面跟了一個msleep(10)。別省也別把延時改成 1ms穩(wěn)壓芯片上電時間有時候就超過 5ms。ov7725_video_cleanup就簡單直接了它把像素時鐘停掉再發(fā)一次軟復(fù)位讓 sensor 進入低功耗狀態(tài)static int ov7725_video_cleanup(struct ov7725_device *dev) { /* 1. 先停 PCLK避免關(guān)電瞬間并口還在跳電平 */ ov7725_write_reg(dev, 0x0f, 0x01); /* 2. 軟復(fù)位回到默認寄存器狀態(tài) */ ov7725_write_reg(dev, 0x12, 0x80); msleep(5); return 0; }這里有一個值得養(yǎng)成的習(xí)慣關(guān)流的順序一定是先停 PCLK再軟復(fù)位最后才斷 sensor 電源。如果反過來sensor 在斷電瞬間仍在輸出時鐘和數(shù)據(jù)信號輕則并口上產(chǎn)生毛刺導(dǎo)致下一輪初始化失敗重則有幾率把接口控制器的輸入引腳電平打壞。嵌入式里這叫時序敏感性調(diào)一次就長記性了。3.3 曝光、增益、幀率圖像參數(shù)在寄存器表里的位置OV7725 之所以在圖像參數(shù)上大有文章是因為曝光、增益、幀率這幾個參數(shù)不是獨立可調(diào)的它們共享同一個時間基準。幀率公式是幀率 xclk / (HTS × VTS)其中 HTS 是行總長VTS 是幀總長。曝光時間則是曝光行數(shù) / 行總長 / 幀率改 HTS 會影響幀率改 VTS 會影響曝光上限參數(shù)之間互相牽制。下面這個表是調(diào)試時最常動的寄存器參數(shù)寄存器說明常見配置模擬增益0x000x00~0x3f數(shù)字越大越亮低光環(huán)境從 0x10 起調(diào)輸出格式0x12 COM7bit7 軟復(fù)位bit3 YUV/RGB 選擇0x00YUV422PCLK 分頻0x0f COM4PCLK 分頻系數(shù)影響輸出速率0x00不分頻幀率時鐘0x11 CLKRC內(nèi)部 PLL 倍頻和分頻0x0024MHz 直通行總長0x2c/0x2aHTS水平總像素數(shù)0x02f0752幀總長0x2d/0x2bVTS垂直總行數(shù)0x01f4500曝光高字節(jié)0x43曝光行數(shù)高 8 位配合 VTS 使用曝光低字節(jié)0x44曝光行數(shù)低 8 位低于 VTS 才有效實戰(zhàn)中改參數(shù)有個血淚經(jīng)驗改造曝光時0x43/0x44寫入的曝光行數(shù)一定不能大于 VTS 值否則 sensor 輸出幀率會直接受影響甚至花屏。調(diào)試順序我一般是先定 HTS/VTS 把幀率鎖死再調(diào)曝光范圍最后用增益做微調(diào)。如果你調(diào)完增益圖像出現(xiàn)橫向條紋別急著改驅(qū)動先看看是不是供電電源紋波大了sensor 的模擬供電對紋波非常敏感這是硬件問題軟件怎么配都救不回來。4. 避坑OV7725 驅(qū)動移植常見問題與排查記錄4.1 I2C 探測失敗probe 沒觸發(fā)還是寄存器讀不到現(xiàn)象模塊 insmod 成功但 dmesg 里沒有任何 probe 日志或者ov7725 detect failed反復(fù)出現(xiàn)。原因兩個層面。一是設(shè)備樹匹配問題I2C 總線號寫錯、reg 地址和模組實際地址不一致、compatible 字符串和驅(qū)動里的of_match_table對不上都會導(dǎo)致 probe 回調(diào)根本不被調(diào)用。二是上電時序問題RESET 引腳和 PWDNpower down引腳的時序不滿足I2C 應(yīng)答時好時壞第一筆讀 ID 就超時。解決先用 i2c-tools 探一下硬件層面到底通不通i2cdetect -y -r 2 0 1 2 3 4 5 6 7 8 9 a b c d e f 10: 21 22 23 24 25 26 27 28 29 2a 2b 2c 2d 2e 2f 30: 30 31 32 33 34 35 36 37 38 39 3a 3b 3c 3d 3e 3f 70: 70 71 72 73 74 75 76 77看到21說明 I2C 地址正確sensor 已經(jīng)在線。如果掃不到 21先檢查設(shè)備樹i2c2節(jié)點是不是真的對應(yīng)硬件上的 I2C 2 號總線再量 RESET 引腳電平上電后應(yīng)該是高電平被拉低就是 GPIO 配置反了。如果21能掃到但驅(qū)動讀寄存器超時多半是 i2c 控制器時鐘頻率太高OV7725 的 SCCB 接口建議跑 100kHz 穩(wěn)妥你把它配到 400kHz 有的模組就不應(yīng)答了。4.2 圖像花屏、偏色、上下顛倒現(xiàn)象v4l2-ctl 抓幀成功但存下來的 raw 圖要么花成雪花點要么整體偏紅偏綠要么圖像是倒的鏡像的。原因花屏優(yōu)先查采樣時序。OV7725 通過并口輸出 PCLK 時鐘和數(shù)據(jù)接口控制器如果在錯誤的時鐘沿采樣采到的數(shù)據(jù)全是亂的。偏色則是像素格式不匹配驅(qū)動里設(shè)的 YUYV 但 sensor 實際輸出 RGB565或者反過來數(shù)據(jù)解釋錯位。鏡像問題最簡單是寄存器控制位沒配。解決逐個排查寄存器配置按下面順序試/* 1. PCLK 采樣沿COM9 寄存器 bit1 控制 */ ov7725_write_reg(dev, 0x3d, 0x02); /* 下降沿采樣 */ ov7725_write_reg(dev, 0x3d, 0x03); /* 上升沿采樣 */ /* 2. 輸出格式匹配 */ ov7725_write_reg(dev, 0x12, 0x00); /* YUV422 */ ov7725_write_reg(dev, 0x12, 0x04); /* RGB565 */ /* 3. 鏡像控制COM3 寄存器 bit5/bit4 */ ov7725_write_reg(dev, 0x0c, 0x48); /* 水平鏡像 */ ov7725_write_reg(dev, 0x0c, 0x28); /* 垂直翻轉(zhuǎn) */這種問題調(diào)試時最怕一次改多個變量。我的習(xí)慣是抓一幀 raw 數(shù)據(jù)用 python 的 matplotlib 或者 ffmpeg 直接轉(zhuǎn)成 PNG 看效果每改一個寄存器抓一幀看到哪種配置圖像正常就能反推出 sensor 實際的輸出模式。別用眼睛盯著屏幕調(diào)太慢而且容易把之前的正常配置搞亂。4.3 打開視頻流報 EBUSY誰把 buffer 占住了現(xiàn)象應(yīng)用層v4l2-ctl --stream-mmap執(zhí)行到VIDIOC_STREAMON時返回Device or resource busy驅(qū)動 dmesg 沒有任何報錯。原因最常見的是上一個進程退出時沒有正常關(guān)閉設(shè)備節(jié)點或者進程被 kill -9 強殺文件描述符雖然釋放了但 vb2 隊列里的 buffer 狀態(tài)還停留在占用的位置。另一種情況是驅(qū)動內(nèi)部video_init返回了錯誤但狀態(tài)位沒復(fù)位下一次 STREAMON 時驅(qū)動認為還在流中直接返回忙。解決先確認誰占著設(shè)備節(jié)點fuser /dev/video0 lsof /dev/video0有 PID 就 kill 掉重試。如果 fuser 沒輸出但依然 busy大概率是驅(qū)動狀態(tài)沒干凈。在驅(qū)動里顯式加一個復(fù)位邏輯static int ov7725_s_stream(struct v4l2_subdev *sd, int enable) { /* 關(guān)流時無論什么狀態(tài)都強制走一遍清理 */ if (!enable || dev-power_on) { ov7725_video_cleanup(dev); dev-power_on false; } ... }順手在vb2_ops里實現(xiàn)wait_prepare和wait_finish這兩個回調(diào)負責(zé)在等待 buffer 時釋放隊列鎖能避免多進程搶占導(dǎo)致的死鎖式 busy。這套組合拳打完EBUSY 基本絕跡。4.4 幀率對不上xclk、PLL 與 HTS/VTS 互相牽制現(xiàn)象應(yīng)用層設(shè)定 30fps 采集實際讀取流幀率只有 18fps或者看到 dmesg 里有幀超時提示。原因幀率公式幀率 xclk / (HTS × VTS)。硬件上 xclk 晶振不是驅(qū)動里認為的 24MHz比如實際是 12MHz或者 HTS/VTS 寄存器值配置太大導(dǎo)致每幀耗時變長。有些模組的晶振直接焊的是 27MHz 的型號驅(qū)動里按 24MHz 算出來的寄存器值自然對不上。解決先拿頻率計或示波器量 xclk確認真實值。然后反推寄存器# 假設(shè) xclk24MHz目標 30fps # HTS 固定 0x02f0752VTS 24000000 / (752 * 30) ≈ 1064 i2cset -y 2 0x21 0x2d 0x04 # VTS 高字節(jié) i2cset -y 2 0x21 0x2b 0x28 # VTS 低字節(jié)0x04281064CLKRC 寄存器 0x11 也影響幀率它控制 PLL 倍頻。常見場景是外部 12MHz 晶振想得到類似 24MHz 的系統(tǒng)時鐘就需要把 CLKRC 配置成 2 倍 PLL。但倍頻會放大時鐘抖動對畫質(zhì)有影響。我一般優(yōu)先改 HTS/VTS 而不是動 PLL只有 HTS/VTS 調(diào)整空間不夠時才用 CLKRC畢竟圖像質(zhì)量是最終目標幀率差幾幀能用參數(shù)找補回來花屏畫質(zhì)差沒法找補。5. 最后一公里用 v4l2-ctl 和 i2c-tools 驗證 OV7725 采集鏈路5.1 確認驅(qū)動在線的三連命令驅(qū)動編譯加載完成后不要急著寫應(yīng)用先用三個命令確認鏈路狀態(tài)ls /dev/video* v4l2-ctl --list-devices i2cdetect -y 2v4l2-ctl --list-devices會列出所有注冊的 V4L2 設(shè)備節(jié)點以及它們對應(yīng)的驅(qū)動名稱。如果你看到ov7725的出現(xiàn)說明 subdev 注冊成功/dev/video0存在說明接口控制器的 video_device 也掛上了i2cdetect能掃到 0x21 說明硬件鏈路沒斷。三條都通過驅(qū)動這層基本穩(wěn)了。5.2 抓一幀原始圖并驗證格式驅(qū)動在線之后驗證圖像數(shù)據(jù)最直接的方式是抓一幀裸數(shù)據(jù)轉(zhuǎn)成圖片看v4l2-ctl -d /dev/video0 --set-fmt-videowidth640,height480,pixelformatYUYV v4l2-ctl -d /dev/video0 --stream-mmap --stream-count1 --stream-toyuyv.raw ffmpeg -f rawvideo -pix_fmt yuyv422 -s 640x480 -i yuyv.raw -frames:v 1 yuyv.png--stream-mmap指定用 mmap 方式采集--stream-count1只抓一幀--stream-to指定輸出文件。抓下來后用 ffmpeg 轉(zhuǎn)成 PNG 是很多工程師的第一個閉環(huán)驗證。這里有個細節(jié)如果抓出來的 raw 文件是綠色大概率是 YUYV 字節(jié)序填反了試著把pixelformat改成YUY2或者攝像頭調(diào)換數(shù)據(jù)線再看。這一步排除的是接口控制器的數(shù)據(jù)通路問題。5.3 寄存器級驗證應(yīng)用層驗證通過后我會再補一步寄存器級驗證確認驅(qū)動對 sensor 的控制真實有效# 讀產(chǎn)品 ID確認通信鏈路 i2cget -y 2 0x21 0x0a # 返回 0x77 # 寫 CLKRC 改變幀率再讀回來驗證 i2cset -y 2 0x21 0x11 0x01 i2cget -y 2 0x21 0x11 # 返回 0x01讀出來是 0x77說明驅(qū)動和硬件之間的 I2C 鏈路完全可信。改寄存器能寫能讀說明 sensor 沒有被拉死。這套驗證做完OV7725 的移植才算真的落地。這段路我走過的最大教訓(xùn)是驅(qū)動編譯過了、設(shè)備節(jié)點出來了不代表圖像鏈路就是通的。有一次花了大半天查圖像花屏問題最后發(fā)現(xiàn)是并口數(shù)據(jù)線順序接錯三根軟件怎么調(diào)寄存器都沒用。從那以后每次拿到新模組我都不急著改代碼先強制走一遍 i2cdetect → 讀 0x0a → 抓原始幀 → 轉(zhuǎn) PNG 這條完整鏈路確認每個節(jié)點都亮了再動手寫業(yè)務(wù)邏輯。希望這套流程也能幫你少走幾個彎路。本文還有配套的精品資源點擊獲取