Design of LED screen image data decoding based on ATmegal28

With the popularity of LED display screens and the reduction of costs, LED display screens have become an important tool for information dissemination in public places. At present, the main methods for changing the text and image of LED display screens are: connecting the display screen to the computer through a serial port or a network cable to achieve changes; remote transmission of data through the GPRS network, decoding it on the computer with specific software after receiving it, and sending it to the LED display screen for display. The above methods always need to be implemented on a computer platform, and the additional cost is relatively high. The design uses a mobile phone as the sender to send MMS to the GPRS module, and uses the ATmegal28 microcontroller to directly decode the MMS image and then send it to the LED display screen for display.

l JPEG decoding feasibility analysis
The data format received by the full-color LED screen used in this design is Xmp format, which is a simplified BMP format. The Xmp format has 6 bytes before the image data to indicate the attributes of the image. The first byte is the number of bytes of a dot; the second byte is the number of pictures contained in the XMP file; the third and fourth bytes are the height of the image; the fifth and sixth bytes are the width of the image, followed by the color of each dot of the image. The color of each dot is represented by 2 bytes (16-bit color). Since the full-color LED screen used has only 64×64 pixels, the image needs to be scaled after JPEG decoding.
The cache required in the JPEG decoding process mainly includes the cache of the original JPEG image data, the cache of the intermediate variables, and the cache of the decoded Xmp data. Depending on the complexity and compression ratio of the JPEG image, the size of a 320×240 color JPEG image is generally between 2 and 20 KB. The JPEG decoding cache is mainly used to store Huffman tables, quantization tables, temporary results of IDCT decoding, etc. These require approximately 8 KB. The RAM required for caching the decoded Xmp data is relatively fixed at 9 KB. In summary, JPEG decoding requires approximately 25 KB of RAM. The ATmegal28 has only 4 KB of SRAM internally, so the system has expanded 64 KB of external RAM.

2 Software Implementation
This design uses avr-gcc as the compilation tool. The default setting of avr-gcc is that the stack grows from the top of the internal RAM downward. Since a large amount of RAM space is required during image processing, all data areas should be moved to the external RAM through settings, leaving only the stack area in the internal RAM to avoid data overlap.
The JPEG decoding process mainly includes Huffman decoding, inverse quantization and IDCT transformation, color transformation and other modules. The LED display screen used in this article is 64×64 pixels and can only display pictures in Xmp format. Therefore, an image scaling module needs to be added after JPEG decoding. Its flow chart is shown in Figure 1.

2.1 Implementation of Huffman Decoding
Huffman decoding is an important part of the decoding process. Traditional Huffman decoding requires searching the Huffman table bit by bit for comparison and judgment. Since the search process requires a large number of shifts and loops, the decoding efficiency is very low. In view of this situation, taking into full consideration the storage capacity limitation of ATmegal28, when reading the file header, the software constructs the minimum value table and maximum value table of Huffman codewords under different code lengths in advance as shown in Table 1, the index of the minimum value in the Huffman table and the encoding table corresponding to each leaf node of the Huffman tree.

When decoding, read a string of binary data and compare it with the maximum and minimum values ​​under each code length. If there is no code word of the code length in the Huffman table, it means that the bit data is not a complete Huff_man code. Then read the next bit data and add it to the previous bit data to form a new code word, and then search in the minimum value table and the maximum value table until the exact code word is found. Finally, subtract the minimum value under the same code length from the code word, and add the index of this minimum value in the Huffman table to get the position of the code word in the encoding table.
2.2 Implementation of IDCT transformation
Multiply the 64 values ​​of the color component unit in the 8×8 block one by one by the corresponding coefficients in the same position in the quantization table, and then rearrange the 64 data in a Z-shaped manner to perform IDCT transformation. The amount of IDCT calculation is very large, including a large number of floating-point multiplication and addition operations, so IDCT takes up the most time in the decoding process. The row-column decomposition method is used to first decompose the two-dimensional IDCT into a one-dimensional 8-point IDCT. For the one-dimensional 8-point IDCT, Loeffler's fast algorithm is used. FIG2 is a flow chart of the Loef-fler algorithm, and an explanation of the operation factors of the Loef-fler algorithm is shown in FIG3.

Direct calculation of the rotation factor requires 4 multiplications and 2 additions, so a one-dimensional IDCT transform of 8 points requires a total of 14 multiplications and 26 additions. The rotation factor can be transformed as shown in formula (1):

Therefore, only 3 multiplications and 3 additions are needed for one rotation factor calculation. Then, only 11 multiplications and 29 additions are needed for one one-dimensional IDCT. Since the cost of multiplication is higher than that of addition, this deformation is beneficial. A total of 16 8-point one-dimensional IDCT operations are required to complete one two-dimensional IDCT operation. Due to the speed limitation of ATmegal28, the floating-point operation is improved to an integer operation during the IDCT operation, and the value of is enlarged 211 times and stored in preparation for the IDCT operation.

2.3 Image Scaling
Since the display screen used in this design is 64×64 pixels, the JPEG format MMS needs to be decoded first and then scaled to make it a 64×64 format. In general, image scaling adopts the "reverse mapping" method from the target image to the source image. However, considering the limitation of ATmegal28 RAM capacity, if the source image is decoded first, a large amount of RAM will be occupied, so the mapping method from the source image to the target image is adopted. When the RGB value of a pixel of the source image is solved, its position in the target image is calculated by calculation; first determine whether this position is zero, if so, store it directly; if not, calculate the average of the two numbers and store it. For the case where n pixels in the source image correspond to 1 pixel in the target image, the color component of this pixel in the target image is I=I1/2n+…+In/2, where: I1 is the color component of the first pixel in the corresponding source image, and In is the color component of the last pixel.
The comparison between the Xmp format image obtained by the method used in this design and the image obtained by the nearest neighbor method is shown in Figure 4. Figure 4(a) is the original Lena image, Figure 4(b) is the Xmp format image obtained by the nearest neighbor method, and Figure 4(c) is the Xmp format image obtained by the method used in this paper. By comparison, it can be seen that the image pixel transitions obtained by the method used here are relatively smooth and have a better display effect. This method is an improvement on the nearest neighbor method, which not only avoids the loss of some pixel information of the source image when using the nearest neighbor method, but also saves the system's RAM resources.

3 Hardware Implementation
The hardware implementation block diagram of the system is shown in Figure 5:

The system uses ATmegal28 microcontroller as the main chip, and transmits data through RS 232 and TR800. ATmegal28 reads the MMS image received by TR800 through commands and decodes it. Then the data is transmitted to the full-color LED display screen through RS 232 to change the image. A latch is used between Amegal28 and the external SRAM. The design uses 74AHC573. TR-800 module is a high-performance, low-power GPRS module. It embeds WAP protocol stack, TCP/IP protocol stack, and MMS protocol stack to facilitate users' secondary development and firmware upgrade. Due to the above characteristics, this design uses this module to realize the MMS sending and receiving processing function. The transmission protocol of the LED display screen complies with the Xmodem communication protocol and adopts CRC check. The operation effect of the whole system shows that it takes about 1s for ATmegal28 to decode a 167×173 pixel JPEG image when using a 16 MHz crystal oscillator.

4 Conclusion
A remote image transmission design suitable for full-color LED display screens is proposed, and solutions to key problems are given. Since the software decoding of the image is realized by using a single-chip microcomputer, it brings convenience to engineering applications. This design can be widely used in the processing and transmission of image data on vehicles or outdoor advertising screens. The computationally intensive JPEG decoding algorithm was successfully transplanted on ATmegal28, and the remote modification of the image data of the full-color LED display screen was realized, which has strong production practicality. The designed "Remote Interactive Multi-User Intelligent Information Screen Based on GPRS" won the second prize in the 10th "Challenge Cup" National College Students' Extracurricular Academic Science and Technology Works Competition.