Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[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: [Select]

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);

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: [Select]

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 */
    }
}

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.

[Rudolph]

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

Besides the issue, that is an odd way to work with strings.
I just use UTF-8 encoding for my source files, so in this case I would have "Österreicher ärgern sich über Ägypter" in the text.

[Craggan]

Oh god, thanks for the tip. I copied it out from an example without thinking.   

[BRT Community]

Hi,

Just to update, We were able to fill RAM_DL to 7964 by using text commands with this string (on BT817)

"123456789\u00B0123456789\u00B0123456789\u00B0"

We will try the NOPs and your other string too to see if we can see the issue, and will update you,

Best Regards, BRT Community

[Rudolph]

Just to update, We were able to fill RAM_DL to 7964 by using text commands with this string (on BT817)

What resolution does the panel have you tested this with?

[BRT Community]

Hi Rudolph,
We checked with a 7" 1024x600 and also with a 10.1" 1280x800 screen.
Here is an example on the 10.1" screen

Best Regards, BRT Community

 

[Rudolph]

I am trying to reproduce your output but I am not getting up to your number.
I am not using an UTF-8 code to not extra complicate things.

With this:

Code: [Select]

{
    static uint32_t alive = 0;
   
    if(tft_active != 0U)
    {
        EVE_cmd_dl(CMD_DLSTART);
        EVE_cmd_dl(DL_CLEAR_COLOR_RGB | WHITE);
        EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);

        EVE_color_rgb(BLACK);
        for(uint8_t lines = 0; lines < 15; lines++)
        {
            EVE_cmd_text(10, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!");
            EVE_cmd_text(400, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!");
        }

        EVE_cmd_number(150, 570, 28, 0, alive++);

        EVE_color_rgb(BLACK);
        EVE_cmd_number(100, EVE_VSIZE - 30, 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);
        EVE_cmd_dl(CMD_SWAP);
       
        EVE_execute_cmd();
    }
}

I do get 15 lines of text just fine, no problem.
But I "only" get 5284 printed for the size of the display list.
Increasing the lines to 19 this passes 7000 depending on the value of the alive counter.
And yes, still no issue.

Modifying the loop to this:

Code: [Select]

    for(uint8_t lines = 0; lines < 16; lines++)
    {
        EVE_cmd_text(10, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!123456789!");
        EVE_cmd_text(490, 10 + lines * 30, 28, 0, "123456789!123456789!123456789!123456789!");
    }

It gets up to 8052 - no issue.

Modifying the alive counter to run from 1000 to 9999 to avoid extra digits and adding one extra line:
EVE_cmd_text(10, 540, 28, 0, "123456789!123");
Results in a display list of 8184 bytes.

So well yes, I need more text to get there, but like this I can really use the full display list.
No flickering, just works this way.