Design and implementation of monitoring server based on TMS320DM355

This design uses TI's DaVinci series chips as the hardware platform, combined with the embedded Linux operating system, to implement a video server based on TMS320DM355. This article explains the selection and function of each hardware module, as well as the software architecture and implementation of the server. At the same time, it gives the framework of the entire network video surveillance system, including the video server, network transmission link and client monitoring terminal. This design uses the MPEG4 video encoding standard, which is completed by the MPEG/JPEG coprocessor inside the DM355. Experiments show that real-time monitoring can be achieved under the condition of sufficient bandwidth.

1. Introduction

Multimedia monitoring has always been one of the hot application technologies that people pay attention to. It is widely used in many occasions due to its intuitive, convenient and rich information content. With the continuous development of embedded systems and video compression technology, video monitoring systems based on embedded technology have also been rapidly developed and applied. It converts the analog signal output by the camera into a digital signal, which is then encoded and transmitted by the embedded system. On the client side, monitoring is performed by installing monitoring software or directly through the Web. The video monitoring system using the embedded Linux operating system has powerful functions such as encoding processing, network communication, and automatic control, and directly supports network transmission and network management, making the monitoring range reach a certain breadth.

In addition, the development of embedded processors is also changing with each passing day. There are ARM series processors that focus on control, DSP processors that are good at fast calculations, and some very targeted processors that can implement hardware video encoding and decoding. The DaVinci processor TMS320DM355 processor recently launched by Texas Instruments (TI) for the portable high-definition (HD) video product market combines their strengths. It has an ARM9EJ-S main processor inside, which is responsible for the control of the entire system. It also integrates an MPEG/JPEG coprocessor, which focuses on the implementation of MPEG/JPEG algorithms. Its internal video processing subsystem (VPSS) and other peripherals can easily and quickly realize video acquisition, preprocessing, display, network transmission and other functions. At the same time, its low price also reduces costs for users. This design uses this processor.

2. Overall framework of video surveillance system

This embedded network video monitoring system consists of three parts: video server, network transmission link, and client monitoring terminal. The video server is responsible for the collection, compression and processing of audio and video data. The network transmission link transmits the multimedia data compressed and sent by the video server, while the client monitoring part receives the audio and video data, decompresses, displays, and controls the video server. The schematic diagram of the entire system is shown in Figure 1.

Figure 1 Schematic diagram of video surveillance system

2.1. Video Server

The video server uses the DaVinci series processor TMS320DM355 recently launched by Texas Instruments (TI) as the main processor, receives the video signal collected by the CCD camera, performs pre-processing and MPEG4 compression, and then transmits the compressed data through the network. At the same time, it receives the commands sent by the host computer, parses and executes them. Each device has a unique ID. When the client connects, the server will first check whether the ID number matches to prevent malicious connections. In addition, when the video server runs abnormally, its internal daemon will monitor and restart when appropriate.

[page]

2.2. Network transmission link

The network transmission link is responsible for the transmission of multimedia data. Here, the network transmission link can be selected according to actual needs. Local area network (LAN), wireless local area network (WLAN), INTERNET, CDMA, 3G, etc. are all available transmission links. Among them, the bandwidth of local area network (LAN) and wireless local area network (WLAN) is sufficient and stable, and the equipment is simple and easy to implement, but it will be limited by distance. INTERNET and CDMA networks can extend the monitoring distance, but their bandwidth is limited and the image quality will be affected. The latest 3G network is also a good choice. The bandwidth can reach 2Mbps in a static state, but its stability has yet to be tested. Users can choose according to their own needs, or directly build a dedicated network to achieve their own monitoring indicators.

2.3． Customer monitoring terminal

The client mainly connects with each video server to realize monitoring. The client can be a PC or a portable device, connected to the network transmission link, connected to the video server through the host computer software, receive the multimedia data sent by the video server, decode it, and then display it on the host computer. At the same time, send control commands to the video server to realize the control of the pan/tilt, lens, etc.

3. Video server hardware design

3.1 Overall Framework The video server completes video acquisition, MPEG4 compression and network transmission, as well as the control of the PTZ and lens. Its hardware structure diagram is shown in Figure 2.

Figure 2 Video server hardware structure diagram

[page]

3.2. Introduction to each module

1) Main processor

TMS320DM355TMS320DM355 is a highly integrated processor designed for digital still cameras, digital photo frames, IP security cameras, video doorbells and other low-power portable digital video applications. It can achieve low-cost, high-image quality video solutions. It combines high performance, low power consumption, and low cost, and provides seamless connection with external CCD or CMOS sensors. In addition, it also provides interfaces with power management, DDR/mDDRmemory, SRAM, NAND, etc.
The main processor of the DM355 processor is an ARM926EJ-S core. The ARM926EJ-S is a 32-bit processor core that provides a clock rate of 216MHz or 270MHz, can execute 32-bit and 16-bit instruction sets, and 32-bit, 16-bit and 8-bit data.

In addition, DM355 also integrates an MPEG/JPEG coprocessor to achieve digital video compression.

DM355 also includes a video processing subsystem (VPSS), which is divided into a video processing front end (VPFE) and a video processing back end (VPBE). The video processing front end provides an interface with the CCD/CMOSimager module and the video decoder. The video processing back end implements hardware OSD support and composite NTSC/PAL or LCD output.

2) Video acquisition module

The video acquisition module is mainly composed of a lens and an analog front-end circuit. The function of the analog front-end is to clamp and amplify the analog signal output by the image sensor and complete the A/D conversion. The TVP5146 is used here. The TVP5146 is a high-quality, single-chip video decoder from TI that digitizes and decodes all mainstream baseband analog video formats. The TVP5146 converts composite or separated NTSC, PAL or SECAM signals into YCbCr format. The output format can be 20-bit YCbCr4:2:2 or 10-bit YCbCr4:2:2. It is controlled by a set of internal registers and configured through I2C to change parameters such as contrast, brightness, saturation, and hue.

3) Audio acquisition module

The audio acquisition module consists of a Mic and an analog-to-digital conversion circuit. TLV320AIC33 is used here. TLV320AIC33 is a low-power stereo audio codec that digitizes analog audio signals. It includes a stereo headphone amplifier and provides multiple inputs and multiple outputs. It supports 8k to 96k sampling. DM355 also configures it through I2C. The data interface uses McBSP.

4) Storage module

This design uses 512MB nandflash to store UBL, U-Boot, kernel, and root file systems. If necessary, it can store a certain amount of audio and video data. The interface between it and DM355 is an 8-bit data line. Commands and data are transmitted through this 8-bit data line.

5) Dynamic storage module

[page]

Since DM355 provides DDR interface, the faster DDR SDRAM is selected as dynamic memory. The Linux operating system and application programs are all running here. When the system is powered on, the bootloader performs some simple settings and then moves itself to SDRAM for running. When the kernel needs to be started, the kernel is moved to SDRAM for running. After that, the control of the entire memory is handed over to the Linux kernel.

6) Ethernet controller The Ethernet controller selects DM9000 to send and receive data through the network transmission link.

7) RS232 and RS485RS232 is mainly used for debugging in the development stage. RS485 is used to control the pan/tilt, lens, etc. RS232 and RS485 can use the common 232 and 485 chips to meet the needs.

8) Power module The power module is responsible for the power supply of the entire system. We use an off-the-shelf power module to provide the 24V AC voltage required by the PTZ, the 12V DC voltage required by the lens, and the 5V DC voltage required by the video server. Since the core voltage of DM355 is 1.3V, the I/O voltage is 3.3V, and the voltage of DDRSDRAM is 1.8V, we chose the TPS65021 power chip to convert the input 5V voltage into 3 different voltage outputs. In addition, we also considered the power-on sequence of DM355.

4. Video server software design

This design uses the embedded Linux operating system as its software foundation. After the system is powered on, the bootloader is first run to initialize the CPU and some I/O devices, and then the Linux kernel is moved to the memory and the control is handed over to the kernel. After the kernel is started, the user application is run. The software hierarchy of the system is shown in Figure 3.

Figure 3 System software hierarchy

4.1. System power-on and boot program

When the system is powered on, the input pin BTSEL[1:0] of DM355 determines whether to boot from ROM or AEMIF. This design chooses to boot from ROM. At this time, the system directly jumps to the starting address (0X00008000) of the internal ROM to execute instructions. The embedded ROM boot code (RBL) performs some configuration operations, and then reads the BOOTCFG register to decide whether to boot from NAND, MMC/SD or UART. This design chooses NAND boot. U-boot, Linux kernel and root file system are pre-burned in NANDflash. After NAND boots, it will read the instructions of the stage1 part of the bootloader to make necessary settings for the system, and then move the code of the stage2 part to SDRAM for execution. When the user chooses to boot the kernel, the bootloader moves the kernel from NANDflash to SDRAM, then jumps to the starting address of the kernel for execution and boots the kernel.

[page]

4.2． Embedded Linux operating system

Embedded Linux operating system is an operating system that tailors and modifies the Linux kernel to run on embedded computer systems according to different application requirements. It is open source, has a small kernel, high efficiency, is suitable for a variety of CPUs and hardware platforms, has stable performance, and good portability, which has opened up a space of its own.

This design selects the embedded Linux operating system as the software platform to realize the addition and transplantation of drivers for each hardware module, and the writing and debugging of user applications.

4.3. User Application

In this design, the entire application is divided into two processes, the data process and the command process. The data process is mainly responsible for the collection, compression and network transmission of audio and video data. Among them, it is divided into three threads, the capture thread, the encoding thread and the control thread. The capture thread controls the acquisition device to collect and preprocess images and sounds; the encoding thread reads data from the capture thread and performs MPEG4 (video) or G.711 (audio) compression. The control thread reads the compressed data from the encoding thread and sends it to the client through the network. The command process receives commands from the host computer, parses and executes them, and controls the pan/tilt, lens and temperature measurement. The command process also adds functions such as user ID verification to provide a simple protection mechanism. The flowchart of the application is shown in Figure 4.

Figure 4 Application flow chart

[page]

4.4. MPEG/JPEG Coprocessor Encoding

Since the DM355 has an integrated MPEG/JPEG coprocessor, the encoding and decoding of audio and video is mainly completed through it. Its operation is implemented by the xDAIS-DM standard based on the eXpressDSP algorithm interoperability standard (xDAIS) formulated by TI. This standard defines a set of unified APIs that are built on various multimedia algorithms, which simplifies the integration difficulty and ensures interoperability. The CodecEngine proposed by TI is a set of APIs for exemplifying and running xDAIS algorithms, and the VISA (Video, Image, Speech, Audio) class is an interface for interacting with the API function set based on various multimedia algorithms defined by the xDAIS-DM algorithm standard. In application programming, the video encoding is completed by performing the following operations.

Open the codec engine:

staticStringengineName=videnc

Engine_Handlece;Engine_Errorerrorcode;ce=Engine_open(engineName,NULL,& amp;errorcode);The video encoding class provides four API functions:Create a video encoding class: VIDENC_Handlehenc;staticStringencoderName=mpeg4enc; henc="VIDENC"_create(ce,encoderName,NULL);Where ce is the handle returned when the encoding engine is opened. Control the video encoding class and set the dynamic parameters of video encoding: VIDENC_control(henc,XDM_SETPARAMS,&dynamicParams,&encStatus);Process data and encode: VIDENC_process(henc,&inBufDesc,&outBufDesc,&inArgs,&outArgs);Where parameter henc is the created VISA class handle, inBufDesc is the original data buffer, outBufDesc is the compressed data buffer, inArgs and outArgs are input and output configuration parameters. Destroy the created video encoding class: VIDENC_delete(henc); By calling the above API in the application, you can use the MPEG/JPEG coprocessor to compress the original video data, and the compression of audio data is similar.

5. Conclusion

This article introduces the design and implementation of a video surveillance server based on the latest DaVinci platform, including hardware components and software design. The entire video server uses the ARM926EJ-S core inside the DM355 to run the embedded Linux operating system, and uses the MPEG/JPEG coprocessor to perform MPEG4 encoding-related calculations. The article also introduces the use of MPEG/JPEG coprocessor for encoding, and also gives the framework of the entire video surveillance system. After testing in the local area network, it can achieve real-time transmission of D1 format video, and can also control the pan/tilt and lens. The system can be used to realize video surveillance in buildings, streets and other places.

References

[1]CodecEngineApplicationDeveloperUsersGuide

[2]xDAIS-DM(DigitalMedia)UserGuide

[3] Wang Tianmiao. Embedded System Design and Case Development Beijing: Tsinghua University Press, 2003.10

[4] Li Shanping, Liu Wenfeng, Wang Huanlong. Linux and Embedded Systems (2nd Edition). Beijing: Tsinghua University Press, 2006.3

[5] Du Chunlei. ARM Architecture and Programming Beijing: Tsinghua University Press, 2003.8