Design and Implementation of UDP-based network cameras in the process of solving key problems and debugging UDP-Based Network Cameras

I. Summary

This blog post focuses on"Design and Implementation of UDP-based network cameras "describes problems encountered during debugging and describes the solution process.

 

Ii. Experimental Platform

Hardware Platform: diy_de2

Software Platform: Quartus II 9.0 + NiO II 9.0 + Visual Studio 2008

 

Iii. experiment content

The VGA display is used as a reference for comprehensive debugging to make the C # Video Display normal. The display resolution of the C # control is 320*240.

1. Initial Image

Figure 1 initial image

Is the initial establishment of the Network CameraOfDisplay Effect: Observe the video image, which has the following features:

(1) Half of the colors are not fully displayed;

(2) The displayed part is italic and serticate;

(3) The display resolution is reduced to 160*120, the same as (1 );

(4) the starting position of the displayed image is not the beginning of the frame image, that is, the image is misplaced.

2. Solve the Problem of image dislocation

The solution is roughly as follows:

(1) first, ensure that the Quartus II ends remain unchanged, and assign a fixed value to the transmitted array instead of reading the video data cached in the SRAM, then the C # end should display a monochrome image. TheCodeThe result of C # is as follows.

Test code of the niosii client:

 

For(J =0; J <76800; J ++){//A [J] = Iord (sram_16bit_512k_0_base, J );//B [J] = Iord (sram_16bit_512k_0_base, j)> 8;A [J]=0xff; B [J]=0x03;}
 

 

 

Figure 2 C # display monochrome image 1

The above images can verify that UDP transmission is correct and C # is displayed.ProgramCorrect.

(2) on the basis of ensuring normal transmission of the niosii, that is, the specific data is directly set in the pressus II compression subroutine press_moudle module, observe the C # terminal display effect, as shown in figure 3.

 

Figure 3 C # display a monochrome image 2

This image is similar to Figure 1, that is, half of the colors are incorrectly displayed (because it is a monochrome image, other features are not easy to see ). According to the comparison in figure 2 and Figure 3, we can see that there is a problem in reading and writing the image data. Is it about reading SRAM or writing SRAM?

(3) Write specific data to the sram on the nioii end, read the data, and transmit the data to the PC through the network. The PC end is displayed in C #. Through this test, it can be found that there is no problem with reading the sram on the nioii end. Therefore, the problem can be identified as writing the SRAM.

(4) The problem of image Dislocation can be located as follows: when writing image data to SRAM, the current data is not the beginning of a frame image, that is, the conditions for writing image data are incorrect. To properly lock the frame start signal and use the state machine function, the key code is as follows:

 

 Always @( Posedge Iclk Or   Negedge  Rst_n)  Begin      If (! Rst_n) test_out <= 0  ;  Else     Begin          If (Niosii_cmd) & (oval_vs = 2  '  B01 ))          Begin  Test_out <= ~ Test_out;  //  If (test_out)  //  Rgb_zuhe <= rgb_zuhe + 1;          End  //  Else //  Test_out <= 0;      End  End  Always @( Posedge Iclk Or   Negedge  Rst_n)  Begin      If (! Rst_n)  Begin  //  Oaddress <= 0; Rd_en <=0  ; Rgb_zuhe <= 0  ;  End      Else      Begin          Case  (Test_out)  0  :  Begin  Oaddress <= 0  ; Rd_en <= 0 ; Rgb_zuhe <= 0  ;  End          1  :  Begin              If (Vga_x_count [ 0 ] & Vga_y_count [ 0 ] & Oval_hs)  Begin  //  Rgb_zuhe <= (rgb_zuhe + 1) % 32; Rgb_zuhe <= { 1  '  B0, IR [9: 5], Ig [9: 5], IB [9: 5]}; Oaddress <= oaddress + 2  ;  If (Oaddress = 18  '  H257fe)                  Begin  Rd_en <= 1  ; Oaddress <=0  ;  End              End              Else  Rd_en <= 0  ;  End          Endcase      End  End 

Because of the reversal of test_out, this is actually the result of capturing a frame at every frame.

After the state machine is used, the image dislocation is solved, as shown in figure 4.

 

Figure 4 Display Effect of image dislocation

3. fixed the problem of reduced display resolution.

In the compression subroutine press_moudle of Quartus II, set the image data to + 1 incremental data. In Wireshark, the packet capture tool, the received data can be seen, the data increases progressively in the form of + 2, so we can conclude that there is a problem during storage.

At the beginning, I thought that the data was stored at a separate address during the storage of the SRAM, And then I analyzed it. Actually, it would not. The reason is that when you read data cached in the SRAM by niosii, it is read from one address, and the read data is indeed in the relationship of + 2. Note: in actual writing, the address is written one by one, but the write controller is faulty.

After reading the relevant information, when the 16-Bit Memory corresponds to the CPU, the address line should be shifted to the left. In the system's top-level file, the address line is not moved left. Therefore, the resolution is reduced by 1/4 again. The solution is to store data in the SRAM address line + 2 at a time (which is already reflected in step 1 code ). The result 5 is displayed.

 

Figure 5 effect of resolution reduction after debugging

4. Solve the Problem of image skew

(1) I started to think that there was a problem with the C # side drawing part. After the C # side writes the buffer data for display, and carefully analyzes the display effect, it is determined that there is no problem with the drawing. The following is the analysis process. Analysis is performed in ascending order of a single color.

C # Write the buffer test code:

 

For(IntM =0; M <num; m ++){If(M %2=0) Buffer [m]=0;ElseBuffer [m]= (Byte) (M-1)*2) %128);}
 

 

Through C # debugging, we can know that num is 1468, that is, 734 pixels. The resolution is calculated by 320*240. Two lines of 94 pixels can be drawn for a pack of data, screenshot details (the upper left of Figure 5), as shown in figure 6.

 

 

Figure 6 C # client Test details

From the figure, we can see that the first packet of data just draws two lines of 94 pixels, and the starting part of the three rows are correctly matched, that is, they all start from pure black, it indicates that image skew is not caused by C.

(2) The niosii test also uses a monochrome incremental method for verification. By analyzing 94 pixels in the first two rows and the subsequent pixels, 95th and 96 pixels are found to be non-pure black, the first 97th pixels are pure black. This indicates that 95 and 96 pixels are other values, not the expected pixel values.

(3) After careful analysis, we find that the last two pixels, that is, four bytes, are the checkpoint of a packet of data. The maximum value for sending a packet of data from the nioshi side is 1510-42-4 = 1464. The first 42 bytes are headers, And the last 4 bytes are check bits. C # draws an image in 1468 bytes. Therefore, the effect of the image is that two pixels are misplaced at a time. Num-4 is required when drawing the image on the C # side. The displayed result after correction is 7.

 

Figure 7 Effect

5. Last Question

C # controls the underlying transmission of video data, that is, when C # receives video data, it starts with an image, rather than a packet of data in the middle. Otherwise, the image will still be misplaced. However, there are some problems in the implementation process. When the C # client sends the command, when the niosii obtains the command through the interrupt method, the following two possible problems may occur:

(1) first, the system sends data to the PC. The PC sends the command to the client. The client can correctly receive the command data, but when the client does not send the command, the niosii still enters the interrupted service function and receives empty commands or unknown redundant commands. Why is the PC automatically sending commands? The PC here is not C #.

(2) The PC-side command can only enter the interrupt service function of the niosii at most once, while the PC-side command waits for the PC command and the PC-side Command sends the command.

The essence of this problem is that the PC and dm9000a send data to each other. The dm9000a receives data sent from the PC in an interrupted way, but the dm9000a cannot normally receive data sent from the PC. The test has not worked well for a long time. Is it a problem with the dm9000a interrupt handling mechanism?

Given that neither of the above conditions is satisfactory, the system adopts another solution:

Before sending video data to the PC, niosii sends a packet of data that is all 0. Once C # first parses the package data, it enables a flag, when the flag is enabled, the image is drawn. This can solve the problem of PC-side image dislocation, but it is not the optimal solution. Because the first packet of data is 0, some colors are displayed on the top of the image. 8.

 

Figure 8 Final Display Effect

 

Iv. Experiment Summary

The transmission speed tested by Wireshark is 1 Mbps. That is to say, the frame rate of the UDP-Based Network Camera is about 1 frame, and the resolution is 320*240. Preliminary verification of the feasibility of the system. Since the video frame rate and resolution are too small, the next step will be to study CompressionAlgorithmAnd the implementation of TCP transmission protocol.