基於TCP協議的網路攝像頭的設計與實現

基於tcp協議的網路攝像頭的設計與實現

基於tcp協議的網路攝像頭的設計大部分和博文「基於udp協議的網路攝像頭的設計與實現」相同，本篇博文採用的tcp協議棧為nichestack協議棧（同理，可使用lwip協議棧實現），協議分析及上位機設計可參考博文「基於nichestack協議棧的網路例程分析及客戶端程式設計」。

二、實驗平台

硬體平台：diy_de2

軟體平台：quartus ii 9.0 + nios ii 9.0 + visual studio 2010

該部分可參考博文「基於udp協議的網路攝像頭的設計與實現」。

該篇博文介紹的重點是底層軟體（nios ii端）和上位機程式的設計，底層和上位機的通訊流程圖如下圖所示。

圖 1 底層和pc之間的通訊流程圖

以上是系統的整體流程圖，下面對一些關鍵的除錯過程做個闡述。

根據「基於udp協議的網路攝像頭的設計與實現」裡面的除錯經驗，對系統進行除錯。

首先，在c#端，重寫buffer，驗證c#顯示控制項的正常。除錯如圖2所示。

圖2 c#控制項顯示調試圖

底層的傳送資料報長度為1500，tcp資料報的包頭長度為54，所以一包資料可以顯示(1500-54)/2=723個畫素，在控制項顯示2行83個畫素。在控制項的頂端細節部分可以看到。

其次，在nios ii寫待傳送的資料，傳送到c#端，驗證顯示正常。這裡採用tcp的拉模式。即c#端手動傳送一次命令，底層傳送上來一包資料，這樣手動傳送107次命令之後，c#控制項可以顯示出底層傳送上來的一幀既定色彩的影象，如圖3所示。

圖3 底層傳送的既定色彩影象

再次，在驗證上述2個步驟的基礎上，新增讀取sram資料，即將獲取的影象傳輸上來，並在c#中新增自動傳送命令功能，則可以在c#端連續收到影象資料，如圖4所示。

圖4 影象效果圖

按照1中的步驟可以將影象顯示出來，只是速度很低，約30s顯示出一幀影象，網路傳輸速度約為10kb/s。之前傳輸慢的原因是，網路傳輸採用的是拉模式，即c#發一次命令，底層傳輸一包資料，這樣一幀影象要107次命令，可見效率極低。另外c#端的程式也有造成速度慢的原因。

改進1：c#端刪除掉不必要的內容，接收及繪圖部分單獨開了乙個執行緒。**如下：

private
void
telnetthread()
//else
//                    //}
thread.sleep(100
);                }
catch
(exception e)
}this.sbpstatus.text = "
狀態：已斷開";
}

這個改進大大提高了c#端的資料接收速度，也解除了不能用for迴圈連續傳送資料報的問題。另外，c#端每收到一幀影象資料後，自動傳送一次命令，使底層繼續傳輸下一幀影象。

改進2：底層部分，每傳送一包資料，將傳送指標指向傳送陣列的首位址，**如下：

for(j = 0; j < 107; j++)
//寫滿傳送陣列之後，將其傳送出去
send(conn->fd, tx_buf, tx_wr_pos - tx_buf, 0
);  
printf(
"nios working\n
"); 
}

改進3：底層部分，pio中斷，每次進入pio中斷後，先將中斷標誌位清零，可是在沒有中斷源的情況下，系統還是頻頻進入中斷服務函式，不知何解？無奈之舉是，進入中斷服務函式之後，直接關閉中斷使能並將中斷標誌位清零，等uc/os ii端將影象資料完全傳輸出去之後，再開啟中斷使能。另外，uc/os ii系統啟動之前，不能開啟中斷使能，所以在初始化的時候應將pio中斷使能禁止，當收到客戶端的命令時，再開啟中斷使能。該部分的操作流程見圖1。

通過上述3個方面的改進，傳輸速度大大提高了，約100kb/s，這樣，顯示一幀影象不到3s，顯示效果也比較清晰。

根據上述幾篇博文的闡述，分別完成了基於udp和tcp傳輸協議的網路攝像頭的設計與實現，博文重點分析了除錯過程，即發現問題、解決問題的過程。博文論證了設計原理的正確性，同時，網路傳輸的速度也得到了測試，不過仍有許多改進和提高的地方，比如在傳輸的同時，寫下一幀影象。

基於TCP協議的網路攝像頭的設計與實現

基於TCP協議的網路攝像頭的設計與實現

基於UDP協議的網路攝像頭的設計與實現

基於Video4Linux的攝像頭驅動設計

基於TCP協議的網路攝像頭的設計與實現

基於TCP協議的網路攝像頭的設計與實現

基於UDP協議的網路攝像頭的設計與實現

基於Video4Linux的攝像頭驅動設計

相關推薦