sensor 驅動與調試小結

目錄：

前言

驅動篇：
1、 Micron sensor ISP的原理圖
2、 sensor 的原理框架
3、Sensor 的初始化步驟
4、Preview時候的sensor設置
5、Capture時候的sensor設置
6、工頻干擾的調試
7、亮度以及夜景模式

調試篇：
1、 清晰度的測試
2、 灰階重現
3、 畫面的均勻性以及暗腳補償
4、 畸變
5、 白平衡的調試

前言
Micron sensor 是我們公司所用最多的圖像傳感器，也是目前市場上評價很高的主流sensor產品。寫這篇文章的目的在於讓後繼調試sensor者對sensor的調試有初步的思路和對micron sensor的一些特性有一定的瞭解，希望以後的調試工作能夠少走一些彎路。具體的sensor的工作原理和更深入的圖像工程方面的知識，可以參看各個sensor的datasheet和上網查找一些關於camera的測試資料。

驅動篇：
Micron sensor ISP的原理圖：

下圖是sensor的功能框架構圖：


         Sensor Core register是實際上控制sensor的register.是直接控制sensor的寄存器(對應的是sensor 寄存器的page 0)。
         Image Flow Processor 裏的register主要是一些控制sensor的算法的寄存器。其中color Pipeline主要是對輸出數據和信號的一些控制。比如 Base configuration, lens shading, resize, output format(page 1)
        Camera control集中了對sensor core的控制算法，控制sensor core的工作都是在這個寄存器組中完成。（page 2）比如AE, AWB, Flicker, Camera control sequencer。

Sensor 的初始化步驟：

一般sensor的初始化通常包含以下幾個步驟：
1、 sensor的上電。Micron sensor的電源分爲數字電源，模擬電源和IO電壓。這三個電源並沒有嚴格的先後上電順序，可以在代碼中同時打開。
2、 對sensor輸出MCLK，配置對PCLK採樣輸出頻率，這是能否正常接收sensor數據的關鍵。
3、 配置V，H同步信號的輸出極性，如果極性配置不對，將造成圖象不能正常採集，自然顯示混亂。
4、 硬件的reset。 Micron sensor的reset爲低reset，並且至少持續1US，
5、 軟件的reset。既然爲軟件的reset，那就必須要求BB或者多媒體MAP能夠對sensor進行寫寄存器。也就是要保證IIC能夠正常地寫數據進入sensor ISP,這點是保證軟件能夠進行調試的基礎。軟件reset通常根據sensor的不同會有所變化，如mt9d111內帶一個MCU，所以在reset的時候要對MCU同時進行reset。而mt9m11就沒有帶MCU。注意硬件reset後要保留一些時間才能使用IIC總線。通常在10個US以上。
6、 Micron sensor mtd9111 系列的帶ISP的2M sensor在ISP中默認了一組寄存器，能夠在reset後不用IIC寫任何寄存器就能輸出圖象，這個時候sensor的input clock是output clock的兩倍，前期可以用這個方法來驗證硬件和軟件供電，復位等是否正確，當後端接受的圖象engine只能用mclk來同步工作時候，必須要正確配置接收的採樣頻率，否
則不能得出正確的圖象。

上圖就是採樣頻率不匹配的現象。請注意與YUV，RGB順序配置錯誤的現象有什麼區別。下圖是順序倒置：
 

7、 寫入micron 工程師給的初始化寄存器，並配置輸出頻率和輸出圖象的分辨率。
8、 讀取sensor的版本號，如果與我們所用產品的version一致，就代表初始化工作正確完成。
初始化sensor的道理很簡單，而且如果平臺比較成熟，有可能一次性就能正確的初始化，也有可能會花很多時間去查問題，特別是如果你遇到了iic寫給sensor的時候出現不穩定的現象或者sensor接收到iic命令和數據，卻不按正常地輸出，那就比較麻煩了，不過2m sensor的ISP既然已經帶了MCU，不妨把它當成一個應用處理器去維護，在寫某些改變sensor內部工作狀態的寄存器時要注意延時。有些時候對一個寄存器可以多次寫入保證其能正常地工作，這是一個還沒有想出原因的經驗。按照以上的流程檢查應該能夠準確定位80%以上的問題。

IIC 總線協議
        I2C串行總線有兩根信號線：一根雙向的數據線SDA；另一根是時鐘線SCL。所有接到I2C總線上的設備的串行數據都接到總線的SDA線，各設備的時鐘線SCL接到總線的SCL。在Vienna平臺上, I2C連了兩個器件，分別是sensor和audio codec，，主控設備（MAP）發送不同的器件ID與兩個設備進行數據傳輸。
        在I2C總線傳輸過程中，將兩種特定的情況定義爲開始和停止條件，當SCL保持“高”，SDA由“高”變爲“低”時爲開始條件；SCL保持“高”，SDA由“低”變爲“高”是爲停止條件。開始和停止條件由主控器產生。使用硬件接口可以很容易地檢測開始和停止條件，沒有這種接口的微機必須以每時鐘週期至少兩次對SDA取樣以使檢測這種變化。
        下圖對就是IIC的一次寫操作，具體的IIC協議很容易在網站上可以找到，micron 的datasheet也能找到一些介紹。
 

Preview時候的sensor設置：

        在preview的時候爲了得到更高的幀率，通常採用低分辨率的輸出，也就是長寬都只有最高分辨率的一半，本來能夠設置更小的分辨率輸出，這個時候sensor的輸出是間隔輸出，並不是對象素採樣後的均勻輸出。但是由於多媒體芯片corelogic的無法接收不規則的pclk的原因，只有作罷。而有些平臺的camera interface就不存在這個問題。從而能直接輸出屏幕大小的圖象，減少後端處理的繁瑣和節約爲preview所開的buffer大小。

Capture時候的sensor設置：

        Capture爲了獲得更大的分辨率和更好的圖象質量，所以必須採用高分辨率的輸出，那麼在切換到capture的時候就需要對sensor進行一組寄存器設置，micron sensor 爲用戶提供了兩個相對獨立的context，能夠存兩個寄存器組，默認的設置是將preview用context A, capture 用context B, context A通常是low power mode，而context B用的是full power mode ,由於corelogic只能用mclk去同步採樣，這樣它便只能接受規則的pclk，不然採樣就會有問題，那麼這樣就要求context A與context B的都爲full power mode，這樣就能保證無論preview還是capture，sensor都能以已固定的頻率的輸出pclk，後端MAP就能正常地接收圖象信息，不至於出現花屏和顏色不對。由於這樣的解決辦法並不是micron 推薦的方案，而是自己想出的彌補方法。所以Vienna平臺上至少一半以上的問題都是由corelogic的這個缺陷，以及爲了彌補這個缺陷所修改的sensor輸出引起的，以後如果要換多媒體應用處理器，請考慮到MAP是否支持接受不規則的pclk。目前Vienna 和高通平臺都不支持變化的PCLK，而Vision平臺是支持的。

lower power 模式下的輸出
 
full power 模式下的輸出
證明corelogic不能接受lower power mode的sensor輸出。

        由於輸出的時鐘頻率preview與capture固定，CMOS sensor暴光原理是行暴光，暴光時間等於行暴光時間，line time=hsync time +hblank time。130萬象素的的sensor爲例，preview的時候輸出VGA，hsync time=640*k, K爲shutter width(快門時間)。而capture的時候hsync time=1280*k, 在k不變的情況下，hsync time發生了巨大的變化，這樣暴光時間也發生了巨大的變化，現象是拍照的時候的圖片明顯過曝。不過micron 給出了一個可以改變shutter width的寄存器，通過改變這個寄存器能夠調整綜合暴光時間，這樣就能解決這個問題，在老化測試的時候經常出現暴光不對，就是因爲這個寄存器沒寫入或寫入後sensor沒有反映造成的，由於preview->capture->preview中間的轉化值都是用軟件來實時計算出來的，所以無論是iic讀或者寫，還是環境亮度引起sensor亮度計算錯誤，都會影響到暴光，維護這段代碼的時候要特別小心。如果遇到拍照的時候與preview的圖像質量差別很大，請從這段代碼開始查。

// sensor在進行模式切換
IIC_Write16bit(0xf0, 0x0001);
IIC_Write16bit(0xC6, 0xA104);
//判斷模式切換是否成功
dataTemp=IIC_Read16bit(0xc8);
if(g_nightmode)
{
waittime=1000;
}
else
{
waittime=50;
}
//判斷模式切換是否成功，請注意這個不一定會成功。
while (dataTemp != 7)
{
dataTemp = IIC_Read16bit(0xC8);
WaitTime_ms(1);
i++;
if(i>waittime)
{
AMOIT(" the sensor change mega mode fail!-----/n");
break;
}
}
AMOIT1("------i=%d-----/n",i);
//以下這段就是在進行暴光控制
IIC_Write16bit(0xf0, 0x0000);
dataTemp = IIC_Read16bit(0x09);
gCurbrightness1 = dataTemp;
IIC_Read16bit(0x09);
WaitTime_ms(10);
IIC_Write16bit(0x09, dataTemp*2/7);
IIC_Write16bit(0xf0, 0x0001);
IIC_Write16bit(0xc6, 0x2225);
dataTemp = IIC_Read16bit (0xc8);
gCurbrightness2 = dataTemp;
WaitTime_ms(10);
IIC_Write16bit(0xf0, 0x0000);
IIC_Write16bit(0x65, 0xB000); // CLOCK_ENABLING
IIC_Write16bit(0x65, 0xE000); // CLOCK_ENABLING
WaitTime_ms(600); // Wait 1 frame time

preview的時候輸出的圖象。

capture 下來的圖象，可以看見明顯的過暴現象。

        根據經驗並非模式切換失敗就一定不能正常輸出百萬象素，而不能正常輸出多半就是模式切換失敗。模式切換的時間與成功率與幀率有一定的關係，一般說來，幀率越快，時間越短，成功率越高。再從capture->preview的時候也必須設置暴光值，以保證圖像不會突然變暗，如果發現拍照越來越暗，多半就是返回preview的時候設置失敗。
        注意：模式切換的時候，用示波器可以看到sensor在做切換的時候會出現突然拉低VSNYC信號，形成一個較長的消隱（blank）信號，然後輸出另外一個MODE的下的信號，有時候不穩定的現象就是這個blank信號過長，特別是發生在低幀率的情況下，會使後端ISP或者DSP無法採集到數據，沒有辦法產生拍照的中斷，造成task被掛起（進入 idle task）或者死機重啓（被狗咬）的現象，具體原因和對策可以根據不同平臺的實現方法去分析解決。
       到了這裏sensor的兩個基本狀態的調試就算基本完成了，後期就是對這段代碼的維護工作。

工頻干擾：

        如果手機出現以如下圖的這種水波紋就是工頻干擾。工頻干擾是由於室內日光燈閃爍造成的。CMOS與CCD 兩種不同的工藝製造出來的sensor工頻干擾現象是不一樣的，這是由暴光的方式不同造成的。
        CMOS是行暴光，也就是在每行暴光時間決定了畫面的亮度，舉例：一個50HZ的光源，電壓曲線爲正弦曲線，那能量曲線定性分析可以認爲是取了絕對值的電壓曲線。那就是能量做1/100秒的週期變化。那就要求暴光的時間必須是1/100秒的整數倍。如果沒有把暴光時間調整到1/100秒的整數倍，就有可能會有每行的暴光值不一樣，造成同一個image上有水波紋現象。CCD是整幀同時暴光，所以，工頻干擾表現的就是圖像有輕微的閃爍。產生的原理與CMOS sensor的原理相似。
        如果有發現這樣的問題，可先計算出暴光時間，再在這個基礎上進行微調。相信很快就能調到沒有工頻干擾。
Micron 有個寄存器能夠調整暴光，以達到消除工頻干擾的目的。
算法：line time *0x58(page 2)/PCLK=N/100(用這個公式算出來的值還要進行微調試，reg 0x58是mt9m111的寄存器，不同的sensor是不一樣的，但一定能找到一個類似的寄存器，N是自然數，datasheet裏面沒有介紹，呵呵，不過如果你瞭解cmos的暴光原理，相信很容易明白的)。

亮度以及夜景模式：

       相信現在大家都知道圖象的亮度與暴光時間相關，所以爲了讓暗處的圖片能夠清晰地顯示必須增加sensor對暗處圖象的暴光時間，也就是line time會設置得比普通模式的時候要大許多，這樣能使CMOS sensor擁有更多的暴光時間，從而提高亮度。

         上圖爲沒有采用夜景模式的照片，下圖爲使用夜景模式的照片

        我們有兩種方法來控制圖像亮度，一種是使用AE target，一種是加大灰度增益。我們使用的是AE target方式，這樣的圖片色彩更逼真。用這種辦法會影響到frame rate，當幀率達到我們限制的極限的時候，就要用增加模擬增益來做了，這樣會同時放大圖像噪聲。一般不用增加數字放大增益來調整圖像亮度。

調試篇

        與一般IC的驅動不同，sensor除了要工作起來和穩定性之外，還需要調試圖象質量。在這點上，所有的sensor都要經過相同的評估測試，調試。通常camera的調試會有下面主要幾個方面：

清晰度的測試
使用ISO12233標板測試

中心垂直分辨率
 

中心水平分辨率

        
        主要看肉眼剛好能夠分清線條時候的刻度值。
        清晰度主要由sensor製作工藝水平和鏡頭參數決定，但可以通過調試銳度（sharp）來增強清晰度。
        副作用是較高的銳度對圖像的平滑性有影響，會使物體邊緣特別明顯，甚至出現鋸齒現象。

灰階重現測試


 
        一般sensor都會有一組寄存器用來調整gamma曲線，也就是我們所說的gamma table，由於本人水平有限，這個調試一般由micron 的工程師完成。

gamma 曲線圖

畫面的均勻性以及暗腳補償：


 
        通過上圖我們可以發現畫面不是很均勻，中心和邊緣的亮度有明顯的差別，由於鏡頭的原因，sensor總是中間的象素暴光比較充分。Micron 能夠調試lens shading來解決這個問題，能將畫面調試得更加均勻。

        調試過後的圖片

        這個調試過程中要防止出現光圈現象。

畸變：

        畸變是由鏡頭形成的，由camera的製造工藝決定，所以無法通過改變ISP的設置改善。
        下圖爲測試畸變的樣板。


白平衡：

        要說到白平衡就要先建立色溫的概念。
       其實在攝影領域，光源大多是根據它們的色溫來定義。色溫的單位是開爾文，在不同溫度下呈現出的色彩就是色溫。當一個黑色物體受熱後便開始發光，它會先變成暗紅色，隨着溫度的繼續升高會變成黃色，然後變成白色，最後就會變成藍色（大家可以觀察一下燈泡中的燈絲，不過由於受到溫度的限制，大家一般不會看到它變成藍色）。總之，這種現象在日常生活中是非常普遍的。

        上圖就是不同的色溫的光源照射下的同一組物體的圖片。

        人的大腦能仔細分析出從眼睛接受的信號，因而能感知不同的色溫（color temperature）來顯示相同的白色。但camera 卻不能，在早晨時分的相片偏紅，而黃昏時候的卻偏黃，就算同一張白紙在不同的環境下被拍攝，如不同的時間，不同的光源，都會出現不同程度的偏差。
調整白平衡，就是要給白色一個定義，能正確記錄我們眼睛所看到的顏色。 Micron sensor 給出了兩種白平衡的控制方法，一種是自動白平衡（AWB），一種是手動白平衡（MWB）。
        自動白平衡爲sensor內部ISP的默認設置，ISP中有一結構複雜的矩形圖，它可決定畫面中的白平衡基準點，以此來達到白平衡調校。由於手機camera不屬於色彩要求很高的照相機範疇，所以我們一般使用自動白平衡，自動白平衡在光源不是特別複雜的時候有較好的效果。
        手動白平衡需要自己設置R，G，B的gain值，micron給我們的寄存器中有專門設置這三個值的寄存器。

       作者水平有限，或許會有些不準確之處，歡迎指正批評。