BRT Community

Please login or register.

Login with username, password and session length
Advanced search  

News:

Welcome to the Bridgetek Community!

Please read our Welcome Note

Technical Support enquires
please contact the team
@ Bridgetek Support

Please refer to our website for detailed information on all our products - Bridgetek - Bridging Technology

Author Topic: Is it possible to display several lists on one screen  (Read 10033 times)

Khtos

  • Newbie
  • *
  • Posts: 1
    • View Profile
Is it possible to display several lists on one screen
« on: September 20, 2019, 01:49:05 PM »

Hello, community!
I am only new in EVE, now I am connecting the first my screen with FT813.
Can someone explain me, how to display several coprocessor display lists on one screen. Unfortunately, I couldn’t understand this from the EVE FT81x programming guide.
I need to displays many text data and draw couple diagrams. And I came to the fact that everything I want to display does not fit in one display list. When I try to execute one display list, and then without giving the CMD_SWAP command, load and execute the second display list, I get a completely broken image on the screen.
Here is a display function that is called every 20 ms (I simplified it). Please tell me what's wrong with it!
Code: [Select]
void TFT_loop(void)
{
   uint8_t temp_c;
uint16_t temp_16;
// uint32_t temp_32;
uint16_t Y;
static uint8_t Data[128];

if(tft_active != 0) {

      for (temp_c = 3;temp_c < 77;temp_c++) {Data[temp_c] = temp_c;}
Data[0]++;
Data[1] += 2;
Data[2] += 3;

Data[77] += 3;
Data[78] += 2;
Data[79] += 1;

  //------
//FT813_StartDisplayList();
EVE_start_cmd_burst(); /* start writing to the cmd-fifo as one stream of bytes, only sending the address once */
   EVE_cmd_dl(CMD_DLSTART); /* start the display list */
   EVE_cmd_dl(VERTEX_FORMAT(0)); /* reduce precision for VERTEX2F to 1 pixel instead of 1/16 pixel default */
   EVE_cmd_dl(TAG(0));
//------
//FT813_ClearScreen(0x00505050);
EVE_cmd_dl(CLEAR_COLOR_RGB(0x50,0x50,0x50));
    EVE_cmd_dl(SCISSOR_XY(0,0));
   EVE_cmd_dl(SCISSOR_SIZE(2048,2048) );
      EVE_cmd_dl(CLEAR(1,1,1));
//------
EVE_cmd_append(MEM_DL_STATIC, num_dl_static); /* insert static part of display-list from copy in gfx-mem */
//------
Y = 50;
//------
//for (temp_c = 0;temp_c < 9; temp_c ++) { FT813_ShowLine(0,temp_c*40 + Y,749,temp_c*40 + Y,16,WHITE);}
EVE_cmd_dl(LINE_WIDTH(16));
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
EVE_cmd_dl(DL_BEGIN | EVE_LINES);
for (temp_16 = 0;temp_16 < 9; temp_16 ++) {
EVE_cmd_dl(VERTEX2F(11, Y + temp_16*40));
EVE_cmd_dl(VERTEX2F(759,Y + temp_16*40));
}
EVE_cmd_dl(DL_END);
//------
//for (temp_c = 0;temp_c < 11; temp_c ++) { FT813_ShowLine(temp_c * 75,Y,temp_c * 75,Y + 320,16,WHITE);}
EVE_cmd_dl(LINE_WIDTH(16));
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
EVE_cmd_dl(DL_BEGIN | EVE_LINES);
for (temp_16 = 0;temp_16 < 11; temp_16 ++) {
EVE_cmd_dl(VERTEX2F(10+temp_16*75,Y+1));
EVE_cmd_dl(VERTEX2F(10+temp_16*75,Y + 320));
}
EVE_cmd_dl(DL_END);
//--------------------------------------------------
Y += 8;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[temp_c],     2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[10 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[20 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[30 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[40 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[50 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[60 + temp_c],2,28,0,ORANGE);}
Y += 40;
for (temp_c = 0;temp_c < 10; temp_c ++) {FT813_ShowHex(30 + temp_c*75, Y, Data[70 + temp_c],2,28,0,ORANGE);}
Y += 40;
//==================================================

//------
EVE_cmd_dl(DL_DISPLAY); /* instruct the graphics processor to show the list */
   EVE_cmd_dl(CMD_SWAP); /* make this list active */
   EVE_end_cmd_burst(); /* stop writing to the cmd-fifo */
   EVE_cmd_start(); /* order the command co-processor to start processing its FIFO queue but do not wait for completion */
while (EVE_busy()) {;}

//---------------------------------------------------
EVE_start_cmd_burst();
EVE_cmd_dl(CMD_DLSTART); /* start the display list */
   EVE_cmd_dl(VERTEX_FORMAT(0)); /* reduce precision for VERTEX2F to 1 pixel instead of 1/16 pixel default */
   EVE_cmd_dl(TAG(0));
//------
EVE_cmd_dl(CLEAR_COLOR_RGB(0x50,0x50,0x50));
    EVE_cmd_dl(SCISSOR_XY(0,0));
   EVE_cmd_dl(SCISSOR_SIZE(2048,2048) );
      //EVE_cmd_dl(CLEAR(1,1,1));
//==================================================

EVE_cmd_dl(DL_COLOR_RGB | GREEN);
EVE_cmd_text(10,390,23,0,"Font 23: Quick brown fox jumps over a lazy dog 0123456789");
EVE_cmd_dl(DL_COLOR_RGB | BLUE);
EVE_cmd_text(10,410,24,0,"Font 24: Quick brown fox jumps over a lazy dog 0123456789");
EVE_cmd_dl(DL_COLOR_RGB | YELLOW);
EVE_cmd_text(10,440,25,0,"Font 25: Quick brown fox jumps over a lazy dog 0123456789");
//--------------------------------------------------
EVE_cmd_dl(DL_DISPLAY); /* instruct the graphics processor to show the list */
EVE_cmd_dl(CMD_SWAP); /* make this list active */
EVE_end_cmd_burst(); /* stop writing to the cmd-fifo */
EVE_cmd_start(); /* order the command co-processor to start processing its FIFO queue but do not wait for completion */
//=======================================================================================
while (EVE_busy()) {;}
}

}


And here is what I want it to display:


And what I get, instead:

« Last Edit: September 20, 2019, 02:00:19 PM by Khtos »
Logged

BRT Community

  • Administrator
  • Hero Member
  • *****
  • Posts: 741
    • View Profile
Re: Is it possible to display several lists on one screen
« Reply #1 on: September 20, 2019, 03:07:56 PM »

Hello,

You can only display one display list at a time with EVE although you can use the append technique as you have done to allow screen updates without re-sending all data. There is a limit of 8Kbytes for the display list.

Note that this is the actual RAM_DL content rather than the number of bytes of co-processor commands as some co-processor commands generate more bytes of RAM_DL instructions than the command itself. Also, note that this total also includes any appended commands and so ensure to count any appended data too.

You can send several blocks of co-processor instructions but you should only have your DISPLAY and SWAP at the end of the last block and begin the first block with a DL_START. Therefore even if you split the commands into several blocks, the result will still be one list in RAM_DL.

If you want to check if you are running out of RAM_DL, you can check the REG_CMD_DL register after executing a set of one or more commands. This register defines where the next RAM_DL entry will be put by the co-processor and so you can check when your list is approaching the limit.

RAM_DL always defines what is actually on the screen whereas RAM_CMD commands will be executed and will result in RAM_DL instructions being generated.

If your issue is running out of RAM_DL, you could consider making some lines or other items into bitmaps as these can be displayed with only a few commands. Your entire table could be make with an L1 bitmap and then just add the text values afterwards.

Best Regards, BRT Community



Logged

Rudolph

  • Sr. Member
  • ****
  • Posts: 390
    • View Profile
Re: Is it possible to display several lists on one screen
« Reply #2 on: September 20, 2019, 09:46:26 PM »

Since it already is within my Library I just tried it myself here now.  :)

My mobile is not really capturing it nicely but as you can see in my picture I got it to work.
Check the four numbers under the table, this is my debug output.
This means:
2068 bytes send over SPI
4248 bytes in the resulting display-list
1036 µs to compose the image
26 µs spent for the touch function

So this is only half the FIFO in use and only half the display list filled.
I put all the parts you posted into a single display list.

For the static part that you use with EVE_cmd_append() I could only guess and just put
the drawing of the 5 red lines plus printing the text there.

Likewise, what "{FT813_ShowHex(30 + temp_c*75, Y, Data[temp_c],     2,28,0,ORANGE);}" is actually doing could be hiding what might be your issue.

I translated that into:
Code: [Select]
EVE_cmd_setbase(16L);

Y += 8;
for (temp_c = 0;temp_c < 10; temp_c ++)
{
EVE_cmd_dl(DL_COLOR_RGB | ORANGE);
EVE_cmd_number(30 + temp_c*75, Y, 28, 2, Data[temp_c]);
}
...
EVE_cmd_setbase(10L);

And at first I left out setting the color but then I thought you might be wanting to set the color
for each cell individually based on the values.

This I commented out:
Code: [Select]
EVE_cmd_dl(SCISSOR_XY(0,0));
EVE_cmd_dl(SCISSOR_SIZE(2048,2048) );
EVE_cmd_dl(CLEAR(1,1,1));

This really is pointless after "EVE_cmd_dl(DL_CLEAR | CLR_COL | CLR_STN | CLR_TAG);"


Optimising, well.

I would draw the line-grid in the static part.
Or well, yes, as suggested, just use a picture for the table - and display the picture in the static part.
However, not drawing the grid at all gives me this debug output: 1872 4048 932
That saves a little but printing the 80 numbers is what really is filling the list.

Setting the color only once to orange (while again drawing the grid) results in: 1748 3924 855

So lets see what really is going on there.
Open the EVE Screen Editor and enter:
Code: [Select]
CLEAR(1, 1, 1)
CMD_SETBASE(16)
CMD_NUMBER(572, 272, 28, 0, 42)
CMD_NUMBER(597, 311, 28, 0, 68)

When you switch from the "Coprocessor" tab to the "Inspector" tab you see that these lines are translated into:
Code: [Select]
Raw Text
0 0x26000007 CLEAR(1, 1, 1)
1 0x22000000 SAVE_CONTEXT()
2 0x27000002 VERTEX_FORMAT(2)
3 0x0500001c BITMAP_HANDLE(28)
4 0x1f000001         BEGIN(BITMAPS)
5 0x06000032 CELL(50)
6 0x44780440 VERTEX2F(2288, 1088)
7 0x06000041 CELL(65)
8 0x44900440 VERTEX2F(2336, 1088)
9 0x23000000 RESTORE_CONTEXT()
10 0x22000000 SAVE_CONTEXT()
11 0x27000002 VERTEX_FORMAT(2)
12 0x0500001c BITMAP_HANDLE(28)
13 0x1f000001         BEGIN(BITMAPS)
14 0x06000034 CELL(52)
15 0x44aa04dc VERTEX2F(2388, 1244)
16 0x06000034 CELL(52)
17 0x44c204dc VERTEX2F(2436, 1244)
18 0x23000000 RESTORE_CONTEXT()

So while conveniant, this creates quite some redundant code, that is just the price for it.

To aoid using cmd_number we can easily break this down to:
Code: [Select]
CLEAR(1, 1, 1)
VERTEX_FORMAT(2)
BITMAP_HANDLE(28)
BEGIN(BITMAPS)
CELL(50)
VERTEX2F(2288, 1088)
CELL(65)
VERTEX2F(2336, 1088)
CELL(52)
VERTEX2F(2388, 1244)
CELL(52)
VERTEX2F(2436, 1244)
END()

Also, why cmd_number() is using VERTEX_FORMAT(2) eludes me, we can as well use VERTEX_FORMAT(0).
The coordinates can be fixed, its like VERTEX2F(collum, row) / VERTEX2F(collum+12, row).
That leaves the CELL() commands and these are just ASCII values.
CELL(50) : "2"
CELL(65) : "A"

Okay, lets see what happens.

Code: [Select]
uint8_t hex_table[] = "0123456789ABCDEF";

EVE_cmd_dl(BITMAP_HANDLE(28));
EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);

Y += 8;
for (temp_c = 0;temp_c < 10; temp_c ++)
{
EVE_cmd_dl(DL_COLOR_RGB | ORANGE);

EVE_cmd_dl(CELL(hex_table[Data[temp_c] >> 4]));
EVE_cmd_dl(VERTEX2F(30 + temp_c*75, Y));

EVE_cmd_dl(CELL(hex_table[Data[temp_c] & 0x0f]));
EVE_cmd_dl(VERTEX2F(42 + temp_c*75, Y));
}
...
EVE_cmd_dl(DL_END);

The result is: 2060 3104 1273

So compared to the original result we have pretty much the same amout of bytes we need to write out by SPI.
The display-list shrinks from 4248 bytes to 3104 bytes - which is quite a lot.
The time to compute this however increases from 1036 µs to 1273 µs.

And it looks exactly the same.


Edit:
I just was curious and with 160 VERTEX2F() this is the perfect test case.
So I pre-calcuted all the coordinates and put them in a table:

Code: [Select]
uint32_t vertex2f_array[20][8];

for(uint8_t Y=0; Y < 8; Y++)
{
for (uint8_t temp_c = 0;temp_c < 10; temp_c ++)
{
vertex2f_array[temp_c*2][Y] = VERTEX2F(30 + temp_c*75, 58+Y*40);
vertex2f_array[1+temp_c*2][Y] = VERTEX2F(42 + temp_c*75, 58+Y*40);
}
}

With the array beeing global.

Then I replaced the code in the loops:
Code: [Select]
for (temp_c = 0;temp_c < 10; temp_c ++)
{
EVE_cmd_dl(DL_COLOR_RGB | ORANGE);
EVE_cmd_dl(CELL(hex_table[Data[temp_c] >> 4]));
// EVE_cmd_dl(VERTEX2F(30 + temp_c*75, Y));
EVE_cmd_dl(vertex2f_array[temp_c*2][0]);
EVE_cmd_dl(CELL(hex_table[Data[temp_c] & 0x0f]));
// EVE_cmd_dl(VERTEX2F(42 + temp_c*75, Y));
EVE_cmd_dl(vertex2f_array[1+temp_c*2][0]);
}

The result is: 2060 3104 1206

So calculating 160 VERTEX2F() takes 67µs on my 48MHz CortexM0+.
That is 0.42µs per VERTEX2F() or ~20 clock cycles.
Even on the 32bit ARM this is somewhat of a bottle-neck.
And this all due to the strange format of VERTEX2F() with X and Y both 15 bit wide and X starting at bit 15.

So, especially on an 8-bit controller, if your visualisation requires a bunch of VERTEX2F() to be
calculated from variables and therefore this can not be optimized during compile-time,
you better make sure to pre-calculate as much of it as you can.
« Last Edit: October 03, 2019, 08:27:04 PM by Rudolph »
Logged