Really nobody can give me a hint?

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

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.

EAB 2.10.2

Hi,

Could you please advise what settings you used to convert the font in EVE Asset Builder and also which version of the EAB you use?

Best Regards, BRT Community

Hi there,

is there a failure in the font converter?

When i create UNICODE fonts bigger than 18 the distance between the letters are to big, please see attachment.

In this case font "Ubuntu".

Or am i wrong?

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.

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.

Hi,

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

Best Regards, BRT Community

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

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.