I just found that EAB 2.10.0 was released.

I went across it, converted images, verified images, converted a font, put that font in a flash container, packed that flash container with the asset compressor, converted the resulting .zopfli file with the BIN2C tool.
And this went very smoothly. :-)

I found one small issue though.
When converting fonts, the "Input Character:" file selection gets cleared every time a new font is selected.

Edit: just found 2.10.1 and the bug is still in while this post is still missing approval.
Edit2: and I just found 2.10.2 which is dated 2023-11-10.

I tried to use the PNG/JPEG Validator and found that the "VALIDATE" button is inactive unless I set the option "Generate Optimized File".
It still works when deselecting "Generate Optimized File".
But the "VALIDATE" button is inactive again when I remove the image and does not become active when adding an image.

This reminded me of your EVE-USB2SPI-KIT-B, are there plans to sell these thru DigiKey or Mouser and perhaps EVE4 series displays as well?
And I would like to buy an EVE4x-40G-IPS for my collection but shipping from Canada directly is a bit expensive while DigiKey and Mouser offer free shipping to EU and handling of the taxes beforehand.
Not asking for free shipping by Matrix Orbital, it's just so conveniant for me to order from Mouser or Digikey and I also can order a bag of other parts at the same time.
Most of my EVE2 and EVE3 series Matrix Orbital displays I ordered from Digikey or Mouser.

Edit:
Mouser is listing the EVE2-USB2SPI-KIT-B now, although there is no stock, yet.

I downloaded and installed EVE-Asset-Builder-setup-2.9_rc1.zip and I have an odd issue.

The button to open the explorer window to select the output folder is not working for me in "Asset Compressor" / "Compress".
When I use the button on the second tab "Validate" though it works, I can select the output folder, I have to confirm twice and
now the output folder is also changed on the "Compress" tab.

I have a function that works fine for putting the attached flash in fast mode.
Check EVE_init_flash() from: https://github.com/RudolphRiedel/FT800-FT813/blob/5.x/EVE_commands.c
My EVE_cmd_flashfast() also is a bit different in that it does not only issue the command, it waits for completion, reads back
the return value from Eve and returns that value.

2. Does the flash need to be detached, attached back and then put into fast mode?

No, it does not, what I usually observe is that the status for the flash is "Basic" after initialization.

Can it not be put into fast mode straight after initialization (and eventually checked if is in basic mode)?

In my basic example I call my EVE_init(), set the backlight PWM, calibrate the touch.
Then I call EVE_init_flash() and if it returns E_OK, a .xfont file is read from the flash.
So yes, pretty much straight after initialization, at this point no images are loaded to RAM_G and only the initial empy display list is executed.

Ok, Arduino IDE 1.8.19 it is.
I swapped around the /AppData/Local/Arduino15 folders to make the 1.x one active.
Then I added https://espressif.github.io/arduino-esp32/package_esp32_index.json to "Addtional Boards Manager URLs" and installed the ESP32 package v2.09,
started IDE 1.8.19, opened the projected that is attached above, selected "DOIT ESP32 DEVKIT V1" since that worked with the ESP32 WROOM-32 board when using PlatformIO.
I changed the pins again:
#if !defined(EVE_CS)
#define EVE_CS 13
#endif

#if !defined(EVE_PDN)
#define EVE_PDN 12
#endif

#if !defined(EVE_SCK)
#define EVE_SCK 18
#endif

#if !defined(EVE_MISO)
#define EVE_MISO 19
#endif

#if !defined(EVE_MOSI)
#define EVE_MOSI 23
#endif

And it compiles just fine.
I can not get it to upload to the board though, something about the serial connection or the drivers not working.
On the serial monitor I get this though when pushing the reset button:
ets Jun  8 2016 00:22:57

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xe
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x0,hd_drv:0x00,wp_drv:0x0
mode:DIO, clock div:2
load:0x3fff0030,len:1184
load:0x40078000,len:13132
load:0x40080400,len:3036
entry 0x400805e4

And still:
A serial exception error occurred: Cannot configure port, something went wrong. Original message: PermissionError(13,
Note: This error originates from pySerial. It is likely not a problem with esptool, but with the hardware connection or drivers.

I hate it when crap like this happens.

For the chance that a different board might behave differently I am trying to buy a new ESP32 board.
But all the ESP32-WROVER boards I can find are using a CH340 USB/Serial chip like the Wroom32 board I already have.

Hmm, I had more boards but I can't find these anymore, like a ESP32-CAM but this one did not have USB at all.


Edit:
I got two new ESP32 boards and while one was advertised as "ESP32 WROVER Development Board" it turned out as WROOM32 board.
So I have two different new WROOM32 boards now.

My old WROOM32 board is still not working, same error, for whatever reason.
One of my new boards is using a CH340C, the other one is using a CP2102. I can upload to both of the new boards just fine.

And I learned something, never ever use "Sketch" / "Add File..." in Arduino IDE 1 in order to edit a file from a sub-folder that is otherwise not getting displayed.
I added EVE_target/EVE_target_Arduino_ESP32.h to change the pins.

And this opportunity to learn something did cost me a number of hours.
The seemingly exact same code worked fine when compiled with PlatformIO and resulted in a watchdog-reset when compiling it with Arduino IDE 1.8.19.
It hang in EVE_cpp_target.cpp / EVE_init_spi() when calling spi_bus_initialize().
And the problem in the end was that when adding the file the Arduino IDE actually copies it to the project folder.
I edited a copy of EVE_target_Arduino_ESP32.h that the code does not use while EVE_target/EVE_target_Arduino_ESP32.h remained untouched and therefore the I/O pins for the SPI were all wrong...ouch.

Now the code works from both the Arduino IDE 1.8.19 and PlatformIO with only a minute detail.
The code compiled with PlatformIO runs a little bit faster since I compile it with -O2 while the default is -Os.


And to my surprise, the Arduino version runs significantly faster now than the native version.
Using the same ESP-IDF based code.
It looks like the ESP-IDF SPI functions in arduino-esp32 are not the same, the pauses between single byte transfers when sending a couple of bytes are shorter.
The pauses are still ridiculously long for a controller running with 240MHz, I measure 9.9µs (PIO Arduino, -O2), 10.0µs (Arduino, -Os) and 13.2µs for (PIO ESP-IDF, -O2).
In contrast I measured 640ns with an ATSAMC21 running 48MHz and 280ns with an ATSAME51 running 120MHz but these are not burdened with a RTOS and my code writes directly to the SPI registers.

The screen update is done using DMA and while the transfer of the data takes the same 113.48µs, the times from CS down to start of the transfer and from end of the transfer to CS up are different.

CS down to start
Arduino: 20.3µs
ESP-IDF: 27.6µs
C21: 860ns

end of data to CS up
Arduino: 5µs
ESP-IDF: 8.4µs
C21: 780ns

I do wonder what is going on there with ESP32.

Another comparision, the 600MHz Teensy 4.1 has 225ns between two SPI.transfer() calls, so going thru the Arduino SPI class.

Hello,

Thanks for your feedback, yes we are going through the Programmers Guide to review the data types and we will update them where applicable. As you said, some of the signed/unsigned types are not the optimal ones.

Thank you, I will gladly remove a couple of casts then. :-)

For the CMD_REGREAD, sorry meant to also mention CMD_MEMWRITE in that reply. You could use the CMD_REGREAD and CMD_MEMWRITE so that you can do reads and writes with low latency between them.

Oh, CMD_MEMWRITE.
I implemented it, again as standalone command like I still have CMD_REGREAD.
And then I commented it out and tagged it as pointless.
I did not even get around implementing it with support for more than 4kiB of data.
Ok, I admit the low latency argument gives this command purpose, at least when using it with well below 4kiB of data.
But I still can not come up with any real use case, outside of perhaps testing the chip that is.
I like to make EVE cry, obviously. :-) But certainly not when doing an actual application.

What is CMD_REGREAD supposed to be used for?
It does not seem to have any use when building a display-list and outside of display list handling it is more efficient to read from the address directly.

I am playing with EVE_cmd_regread() and EVE_memRead32() on a BT817 - the results are the same for the most part.

for(uint8_t index=0; index < 32; index++)
{
    test1[index] = EVE_cmd_regread(0x302000UL + (index*4));
    test2[index] = EVE_memRead32(0x302000UL + (index*4));
}

Some of the not documented registers seem to be pretty usefull, like 0x3021A8UL + 0x3021ACUL, I wonder why these are not documented.
Reading from the not documented REG_DATESTAMP returned a string: "2019-10-28_2.5.3"
Reading from for example 0x303000 returns 0xdeadbeef.
Reading from 0x309218 returns 3, whatever that means. :-)

Reading from RAM_JTBOOT (0x30b000) is returning inconsistent results between EVE_cmd_regread() and EVE_memRead32(), not like EVE_cmd_regread() is executed with higher privilege, more like what is returned for this memory region is not actually accessible for both functions.

The region from 0x309000 to 0x30914e has a few documented registers like REG_TRACKER and REG_FLASH_SIZE,
it is not mentioned in the memory map though, "Table 5-1 BT817/8 Memory Map".


I also had a look at the code for BRT_AN_025.
The functions EVE_CMD_REGREAD(), EVE_CMD_GETPROPS(), EVE_CMD_FONTCACHEQUERY(), EVE_CMD_GETIMAGE() and EVE_CMD_GETPTR()
are not implemented to do anything usefull and all these write out the parameters to EVE that are return parameters.
There is EVE_LIB_GetProps() though.

EVE_CMD_PCLKFREQ() does write the parameter "factual" although this is a return parameter.
EVE_CMD_FLASHFAST() does write the parameter "result" although this is a return parameter.
EVE_CMD_MEMCRC() does write the parameter "result" although this is a return parameter.