I just found this in BRT_AN_033 BT81X Series Programming Guide version 2.3 which was not there in the previous revisions:

Important Note:
When using this command, the flash BLOB is required in order to ensure that the calculated PLL2
setting remains within the specification of 228MHz. Therefore, before using this command, ensure
that the following steps have been taken:
- External Flash chip connected to the BT817/8
- External Flash chip has the BLOB installed in the first 4096 bytes beginning at 0
- External Flash chip has been set to full-speedmode

Is this an editorial error?

I have been using CMD_PCLKFREQ in my init from the very beginning when the documentation for the bits in REG_PCLK_FREQ was not correct.
I have never set the flash to fullspeed mode before using CMD_PCLKFREQ.
Also the the flash was empty for at least the first tries of bringing up a new BT817 module.
It works just fine this way.

What dependency is supposedly between the external flash chip and the PLL2 for the pixel clock?



And I just did what I guess was a bit overdue, I calculated all possible frequencies for the pixel-clock
that can be setup with PLL2 thru writing to REG_PCLK_FREQ.

REG_PCLK_FREQ[11:10] is the range for the PLL2 frequency and not part of the calculation, my guess this is used for validation.
00: 20 – 40 MHz
01: 40 – 80 MHz
10: 80 – 160 MHz
11: 160 – 228 MHz

REG_PCLK_FREQ[9:4] is multiplied by 12MHz and the resulting PLL2 frequency must not be higher than 228MHz,
so the effective range for this 6 bit value is 1 to 19.
I really hope this value can go a couple of steps higher in a future device.

REG_PCLK_FREQ[3:0] is the divider and the pixel clock is calculated with this formula:
PCLK frequency = PLL2 frequency / REG_PCLK_FREQ[3:0] / 2
This makes the useable range for this 4 bit value to go from 1 to 12, at least is unlikely that higher values are of use.
The pixel clock must not be higher than 96MHz.

I put it all in a spreadsheet and sorted it by pixel clock.
These are the top values:

11   10   9   8   7   6   5   4   3   2   1   0         Range   Frac9:4   Frac3:0   PLL2 Freq   PCLK Freq
1   1   0   1   0   0   1   1   0   0   0   1   3377   D31   3   19   1   228   114,000
1   1   0   1   0   0   1   0   0   0   0   1   3361   D21   3   18   1   216   108,000
1   1   0   1   0   0   0   1   0   0   0   1   3345   D11   3   17   1   204   102,000
1   1   0   1   0   0   0   0   0   0   0   1   3329   D01   3   16   1   192   96,000 x
1   1   0   0   1   1   1   1   0   0   0   1   3313   CF1   3   15   1   180   90,000 x
1   1   0   0   1   1   1   0   0   0   0   1   3297   CE1   3   14   1   168   84,000 x
1   0   0   0   1   1   0   1   0   0   0   1   2257   8D1   2   13   1   156   78,000 x
1   0   0   0   1   1   0   0   0   0   0   1   2241   8C1   2   12   1   144   72,000 x
1   0   0   0   1   0   1   1   0   0   0   1   2225   8B1   2   11   1   132   66,000 x
1   0   0   0   1   0   1   0   0   0   0   1   2209   8A1   2   10   1   120   60,000 x
1   1   0   1   0   0   1   1   0   0   1   0   3378   D32   3   19   2   228   57,000 x
1   0   0   0   1   0   0   1   0   0   0   1   2193   891   2   9   1   108   54,000 x
1   1   0   1   0   0   1   0   0   0   1   0   3362   D22   3   18   2   216   54,000
1   1   0   1   0   0   0   1   0   0   1   0   3346   D12   3   17   2   204   51,000 x
1   0   0   0   1   0   0   0   0   0   0   1   2177   881   2   8   1   96   48,000 x

The first three are not valid as these are above 96MHz.
The lines with the "x" at the end are also found in the table 4-11 of the BT817/8 datasheet.

This is a bit of a surprise for me as I went the first time thru this, there are very few frequencies to choose from above 60MHz.
Totally plausible when put in a table like this.

I was feeding CMD_PCLKFREQ with 71MHz for the 1280x800 displays.
And now I see that this is not even possible and the result likely was 72MHz.
The reason why I even looked into this is that the 10.1" panel with 1280x800 that I am trying to add a configuration for
is using a pixel clock of 72.4MHz (typical).
Ok, no problem, 72MHz it is.

I went with using CMD_PCLKFREQ as my first calculations with the previously incorrectly documented bits for REG_PCLK_FREQ got me nowhere.
And using CMD_PCLKFREQ did not only work, it looked like it allowed more flexibility over the apparently select "few" values
for REG_PCLK_FREQ in the datasheet.
Now I will remove the call to CMD_PCLKFREQ.

And as a final thought, these are the values if the PLL2 frequency would be allowed to go up to 480MHz:

   Range   Frac9:4   Frac3:0   PLL2 Freq   PCLK Freq
E02   3   32   2   384   96,000
DF2   3   31   2   372   93,000
DE2   3   30   2   360   90,000
DD2   3   29   2   348   87,000
DC2   3   28   2   336   84,000
DB2   3   27   2   324   81,000
E83   3   40   3   480   80,000
DA2   3   26   2   312   78,000
E73   3   39   3   468   78,000
E63   3   38   3   456   76,000
D92   3   25   2   300   75,000
E53   3   37   3   444   74,000
D82   3   24   2   288   72,000
E43   3   36   3   432   72,000
E33   3   35   3   420   70,000
D72   3   23   2   276   69,000
E23   3   34   3   408   68,000
D62   3   22   2   264   66,000

The granularity is only a little higher so "just" allowing the PPL2 to run much higher does only achieve very little.

Adding a pre-scaler to bring down the 12MHz to a lower value before it is fed into the PLL2 would be much simpler to implement,
under the assumption that the multiplier already works all the way up to 63x.
So I kind of wish now that a future device would feature a clock pre-scaler for PLL2. 

This is the top of the table with a pre-scaler of 4 so the PLL2 gets 3MHz as input frequency:

   Range   Frac9:4   Frac3:0   PLL2 Freq   PCLK Freq
FF1   3   63   1   189   94,500
FE1   3   62   1   186   93,000
FD1   3   61   1   183   91,500
FC1   3   60   1   180   90,000
FB1   3   59   1   177   88,500
FA1   3   58   1   174   87,000
F91   3   57   1   171   85,500
F81   3   56   1   168   84,000
F71   3   55   1   165   82,500
F61   3   54   1   162   81,000
F51   3   53   1   159   79,500
F41   3   52   1   156   78,000
F31   3   51   1   153   76,500
F21   3   50   1   150   75,000
F11   3   49   1   147   73,500
F01   3   48   1   144   72,000
EF1   3   47   1   141   70,500
EE1   3   46   1   138   69,000
ED1   3   45   1   135   67,500
EC1   3   44   1   132   66,000

First of I feel like I need to apologize, I am certain that a live conversation would come across friendlier. :-)
Sorry.

Thanks for taking some time.

This is a mere coincidence, I only analyzed the SPI traffic from GD2 library to be able to add
support for the GD3X to my library.
I do not know why, but there is close to no documentation for the GD3X.
Anyway, I got all the data I was looking for and some I was not looking for.

The library for gameduino 23x has the file wiring.h as its axis of operation, within that file the starting of the EVEx chips occurs.

This is the library I've been testing with: GDSTx. You just have to place it in the libraries folder of the arduino IDE.

I already saw that it differs from GD2 library but did not have a chance so far to actually run it and look at the trace.
I opened an issue on Github to ask about the target support.
Looks like of the boards I have "only" the Teensy 4.1 is supported and I did not get around connecting a display, yet.

I uploaded the video examples, as evidence that it is possible to draw arc segments, not to test them; As I said, I have spent several years trying to understand the library and adapt it to be able to use it with teensy 4.1 and especially with its SDIO reader. Over time there have been several versions of the library, which is why I decided to upload the changes to Github to always have a backup. Unfortunately several examples were lost, when the hard drive I was working on failed a couple of years ago; only youtube videos remained.

I apologize for not being able to share the complete examples or the libraries, as I no longer have them.

I share the example for drawing arc segments, which resulted from all those experiments.

Absolutely no need for you to apologize.
I liked the examples and also the last image looks very nice.
Only my perspective is a bit different, my view is from the bottom and not from the top.
I spent quite a number of years now writing my own library.

And while I still apreciate your examples, my view from the bottom tells me that GD2 library and also GDSTx library
has a number of issues at the very core, starting with that the initialization bears close to no resemblence with the description in the programming guide.
Yes, this is way off topic now and again coincidence that I even saw this.

Have a look at my library: https://github.com/RudolphRiedel/FT800-FT813/
Not to switch over, but to take whatever you might need.
My library does for example use DMA for the display-update SPI transfers on the Teensy 4 boards.

I just checked the code and while it works this is probably the worst solution to solve the problem.

  GD.Begin(LINE_STRIP);
  GD.ColorRGB(0xFFFFFF);
  int x, y;

  for (int i = 0; i <= valor; i++) {
    x = 400 + 100 * cos(i * PI/180 );
    y = 240 + 100 * sin(i * PI/180 );
    GD.Vertex2f(16*x, 16*y);
  }
  GD.RestoreContext();

So the segment of the circle is actually composed of a LINE_STRIP for which the coordinates are calculated.
Not only does this take rather long to calculate, one full circle would take 18% of the display list.

Not that I have a simple and elegant solution for the issue, for circles I am using two DOTs and making it to an arc might involve SCISSORS.
Or two DOTs and a RECTANGLE could be used.
A different solution would be to render the arc in a bitmap and display it.

An arc command would be as nice, yes, but this is something we do not currently have.

Hello,
how can I create, upload to the display (BT815) and call a widget?
Note: I can't use the ESD.

Thanks

No, uploading functions for the command co-processor to execute and add lines to the display-list based on supplied parameters is not possible,
or at least there is no documented API for that.
And the few bits and pieces that I gathered about the undocumented API do not seem to allow this either.

What you can do is pre-calculate sequences of display-list commands, copy these from the display-list to RAM_G and then use CMD_APPEND to add these snippets into your display list.
Ok, this not not CMD_MYBUTTON but you can still reduce the SPI traffic significantly.
In my simple example code I am using this mechanism only to create a section of display list commands that never change, a colored rectangle on top, a line to separate things, a text in the middle and o logo.

Sure, you could take it one step further and manipulate the snippets before using them.
But this would mean to mix co-processor commands for the display llist and memory functions,
probably does not much to reduce the SPI traffic and the result is probably rather slow compared to
do the display update in one DMA transfer.

There also is CMD_NEWLIST / CMD_CALLIST which allows to write co-processor commands verbatim to RAM_G and execute this snippets during display list building.
The difference to CMD_APPEND is that you get for example cmd_button(20, 20, 60, 60, 30, 0, "OK!"); in RAM_G and not all the display list commands that the co-processor is generating from a widget command.

Because of other integrations, I choosed not to work with PlatformIO even if I agree that the plain Arduino IDE is way too basic.

I am only using PlatformIO because I would not even call "Arduino IDE 1.x" an IDE and the 2.0 still has nothing that VSCode could not do better.

I tried to move your library to the plain Arduino and it was too tricky because of PlatformIO (compiler definitions are not supported by the Arduino IDE but only using the CLI).

Hmm, I had an intern for the last two weeks and I gave him an Arduino UNO and an EVE3-50G to play with.
I took my current example and after a little convincing it ran in Arduino IDE 1.8.19.
He used my archive with Arduino IDE 2.0.3 on his own notebook and apart from that the "IDE" killed the project a couple of times it worked fine.

Also, I am pretty much done. All I have to do is integrating the "low level" APIs with my own abstraction layer that allows to draw items using OOP and completely forget about commands and the underlying BT C APIs.

Well, you still could use my library as a reference point.

Everything works but I am trying to understand what does not work with flashing. Most of the issues I had is because of the very poor documentation. But after reading tons of posts here and examples, I am pretty sure that the code is ok (I also compared the flashing procedure to your code).

I was wondering why BT does not provide a clear documentation of these procedures. Even reading the BT IC datasheet I could not find exhaustive explanations.

Have you ever had problems with unreliable writing on the flash?

No, I can't recall that I ran into severe issues when I implemented the flash commands.
But then I am probably not a good reference here since I am doing this for a number of years now. :-)
One thing that is important when using these functions though and that is that the alignment requirements must be strictly followed.
This is why I added these to the comment on top of my functions:

/* This is meant to be called outside display-list building, it includes executing the command and waiting for completion, does not support cmd-burst.*/
/* write "num" bytes from src in RAM_G to to the external flash on a BT81x board at address dest */
/* note: dest must be 4096-byte aligned, src must be 4-byte aligned, num must be a multiple of 4096 */
/* note: EVE will not do anything if the alignment requirements are not met */
/* note: the address ptr is relative to the flash so the first address is 0x00000000 not 0x800000 */
void EVE_cmd_flashupdate(uint32_t dest, uint32_t src, uint32_t num)
{
    eve_begin_cmd(CMD_FLASHUPDATE);
    spi_transmit_32(dest);
    spi_transmit_32(src);
    spi_transmit_32(num);
    EVE_cs_clear();
    EVE_execute_cmd();
}

And yes, it took a few iterations to make the code this "simple". :-)

I am normally using CMD_INFLATE to get the data into RAM_G since especially fonts are usually highly compressable, probabably because they contain empty glyhps and because all glyphs need to be the same pixel size.

And then flashing from the host controller is not really meant for regular use, for a bigger project with several fonts and images I would flash the image file from EAB with a USB/SPI adapter.

I was forgetting one important info.
I carefully observed with the oscilloscope the timings of the ESP32 SPI using both ESP32-IDF (with and without DMA) and the Arduino SPI for ESP32.
The results are:
- The native ESP-IDF performance is poor (even using transactions) because there are lengthy gaps between every transmissions.
- The Arduino SPI library is much way faster.
In the ESP32-IDF forums I was told that the Arduino wrapper does NOT use the IDF abstraction APIs but goes directly to the ESP32 registers. They also said that the IDF library is typically much slower because Espressif wants to provide a stable abstraction over future silicons.

Oh? When did this change?
When I implemented the ESP32 Arduino code back in end of 2020 it was really really slow.
On a first test with the SPI class my ESP32 was running the display update in 1476µs while the Arduino UNO
was running the exact same code in 516µs.
https://github.com/RudolphRiedel/FT800-FT813/issues/14

The SPI class was running on top of ESP-IDF back then.

So I may need to try this again.
What I am not seeing in the current ESP32 SPI class is DMA support though.
And what I do see is that there is a heck of a lot of code that gets executed everytime in order to try to make the implementation bullet proof.
So even if it really is running faster it still is running with the handbrake engaged.

Update: I was able to reliably flash the display with the same code but changing cable.

Anyway, I always have to reboot the display (after flashing), otherwise the FLASH always stay in the "INIT" state and never changes.
How can I make the display flash transitioning from INIT to (at least) BASIC?

Is rebooting after flashing a mandatory action?

No, there is no need to put the flash thru the init state, it even should go thru the init automatically and reach BASIC state.

From my example, shortened a little:

void TFT_init(void)
{
    if(E_OK == EVE_init())
    {
         EVE_memWrite8(REG_PWM_DUTY, 0x30);  /* setup backlight, range is from 0 = off to 0x80 = max */
        touch_calibrate();

    #if 0
        /* this is only needed once to transfer the flash-image to the external flash */
        uint32_t datasize;

        EVE_cmd_inflate(0, flash, sizeof(flash)); /* de-compress flash-image to RAM_G */
        datasize = EVE_cmd_getptr(); /* we unpacked to RAM_G address 0x0000, so the first address after the unpacked data also is the size */
        EVE_cmd_flashupdate(0,0,4096); /* write blob first */
        if (E_OK == EVE_init_flash())
        {
            EVE_cmd_flashupdate(0,0,(datasize|4095)+1); /* size must be a multiple of 4096, so set the lower 12 bits and add 1 */
        }
    #endif

        if (E_OK == EVE_init_flash())
       {
          EVE_cmd_flashread(MEM_FONT, 84928, 320); /* copy .xfont from FLASH to RAM_G, offset and length are from the .map file */
       }
...
}

This code assumes that the flash is completely empty and it does not bother to check the state of the flash first since there practically is no way
that a correctly attached flash is not in state BASIC at this point, especially not after full initialization of the display.
The first 4k contain the binary blob that is necessary to put the flash into state FULL so this is flashed first.
After that my EVE_init_flash() function is called to put the flash into state FULL - and it does a whole lot more than just that, have a look.
If the flash was sucessfully initialized to state FULL the whole image is flashed with CMD_FLASHUPDATE.
The next call to EVE_init_flash() is only there as the block that flashes the image can be commented out after the first time.

So even on a first run with flash update active this just runs thru, no need for a reset at all.

And the only reason I am doing this in two steps is that writing to the flash is a lot faster in state FULL.

If the flash is viable then REG_FLASH_STATUS automatically indicates state BASIC after power-up and from there you can use CMD_ FLASHERASE, FLASHWRITE, FLASHUPDATE, FLASHPROGRAM, FLASHREAD and FLASHDETACH.

The "ASSET COMPRESSOR" in EAB says: "Compress asset by using Zlib or Zopfli library".
And the difference is that Zopfli is compressing better but eats more computrons doing so.

A simple way to draw a meter could be to use cmd_gauge with OPT_NOBACK and OPT_NOTICKS on a fancier background image.

What I have done a couple of times now in projects which is even simpler is to use two rectangles on top of each other for a frame and then use a third rectangle within the frame, not as fancy but very efficient.
And you can round the edges of rectangles with the line width.
The result is more like a battery indicator.
It could be combined with changing the color, lines on top to form segments, numbers on the side and/or a number below/on top to show the current value.
I displayed values for temperature, voltage, torgue and rotational speed next to each other.
Funtionality was the goal, not so much eye-candy.

Have you checked with CMD_FONTCACHEQUERY how many glyphs are actually used?
In my experience it does not flicker though, using more characters than there is room for in the cache did result in crashes for me.

And I just checked the timings, I am using these as well.
Except for the magic cookie "0xD12" as my library configures the display clock by Hz.
"0xD12" is 51MHz though according to table 4-11 of the datasheet and I am using 51MHz.

How fast do you update the display?
There is flickering when you try to update the display list faster than EVE can display it.
With the given timing parameters the frame rate is 59,76 Hz so the pause between two updates should be
longer than 16.73 ms.