1、camera如何調試？ Camera的接口如下： 1.VSYNC2.HSYNC3.PWDN4.RESET5.AGND6.SCL7.SDA8.DVDD189.DOVDD2810.MCLK11.PCLK12.DGND13.DATA0-DATA714.IOVDD2815.GND 看sensor的spec來調試。 1）莫爾條紋（綵帶） 從技術角度上講，莫爾條紋是兩條線或兩個物體之間以恆定的角度和頻率發生干涉的視覺結果，當人眼無法分辨這兩條線 或兩個物體時，只能看到干涉的花紋，這種光學現象就是莫爾條紋。莫爾條紋現象是由於信號取樣頻率接近感光器分辨率所致，通常解決方法用一個低通濾鏡把高於
感光器分辨率的信號擋住，其副作用就是降低成像分辨率。因此在設計低通濾鏡時設計師要在分辨率和莫爾條紋之間做一個妥協選擇。因爲D70的CCD前面使用 效果比較弱的低通濾鏡，所以在提高成像分辨率也造成了莫爾條紋出現機率的增大，此現象也廣泛出現於其他DSLR上。 推薦解決方法：避免拍攝場面有接近相機分辨率的規則性圖案，或者後期通過軟件去除。 "水波紋"的現象、banding或者是fliker，如下圖所示： 關於你反映的手機對着日光燈preview時有類似"水波紋"的現象， 現解釋如下： 這個現象叫做banding或者是fliker,主要是由於日光燈的頻率
和曝光時間而引起的。我們已經避免了在室內正常情況下(不對着日光燈的情況) 沒有banding的現象。但是對着日光燈時，banding現象是無法完全消除的。 這種現象屬於正常的。2）對比度過大導致顏色更豔，有偏紅。 3）中間亮，四周暗：shutting不夠。 4）暗處噪聲大：調gamma。 5）鏡頭能夠影響分辨率和清晰度。 6)preview 和capture 時存在的壞點是由於sensor自己產生的。一般主要是亮的壞點。 OV2640在Fxxxx上通過取2.0M（1600*1200）sensor處理後輸出給sunplus556（800*600）來減小壞點。
7）高低亮度動態範圍太小。導致高亮時過曝，低亮圖片亮度不夠。(ov9655)解決方法：(會使圖片變的模糊.模糊的原因是因爲使用的鏡頭的mtf數值太小,模組整體高度太低造成的.要徹底解決這個問題,只有更換更好的鏡頭才行.)修改gamma:60 7A2c60 7B C60 7C 1960 7D 2860 7E 4060 7F 4b60 80 5660 81 6060 82 6760 83 7060 84 7a60 85 8960 86 9560 87 AF60 88 C860 89 DF ８）預覽低亮度拍照目標效果不佳，需要改善。(ov9655)解決方法：增加gain:60
142e ９）預覽低亮度拍照目標會出現閃爍，請調整。(ov9655)解決方法：(亮度的調整需要時間,所以亮度會閃幾下)固定fps:60 3b0c 10) preview和capture的不一致：(ov9655)我們preview使用的是vga的模式，capture使用的是sxga的模式．兩個模式切換過程中要進行亮度計算，這個計算是將sensor的增益轉化成曝光時間．由於這兩種實現亮度的方式有差別，所以preview和capture一定存在差異．我們的調試就是讓這種差異儘量的小． 11)preview中有跳動的感覺．(ov9655)從亮到暗和從暗到亮的變化中，sensor的調整需要時間．在這個時間中，vsync一直有輸出，所以可以看到這個問題．(主要是壞幀的問題)現在的修改是調整過程中的vsync不輸出，所以看不到這個問題了．
12）在暗處切換夜景和自動後，回到正常光線preview不停的閃動。(ov9655) For 9655 night mode: night:0x3b,0xcc normal:0x3b,0x0c0x2d,0x000x2e,0x00在夜間模式的時候是會自動變楨率的,sensor會自動調整0x2d,0x2e的數值來變楨率.切回自動的時候要將這兩個寄存器清零,不然它們還是夜間模式裏面的數值. 13）Fxxxx的顏色不夠鮮豔目前最新的版本發灰。這個應該是圖象的數據分佈有問題，範圍窄（我看下來32以下的數據很少），而cxxxxx的數據分佈比較寬。另外，我們和LCDC（sunplus）調整顏色是對者標準色板來調試的。其實Cxxxx的顏色反而是有些失真的。建議：必須需要isp做black
levelcaliberation，讓響應曲線過零點。 如果沒有，看看有沒有Y_offset，Y_contrast可以動動的。 14）亮度不夠。從分析來看，平均亮度在128+/-10範圍之內了，曝光控制是正常的。可能是因爲圖象發灰導致看上去亮度不夠建議：解決第一條可能這條也解決了。 15）暗光下噪點大。暗光對sensor的要求高。任何sensor的噪聲都要變大。對於30萬象素的手機，主要還是看屏上的效果，雖然噪聲大了點，但屏小 ，所以不明顯。重點應該在提升其他方面，使preview的效果更好。 16）夜景下比Cxxxxxx噪點大。微帶發綠。大部分sensor都會在暗處發綠和亮處發紅，但應該在一個可接受的範圍之內。原因：紅綠藍三個顏色的響應曲線是非線形的，在做白平衡時候靠簡單的線形處理無法將三根曲線進行重合。手機DSP能力畢竟不能夠和數碼相機的能力相比。如果把暗光顏色很準，那麼可能正常下顏色就不夠鮮豔或者亮處顏色不準，或者噪聲大等其他更加嚴重的狀況出現。我覺得現在的狀況還不算離譜。17）數字影像測試總評·
白平衡檢測（White Balance） 白平衡差異（White Balance）影響數字相機的色彩表現甚鉅，雖然大多數的數字相機自動白平衡（AUTOWB）都能應付一般的拍攝狀況。不過， 若將白平衡誤差 更進一步以（K）色溫來區分，則誤差普遍存在於各廠家的設定之中。ColorChecker 特別針對白平衡部分設計了圖塊檢測，標示 (1) 爲原始攝影圖塊、標示（2）則爲理想的 ColorChecker HSV值合併運算曝光之表現以及標示 (3) 原始 ColorChecker 理想值，以 HSV 和 K 兩種系統顯示白平衡的誤差比值。
· 鏡頭光衰減（Light FallOff） 採用多重鏡片組合設計的鏡頭，鏡片材質、形狀，或多或少都會影響光線路徑和光量大小；不同於色像差，Light Falloff 主要是判別自鏡頭中央 起至整幅畫面邊緣位置於拍攝均勻光線下所產生的光差。理想鏡頭於均勻光線下，自中心到邊緣的光分佈應爲相同，但實際上卻不容易做到，形成許多攝影人員口中的『暗角』現象。 光衰減檢測，可以看出鏡頭中心到邊緣影像光線不均勻分佈的情形 優良的鏡頭設計下，人眼幾乎難以辨認 Falloff 的發生。但在電腦或專業儀器的輔助下，鏡頭的光衰減卻相當明顯。理想的光衰減檢測，可透過
Labsphere 或 Electro-Optical Industries(EOI) 產生球狀均勻光線（模擬自然狀態下三維空間之均勻光線產生），例如：Labsphere 出品的 USS-1200 或 USS-1200V；實際上，一般的檢測也可以透過大面的素色板（或牆壁），藉着散焦方式取得均勻光線進入相機之中，再利用相關的電腦軟件取得對應的數據。 · 影像器材數據化量測綜合評量 今日的影像器材效能檢測已經是一門相當科學且專業化的科目，一般攝影玩家較難負擔如此複雜且昂貴的測試器材，而必須仰賴媒體或公正第三者提供相關測試報告。爲了方便大家快速且有效的認知器材性能，多數評量都集中『解像力』和『色彩』表現上。然而，實際上，影響影像品質的因素不單只是鏡頭和
CCD 而已，甚至包括許多外在的人爲因素。 附註：人爲因素的影響在測試報告中很難被發現，多數的專業媒體理當避免人爲影響其最終測試結果。 影響數字相機 測試表現的因素，也往往是許多業餘攝影者常犯的錯誤。例如：1. 相機是否固定於穩定的三角架（反光鏡是否鎖起）；相機機身是否會晃動影像畫質2. 相機與測試標的距離是否恰當3. 相機是否正確與測試標的完成對焦； 對焦選擇是否正確、對焦點是否位於正確中心4. 影像格式和壓縮比是否正確選擇（RAW格式是否可以選擇） ； 過高的壓縮比或過低的解析度，同樣影響畫質的表現5.
環境 Gamma 值的選擇 ； 環境亮度影響畫質清晰表現甚鉅6. 清潔工作是否確實 ； 無論鏡頭表現、UV濾鏡、保護鏡，甚至於相機內之CCD / CMOS 等，沾染上灰塵等，都將影響後續的測試值7. 鏡頭的設定 ； 測試標的是否位於有效的景深內（鏡頭之光圈和焦長是否正確設定）； 測試 DSLR 最好可以選擇定焦鏡頭8. 光線的位置 ； 直射光線易造成測試標的的反光，影響判別。 · 親身體驗 因此，數據化的測試報告，雖有助於你瞭解相機的性能表現，卻不一定讓你在操作上得心應手。一架具備完善操作設計的消費型數位相機，未必一定輸給
DSLR。『盡信書，不如無書！』，實際走訪體驗你心目中的影像器材，輔之你網路或是平面上閱讀到的測試報告，將更具說服力。18）我多次拍攝白紙的照片.一般在剛進入preview時,馬上拍攝會出現嚴重偏紅或者偏藍等. OV：因爲自動曝光和自動白平衡在preview開始前會有一個初始值得設置，在進入preview後，曝光和白平衡自動調節開始，調節過程的長短與初始設置和實際環境間的差異相關。改變初始值可以使在某一特定環境下的調節時間最短，但對其他條件，還是要視環境差異的大小而定。 通過提高preview的楨率可以縮短調節的時間，或者可以使用跳楨的方法使此現象減輕。LCDC（Sunplus）：這個以前我們調過，但是AWB初始化速度太慢，沒有效果。
但是你可以通過流程來控制，讓開始的幾幀不要顯示在屏幕上，即讓那個等待界面時間長一些，將preview的前幾幀不要顯示。 19）ov7670在對着窗外一會（亮處），再轉換到室內（暗處）這時候調節亮度特別慢或者preview全黑不能恢復。這個問題是因爲LCDC（sunplus）在進入preview時沒有完全給ov7670初始化，而是隻在手機開機初始化一次，以後只是更改少部分寄存器。後來更改爲進入preview時就初始化一次寄存器就可以了。 2、stack棧和heap堆的關係？ 一、預備知識—程序的內存分配一個由c/C++編譯的程序佔用的內存分爲以下幾個部分1、棧區（stack）—
由編譯器自動分配釋放，存放函數的參數值，局部變量的值等。其操作方式類似於數據結構中的棧。2、堆區（heap） — 一般由程序員分配釋放，若程序員不釋放，程序結束時可能由OS回收 。注意它與數據結構中的堆是兩回事，分配方式倒是類似於鏈表，呵呵。3、全局區（靜態區）（static）—，全局變量和靜態變量的存儲是放在一塊的，初始化的全局變量和靜態變量在一塊區域，未初始化的全局變量和未初始化的靜態變量在相鄰的另一塊區域。 - 程序結束後有系統釋放4、文字常量區 —常量字符串就是放在這裏的。 程序結束後由系統釋放5、程序代碼區—存放函數體的二進制代碼。二、例子程序這是一個前輩寫的，非常詳細//main.cppint
a = 0; 全局初始化區char *p1; 全局未初始化區main(){int b; 棧char s[] = "abc"; 棧char *p2; 棧char *p3 = "123456"; 123456\0在常量區，p3在棧上。static int c =0； 全局（靜態）初始化區p1 = (char *)malloc(10);p2 = (char *)malloc(20);分配得來得10和20字節的區域就在堆區。strcpy(p1, "123456"); 123456\0放在常量區，編譯器可能會將它與p3所指向的"123456"優化成一個地方。}二、堆和棧的理論知識2.1申請方式stack:由系統自動分配。
例如，聲明在函數中一個局部變量 int b; 系統自動在棧中爲b開闢空間heap:需要程序員自己申請，並指明大小，在c中malloc函數如p1 = (char *)malloc(10);在C++中用new運算符如p2 = (char *)malloc(10);但是注意p1、p2本身是在棧中的。2.2申請後系統的響應棧：只要棧的剩餘空間大於所申請空間，系統將爲程序提供內存，否則將報異常提示棧溢出。堆：首先應該知道操作系統有一個記錄空閒內存地址的鏈表，當系統收到程序的申請時， 會遍歷該鏈表，尋找第一個空間大於所申請空間的堆結點，然後將該結點從空閒結點鏈表中刪除，並將該結點的空間分配給程序，另外，對於大多數系統，會在這塊內存空間中的首地址處記錄本次分配的大小，這樣，代碼中的delete語句才能正確的釋放本內存空間。另外，由於找到的堆結點的大小不一定正好等於申請的大小，系統會自動的將多餘的那部分重新放入空閒鏈表中。2.3申請大小的限制棧：在Windows下,棧是向低地址擴展的數
據結構，是一塊連續的內存的區域。這句話的意思是棧頂的地址和棧的最大容量是系統預先規定好的，在WINDOWS下，棧的大小是2M（也有的說是1M，總 之是一個編譯時就確定的常數），如果申請的空間超過棧的剩餘空間時，將提示overflow。因此，能從棧獲得的空間較小。堆：堆是向高地址擴展的數據結構，是不連續的內存區域。這是由於系統是用鏈表來存儲的空閒內存地址的，自然是不連續的，而鏈表的遍歷方向是由低地址向高地址。堆的大小受限於計算機系統中有效的虛擬內存。由此可見，堆獲得的空間比較靈活，也比較大。2.4申請效率的比較：棧由系統自動分配，速度較快。但程序員是無法控制的。堆是由new分配的內存，一般速度比較慢，而且容易產生內存碎片,不過用起來最方便.另外，在WINDOWS下，最好的方式是用VirtualAlloc分配內存，他不是在堆，也不是在棧是直接在進程的地址空間中保留一快內存，雖然用起來最不方便。但是速度快，也最靈活。2.5堆和棧中的存儲內容棧：
在函數調用時，第一個進棧的是主函數中後的下一條指令（函數調用語句的下一條可執行語句）的地址，然後是函數的各個參數，在大多數的C編譯器中，參數是由右往左入棧的，然後是函數中的局部變量。注意靜態變量是不入棧的。當本次函數調用結束後，局部變量先出棧，然後是參數，最後棧頂指針指向最開始存的地址，也就是主函數中的下一條指令，程序由該點繼續運行。堆：一般是在堆的頭部用一個字節存放堆的大小。堆中的具體內容有程序員安排。2.6存取效率的比較char s1[] = "aaaaaaaaaaaaaaa";char *s2 = "bbbbbbbbbbbbbbbbb";aaaaaaaaaaa是在運行時刻賦值的；而bbbbbbbbbbb是在編譯時就確定的；但是，在以後的存取中，在棧上的數組比指針所指向的字符串(例如堆)快。比如：＃i
ncludevoid main(){char a = 1;char c[] = "1234567890";char *p ="1234567890";a = c[1];a = p[1];return;}對應的彙編代碼10: a = c[1];00401067 8A 4D F1 mov cl,byte ptr [ebp-0Fh]0040106A 88 4D FC mov byte ptr [ebp-4],cl11: a = p[1];0040106D 8B 55 EC mov edx,dword ptr [ebp-14h]00401070
8A 42 01 mov al,byte ptr [edx+1]00401073 88 45 FC mov byte ptr [ebp-4],al第一種在讀取時直接就把字符串中的元素讀到寄存器cl中，而第二種則要先把指針值讀到edx中，在根據edx讀取字符，顯然慢了。2.7小結：堆和棧的區別可以用如下的比喻來看出：使用棧就象我們去飯館裏吃飯，只管點菜（發出申請）、付錢、和吃（使用），吃飽了就走，不必理會切菜、洗菜等準備工作和洗碗、刷鍋等掃尾工作，他的好處是快捷，但是自由度小。使用堆就象是自己動手做喜歡吃的菜餚，比較麻煩，但是比較符合自己的口味，而且自由度大。
下面是另一篇，總結的比上面好：堆和棧的聯繫與區別dd 在bbs上，堆與棧的區分問題，似乎是一個永恆的話題，由此可見，初學者對此往往是混淆不清的，所以我決定拿他第一個開刀。 首先，我們舉一個例子： void f() { int* p=new int[5]; } 這條短短的一句話就包含了堆與棧，看到new，我們首先就應該想到，我們分配了一塊堆內存，那麼指針p呢？他分配的是一塊棧內存，所以這句話的意思就是：在棧內存中存放了一個指向一塊堆內存的指針p。在程序會先確定在堆中分配內存的大小，然後調用operator new分配內存，然後返回這塊內存的首地址，放入棧中，他在VC6下的彙編代碼如下：
00401028 push 14h 0040102A call operator new (00401060) 0040102F add esp,4 00401032 mov dword ptr [ebp-8],eax 00401035 mov eax,dword ptr [ebp-8] 00401038 mov dword ptr [ebp-4],eax 這裏，我們爲了簡單並沒有釋放內存，那麼該怎麼去釋放呢？是delete p麼？澳，錯了，應該是delete []p，這是爲了告訴編譯器：我刪除的是一個數組，VC6就會根據相應的Cookie信息去進行釋放內存的工作。
好了，我們回到我們的主題：堆和棧究竟有什麼區別？ 主要的區別由以下幾點： 1、管理方式不同； 2、空間大小不同； 3、能否產生碎片不同； 4、生長方向不同； 5、分配方式不同； 6、分配效率不同； 管理方式：對於棧來講，是由編譯器自動管理，無需我們手工控制；對於堆來說，釋放工作由程序員控制，容易產生memory leak。 空間大小：一般來講在32位系統下，堆內存可以達到4G的空間，從這個角度來看堆內存幾乎是沒有什麼限制的。但是對於棧來講，一般都是有一定的空間大小的，例如，在VC6下面，默認的棧空間大小是1M（好像是，記不清楚了）。當然，我們可以修改：
打開工程，依次操作菜單如下：Project->Setting->Link，在Category 中選中Output，然後在Reserve中設定堆棧的最大值和commit。注意：reserve最小值爲4Byte；commit是保留在虛擬內存的頁文件裏面，它設置的較大會使棧開闢較大的值，可能增加內存的開銷和啓動時間。 碎片問題：對於堆來講，頻繁的new/delete勢 必會造成內存空間的不連續，從而造成大量的碎片，使程序效率降低。對於棧來講，則不會存在這個問題，因爲棧是先進後出的隊列，他們是如此的一一對應，以至於永遠都不可能有一個內存塊從棧中間彈出，在他彈出之前，在他上面的後進的棧內容已經被彈出，詳細的可以參考數據結構，這裏我們就不再一一討論了。
生長方向：對於堆來講，生長方向是向上的，也就是向着內存地址增加的方向；對於棧來講，它的生長方向是向下的，是向着內存地址減小的方向增長。 分配方式：堆都是動態分配的，沒有靜態分配的堆。棧有2種分配方式：靜態分配和動態分配。靜態分配是編譯器完成的，比如局部變量的分配。動態分配由alloca函數進行分配，但是棧的動態分配和堆是不同的，他的動態分配是由編譯器進行釋放，無需我們手工實現。 分配效率：棧是機器系統提供的數據結構，計算機會在底層對棧提供支持：分配專門的寄存器存放棧的地址，壓棧出棧都有專門的指令執行，這就決定了棧的效率比較高。堆則是C/C++函數庫提供的，它的機制是很複雜的，例如爲了分配一塊內存，庫函數會按照一定的算法（具體的算法可以參考數據結構/操作系統）在堆內存中搜索可用的足夠大小的空間，如果沒有足夠大小的空間（可能是由於內存碎片太多），就有可能調用系統功能去增加程序數據段的內存空間，這樣就有機會分到足夠大小的內存，然後進行返回。顯然，堆的效率比棧要低得多。
從這裏我們可以看到，堆和棧相比，由於大量new/delete的使用，容易造成大量的內存碎片；由於沒有專門的系統支持，效率很低；由於可能引發用戶態和核心態的切換，內存的申請，代價變得更加昂貴。所以棧在程序中是應用最廣泛的，就算是函數的調用也利用棧去完成，函數調用過程中的參數，返回地址，EBP和局部變量都採用棧的方式存放。所以，我們推薦大家儘量用棧，而不是用堆。 雖然棧有如此衆多的好處，但是由於和堆相比不是那麼靈活，有時候分配大量的內存空間，還是用堆好一些。 無論是堆還是棧，都要防止越界現象的發生（除非你是故意使其越界），因爲越界的結果要麼是程序崩潰，要麼是摧毀程序的堆、棧結構，產生以想不到的結果,就算是在你的程序運行過程中，沒有發生上面的問題，你還是要小心，說不定什麼時候就崩掉，那時候debug可是相當困難的：）
對了，還有一件事，如果有人把堆棧合起來說，那它的意思是棧，可不是堆，呵呵，清楚了 3、進程和線程的關係。解釋一： Linux是一個多用戶、多任務的操作系統。多用戶是指多個用戶可以在同一時間使用計算機系統；多任務是指Linux可以同時執行幾個任務，它可以在還未 執行完一個任務時又執行另一項任務。在操作系統設計上，從進程（Process）演化出線程（Thread），最主要的目的就是更好地支持多處理器，並且 減小（進程/線程）上下文切換的開銷。進程和線程的關係根據操作系統的定義，進程是系統資源管理的最小單位，線程是程序執行的最小單位。線程和進程十分相似，不同的只是線程比進程小。首先，線程採用了多個線程可共享資源的設計思想。例如，它們的操作大部分都是在同一地址空間進行的。其次，從一個線程切換到另一線程所花費的代價比進程低。再次，進程本身的信息在內存中佔用的空間比線程大。因此，線程更能允分地利用內存。線程可以看作是在進程內部執行的指定序列。線程和進程的最大區別在於線程完全共享相同的地址空間，運行在同一地址上。Linux線程的定義線程是在共享內存空間中併發的多道執行路徑，它們共享一個進程的資源，如文件描述和信號處理。在兩個普通進程(非線程)間進行切換時，內核準備從一個進程的上下文切換到另一個進程的上下文要花費很大的開銷。這裏上下文切換的主要任務是保存老進程CPU狀態，並加載新進程的保存狀態，用新進程的內存映像替換老進程的內存映像。線程允許進程在幾個正在運行的任務之間進行切換，而不必執行前面提到的完整的上下文。在Unix類系統中，曾經出現過一些不同線程標準，它們都支持可移植操作系統接口標準POSIX(Portable
Operating System Interface Standard)。POSIX 標準由IEEE制定，並由國際標準化組織接受爲國際標準。POSIX 1003.1c是一個用於線程（在一個程序中當前被執行的代碼段）的標準，以前是P1993.4或POSIX.4的一部分，這個標準已經在1995年被 IEEE通過，歸入ISO/IEC 9945-1:1996。本文介紹線程主要是針對POSIX線程，即Pthread，因爲Linux 對它的支持最好。相對進程而言，線程是一個更加接近於執行體的概念，它可以與進程中的其它線程共享數據，但擁有自己的棧空間，擁有獨立的執行序列。在串行
程序基礎上引入線程和進程是爲了提高程序的併發度，從而提高程序運行效率和響應時間。也可以將線程和輕量級進程（LWP）視爲等同，但其實在不同的系統/實現中有不同的解釋。LWP更恰當的解釋可能爲一個虛擬CPU或內核的線程，它可以幫助用戶態線程實現一些特殊的功能。Pthread是一種標準化模型，它用來把一個程序分成一組能夠同時執行的任務。解釋二： 進程是表示資源分配的基本單位，又是調度運行的基本單位。例如，用戶運行自己的程序， 系統就創建一個進程，併爲它分配資源，包括各種表格、內存空間、磁盤空間、I／O設備等。然後，把該進程放人進程的就緒隊列。進程調度程序選中它，爲它分
配CPU以及其它有關資源，該進程才真正運行。所以，進程是系統中的併發執行的單位。 在Mach、Windows NT等採用微內核結構的操作系統中，進程的功能發生了變化：它只是資源分配的單位，而不再是調度運行的單位。在微內核系統中，真正調度運行的基本單位是線程。因此，實現併發功能的單位是線程。線程概念 線程是進程中執行運算的最小單位，亦即執行處理機調度的基本單位。如果把進程理解爲在邏輯上操作系統所完成的任務，那麼線程表示完成該任務的許多可能的 子任務之一。例如，假設用戶啓動了一個窗口中的數據庫應用程序，操作系統就將對數據庫的調用表示爲一個進程。假設用戶要從數據庫中產生一份工資單報表，並
傳到一個文件中，這是一個子任務；在產生工資單報表的過程中，用戶又可以輸人數據庫查詢請求，這又是一個子任務。這樣，操作系統則把每一個請求――工資單 報表和新輸人的數據查詢表示爲數據庫進程中的獨立的線程。線程可以在處理器上獨立調度執行，這樣，在多處理器環境下就允許幾個線程各自在單獨處理器上進 行。操作系統提供線程就是爲了方便而有效地實現這種併發性 引入線程的好處 （1）易於調度。 （2）提高併發性。通過線程可方便有效地實現併發性。進程可創建多個線程來執行同一程序的不同部分。 （3）開銷少。創建線程比創建進程要快，所需開銷很少。。
（4）利於充分發揮多處理器的功能。通過創建多線程進程（即一個進程可具有兩個或更多個線程），每個線程在一個處理器上運行，從而實現應用程序的併發性，使每個處理器都得到充分運行。 進程和線程的關係 （1）一個線程只能屬於一個進程，而一個進程可以有多個線程，但至少有一個線程。 （2）資源分配給進程，同一進程的所有線程共享該進程的所有資源。 （3）處理機分給線程，即真正在處理機上運行的是線程。 （4）線程在執行過程中，需要協作同步。不同進程的線程間要利用消息通信的辦法實現同步。 4、硬件I2C和軟件I2C的對比。用軟件實現和硬件實現基本上沒有區別,可以把多個不同種類的器件加到一個雙線結構上,只是要注意:1.
注意軟件產生的時序要滿足i2c協議要求,就是那些AC參數,具體情況和MCU種類,速率等有關; 因爲指令延時的關係,可能無法達到要求的通訊速率,但可以很接近;2. 作爲SDA總線的I/O端口在轉換輸入和輸出方向時,要注意滿足總線協議,當器件較多時要使用一個外部上拉電阻;3.如果使用帶有擴展地址字節的存儲器和一般的I2C器件在同一總線中,注意不要產生協議上的衝突; 解釋二：I2C（發音爲：”I squared see”）能用於替代標準的並行總線，能連接的各種集成電路和功能模塊。對於嵌入式系統設計者來說，有以下好處：·
更少的管腳連接，也就不需要並行總線接口。· 由更少的管腳連接帶來的更小的電路規模。· 更少的電路板層數和更少的電路連線。· 由於I2C支持多主控，所以更容易調試。支持I2C的設備有微控制器，A/D、D/A轉換器，儲存器，LCD控制器，LED驅動器，I/O端口擴展器以及實時時鐘。通過使用內建的I2C接口硬件或者連接到微控制器標準並行總線的外部I2C控制芯片，微控制器能夠連接到I2C總線。任選其中一種方式，通過通常的 I/0管腳和軟件上的“位拆裂（bit-banging）”技術，你就能實現一種軟件I2C接口。這種方式比較慢，比以硬件爲基礎的實現要複雜的多。I2C的性能標準I2C總線傳輸速率可以到100Kbit/s，通過使用了7位地址碼，就能支持128個設備。加強型I2C總線用了10位地址碼（能夠支持1024個設備），快速模式（400Kbit/s）和高速模式（最高有3.4Mbit/s）。I2C是多主控總線，所以任何一個設備都能像主控器一樣工作，並控制總線。總線上每一個設備都有一個獨一無二的地址，根據設備它們自己的能力，它們可以作爲發射器或接收器工作。多路微控制器能在同一個I2C總線上共存。只要很小的電路附件，I2C總線就能夠支持設備在不同電平下工作（例如：3.3伏和5伏），I2C總線的工作情況I2C總線的規範中規定了如何在兩個設備之間傳遞數據，採取的方法是總線仲裁、時鐘同步和總線的電氣特徵。在一次數據傳輸中，一個設備扮演臨時主控器，開始在它和一個有單一地址設備（從控器）之間的傳輸。主控器爲數據傳輸產生時鐘信號。規範中要求數據線（SDA，串行數據線）只有在時鐘（SCL，串行時鐘線）處於低平時才能變化。總線的一次典型工作流程如下：1．開始：信號表明傳輸開始。2．地址：主設備發送地址信息，包含7位的從設備地址和1位的指示位（表明讀或者寫，即數據流的方向）。3．數據：根據指示位，數據在主設備和從設備之間傳輸。數據一般以8位傳輸，最重要的位放在前面；具體能傳輸多少量的數據並沒有限制。接收器上用一位的ACK（回答信號）表明每一個字節都收到了。傳輸可以被終止和從新開始。4．停止：信號結束傳輸。I2C的仲裁在向那些只有一個主設備（典型的是主微控制器）的基本系統中不會有仲裁的。然而，更多的複雜系統能夠有多個主控設備，因此，就有必要用某種形式的仲裁來避免總線衝突和數據丟失。通過用線與（開路基極）連接I2C總線的兩路信號（數據和時鐘）可以實現仲裁。所有的主設備必須監視I2C的數據和時鐘線，如果主設備發現已經有傳輸正在進行，它就不會開始傳輸了。有很小的機率會產生一下情況：有兩個或更多的設備同時發出“開始”信號。在這種情況下，相互競爭的設備自動使它們的時鐘保持同步，然後像平常一樣繼續發射信號。第一個檢測到自己發送的數據和總線上的數據不匹配的設備要失去仲裁能力。這種情況會在這時發生：當前述設備發送一個高電平時，而同時另一個主控設備也正在發送一個低電平。也許直到相互競爭的設備已經傳輸了許多字節後，仲裁纔會完成。因爲沒有數據丟失，仲裁處理是不需要一種特殊的仲裁相位的。獲得主控權的設備從本質上來說，是不知道它爲了總線而和其它設備競爭的。在一個以硬件爲基礎的I2C中，有關發送、同步和仲裁的細節是自動處理的，不用你操心。如果你計劃實現一個軟件驅動的多主控I2C接口，那你需要研究I2C詳細規範（study
the I2C specification in detail），並懂得其細微差別， 5、待機電流、底電流。 通常在測待機電流出現異常時，要先打開某個功能，然後離開，等待手機進入待機狀態，然後再測試待機電流。比如開機->進入待機->打開照相機->關閉照相機->待機->測待機電流要一個功能一個功能去驗證，看看是否因爲沒有真正關閉某個功能而導致待機電流很大 有一個基站的參數是BS_PA,它的設定值爲2到9，設爲X；一個單位週期爲一個復幀，51*5000*12/13=0.235S每 X*0.235 手機將會醒過來，與基站同步。還有一點很重要，X的不同，測出來的待機電流相差也很大的。
那是不是說如果PR爲2的話，那麼手機每0.47S與基站同步一次，也就是0.47秒搜網一次吧。比較我以前測的數據。推測聯通是paging 2，移動是paging 8實際測聯通卡的搜網間隔是470mS，測移動卡的搜網間隔是1.89秒，算出來的是0.235*2=0.47S，0.235*8=1.88S都非常吻合，現在明白了，謝謝！ 經常碰到這種波形，往往是鬧鐘啊，記事本呀等等定時啓動。與基站聯絡時的波形爲週期性2A脈衝的波形，前面已經提到週期的計算方法不累訴。叫MMI的查查，很容易的，先關掉與RTC有關的模塊，往往就正常了。
正常的情況下，很多RF模塊大概1秒鐘和基站通信一次，所以一秒鐘會有個高脈衝，至於連續10秒的脈衝，這是對應的RF模塊有關，一個穩定的RF模塊是沒有這個情況出現的，你可以測試一下其他平臺，手機RF部分最小電流一般有1mA，平均下來差不多3mA，當然這和不同的手機RF模塊有關 我從軟件來簡單分析下待機電流問題：1、所謂待機電流就是ｂｂ ｃｐｕ主動降低ｃｐｕ運行時鐘，如果原來高速運行是26Ｍ的話，那麼在待機的情況下 可能就是幾ｋ，這樣，整個系統ｉｏ都關閉，系統只是非常慢的處理一些待機程序。2、有人說到卡不同，待機電流不同，這是由於手機軟件在待機的情況下，要每隔段時間搜索網絡，如果網絡信號好的話， 搜索快，電流就小，如果網絡信號不好，就慢，同時耗電流就大。4、所謂的搜網間隔時間，在手機系統中一般是比較固定的，因爲對整個系統的時間片要求比較嚴格。3、地域不同引起的電流不同同2一樣，與網絡信號有關。
6、BB和LCDC的通信。16位通過發命令和數據通信。 I80總線即80總線。 7、sensor的數據格式YUV和RAW data RGB的區別。 解釋一： RGB是三基色，一般每個象素點用24表示，RGB個佔8位。YUV中Y爲亮度分量，UV爲色度分量，YUV有好幾種格式，相比RGB，YUV可以減少數據量。對於黑白電視，只需要使用Y分量即可，因而YUV可以兼容黑店電視。 RGB和YUV都是色彩空間，用於表示顏色，兩者可以相互轉化．至於電視採用YUV分量形式是由ITU（國際電信聯盟）規定的，因爲其能減少數據儲存空間和數據傳輸帶寬，同時又能非常方便的兼容黑白電視！
首先,200萬象素的sensor,就是有2M個pixel; YUV是電視傳輸用的名詞,一個亮度信號（Y），兩個色差信號（U分量、V分量） YUV （亦稱YCrCb）是被歐洲電視系統所採用的一種顏色編碼方法（屬於PAL）。YUV主要用於優化彩色視頻信號的傳輸，使其向後兼容老式黑白電視。與 RGB視頻信號傳輸相比，它最大的優點在於只需佔用極少的帶寬（RGB要求三個獨立的視頻信號同時傳輸）。其中“Y”表示明亮度（Luminance或 Luma），也就是灰階值；而“U”和“V”表示的則是色度（Chrominance或Chroma），作用是描述影像色彩及飽和度，用於指定像素的顏
色。“亮度”是通過RGB輸入信號來創建的，方法是將RGB信號的特定部分疊加到一起。“色度”則定義了顏色的兩個方面—色調與飽和度，分別用Cr和CB 來表示。其中，Cr反映了GB輸入信號紅色部分與RGB信號亮度值之間的差異。而CB反映的是RGB輸入信號藍色部分與RGB信號亮度值之同的差異。 在現代彩色電視系統中，通常採用三管彩色攝像機或彩色CCD（點耦合器件）攝像機，它把攝得的彩色圖像信號，經分色、分別放大校正得到RGB，再經過矩陣 變換電路得到亮度信號Y和兩個色差信號R-Y、B-Y，最後發送端將亮度和色差三個信號分別進行編碼，用同一信道發送出去。這就是我們常用的YUV色彩空
間。 YUV (YCrCb)和4:2:2, 4:1:1, 4:2:0 是指亮度信號Y和紅/藍色差信號的抽樣格 式. 在dv中, ntsc是4:1:1, pal採用4:2:0. 注意, 4:2:0並非藍色差信號採樣爲0,而是和4:1:1相比,在水平方向上提高1倍色差採樣頻率,在垂直方向上以Cr/Cb間隔的方式減小一半色差採樣. RGB色彩模式是工業界的一種顏色標準，是通過對紅(R)、綠(G)、藍(B)三個顏色通道的變化以及它們相互之間的疊加來得到各式各樣的顏色的，RGB 即是代表紅、綠、藍三個通道的顏色，這個標準幾乎包括了人類視力所能感知的所有顏色，是目前運用最廣的顏色系統之一。 而與我們電腦相關的地方，就是目前的顯示器大都是採用了RGB顏色標準，這就是爲什麼它對我們來說這麼重要了。 在顯示器上，是通過電子槍打在屏幕的紅、綠、藍三色發光極上來產生色彩的，目前的電腦一般都能顯示32位顏色，約有一百萬種以上的顏色。如果說它所顯示的顏色還不能完全吻合自然界中的某種色彩的話，那已經幾乎是我們肉眼所不能分辯出來的了。
RGB是從顏色發光的原理來設計定的，通俗點說它的顏色混合方式就好象有紅、綠、藍三盞燈，當它們的光相互疊合的時候，色彩相混，而亮度卻等於兩者亮度之總和（兩盞燈的亮度嘛！），越混合亮度越高，即加法混合。 有色光可被無色光沖淡並變亮。如藍色光與白光相遇，結果是產生更加明亮的淺藍色光。知道它的混合原理後，在軟件中設定顏色就容易理解了. 紅、綠、藍三盞燈的疊加情況，中心三色最亮的疊加區爲白色，加法混合的特點：越疊加越明亮。 紅、綠、藍三個顏色通道每種色各分爲255階亮度，在0時“燈”最弱——是關掉的，而在255時“燈”最亮。當三色數值相同時爲無色彩的灰度色，而三色都爲255時爲最亮的白色，都爲0時爲黑色。
解釋二： YUV和RGB是兩種不同的顏色空間。一般來說，用YUV的話，可以節省存儲空間，且對視頻編解碼有利。不過LCD直接接收的格式基本都是RGB的，在DSP或者類似控制器裏面有專門的YUV到RGB的轉換電路。 解釋三：RGB是由ＹＵＶ進行矩陣計算得到的，其效果要比Ｓ端子和ＣＶＢＳ好很多．是目前電腦顯示器上主要用的視頻接口（ＶＧＡ），但畢竟還是模擬信號，所以以後 的主流都是ＴＭＤＳ（最小差分信號傳輸）信號的ＤＶＩ接口和ＨＤＭＩ接口．畢竟數字纔是未來嗎，呵呵．．．而這些接口之間有些是可以很輕鬆的進行轉換的，
所以使用的時候我們根據需要可以進行必要的改進． 解釋四：RGB三基色信號，YUV是色差信號。/fF:fK;h_X 如果是攝像機輸出，RGB三基色信號可以比YUV色差信號清晰度高，UV信號一般經過壓縮。‑s*B"N;S p5t nKIg如果是衛星機輸出，RGB三基色信號和YUV色差信號清晰度一樣，只是信號方式不一樣。 解釋五：RGB 顏色模式 雖然可見光的波長有一定的範圍，但我們在處理顏色時並不需要將每一種波長的顏色都單獨表示。因爲自然界中所有的顏色都可以用紅、綠、藍（RGB）這三 種顏色波長的不同強度組合而得，這就是人們常說的三原色原理。因此，這三種光常被人們稱爲三基色或三原色。有時候我們亦稱這三種基色爲添加色
（Additive Colors），這是因爲當我們把不同光的波長加到一起的時候，得到的將會是更加明亮的顏色。把三種基色交互重疊，就產生了次混合色：青（Cyan）、洋 紅（Magenta）、黃（Yellow）。這同時也引出了互補色（Complement Colors）的概念。基色和次混合色是彼此的互補色，即彼此之間最不一樣的顏色。例如青色由藍色和綠色構成，而紅色是缺少的一種顏色，因此青色和紅色構 成了彼此的互補色。在數字視頻中，對 RGB 三基色各進行 8 位編碼就構成了大約16.7萬種顏色，這就是我們常說的真彩色。順便提一句，電視機和計算機的監視器都是基於
RGB 顏色模式來創建其顏色的； Lab 顏色模式 Lab 顏色是由 RGB 三基色轉換而來的，它是由 RGB 模式轉換爲 HSB 模式和 CMYK 模式的橋樑。該顏色模式由一個發光率（Luminance）和兩個顏色（a,b）軸組成。它由顏色軸所構成的平面上的環形線來表示顏色的變化，其中徑向表 示色飽和度的變化，自內向外，飽和度逐漸增高；圓周方向表示色調的變化，每個圓周形成一個色環；而不同的發光率表示不同的亮度並對應不同環形顏色變化線。 它是一種具有“獨立於設備”的顏色模式，即不論使用任何一種監視器或者打印機，Lab
的顏色不變。 HSB 顏色模式 從心理學的角度來看，顏色有三個要素：色澤（Hue）、飽和度（Saturation）和亮度（Brightness）。HSB 顏色模式便是基於人對顏色的心理感受的一種顏色模式。它是由 RGB 三基色轉換爲 Lab 模式，再在Lab 模式的基礎上考慮了人對顏色的心理感受這一因素而轉換成的。因此這種顏色模式比較符合人的視覺感受，讓人覺得更加直觀一些。它可由底與底對接的兩個圓錐體 立體模型來表示，其中軸向表示亮度，自上而下由白變黑；徑向表示色飽和度，自內向外逐漸變高；而圓周方向，則表示色調的變化，形成色環。
YUV 顏色模式 這是電視系統中常用的顏色模式，即電視中所謂的分量（Component）信號。該模式由一個亮度信號 Y 和兩個色差信號 U、V 組成。它是利用了人眼對亮度信號敏感而對色度信號相對不敏感的特點，將 RGB 顏色通過亮度信號公式Y=039R＋050G＋011B轉換爲一個亮度信號 Y 和兩個色差分量信號 U（R－Y）、V（B－Y），即對色差信號進行了頻帶壓縮。毫無疑問，這是以犧牲信號的質量爲代價的。 CMYK 顏色模式 這是彩色印刷使用的一種顏色模式。它由青（Cyan）、洋紅（Magenta）、黃（Yellow）和黑（Black）四種顏色組成。其中黑色之所以
用 K 來表示，是爲避免和 RGB 三基色中的藍色（Blue，用B表示）發生混淆。該種模式的創建基礎和 RGB 不同，它不是靠增加光線，而是靠減去光線，因爲和監視器或者電視機不同的是，打印紙不能創建光源，它不會發射光線，只能吸收和反射光線。因此通過對上述四 種顏色的組合，便可以產生可見光譜中的絕大部分顏色了 解釋六：在Camera Sensor中，最常用的YUV模型是 YUV422格式，因爲它採用4個字節描述兩個像素，能和RGB565模型比較好的兼容。有利於Camera Sensor和Camera controller的軟硬件接口設計。
解釋七：http://dearymz.blog.163.com/blog/static/2056574200741774122887/自然界的顏色千變 萬化，爲了給顏色一個量化的衡量標準，就需要建立色彩空間模型來描述各種各樣的顏色，由於人對色彩的感知是一個複雜的生理和心理聯合作用的過程，所以在不同的應用領域中爲了更好更準確的滿足各自的需求，就出現了各種各樣的色彩空間模型來量化的描述顏色。我們比較常接觸到的就包括 RGB /CMYK / YIQ / YUV / HSI等等。 對於數字電子多媒體領域來說，我們經常接觸到的色彩空間的概念，主要是RGB
,YUV這兩種（實際上，這兩種體系包含了許多種具體的顏色表達方式和模型，如sRGB,Adobe RGB, YUV422, YUV420 …）, RGB是按三基色加光系統的原理來描述顏色，而YUV則是按照 亮度，色差的原理來描述顏色。 即使只是RGB YUV這兩大類色彩空間，所涉及到的知識也是十分豐富複雜的，自知不具備足夠的相關專業知識，所以本文主要針對工程領域的應用及算法進行討論。而在Camera Sensor中，最常用的YUV模型是 YUV422格式，因爲它採用4個字節描述兩個像素，能和RGB565模型比較好的兼容。有利於Camera
Sensor和Camera controller的軟硬件接口設計。 進一步分析，我們可以看到，因爲在手機等嵌入式運用上我們最終是要把數據轉換成RGB565格式送到LCD屏上顯示的，所以，對於RGB三分量來說，我們根本不需要8bit這麼高的精度，爲了簡單和運算的統一起見，對每個分量我們其實只需要高6bit的數據就足夠了，所以我們可以進一步把表格改爲4個6*6的二維表格，這樣一共只需要佔用16K內存！在計算表格元素值的時候還可以把最終的溢出判斷也事先做完。最後的算法如下： y = (YUVdata[Y1POS]
>> 2); u = (YUVdata[UPOS] >> 2); v = (YUVdata[VPOS] >> 2); r = yv2r_table[ y ][ v ]; g = yig2g_table[ y ][ uv2ig_table[ u][ v ] ]; b = yu2b_table[ y ][ u ]; RGBdata[1] =( (r & 0xF8) |( g >> 5) ); RGBdata[0] =( ((g & 0x1C)<< 3) | ( b >> 3) ); 這樣相對部分查表法，我們增加了3次移位運算，而進一步減少了4次加法運算和6次比較賦值操作。
在計算表格元素數值的時候，要考慮舍入和偏移等因數使得計算的中間結果滿足數組下標非負的要求，需要一定的技巧。 採用完全查表法，相對於第一種算法，最終運算速度可以有比較明顯的提高，具體性能能提高多少，要看所在平臺的CPU運算速度和內存存取速度的相對比例。內存存取速度越快，用查表法帶來的性能改善越明顯。在我的PC上測試的結果性能大約能提高35%。而在某ARM平臺上測試只提高了約15%。3.4 進一步的思考 實際上，上述算法： RGBdata[1]=( (r & 0xF8) | ( g >> 5) ); RGBdata[0]
=( ((g & 0x1C)<< 3) | ( b >> 3) ); 中的 (r & 0xF8) 和 ( b >> 3) 等運算也完全可以在表格中事先計算出來。另外，YU / YV的取值實際上不可能覆蓋滿6*6的範圍，中間有些點是永遠取不到的無輸入，RB的運算也可以考慮用5*5的表格。這些都可能進一步提高運算的速度，減小表格的尺寸。 另外，在嵌入式運用中，如果可能儘量將表格放在高速內存如SRAM中應該比放在SDRAM中更加能發揮查表法的優勢。4 RGB2YUV ? 目前覺得這個是沒法將3維表格的查表運算化簡爲2維表格的查表運算了。只能用部分查表法替代其中的乘法運算。
另外，多數情況下，我們需要的還是YUV2RGB的轉換，因爲從Sensor得到的數據通常我們會用YUV數據，此外JPG和MPEG實際上也是基於YUV格式編碼的，所以要顯示解碼後的數據需要的也是YUV2RGB的運算。
