Design of LED display system with independent video source using ARM and FPGA chips

At present, there are two main types of display screens according to the data transmission method: one is a real-time video screen that displays the same content as the computer; the other is an independent video source display screen that sends the display content to the display screen through communication means such as USB and Ethernet. If wireless communication is used, the display content can be updated at any time, which is highly flexible. In addition, using an embedded system to replace the computer to provide the video source can not only reduce costs, but also has high feasibility and flexibility, and is easy to construct. Therefore, the demand for independent video source LED display systems is increasing.

This system adopts the ARM+FPGA architecture, making full use of the super processing power and rich interfaces of ARM to achieve true network remote operation. Therefore, it can not only be used as a general LED display controller, but also can form a large outdoor advertising media network with various display nodes. FPGA is a very flexible programmable logic device that can be programmed and configured like software, so that flexible and convenient changes and development can be made in real time, improving system efficiency.

1 Independent video LED system

The main performance indicators of LED display screens include field scanning frequency, resolution, grayscale and brightness. Resolution refers to the number of LED tubes that the controller can control, grayscale is the resolution of color, and high brightness requires a long display time for each grayscale. Obviously, these three indicators will greatly reduce the field scanning frequency, so it is necessary to make appropriate trade-offs between these indicators in different occasions. Usually, the grayscale, brightness and field scanning frequency are determined by a single controller, while the resolution can be greatly improved through the controller array. In this way, the grayscale and brightness of each controller are very good, the field scanning frequency is also appropriate, and then through the form of controller array, a large control area can be achieved, and a full-color ultra-large screen LED display controller with delicate colors can be realized. The independent video LED system is completely out of the control of the computer and can realize communication, video playback, data distribution, scanning control and other functions. In order to achieve a large screen, full color and high field frequency, this system adopts the controller array mode, as shown in Figure 1.

Figure 1 Independent video LED system structure

The system can update local data from the network server through the network interface (Ethernet interface), and the video playback part decodes the data to obtain the video stream in RGB format. Then, through the data distribution unit, these data are sent to different LED display controllers, and the controller displays the data provided by the playback unit on the full-color large-screen LED.

2 Communication interface and video playback unit

The communication interface and video playback part of this system are implemented by ARM uClinux. ARM (Advanced RISCMachine) is a general-purpose 32-bit RISC microprocessor architecture designed and developed by the British ARM company. The design goal is to realize a miniaturized, low-power, high-performance microprocessor. Linux, as a stable and efficient open source operating system, has been widely used in various fields, while uClinux is a Linux system designed specifically for the microcontroller field. It has the advantages of being scalable, small kernel, perfect network interface protocols and interfaces, excellent file systems, and rich open source resources. It is being adopted by more and more embedded systems. The system uses the Intel XScale series PXA255 chip, which is compatible with the ARM v5TE instruction set, and uses ARM's memory management, interrupt processing and other mechanisms, and has made some extensions on this basis, such as DMA controller, LCD controller, etc. Due to the limited processing power of ARM9, it is currently only used to play 320×240 pixel videos.

The data for the video playback of the system comes from the SD memory card (Secure Digital Memory Card) in the system. There are two ways to update the data of the SD card: one is to update the data of the SD card with a computer; the other is to receive data from the server through the network and update the SD card directly by ARM. In addition, the player can also directly play the MPEG-4 format data transmitted by the network. Since XScale does not provide a physical layer interface, if you want to realize the network function, you need to connect an external physical layer chip. This system uses SMSC's high-performance 100M Ethernet controller LAN9118.

3 Video Data Distribution

Since the controller adopts array mode, it is necessary to distribute the data provided by the video source and correctly send the data in different rows and columns to different controllers.

3.1 Data Distribution Unit Solution

The LED controller in this system has a grayscale of up to 3×12 bits (can display up to 64G colors) and a control area of ​​128×128 dots. The data provided by the system playback unit is 320×240 pixels, so it needs to be decomposed into 6 LED controllers for control (see Figure 1). Therefore, the RGB data provided by PXA255 needs to be divided into 3 groups and sent to these 6 controllers, which can be implemented with FPGA. The solution is shown in Figure 2.

Figure 2 Data distribution unit scheme

The LCD interface submodule receives data and control signals from the PXA255 LCD interface, stores the input data into SDRAM after point-by-point correction, and then divides the field data into 3 groups, each with 128 lines (the last group has only 64 lines, which are padded with zeros by the bus scheduler for consistency with the subsequent control board), and sends them simultaneously, which are then processed by the LED display controller.

3.2 Memory Allocation and Bus Scheduling

In order to facilitate the interface between modules and facilitate data synchronization in different clock domains, the system memory adopts a two-level storage mode, that is, SDRAM is used as the main memory, and each module also has a corresponding FIFO as a cache. SDRAM has the advantages of large capacity, high bandwidth, and low price; but the control is relatively complex, and each read and write has multiple control and waiting cycles. Therefore, in order to improve efficiency, the address increment fragmented reading and writing method is usually adopted, and data at any address cannot be read at any time like SRAM.

This solution adopts a completely dynamic memory allocation mechanism, that is, when each module requests, if it is not the same field data, a new memory can be allocated, and once the data in the memory is no longer valid, the memory is released. In this way, each memory has its own attributes, marking whether it is in use or free memory, and whether the data in the current memory is in the queue waiting to be used, so the memory needs to be divided into 3 blocks. One block stores the point-by-point correction parameters, one block stores the current field data, and the other block stores the previous field data (that is, the data being sent). This requires that the data must be sent within a field synchronization cycle, and this requirement can be fully achieved.

Bus scheduling is the core part of this module. It is necessary to accurately calculate the bus bandwidth usage and determine the depth of each FIFO to ensure that each FIFO will not overflow or be read empty.

The bus scheduler needs to schedule three memory blocks and maintain a starting address of the offset address and an offset address count register for each module. In order to facilitate the calculation of the offset address, two physical rows of SDRAM are used to store the data of one row, and the excess part is left empty.

The arbitration algorithm of the bus scheduler is: the point-by-point correction parameters and the priority of the corrected data written into the SDRAM are the same, and the bus is occupied in a first-come-first-served manner, and the bus occupation is triggered by the pointer of each FIFO. After a data is written into the SDRAM, it starts to be sent. It is necessary to read the data of the nth, n+ 128th, and n+ 256th rows in turn to the data transmission FIFO0, 1, and 2, and wait for the data transmission unit to start sending.

3.3 LCD interface and point-by-point correction

The LCD interface of PXA255 is configured as a smart panel. For specific timing relationships, please refer to the PXA255 manual. FPGA reads the data according to these timing relationships and performs the next step of processing.

Since the parameters of LED tubes cannot be completely consistent during the production process, in order to obtain good image display effects, LED tubes must be screened. This is also an important reason why LED screens are expensive.

The point-by-point correction technology can adjust the brightness of the LED point by point, and improve the consistency of the brightness of the display screen by an order of magnitude, so that the purchasing manufacturer can relax the requirements of the brightness and color of the LED, and the cost of LED procurement will be greatly reduced. In addition, the point-by-point correction technology used by the system can modify the correction parameters online, so that the correction parameters of the LED screen can also be modified after it is put into operation, compensating for the impact of the aging of the LED tube on the display effect and increasing the service life of the LED screen. Therefore, the point-by-point correction technology makes the LED module an ideal solution as the basic component of the indoor and outdoor full-color display screen.

The point-by-point calibration parameters are stored in the SD card. After the system is powered on, the ARM first transmits the data to the FPGA through the LCD interface (configured as GPIO at this time), and the FPGA stores it in the SDRAM. After that, the data input by the LCD interface can be calibrated.