General Category > Discussion - EVE

BT817Q's DL memory gets full with only 4404 bytes

(1/3) > >>

TreeOone:
Hi!

I have Riverdy's EVE4 IPS 10.1" LCD TFT (type RVT101HVBNWC00-B), which is run by BT817Q.

I noticed that my application can not take full advantage of DL memory in BT817Q.

To further investigate the problem I wrote simple test program:

   
--- Code: ---printf("\r\n ------------------------------------------------ \r\n");
uint32_t c = 1091;
//uint32_t c = 2038;


Gpu_Copro_SendCmd(phost, CMD_COLDSTART);
Gpu_Copro_SendCmd(phost, CMD_DLSTART);
Gpu_Copro_SendCmd(phost, CLEAR_COLOR_RGB(0, 0, 0));
Gpu_Copro_SendCmd(phost, CLEAR(1, 1, 1));

for(uint32_t i = 0; i < c; i++)
{
Gpu_Copro_SendCmd(phost, NOP());
//Gpu_Copro_SendCmd(phost, TAG(1));
}

Gpu_Copro_SendCmd(phost, COLOR_RGB(255, 0, 0));
Gpu_Copro_SendCmd(phost, VERTEX_FORMAT(3));
Gpu_Copro_SendCmd(phost, BEGIN(LINE_STRIP));
Gpu_Copro_SendCmd(phost, LINE_WIDTH(5 * 16));
Gpu_Copro_SendCmd(phost, VERTEX2F(10 * 8, 10 * 8));
Gpu_Copro_SendCmd(phost, VERTEX2F(500 * 8, 500 * 8));
Gpu_Copro_SendCmd(phost, END());

Gpu_Copro_SendCmd(phost, DISPLAY());
Gpu_Copro_SendCmd(phost, CMD_SWAP);

uint32_t reg_REG_CMD_DL = Gpu_Hal_Rd32 (phost, REG_CMD_DL);

printf("reg_REG_CMD_DL = %d        c = %d \r\n", reg_REG_CMD_DL, c);
--- End code ---


If I run this program I can go with variable “c”, which is filling up DL memory with dummy NOP command up to value 1091. If “c” becomes 1092, red line on screen starts having artifacts.

Printf command for last stable c = 1091 returns:

reg_REG_CMD_DL = 4404        c = 1091

So here we have magical upper limit of DL’s memory at 4404 bytes. 

This is strange because DL's size should be 8191, according to manual.

Further tinkering revealed that if I fill DL’s memory with another dummy command like TAG(1) behaviour changes.

For instance if I remove lines of code (comment them):

uint32_t c = 1091;
…and
Gpu_Copro_SendCmd(phost, NOP());

…and uncomment lines:
//uint32_t c = 2038;
…and
//Gpu_Copro_SendCmd(phost, TAG(1));

…my test application behaves as expected. I can go with variable “c” up to 2038.

In this case printf returns:

reg_REG_CMD_DL = 8191        c = 2038

…for last stable “c”. For c = 2039 and above, screen turns black, i.e. DL’s memory overflows.

Can somebody explain this?

I my actual application I am not filling DL’s memory with dummy code like in above example, instead I am filling it up with graphics primitives (lines, dots, circles etc), however when DL’s fullness reaches 4404, display starts displaying gibberish.

Rudolph:
That is interesting, I converted that code to work with my library to see if your library is at fault.


--- Code: ---void TFT_display(void)
{
    if(tft_active != 0U)
    {
        EVE_cmd_dl(CMD_DLSTART); /* start the display list */
        EVE_cmd_dl(DL_CLEAR_COLOR_RGB | BLACK); /* set the default clear color to black */
        EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);

        for(uint32_t i = 0; i < SENDNOPS; i++)
        {
           EVE_cmd_dl(DL_NOP);
        }

        EVE_color_rgb(0x600060);
        EVE_cmd_dl(VERTEX_FORMAT(3));
        EVE_cmd_dl(DL_BEGIN | EVE_LINE_STRIP);
        EVE_cmd_dl(LINE_WIDTH(5 * 16));
        EVE_cmd_dl(VERTEX2F(10 * 8, 10 * 8));
        EVE_cmd_dl(VERTEX2F(500 * 8, 500 * 8));
        EVE_cmd_dl(DL_END);
       
        EVE_cmd_button(250, 100, 100, 100, 28, 0, "Button");
        EVE_cmd_button(400, 100, 100, 100, 28, 0, "Button");
        EVE_cmd_button(550, 100, 100, 100, 28, 0, "Button");

        EVE_color_rgb(WHITE);
        EVE_cmd_number(100, EVE_VSIZE - 50, 26, EVE_OPT_RIGHTX, display_list_size); /* number of bytes written to the display-list by the command co-pro */

        EVE_cmd_dl(DL_DISPLAY); /* instruct the co-processor to show the list */
        EVE_cmd_dl(CMD_SWAP); /* make this list active */
       
        EVE_execute_cmd(); /* wait for the display list to be processed */
    }
}

--- End code ---

And like this I can set SENDNOPS to 1003 with a resulting display list of 4784 bytes before the display glitches out.
Commenting out the three buttons I can set SENDNOPS to 1334 which is a display list of 5432 bytes.
So I can go higher, but I can not use the full 8kiB of the display list either.

One thing that could go wrong is that the CMD-FIFO is getting full since it only has 4kiB.
But that is not the issue, I am using individual commands in this example, no DMA, chip-select low, address, command, chip-select high.
It should not be possible to throw in more in the FIFO like this than the co-processor can handle.
But to make sure I slowed down the SPI and also added a busy-wait for the FIFO to be empty in the loop - makes no difference.

In a different project that really is putting stress on the BT817 with thousands of line-strip segments, I am using DMA and fill the FIFO with 3676 bytes with a resulting display list of 6108 bytes - but it glitches out after a minute or less.
When I put in less it runs longer without issue - and by less I mean less iterations, like "only" using 36 points per line strip instead of 64.
It looks like my BT817 is overheating, pretty sure it is not, but it looks like it is.

Oh, another observation out of a hunch, updating the display list less often seems to help as well, I am at 20Hz / 50ms now with 5672 bytes in the display list.

This does not help with the program above though, the limit is still 1334 NOPs with a display list of 5432 bytes.

BRT Community:
Hi,

We will test out and investigate this also and keep you updated, thanks for your additional test results Rudolph,

Best Regards, BRT Community

Rudolph:
I have a RVT70HSBNWC00-B and I am using the exact same controller board with it, I only modified the regulator for the backlight to only do 5V since this is what the RVT70HSBNWC00-B requires while the RVT101HVBNWC00-B needs 7...14V for the backlight.

So on my side the same controller on the same board and therefore the exact same software using the same compiler etc.
With the 1024x600 RVT70HSBNWC00-B I can increase the NOPs to 1794 which results in a display list of 7272 bytes.
One more and it starts to flicker.

Craggan:
Just testing Unicode strings.

The cmd_text() row also floods the screen. One word less at the end and it works, but the screen flickers.

EVE_cmd_setfont2( 1, EVE_RAM_G,  0 );
cmd_text( 10,  10, 1, 0, "\u00D6sterreicher \u00E4rgern sich \u00FCber \u00E4gypter");

20 rows with 2 or 3 Umlauts in 1 line are OK. More then 3 Umlauts in 1 line kill.

Navigation

[0] Message Index

[#] Next page