想法產生：
我想寫一寫自己對調攝像頭時的的一點小心得，剛開始調攝像頭時候，就對pit定時和攝像頭的場中斷了解的不太清楚，似乎發現有問題但不知道是什麼。比如把處理影象的程式是放在主函式裡好呢，還是放在
pit中好呢，場中斷和
pit讓誰的優先順序更高一點好呢，場中斷時間和我自己程式執行的時間都是多少呢？
校內賽過後，從郭兆裕學長**學到可以利用改變乙個引腳的高低電平和利用示波器來測量出來時間。這是很好的想法。
想法探索
東北賽過後，在硬體已經沒有多大變動的時候，我又重新開始想這個問題，我那時候的程式是借鑑以前學長的那種pit和場中斷都有的那種。我首先想到的是把pit時間從
30ms
縮小到20ms，本以為控制頻率增加了肯定會對車有好處，但結果是車子跑的更差了。於是我用示波器測量乙個微控制器的引腳，這個引腳在場中斷服務函式開始時候為高電平結束時為低電平，示波器的顯示結果是影象上有許多尖尖的脈衝
，乙個尖尖的脈衝即為一次場中斷，因為場中斷服務函式作用就是開啟dma，所以持續時間並不長。但是這些尖尖的脈衝週期並不一致，有的是
16ms
來一次，有的是16的二倍
32ms來一次。
我比較了pit時間從
10ms
到30ms
時間裡所有的情況，發現
pit時間越長
16ms
的尖尖的脈衝越多，證明固定時間內場中斷的次數越多。分析原因是：攝像頭的場中斷優先順序並沒有ｐｉｔ高因此在執行ｐｉｔ中斷時來的場中斷並不會被響應，若縮短ｐｉｔ時間會導致固定時間內有效場中斷次數減少，即處理新影象次數減少，致使車跑的並不好。
那你可能會想把場中斷設成優先順序比pit高的不就行了嗎。但是也會有問題，因為在處理場中斷服務函式時候，
pit來了不會執行，會導致
pit定時不准。
然而ｐｉｔ裡有採集編碼器的返回值的量，這個量需要固定時間返回才有意義
，所以這種方法也是不可取的。
8ms攝像頭就採集完一幀影象了；攝像頭把影象傳給微控制器需要
8ms多一點點
，因此微控制器採集影象的時序是這樣的：來場中斷，經過8ms多一點影象傳給微控制器，此時已經略過下一次場中斷了，需要再等一次場中斷才能進行下一次傳輸影象。因此採集一次影象的最短週期是
16ms
（兩次場中斷的時間）。也就是說每兩次場中斷利用一次影象控制一次效率是最高的。
我們現在就可以想出來優化的時序是什麼樣子的了。如下圖：
這樣就可以完全實現一次採集影象一次控制，若自己寫的程式時間較長，往後延長至三個場中斷一次採集一次控制。時間為24ms，以此類推。
實現方法
注意：不用pit中斷。
（2）設定
pit中斷高於場中斷，把
pit時間調成很小，小於所要執行函式的時間，它會把自己的程式執行完後馬上進入下一次中斷，（相當於在主函式裡
while（1
））。注意：ｐｉｔ時間要小。
重要的事最後說：
我所使用的場中斷時間、傳輸時間
基於ｋｌ２６晶元和鷹眼攝像頭
，你需要根據自己的實際情況來確定自己的時間，比如ｋ６０的執行速度比ｋｌ２６快，而且鷹眼的場中斷時間也可以自己配置；我介紹的事一種處理場中斷和ｐｉｔ中斷時序的方法
，要具體情況具體分析。
基於mini2440的ov9650攝像頭裸機測試
ov9650暫存器在模組的內部，s3c2440是以sccb匯流排來與ov9650通訊。sccb匯流排類似iic匯流排，而且mini2440攝像頭介面的sccb匯流排就接在了他的iic介面上，所以可以通過iic來配置ov9650的暫存器，同樣也可以用gpio來模擬sccb匯流排的時序。ov9650有大...
ov5640攝像頭驅動的開發過程
對於在linux 下ov5640 攝像頭驅動開發的過程。硬體連線電路設計 1 omap4 通過 csi2 介面連線 ov5640 感測器 mipi 標準 使用三組差分信 號，其中一組差分傳送時鐘，另兩組差分傳送資料訊號。一組差分訊號的傳輸速 度最大可以達到 1gpbs。電路原理圖mipi csi2匯...
基於mini2440的ov9650攝像頭裸機測試
ov9650暫存器在模組的內部，s3c2440是以sccb匯流排來與ov9650通訊。sccb匯流排類似iic匯流排，而且mini2440攝像頭介面的sccb匯流排就接在了他的iic介面上，所以可以通過iic來配置ov9650的暫存器，同樣也可以用gpio來模擬sccb匯流排的時序。ov9650有大...