高通CAMIF和OV sensor除錯經驗分享
阿新 • • 發佈：2019-01-17
要借用某高通平臺的camera介面，聯合OV(OmniVision)公司的sensor，實現手機攝像頭的拍照及錄影功能，需要處理兩晶片、顯示屏和需求配合的問題，在這個過程中遇到並解決了許多問題。
【關鍵詞】
拍照 預覽 CAMIF
一、問題的提出
新手上路，第一次見到ov sensor，第一次認識Qualcomm的 CAMIF，沒有任何經驗，除錯中遇到諸多劫難，如沒有預覽不到任何象素點、影象色彩不對、拍照無效區域、dispsize設定不合適預覽全屏問題、黑白模式上層設不成、預覽和拍照範圍不一致的問題、軟體轉90度壓扁問題等等。
二、解決思路
先做基礎理論的儲備。
VGA ：640x480；
QVGA ：320x240；
YUV格式：4：2：2
曝光控制/伽瑪增益/白平衡等都是效果方面的調整。
對於象素數較大的sensor，如1280x1024，由於資料量較大，通常預覽解析度640x512拍照解析度是1280x1024，且拍照時的PCLK是預覽時的2倍，這樣可以對VFE（video front end）來說是同樣的幀速率。
Ov7670的暫存器0x15的bit6可以切換sensor輸出HREF或HSYNC，我們用HREF。
Camera_process_config_vfe初始化VFE暫存器；
Qcamraw_set_header設定sensor幀頭；
程式碼分層：
層 Drivers services Oem層 App層
程式碼位置 camsensor camera Oemcamera.c Qcamera.c/Qcamcorder.c
Trace32命令:data.image addr. 640. 480. /GS8，可方便的看某buffer地址中的圖片，判斷取到的預覽圖片內容和最終顯示的屏上的差異。
camera_qdsp_cb是收到幀等事件的回撥，根據預覽和拍照的不同需要，QDSP會送來不同的格式，本例中拍照格式是YUV422PS，預覽格式是RGB565LE。
要得到需要的幀率，需要給sensor暫存器設定時加入空白象素和空白行。對於ov7670，0x92/0x93加入空白行個數。
幀率的計算按照以下公式：
fps*(640+144)*(510+x)*2 = 12M(Pclk)
其中x是空行數，{0x92, 0x00},{0x93, 0x00}時，x為0，fps為15；{0x92, 0x19},{0x93, 0x01}時，x為281（0x119），fps為9.67。
如下圖1是x為0時的時序圖：
圖 1 VGA Frame Timing
三、實踐情況
3.1預覽
首先關注暫存器設定是否成功，測試發現寫完暫存器，再讀出的值和寫的部分不同，因為某些暫存器是在自動重新整理的。
對於sensor，只要供電正常，且有MCLK，就應該有行場同步及PCLK訊號。開始沒有測到訊號，後查出來同步訊號在傳輸過程中由於某管腳對地短路，衰減了。
要保證程式碼中主晶片和sensor側象素數（寬、高）、同步訊號極性（高低電平）和取樣頻率（PCLK）設定一致，才能預覽。主晶片通過CAMIF介面的暫存器設定。在camera_process_config_vfe中寫入。
軟體設定如下：
測出9.679fps時的波形如下圖：
15fps的時序如下：
VSYNC High:66ms（約510=17+480+10 lines）Low 394us 週期約66ms 即15fps;
HSYNC High:106us (約1280 clks) low 24.4us 週期約130us;
VSYNC上升沿到HSYNC上升沿的time :1.98ms，約17 lines;
HSYNC下降沿到VSYNC下降沿的time :1.57ms，約10 lines;
PCLK是12MHz.
HREF、VSYNC都用做同步訊號，高通新近平臺上通過取樣同步訊號得到資料，有效行前邊的無效行不需精確設定，只要同步訊號電平給定即可。檢測計數到夠一幀才會產生中斷資料。
查完一切狀態正常，但從log檔案可以看看主晶片還是是未接到sensor的幀；
後再測訊號，發現HREF訊號實際板子上沒傳到CPU子板上。
總結經驗：硬體除錯時注意，訊號測試要逐級測試，從輸出一直到輸入點上，考慮硬體通路可能存在的傳輸問題。硬體電路容易有對地短路的點，如遇到訊號傳輸異常的。可以斷電側對地電阻，確認是否對地短路。
3.2拍照無效區域的問題
Dispsize設為216x160可以在128*160的屏上全屏預覽，但拍出的照片有一條雜色區域，如圖所示，這個問題在預設Dispsize設定128x96時也有。
30萬畫素，資料量比較小，預覽和拍照可以用同一解析度，所以snapshot不用重設暫存器，驅動中重設暫存器引起了拍照無效區域的問題，去掉解決。
3.4預覽和拍照範圍不一致的問題
CAMIF輸出的是一個橫長的影象，在豎長的屏上預覽需要裁減，因此造成了使用者看到的和拍到的明顯不一致，為解決這個問題，需要把sensor從橫著放置改為豎直放置，但是所用高通平臺沒有一個MDP，即影象旋轉的硬體加速器，軟體上的旋轉可能會增加負擔，對此，做了必要的驗證工作。
從原理上看，不旋轉和旋轉90度的處理演算法沒有明顯差異。
現象上看，軟體令camera_default_rotation =90，camera預覽和拍照及camcorder預覽及錄下的視訊都順時針轉了90度。
用task profiling跟蹤，不旋轉和旋轉90度佔用CPU時間一樣。詳如下圖：
旋轉：0度； display size: 216x160； Image size :160*120
九宮格 QCAMERA預覽 拍照 拍照 QCAMERA預覽
旋轉：90度； display size: 216x160； Image size :160*120
九宮格 QCAMERA預覽 拍照 拍照 QCAMERA預覽
3.5拍小尺寸照片壓扁問題
軟體和硬體都轉過90度之後，拍出來的大尺寸照片和預覽只有了微小差異，但小照片卻被壓扁了，從理論上分析，寬高比等和屏同樣很協調，怎麼也想不出道理。
最終用模擬器仔細跟蹤拍照過程中各引數的設定，找到了原因：預覽的CAMIF window根據 display_aspect_ratio不同分別基於寬或高來計算，拍照的CAMIF window也需要這麼處理，否則看到的和拍到的會不同。
因此在程式碼上加了類似的處理。
【關鍵詞】
拍照 預覽 CAMIF
一、問題的提出
新手上路，第一次見到ov sensor，第一次認識Qualcomm的 CAMIF，沒有任何經驗，除錯中遇到諸多劫難，如沒有預覽不到任何象素點、影象色彩不對、拍照無效區域、dispsize設定不合適預覽全屏問題、黑白模式上層設不成、預覽和拍照範圍不一致的問題、軟體轉90度壓扁問題等等。
二、解決思路
先做基礎理論的儲備。
VGA ：640x480；
QVGA ：320x240；
YUV格式：4：2：2
曝光控制/伽瑪增益/白平衡等都是效果方面的調整。
對於象素數較大的sensor，如1280x1024，由於資料量較大，通常預覽解析度640x512拍照解析度是1280x1024，且拍照時的PCLK是預覽時的2倍，這樣可以對VFE（video front end）來說是同樣的幀速率。
Ov7670的暫存器0x15的bit6可以切換sensor輸出HREF或HSYNC，我們用HREF。
Camera_process_config_vfe初始化VFE暫存器；
Qcamraw_set_header設定sensor幀頭；
程式碼分層：
層 Drivers services Oem層 App層
程式碼位置 camsensor camera Oemcamera.c Qcamera.c/Qcamcorder.c
Trace32命令:data.image addr. 640. 480. /GS8，可方便的看某buffer地址中的圖片，判斷取到的預覽圖片內容和最終顯示的屏上的差異。
camera_qdsp_cb是收到幀等事件的回撥，根據預覽和拍照的不同需要，QDSP會送來不同的格式，本例中拍照格式是YUV422PS，預覽格式是RGB565LE。
要得到需要的幀率，需要給sensor暫存器設定時加入空白象素和空白行。對於ov7670，0x92/0x93加入空白行個數。
幀率的計算按照以下公式：
fps*(640+144)*(510+x)*2 = 12M(Pclk)
其中x是空行數，{0x92, 0x00},{0x93, 0x00}時，x為0，fps為15；{0x92, 0x19},{0x93, 0x01}時，x為281（0x119），fps為9.67。
如下圖1是x為0時的時序圖：
圖 1 VGA Frame Timing
三、實踐情況
3.1預覽
首先關注暫存器設定是否成功，測試發現寫完暫存器，再讀出的值和寫的部分不同，因為某些暫存器是在自動重新整理的。
對於sensor，只要供電正常，且有MCLK，就應該有行場同步及PCLK訊號。開始沒有測到訊號，後查出來同步訊號在傳輸過程中由於某管腳對地短路，衰減了。
要保證程式碼中主晶片和sensor側象素數（寬、高）、同步訊號極性（高低電平）和取樣頻率（PCLK）設定一致，才能預覽。主晶片通過CAMIF介面的暫存器設定。在camera_process_config_vfe中寫入。
軟體設定如下：
測出9.679fps時的波形如下圖：
15fps的時序如下：
VSYNC High:66ms（約510=17+480+10 lines）Low 394us 週期約66ms 即15fps;
HSYNC High:106us (約1280 clks) low 24.4us 週期約130us;
VSYNC上升沿到HSYNC上升沿的time :1.98ms，約17 lines;
HSYNC下降沿到VSYNC下降沿的time :1.57ms，約10 lines;
PCLK是12MHz.
HREF、VSYNC都用做同步訊號，高通新近平臺上通過取樣同步訊號得到資料，有效行前邊的無效行不需精確設定，只要同步訊號電平給定即可。檢測計數到夠一幀才會產生中斷資料。
查完一切狀態正常，但從log檔案可以看看主晶片還是是未接到sensor的幀；
後再測訊號，發現HREF訊號實際板子上沒傳到CPU子板上。
總結經驗：硬體除錯時注意，訊號測試要逐級測試，從輸出一直到輸入點上，考慮硬體通路可能存在的傳輸問題。硬體電路容易有對地短路的點，如遇到訊號傳輸異常的。可以斷電側對地電阻，確認是否對地短路。
3.2拍照無效區域的問題
Dispsize設為216x160可以在128*160的屏上全屏預覽，但拍出的照片有一條雜色區域，如圖所示，這個問題在預設Dispsize設定128x96時也有。
30萬畫素，資料量比較小，預覽和拍照可以用同一解析度，所以snapshot不用重設暫存器，驅動中重設暫存器引起了拍照無效區域的問題，去掉解決。
3.4預覽和拍照範圍不一致的問題
CAMIF輸出的是一個橫長的影象，在豎長的屏上預覽需要裁減，因此造成了使用者看到的和拍到的明顯不一致，為解決這個問題，需要把sensor從橫著放置改為豎直放置，但是所用高通平臺沒有一個MDP，即影象旋轉的硬體加速器，軟體上的旋轉可能會增加負擔，對此，做了必要的驗證工作。
從原理上看，不旋轉和旋轉90度的處理演算法沒有明顯差異。
現象上看，軟體令camera_default_rotation =90，camera預覽和拍照及camcorder預覽及錄下的視訊都順時針轉了90度。
用task profiling跟蹤，不旋轉和旋轉90度佔用CPU時間一樣。詳如下圖：
旋轉：0度； display size: 216x160； Image size :160*120
九宮格 QCAMERA預覽 拍照 拍照 QCAMERA預覽
旋轉：90度； display size: 216x160； Image size :160*120
九宮格 QCAMERA預覽 拍照 拍照 QCAMERA預覽
3.5拍小尺寸照片壓扁問題
軟體和硬體都轉過90度之後，拍出來的大尺寸照片和預覽只有了微小差異，但小照片卻被壓扁了，從理論上分析，寬高比等和屏同樣很協調，怎麼也想不出道理。
最終用模擬器仔細跟蹤拍照過程中各引數的設定，找到了原因：預覽的CAMIF window根據 display_aspect_ratio不同分別基於寬或高來計算，拍照的CAMIF window也需要這麼處理，否則看到的和拍到的會不同。
因此在程式碼上加了類似的處理。