Yes, the command FIFO will automatically loop around.

Apart from that you do not need BEGIN(BITMAPS) for a CMD_TEXT, using COLOR_RGB before CMD_TEXT is exactly the way to do it.

And I just tried it, using BEGIN(BITMAPS) does not break it.

//EVE_cmd_dl(DL_BEGIN | EVE_BITMAPS);
EVE_cmd_dl(DL_COLOR_RGB | BLACK);
EVE_cmd_text(100,200,28,0,"Black");
EVE_cmd_dl(DL_COLOR_RGB | RED);
EVE_cmd_text(100,220,28,0,"Red");
EVE_cmd_dl(DL_COLOR_RGB | GREEN);
EVE_cmd_text(100,240,28,0,"Green");
//EVE_cmd_dl(DL_END);

With or without the BEGIN/END pair I get the same result, three lines of text in black, red and green.

Yes, this also works with custom UTF-8 fonts from FLASH, I just tried that as well.

Since the inflate command can not know how much memory will be required to store the result of inflation, EVE writes back the last memory location used in a unconventional place.  In the "EVE School" example from Matrix Orbital, you can see this in action on the last line of the LoadJPG() function in "process.c".

https://github.com/MatrixOrbital/EVE-School

Well, the question was about CMD_INFLATE, not CMD_LOADIMAGE.
And you are using CMD_GETPTR after CMD_LOADIMAGE in your example.

The Programming Guides up to 1.2 for BT81x state for CMD_GETPTR:
"Get the End Memory Address of Data Inflated by CMD_INFLATE"

For CMD_LOADIMAGE we have CMD_GETPROPS - although this is kind of useless.
The pointer returned is the start-address which we already fed as parameter into CMD_LOADIMAGE.
And width and height are not helpfull without the format of the decoded image.


I just gave it a quick try with a FT813 and CMD_GETPTR does not work for CMD_LOADIMAGE.

EVE_cmd_inflate(MEM_LOGO, logo, sizeof(logo));
test_pointer1 = EVE_cmd_getptr();
EVE_cmd_loadimage(MEM_PIC1, EVE_OPT_NODL, pic, sizeof(pic));
test_pointer2 = EVE_cmd_getptr();

EVE_cmd_dl(DL_COLOR_RGB | BLACK);
EVE_cmd_number(120, 300, 28, EVE_OPT_RIGHTX, test_pointer1);
EVE_cmd_number(120, 330, 28, EVE_OPT_RIGHTX, test_pointer2);

This prints the same number twice and it is the end-address of the deflated logo image.
Hmm, well, it actually is the first address after the deflated data.

So, how does the processor know when it is the end of our stream of bytes?

From what I understand this is a property of the ZLIB compression that is used.
At the end of the data is a checksum and the decompression if finished when the checksum checks out.

Interesting, I was not aware of this.
And I just tested it, you can throw EVE completely off the roof with editing a single byte in a compressed picture.
I never observed this as an issue though.

Isn't that the "norm" that the panels integrate the touch controller?
At least I have not found a panel yet that has the rasterizer for capacitive touch attached but no touch-controller.
I could provide dozens of examples with touch controller.
Please provide one example of a display with capacitive touch without touch controller.

The reason for this would be that the lines to measure the capacitance need to be a lot more sensitive and therefore are much more prone to faults, adding a connector would make the connections a lot longer, add the resistance from the connector and would require a much bigger connector.
Usually the touch controllers on the displays are even shielded with a small metal plate that also provides stiffness.

Adding a 6 to 12 pin connector for the I2C connection of the touch-controller is something entirely different.

I built a unit with a couple of touch-buttons for a customer and went with a touch-controller chip on a separate board due to mechanical restrictions.
And to keep the story short, I would not do it this way anymore.

Sorry to say so, but your schematic is nearly unreadable.
Using labels for GND would help and not drawing signals thru the symbols.

I found more issues with EAB 1.4.0 beside the UTF-8 ones that are already under investigation.

The release notes state:
- Add the "Verify" function in flash utility

And yes, there is a checkmark-button for this in the EAB GUI.
However, when you activate the option and click "UPDATE", you only get the default output of "ProgFlash.exe"
in the Log window:
Welcome to BT81X Flash Programming Utility v1.0
Copyright(c) Bridgetek Pte Ltd All Rights Reserved

Usage: ProgFlash [command] [argument]

module       Select Program Module [ FT4222 (default) | MPSSE ]
chip         Select Program EVE Chip [ BT815 | BT816 | BT815A ]
erase        Erase all of flash
newblob      Install blob <file_name> in flash
write        Write <file_name> to flash (assumes flash is already erased)
update       Write <file_name> to flash, erasing if necessary
read         Read all of flash into <filename>

As if the "ProgFlash.exe" is supposed to have a verify command but the version shipped with the EAB package does not.
The "ProgFlash.exe" from EAB 1.2 has the exact same output, the newer version is 512 bytes longer though.
And I have not found a verify command in the .exe but the list above is missing the "detect" command.

Regarding "detect", it does work as a command from the command-line but fails from the GUI.
And the GUI suggests that there is a parameter to avoid measuring the writing speed, I wonder if that is there and what is.


When I use ProgFlash to erase a chip this is what happens:
---
D:\Chip_Test>ProgFlash module MPSSE erase
 Information on channel number 0:
 Flags=0x2
 Type=0x8
 ID=0x4036014
 LocId=0x422
 SerialNumber=
 Description=Single RS232-HS
 ftHandle=0x0

handle=0x7197f0 status=0x0
VC1 register ID after wake up 7c

 reg_touch_rz =0x7fff
 reg_touch_rzthresh =0xffff
 reg_touch_tag_xy=0x80008000
 reg_touch_tag=0x0

Switch flash status to FULL. Result: SUCCESS
Erasing Flash...
Progress ERASE 1
Progress ERASE 90
Switch flash status to BASIC. Result: SUCCESS
Progress ERASE 100
Erase Flash successfully
---

Why does it switch the flash to FULL in order to erase it?
There is no need to this, the chip-erase command will not work any faster.
What it does however is making it impossible to erase chips with EAB that do not work with the "unified.blob".
For example AT25SF641-SUB-T and AT25QF128A-SHB-T from Adesto.


On a side-note, what is a BT815A?

And why does EAB come with a "unified.blob", a "BT815.blob" and a "BT816.blob" now?
Which really is the same file with three different names.


- Replace 'numpy' by 'tinynumpy' to reduce distribution package size

No numpy to be found anywhere in the EVE Asset Builder installation.