LCD virtual display test of S3C2440

I. Overview   

    The LCD controller of S3C2440 supports virtual display, which is easier to understand as it can display images larger than the actual display. You can imagine that there is a large picture, but the display (display serial port) is relatively small, but we can move the position of the display relative to the large picture (that is, the large picture does not move), so as to observe the content of other parts of the large picture. The chip manual uses a picture to vividly show this part of the content as follows.

Here are four points:

　　1. Virtual memory (storage space for large photos) is larger than the viewport buffer space

　　2. The base address of virtual memory is fixed

　　3. The starting position of the large photo (the base address of the virtual memory (LCDBANK)) is aligned to 4M, eg: 0x30400000

　　4. You can change the base address (LCDBASEU) and end address (LCDBASEL) of the viewport to move the viewport

2. LCD Controller Analysis

1. The principle of virtual display

Consider two questions:

　　1. How to tell the LCD controller the size of the large picture? This will involve the problem of how to get data from the viewport in the future (configure LCDSADDR3)

　　2. How to move the window (configure LCDSADDR1 and LCDSADDR2)

　　I can tell you directly that you don't need to set the vertical length of the large photo, just set the horizontal width of the large photo. For example, my monitor viewport size is 480*272, but the photo size is 640*480. At this time, we only need to tell the LCD controller that the horizontal width of the large photo is 640. In LCDSADDR3, there is an OFFSIZE and PAGEWIDTH, where PAGEWIDTH is the viewport width (480), and OFFSIZE is the width of the large photo that is larger than the viewport (160). Through these two parameters, the controller is told that the horizontal width of the large photo is (480+160=640).

　　Why do we need to specify the width of this large photo? First, let's consider how photos are stored in memory (taking 16bpp as an example): 

　　It can be seen that in theory it is a three-dimensional space, (x, y) determines the plane coordinates, and z determines the color. However, in the memory, the addresses are continuous and can be regarded as one-dimensional, which means that the color at position (0,0) is stored first, occupying two bytes, and then the color at position (1,0) is stored, occupying two bytes... When one row is stored, the next row is stored immediately. In a word, this large image is stored continuously in the memory.

　　Then, let's consider that there is a small window here. Let's take the window in the upper left corner as an example, as shown in the following figure: 

　　We can see that the viewport to be displayed is relatively small, and when it is displayed, it reads data from the memory, not from a continuous space, but only reads part of each line (PAGEWIDTH).

　　Finally, let's consider the significance of specifying large image widths (PAGEWIDTH and OFFSIZE).

1. By specifying the width of the large image, the LCD controller knows how to divide the continuous storage space into rows, that is, to make the continuous space three-dimensional. Take LCDBANK as 0x30400000 as an example, the image width is (PAGEWIDTH+OFFSIZE=480+160=640). In this way, the LCD controller knows that the address (in bytes) at the end of the first row is (0x30400000+640*2-1). Among them, because it is 16bpp, each pixel occupies two bytes, so 640 must be multiplied by 2 to get the actual movement distance of a row. Similarly, the address of the first pixel in the third row is (0x30400000+640*2*2).

2. PAGEWIDTH and OFFSIZE can tell the LCD controller which data to display and which to skip. Let's take the above picture as an example. In fact, the base address of the viewport of this picture is LCDBANK. When reading data, first read the storage space in the range of (0x30400000, 0x30400000+(PAGEDITH-1)*2) to the first line of the display, and then skip OFFSIZE*2 storage units (BYTE); then read (0x30400000+(PAGEDITH+OFFSIZE)*1*2, 0x30400000+(PAGEDITH+OFFSIZE)*1*2+(PAGEDITH-1)*2) to the second line of the display, where multiplying by 1 represents the distance of one line offset; then read (0x30400000+(PAGEDITH+OFFSIZE)*2*2, 0x30400000+(PAGEDITH+OFFSIZE)*2*2+(PAGEDITH-1)*2) to the third line of the display...

　　Through these contents, I believe you have understood the basic principles of virtual memory display.

2. Mobile viewport

　　Another question is how to move the viewport. If you understand the above explanation, this question is quite simple. We just need to change the viewport's start address (LCDBASEU) and end address (LCDBASEL). Let's first talk about the meaning of these two parameters. LCDBASEU is the offset address of the viewport's start position relative to LCDBANK, and LCDBASEL is the address of the viewport's end position relative to LCDBANK.

　　Okay, let's take an example to illustrate how to pan the viewport. Assume that we have already transferred the large image to the virtual memory (with 0x30400000 as the starting address, and the storage space occupied is 640*480*2). The memory space occupied by our viewport is (480*272*2). At the beginning, our viewport is at the upper left corner of the large image, that is, LCDBASEU=0, and LCDBASEL is LOWER21BITS(((0x30400000+640*272*2)>>1)). Among them, the function LOWER21BITS() is the lower 21 bits. In fact, the end address of the viewport (in BYTE) is 0x30400000+640*272*2-1, and (0x30400000+640*272*2) (less than this limit) is a good way to specify the end address limit. It should be noted that the base of the multiplication here is 640, not 480, because the width of a row is 640. We can understand this by combining the LCDBASEL address calculation below.

　At this time, assuming we want to shift the image 100 pixels to the right, we can just set LCDSADDR1 and LCDSADDR2.

#define LOWER21BITS(n)  ((n) & 0x1fffff)

#define  LCDFRAMEBUFFER      0x30400000

#define  LINEVAL_TFT_480272   (272-1)

#define HOZVAL_TFT_480272    (480-1)

LCDSADDR1 = ((LCDFRAMEBUFFER>>22)<<21) | LOWER21BITS((LCDFRAMEBUFFER+100*2)>>1);

LCDSADDR2 = LOWER21BITS(((LCDFRAMEBUFFER+100*2)+ \

                         (LINEVAL_TFT_480272+1)*((HOZVAL_TFT_480272+1)+160)*2)>>1);

We move 200 pixels down on this basis, so the program is:

LCDSADDR1 = ((LCDFRAMEBUFFER>>22)<<21) | LOWER21BITS((LCDFRAMEBUFFER+100*2+640*200*2)>>1);

LCDSADDR2 = LOWER21BITS(((LCDFRAMEBUFFER+100*2+640*200*2)+ \

                          (LINEVAL_TFT_480272+1)*((HOZVAL_TFT_480272+1)+160)*2)>>1);

On this basis, we move up 100 pixels and left 50 pixels, so the program is:

LCDSADDR1 = ((LCDFRAMEBUFFER>>22)<<21) | LOWER21BITS((LCDFRAMEBUFFER+100*2+640*200*2-50*2-640*100*2)>>1);

LCDSADDR2 = LOWER21BITS(((LCDFRAMEBUFFER+100*2+640*200*2-50*2-640*100*2)+ \

                          (LINEVAL_TFT_480272+1)*((HOZVAL_TFT_480272+1)+160)*2)>>1);