346
Discussion - EVE / Re: Is it possible to display several lists on one screen
« 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:
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:
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:
When you switch from the "Coprocessor" tab to the "Inspector" tab you see that these lines are translated into:
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:
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.
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:
With the array beeing global.
Then I replaced the code in the loops:
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.
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.