無線圖像傳輸系統(tǒng)ARM9+Atmega16+OV7620+

作者：時間：2012-09-25 來源：網(wǎng)絡(luò)

加入技術(shù)交流群
- 掃碼加入
  和技術(shù)大咖面對面交流
  海量資料庫查詢

下面就介紹下nrf24l01的寄存器配置問題。這里我采用了增強(qiáng)型ShockBurst模式，具有自動前導(dǎo)碼生成、CRC校驗，并配置為自動應(yīng)答ACK，這樣的好處是可以減輕MCU的負(fù)擔(dān)，減少開發(fā)難度。目前還沒有實現(xiàn)組網(wǎng)，所以只用了其中的一個通道0，為了更簡單的傳輸，把發(fā)送端和接收端的地址都設(shè)為同一個。需要注意的就是在啟動發(fā)送和接收時的延時問題，以及發(fā)送完和接收完緩存的清除。在其Datasheet上標(biāo)注的很清楚，在進(jìn)入發(fā)射模式，CE置高的持續(xù)時間至少是10us，而在進(jìn)入接收模式，CE置高后160us后才會檢測空中信號。所以，在編程時要多加注意。我覺得主要的還是發(fā)送和接收緩存的清除問題，因為我開始時在發(fā)送語句的下一句就寫了清除發(fā)送緩存的語句，結(jié)果。。。一看便知，接收一個數(shù)據(jù)包后戛然而止。這里的延時也影響整個圖像數(shù)據(jù)發(fā)送的時長，我在程序中的延時是0.2ms，所以在發(fā)送所有數(shù)據(jù)時的總延時一算便知，(320*240/32)*0.2ms=480ms,而在ARM端的驅(qū)動中使用時鐘滴答數(shù)jiffies記錄了兩個中斷(接收100個數(shù)據(jù)包，也就是中端了100次，為了方便顯示，100次打印一次)到來時的時刻，差值為50ms左右，這樣可以算出一幀圖像傳輸?shù)臅r間為24*50ms=1.2s，如果再減去采集端發(fā)送延時等待的時間便可算出一幀圖像數(shù)據(jù)實際的空中傳輸時間為720ms，所以在最理想的情況下可以達(dá)到1幀/s的傳輸速率——這個速率對于我這個項目來說還算可以(后面希望優(yōu)化得到2幀/s)?？纯磏rf24l01的數(shù)據(jù)手冊，它支持兩種傳輸速率1M和2M，按照理論一幀圖像320*240=76800，傳輸?shù)臅r間應(yīng)為76.8ms，差距還是蠻大的(一個數(shù)量級啊)。

在采集板上還有一個比較重要的部分，那就是DRAM FIFO模塊——攝像頭采集速率太快，而且數(shù)據(jù)量又太大，要是直接傳給弱不禁風(fēng)的單片機(jī)，不知道最后能得到幾個數(shù)據(jù)——有待驗證，呵呵。所以需要有一個高速緩存(沖)器來解決這個問題，本次采用的是AL422B(別人好像也都是這么用的，Why)，3Mbit容量——對本次應(yīng)用來說足矣。AL422B操作很簡單，要特別注意的也就是讀寫的時序、讀寫reset、讀寫使能位的控制。寫端/WE由OV7620的HREF和MCU的一個引腳PD4通過與非門控制,而讀端直接接地，隨時可以讀取，而其寫時序是由OV7620的PCLK引腳提供時鐘，這樣就可以保證每個像素值都可以按照順序?qū)懭搿．?dāng)OV7620的VSYNC引腳拉高時表明已經(jīng)開始采集一幀圖像，MCU判斷到此值后拉高PD4，之后HREF也會被拉高，這樣AL422B的寫使能已經(jīng)有效，在PCLK的時鐘下源源不斷的寫入數(shù)據(jù)。下面貼出本段相關(guān)的代碼：

/**************************************/

while( !( PIND (1

PORTD |=(1

enable_int0(); //檢測到下降沿表明，一幀圖像采集完畢，采用中斷方式停止數(shù)據(jù)寫入

delay_ms(20);

/*****************IRQ ISP****************/

#pragma interrupt_handler int0_isr:iv_INT0

void int0_isr(void)

{

PORTD =~(1

dISAble_int0();

}