There is a new EVE Asset Builder - v1.2.0 - and I like it. 

With regards to this thread it is now possible to set the tiling manually or disable it entirely.
Thanks!

Also interesting is the option to feed it GIF animations.

Interesting, what about using more different pictures?

And you changed the code, you used VERTEX2II() as well.
I tried this as well and it still does not work with

0 1 2 3 4 5 6
7 0 0 0 0 0 0

This works:

0 1 2 3 4 5 6
0 0 0 0 0 0 0

And more interestingly this works as well:

0 1 2 3 0 0 0
4 5 6 7 0 0 0

So I tried to leave out the last two images in the row for which I use VERTEX2F().

This works:

0 1 2 3 0
4 5 6 7 0

0 1 2 3 4
5 0 9 0 0

This fails:
0 1 2 3 0
4 5 6 7 8

0 1 2 3 4
5 6 9 0 0


Okay, it looks like I really have to get annother display.
The one I have from Riverdi unfortunately is only the 4.3" version.
And my EVE3-50G for some unknown reason died a while back, just stopped working for no apparent reason.

Well, annother EVE3-50G it is then.

Edit: I maybe need to clarify this a little, I really have no idea why it stopped working, I had it on my desk, connected to my target board and it worked, I uploaded a new software to my board like I did a couple of times this evening, and the BT815 did not respond anymore and the panel stayed black.
There was no magic smoke involved and there was no visual clue on the board that something failed.
Since it was send to me from Digikey on the other side of the globe it did not even occur to me to send it back.
Instead I decided to try to fix it myself by replacing the BT815Q.
Well, that did not work out either but I learned that I am not ready yet to solder VQFN-64 packages. :-)
Whatever, I would not have bought just annother one from probably even the same batch if I were suspicous that there is anything wong with the EVE3-50G.

EVE is around for some time now and yet I do know any product that has a FT8xx / BT81x inside.
There should be for example Coffee Makers with EVE inside.

Please name any product featuring a FT8xx/BT81x, regardless of what it is,
where are the Coffee Makers, Copiers, Glucose Monitors, Fish finders??

>Tried to display 28 different ASTC8x8 images(each image is 100x100) : 7 from flash and 21 from RAM_G.
> Found no issue at my side, see the picture attached.

Okay, what about really different images and all from flash? :-)
I have attached my flash file.

And why all these "BEGIN(BITMAPS)"?
One for a block of bitmaps is enough.
Also there is no END() in your posted code.

>Can you have a test on the flash read speed?

Not directly but I can measure how much time cmd_flashread() takes.
There is not much to gain from this as we have no information about how EVE is actually processing
the display-list and displaying anything.
A SPI trace would be more interesting, but my logic analyzer is way too slow to capture a QSPI which I expect to run at a minimum clock of 36MHz (half of EVEs clock).

An EVE_cmd_flashread(0,0,86784); takes about 4700µs.
An EVE_cmd_flashread(4096,4096,4752); takes about 320µs.
An EVE_cmd_flashread(0,0,256000); takes about 13720µs.
An EVE_cmd_flashread(0,0,384000); takes about 20550µs.

In Bytes/µs this is 18.46, 14.85, 18.66 and  18.69

So there is some overhead from my function which has less influence on the time with more data copied.
So lets say the flash can transfer 18 bytes per µs.
That results in 264µs for 4752 bytes.
And this also is close enough to show that the QSPI runs at 36MHz.

> I guess the issue may be related to flash read throughput.

Yes, maybe.
But then reading chunks of 2752 bytes from the very same flash chip that Bridgetek is using on their boards really should not be an issue.
And it could very well be that EVE is processing the images line by line and reading only the necessary data with every line.

Speculation.

Again, it does not seem to work like it should and I would apreciate a statement from Bridgetek regarding the issue.



Edit:
I just converted the set to 96x96 pixels.
And it has the same issues, directly using the icons from FLASH does only works up to a certain amount of different icons.
I can use 28 different icons from RAM_G without any issue.
And I can display 28 times the same icon from FLASH without issue.

Now I tried something new.

I changed the code to display only two lines of icons from FLASH:

0 1 2 3 4 5 6
0 0 0 0 0 0 0
This works.

0 1 2 3 4 5 6
7 0 0 0 0 0 0
This fails.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.

Okay. less icons overall (the '-' means the icon is not displayed):

0 1 2 3 4 - -
7 8 9 10 0 - -
This fails.

0 1 2 3 0 - -
7 8 9 10 0 - -
This works.

0 1 2 3 - - 6
7 - 9 - 0 - 0
This works.

0 1 2 3 - - 6
7 - 9 - 10 - 0
This works.

0 1 2 3 - - 6
7 - 9 - 0 - 10
This works.

0 1 2 3 - - 6
7 - 9 - 10 - 10
This fails.

0 1 2 3 - - 6
7 - 9 - 10 - 11
This fails.


Now this is interesting, if this would be an issue with the speed of the FLASH it should work better if there are less icons
on a single row and when there is more space between the icons - this is not the case.

Okay, annother idea, I added
EVE_cmd_dl(DL_COLOR_RGB | WHITE);
lines after each VERTEX2F(), initally one line, then two lines.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.

Now I added BEGIN/END lines to each row of icons.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.

Now I added BEGIN/END lines to every single icon.

0 1 2 3 0 0 0
7 8 9 10 0 0 0
This works.

0 1 2 3 4 0 0
7 8 9 10 0 0 0
This fails.


It still looks like something in EVE is broken and it is not getting any clearer what.

Thank you for the suggestion!

So I added "EVE_cmd_flashread(0,0,86784);" to my TFT_init() function.
And yes, at this point the FLASH already is in QSPI mode.

Then I changed my code to:
EVE_cmd_setbitmap(4096+(2752*0), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(0, 10));
EVE_cmd_setbitmap(4096+(2752*1), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(105, 10));
EVE_cmd_setbitmap(4096+(2752*2), EVE_COMPRESSED_RGBA_ASTC_8x8_KHR, 100, 100);
EVE_cmd_dl(VERTEX2F(210, 10));
...

And now I can display 28 different icons.
Which also verifies in one image that all of the icons in the FLASH are not corrupted.

I switched back to the original code for the first row.
And as you can see in the second attached image it works with 6 different icons from the SPI FLASH
and 21 different icons from RAM-G.
But when I change it to 7 different icons on the first row it completely bugs out and looks like
"20191013_202605s.jpg" of my previous post.


So I guess it is safe to deduce from this observation that the image decoder is not the source of the problem, at least not on its own.

And this looks like a reasonable workaorund, use highly compressed images from RAM-G that are stored in FLASH.
Only 2752 bytes for ASTC 8x8 with 100x100 instead of 20.000 bytes for ARGB1555 is nice.

Yet, this is not as advertised, if there really is a limit to what EVE can display directly from FLASH this should at the very least be documented with details what these limits are and why they exist.

While a funtion named Gpu_CoCmd_Text() does not exist in my own code library for EVE ( https://github.com/RudolphRiedel/FT800-FT813 ),  you left out the most interesting part. :-)

/* Count number of arguments in Cmd_Text for string format*/
uint8_t COUNT_ARGS(const char* str)
{
uint8_t count = 0;
const char *tmp = str;

while (tmp = strstr(tmp, "%"))
{
if (*(tmp + 1) == '%') {
tmp += 2;
}
else {
count++;
tmp++;
}
}
return count;
}

I might borrow this one since it is a portable way to do this.

However, my solution might be a little more inconveniant, but it is definately faster. :-)
A COUNT_ARGS() that is resolved during compilation would be sweet.

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:
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:
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:
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:
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:
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.

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:

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:
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.

>FLASH is in attached state and I can read/write to it in no-fast mode. No blob is present in the FLASH.

For this to work the FLASH has to be in full-speed mode and for full-speed mode a .blob must be installed.

>First of all, am I wrong in assuming that CMD_INFLATE2 reads the FLASH from an address given by >CMD_FLASHSOURCE? Something like:
cmd_flashsource(flash_addr);
cmd_inflate2(ram_g, 64);
Yes, it works this way.

>Secondly, which kind of flash_addr does CMD_INFLATE2 need? A physical address or a >BITMAP_SOURCE-like one (i.e., 0x800000 | phy_addr/32)?

The adress is relative to the FLASH itself, so exactly like in the map file:
unified.blob            : 0     : 4096
map_64x64_ARGB1555.bin  : 4096  : 7040
Wolf_96x96_ARGB1555.bin : 11136 : 5184

EVE_cmd_flashsource(4096);
EVE_cmd_inflate2(MEM_PIC2, EVE_OPT_FLASH,0,0);
EVE_cmd_flashsource(11136);
EVE_cmd_inflate2(MEM_PIC3, EVE_OPT_FLASH,0,0);

>Thirdly, what does CMD_INFLATE2 exactly do? Does it read data from FLASH and inflate them on-the-fly,
>writing the result to RAM_G? Or does it read from FLASH, write data to RAM_CMD,
>then command CMD_INFLATE to RAM_G?

As there are no precautions listed this should decompress directly from FLASH to RAM_G.
Otherwise it would destroy whatever commands that are waiting to be executed in RAM_CMD.
And RAM_CMD is only 4kB anyways.

>By the way, byte₁ at page 115 starts at byte 12, doesn't it?

Yes, I would think so as well.
And to be consistent with other commands it should be called byte0.



Since cmd_inflate2() is practically a twin of cmd_loadimage() I wonder why we even have cmd_inflate2().
A flag OPT_INFLATE for cmd_loadimage() would have been nice as well, and it could have been defined to include OPT_NODL.