Max number of lines (VERTEX2F) which can fit in BT817

[TreeOone]

Hi,
I am drawing lots of lines via command VERTEX2F on screen. I am trying to figure out how much I can fit inside BT817 before it crashes.
I have STM32 F4, running Rudolph Riedel's library, which is running Riverdi's 10'' display RVT101HVBNWC00-B.
To achieve that, I am writing commands to REG_CMDB_WRITE register.
At some point screen starts flickering. Now I am puzzled which limit I managed to hit.
After each new line, which is add, I am reading registers REG_CMD_DL, REG_CMD_WRITE, REG_CMD_READ, REG_CMDB_SPACE.
What I noticed so far:
1)   REG_CMDB_SPACE is always equal to 4092, no matter at which point I try to read it. From that I can conclude that every dword that is written in REG_CMDB_WRITE register, coprocessor command gets read, meaning it is not possible to overflow FIFO buffer. It will always be empty for new commands, because they are momentarily processed.
Is this correct?
2)   Flickering starts happening at rather strange moment. Writing new commands to REG_CMDB_WRITE eventually leads to large number of commands, even larger than 4096 bytes, which should overflow FIFO, but still flickering does not start.
3)   Flickering starts happening at 1200 line segments, but is dependent on line width (??!?!?), how long are lines, etc. Why??
4)   When flickering starts, REG_CMD_DL is at approx. 6000 bytes full, so it is not overflowing.

Can someone explain this?

Code:

Code Select Expand


void demo_CoPro_8()
{
uint32_t c = 0;
uint32_t old_reg_REG_CMD_WRITE = 0;

while(1)
{
EVE_cmd_dl(CMD_COLDSTART);
EVE_cmd_dl(CMD_DLSTART);
EVE_cmd_dl(CLEAR_COLOR_RGB(0, 0, 0));
EVE_cmd_dl(CLEAR(1, 1, 1));
EVE_cmd_dl(COLOR_RGB(255, 250, 0));
EVE_cmd_dl(VERTEX_FORMAT(3)); // Set the precision of VERTEX2F coordinates.
EVE_begin(EVE_LINE_STRIP);
EVE_cmd_dl(LINE_WIDTH(2 * 16)); // Specify the width of lines to be drawn with primitive LINES in 1/16 pixel precision.

uint32_t min_X = 10;
uint32_t max_X = 1250;
uint32_t min_Y = 10;
uint32_t max_Y = 760;
uint32_t incrementor = 20;
uint32_t coordinates[] = {min_X, min_Y};
uint32_t direction[] = {1, 0};
uint32_t flag = 0;

EVE_cmd_dl(VERTEX2F(coordinates[0] * 8, coordinates[1] * 8));


for(size_t i = 0; i < c; i++)
{
uint32_t new_X = coordinates[0] + incrementor * direction[0];
uint32_t new_Y = coordinates[1] + incrementor * direction[1];

if(new_X > max_X)
{
direction[0] = 0;
direction[1] = 1;
min_X += incrementor;
}
else if (new_X < min_X)
{
direction[0] = 0;
direction[1] = -1;
max_X -= incrementor;
}
else if(new_Y > max_Y)
{
direction[0] = -1;
direction[1] = 0;
min_Y += incrementor;
}
else if (new_Y < min_Y)
{
direction[0] = 1;
direction[1] = 0;
max_Y -= incrementor;
}

coordinates[0] += incrementor * direction[0];
coordinates[1] += incrementor * direction[1];

EVE_cmd_dl(VERTEX2F(coordinates[0] * 8, coordinates[1] * 8));

}
EVE_end();
EVE_cmd_dl(DL_DISPLAY);
EVE_cmd_dl(CMD_SWAP);

uint32_t reg_RAM_ERR_REPORT = 0x309800;
uint8_t error_report[128] = {0};
EVE_memRead_sram_buffer(RAM_ERR_REPORT, error_report, 128);

uint32_t reg_REG_CMD_DL = EVE_memRead32(REG_CMD_DL);
uint32_t reg_REG_CMD_WRITE = EVE_memRead32(REG_CMD_WRITE);
uint32_t reg_REG_CMD_READ = EVE_memRead32(REG_CMD_READ);
uint32_t reg_REG_CMDB_SPACE = EVE_memRead32(REG_CMDB_SPACE);

uint32_t delta = 0;

if(reg_REG_CMD_WRITE > old_reg_REG_CMD_WRITE)
{
delta = reg_REG_CMD_WRITE - old_reg_REG_CMD_WRITE;
}
else
{
delta = 4096 - old_reg_REG_CMD_WRITE + reg_REG_CMD_WRITE;
}

old_reg_REG_CMD_WRITE = reg_REG_CMD_WRITE;

printf("\r\n------------------------------------------------------\r\n");
printf("reg_REG_CMD_WRITE = %d (max 4096 - 4 byte = 4092)  delta = +%d\r\n", reg_REG_CMD_WRITE, delta);
printf("reg_REG_CMD_READ = %d\r\n", reg_REG_CMD_READ);
printf("reg_REG_CMDB_SPACE = %d\r\n", reg_REG_CMDB_SPACE);
printf("reg_REG_CMD_DL = %d (max 8192 - 4 byte = 8188)\r\n", reg_REG_CMD_DL);
printf("c = %d\r\n", c);
printf("ERROR report = %s\r\n", error_report);
printf("------------------------------------------------------\r\n");

c++;
}
}


This code is basically drawing long line composed of small segments. See attachment.

[Rudolph]

Hi,
I am drawing lots of lines via command VERTEX2F on screen. I am trying to figure out how much I can fit inside BT817 before it crashes.
I have STM32 F4, running Rudolph Riedel's library, which is running Riverdi's 10'' display RVT101HVBNWC00-B.
To achieve that, I am writing commands to REG_CMDB_WRITE register.
At some point screen starts flickering. Now I am puzzled which limit I managed to hit.

That is more than likely the pixel engine, at some point the display list grows so complex that generating a line takes more time
than displaying a line.

I have a torture test somewhere in which I did an animated line-strip with several segments, I am not sure right now if I ran this on the RVT101H,
looks like I only use the RVT70H.
Anyways, the pixel engine needs a bit more time.

Add this after the init:
EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500);

This should allow the pixel engine to spend more time on a line at the cost of course of reducing the framerate.

After each new line, which is add, I am reading registers REG_CMD_DL, REG_CMD_WRITE, REG_CMD_READ, REG_CMDB_SPACE.
What I noticed so far:
1)   REG_CMDB_SPACE is always equal to 4092, no matter at which point I try to read it. From that I can conclude that every dword that is written in REG_CMDB_WRITE register, coprocessor command gets read, meaning it is not possible to overflow FIFO buffer. It will always be empty for new commands, because they are momentarily processed.
Is this correct?

For display-list commands issued separately, this is what I observed as well.
Commands like CMD_LOADIMAGE actually need some time to process, simpler commands not really.

2)   Flickering starts happening at rather strange moment. Writing new commands to REG_CMDB_WRITE eventually leads to large number of commands, even larger than 4096 bytes, which should overflow FIFO, but still flickering does not start.

There should be an issue if you send all commands in one go, aka burst-mode, so not raising CS in between the commands and only sending the address once.
But separately, yes, the commands are processed and the FIFO never gets filled.

From what I saw in the sources my torture test does at least 960 line segments.
But then there also is some other stuff on the screen.

3)   Flickering starts happening at 1200 line segments, but is dependent on line width (??!?!?), how long are lines, etc. Why??

More pixels to put out.

4)   When flickering starts, REG_CMD_DL is at approx. 6000 bytes full, so it is not overflowing.

Yes, I made it give up as well before I had the display list full. :-)


Edit: I was about to put your source code in my project, I missed this when briefly looking at your code:

   while(1)
   {
      EVE_cmd_dl(CMD_COLDSTART);   

Like this I would expect it to flicker with less line segments since there is a high potential that you are trying to update faster than frame rate.
What is probably saving you there are all the printf() lines.

60Hz = 16.667ms -> do not try to update the screen faster than that

[TreeOone]

Thank you for your comments. 

EVE_memWrite32(REG_AH_HCYCLE_MAX, EVE_HCYCLE + 500);

.....removed limits of 1200 line segments.

I was not aware of pixel engine's limitations.

So, it is possible to crash BT81x, even if you pay attention to FIFO and RAM_DL fullness. This also means when one deals with lots of elements on screen, behaviour is not fully deterministic. Anything can happen.

Another conclusion is do not use while(1) {....} to fill BT with commands

BTW
Rudolph, your library is great. Unfortunately for me, it is heavily dependent on SPI communication, which is not ideal for me, because I am using QSPI, which on STM32 works a little bit different, so I had to rewrite all functions in EVE_commands.c. BTW2 I still can not get it working on 4 data lines, so far only 2 lines working, but that is discussion for another thread, after I give up trying to fix it.

[Rudolph]

I was not aware of pixel engine's limitations.

It is more an issue with resolutions beyond 800x480.

Rudolph, your library is great. Unfortunately for me, it is heavily dependent on SPI communication, which is not ideal for me, because I am using QSPI, which on STM32 works a little bit different, so I had to rewrite all functions in EVE_commands.c.

There shouldn't be a need to rewrite anything in EVE_commands.c, the hardware-abstraction is in EVE_target/EVE_target_STM32.h for example.
Ok, for STM32 in particular there also is EVE_init_spi() in EVE_target.c - but this is nice to have, not must use.

And yes, I have not looked at the QSPI unit in particular, but it should be covered by HAL, if not LL HAL.

And quad SPI? I simply found no use case for it so far, display updates only take xx micro-seconds when you make use of DMA. :-)

Edit: I looked, ok, there does not seem to be LL HAL support for QSPI.
And I have a NUCLEO-G474RE and I am looking at it n STM32CubeIDE, unfortunately the Device Configuration Tool does not seem to allow me to configure the QSPI with a single line and also trying to not use the chip select line under the control of the unit does not work -> really not my cup of tea.