Most existing video surveillance system designs use USB video capture and Ethernet transmission, and require video compression solutions, which usually require operating system support; therefore, the selected development platform is expensive, resulting in high costs for video surveillance systems, making them difficult for small factories and home users to accept.

  This project uses the ARM7 development platform of the S3C44BO microprocessor to drive the USB interface chip CH374 for video data acquisition, providing a low-cost video acquisition solution. USB video acquisition involves USB synchronous transmission, but in the design of many USB host chips, most of them are mainly control transmission and batch transmission, and the explanation of synchronous transmission is extremely rare. This article provides a design example of USB synchronous transmission.

  1 System Working Principle

  A typical USB video acquisition system is shown in Figure 1. The USB system contains two basic elements: the host and the physical device. A USB system can only have one USB host and can connect multiple physical devices. The device in this design is a USB camera, and the USB host is composed of a USB host controller, a microprocessor, and driver software. The USB system has clear working levels: the USB interface layer provides the physical connection between the host controller and the device; in the device layer, the USB host calls the driver to send and obtain the control information of the USB device through endpoint 0; the functional layer performs actual data transmission, and the host must select the appropriate interface and endpoint, and call the interface function provided by the underlying driver to obtain the video data stream of the USB camera.

Typical USB video capture system

  1.1 USB Camera SPCA561A

  The video signal acquisition is usually realized by using a USB camera. As shown in Figure 2, the USB camera SPCA561A integrates a lens, a CMOS sensor, a USB image processor, and a USB controller. 

USB Camera SPCA561A

  
        Compared with CMOS sensors that interface directly with microprocessors, using USB cameras is more expensive, but it is easy to implement, saves CPU resources, and has rich driver support. SPCA561A provides a single-chip camera solution that integrates a CIF CMOS sensor, an image processor, and a USB controller into a single chip, greatly reducing costs and development difficulties; the disadvantage is that it only has 100,000 pixels and a low frame rate per second, but it is very suitable for small surveillance systems with low image requirements.

  1.2 USB host controller CH374

  CH374 is a universal interface chip for embedded USB bus, supporting USB host mode and USB device mode, and supporting low-speed and full-speed control transmission, bulk transmission, interrupt transmission and synchronous transmission. On the local side, CH374 has an 8-bit data bus and read, write, chip select control lines and interrupt output, which can be easily connected to the system bus of controllers such as DSP/MCU/MPU. Most embedded USB host interface chips do not provide synchronous transmission mode, but a major feature of CH374 is that it provides synchronous transmission, making the transmission of video and audio streams possible.

  This system uses CH374 as the USB host controller, as shown in Figure 3. CH374 is connected to S3C44B0 in bus mode, and the microcontroller implements USB host driver by reading and writing CH374 registers.

CH374 as USB host controller

  1.3 USB synchronous transmission principle

  Isochronous transmission is mainly used to transmit audio or video signals. This type of information is periodic and real-time, and has high requirements for information real-time, but can tolerate bit error rate. Therefore, USB reserves 90% of the bandwidth for this type of information, and other types of transmission cannot be occupied during isochronous transmission.

  To ensure the real-time nature of data transmission, synchronous transmission does not retransmit data errors, nor does it respond to a handshake packet at the hardware level. The host of synchronous transmission sends a SOF synchronization signal every 1 ms, and then receives the signal sent by the device. The data flow is shown in Figure 4.

Data flow

  In synchronous transmission, the capacity of each packet is certain. Take SPCA561 as an example. Before starting synchronous transmission, the corresponding interface number must be set. Different interface numbers determine the size of the packet to be sent. For example, the packet capacity of interface number 1 is 128 bytes each time, and the packet capacity of interface number 6 is 896 bytes. The interface number is set through the USB standard device request SET_INTERFACE. Since the maximum buffer of CH374 is 128 bytes, interface number 1 is used in this design, and the size of each packet received in synchronous transmission is a 128-byte packet.

  1.4 Video Data Collection Process

  As shown in Figure 5, the video signal is collected by the camera SPCA561A and encoded into a specified format after passing through the internal image processing chip, which is generally RGB or YUV format, but SPCA561 uses a relatively special S561 image format (similar to RGB format). Because the amount of data in a frame of image is very large and cannot be transmitted in a synchronous packet, it is divided into multiple units, and a header is added to each unit (the content of the header includes the current packet sequence number and the image frame information) to form multiple synchronous packets, which are sent to the USB bus through the FIFO buffer. The host controller receives each packet in a synchronous manner, removes the header and merges it into data in S561 format to form a complete image frame. Finally, the software pre-encodes this image frame into image data in YUV420 format for subsequent compression processing.

Video data collection process

  2 Implementation of USB camera driver

  USB cameras are not standard USB peripherals. Unlike other USB peripherals, each manufacturer's camera chip has its own defined device request, and these camera chip data sheets are not open to the public, so it is very difficult to write camera drivers. If you want to drive more cameras, the program will be very complicated. This article only introduces the method of driving the SPCA561A camera. [page]

  2.1 USB camera initialization

  There are two steps to initialize a USB camera. The first step is camera enumeration and the second step is camera customization.

  (1) Device enumeration

  Device enumeration is the process of standard device requests, which is included in Chapter 9 of the USB protocol. For a USB camera, the enumeration process is as follows:

  ① Get the device descriptor. Get the load of endpoint 0, that is, the maximum transmission packet capacity, through the device descriptor.

  ② Set the address. Assign an address other than the default address 0 to the device.

  ③ Get the configuration descriptor. This process includes two stages. The first 4 bytes of the configuration descriptor are used to get the real length of the configuration descriptor. Then the configuration descriptor is obtained for the second time with the real length. This descriptor contains the configuration information of the device and multiple interface information. From here, the available interface number and the corresponding packet load can be obtained.

  ④ Set configuration information. The main information to be set is the fifth field bConfigurationValue in the configuration descriptor.

  ⑤ Set the interface. Different interface numbers of USB cameras correspond to different packet loads. The interface number selected in this design is 2, and the corresponding packet load is 128 bytes.

  (2) Custom settings

  USB cameras are not standard USB peripherals and require many custom settings, which can be called "custom device requests". They are transmitted in the form of standard device request packets. The purpose is to modify internal registers and configure the acquisition image and compression method. The different contents of standard device request and custom device request packets are listed in Table 1. The content of custom device request is very rich, and it includes the following aspects:

  ① Timing generation settings, including image acquisition frequency and oscillator settings, etc.

  ② Image processing settings. Including image window size, compression type, color distribution and other configuration properties.

  ③Memory setting: Set the image buffer.

  ④Control and status settings. Including configuration properties such as starting and stopping image acquisition, data transmission method, current status, etc.

Different contents of standard device request and custom device request packets

  There are nearly 100 initialization settings in the program. For specific settings, please refer to the open source code in reference [1]. After the initialization is completed, the image format can be set as needed. SPCA561A supports four formats: SQVGA (160×120), QCIF (176×144), QVGA (320×240), and CIF (352×288). After the settings are completed, the camera acquisition is started and data transmission is performed.

  2.2 Synchronous transmission and image frame processing

  The synchronous transmission process is very simple, and does not even include handshake information; however, since synchronous transmission has high requirements on timing, it is difficult to process synchronous transmission data. The design of this driver uses the interrupt service routine to process the reception of synchronous data, and the processing of synchronous data is performed outside the interrupt service.

  ① The interrupt service program flow is shown in Figure 6. Each time a synchronous interrupt occurs, the received 128-byte synchronous packet is first read from the buffer of the USB host controller and the data is stored in the storage unit provided by the data processing program. Then the PID_IN flag and endpoint number are sent, the synchronous transmission type is set and the next transmission is started. The CH374 host will send a SOF synchronous flag every 1 ms. After receiving the SOF flag, the USB device will transmit the next synchronous packet.

Interrupt service routine flow

  ② The synchronous data processing program is shown in Figure 7. After the interrupt ends, the data processing program is executed. The program reads the first byte of the synchronous packet and confirms the sequence number of the packet. The range of this sequence number is 0 to 0xFF. If this sequence number is 0xFF, it means that it is an invalid packet and needs to be discarded. If this sequence number is 0, it may be the first synchronous data packet obtained for the first time, and this data is directly stored in the image frame; it may also be the first synchronous packet of the next frame of the image after the current image frame ends. In this case, it is necessary to process the current frame image that has ended and set the current frame to the next frame. So far, a frame of image data has been obtained.

Synchronous data handler

  2.3 Precoding of image data

  The processed image frame is in S561 format, which is an RGB format image and cannot be used by subsequent image encoders. The video data input by common video compression standards (such as H.263, MPEG4, etc.) is in YUV420 format, so the current S561 format data must be pre-encoded to YUV420 format. Because the algorithm is relatively complex, it is not described in detail here. Please refer to the source code of the bayer_decode() function in reference [1]. At this point, the camera driver based on CH374 is completed.

  3 Design Experience

  Since this USB host is based on a low-end embedded hardware system, there is no operating system support, and there is no USB data flow analysis software support like BUSHOUND, it is difficult to find a reference program for USB synchronous transmission based on an embedded platform, so the design is very difficult. The author's design experience focuses on the selection of reference programs.

  The design of this topic can be divided into two parts: one is the underlying CH374 host controller driver, which mainly includes device detection and enumeration (the design of this part of the program can refer to similar host controller drivers, such as Cypress's SL811HS chip host driver [3]); the other part is the camera initialization, video data reading and processing program. The only reference material is the open source USB camera driver under Linux. In the design process, you first need to understand the Linux device driver principle and analyze the USB camera driver well before you can have a design idea.

  Conclusion

  This driver is added to the existing video compression program, and the video is transmitted to the PC through the network for playback. Under the image attribute of QVGA (160×120), 7 frames per second can be achieved, which basically meets the actual needs. The USB camera driver based on CH374 provides a low-cost embedded platform to realize video acquisition, making the convenient video acquisition system no longer out of reach, and plays a positive role in the popularization of video surveillance.