And something else entirely, as I am tinkering with ASTC fonts I noticed that EAB still includes astcenc.exe 2.1 while the latest release is 4.5.0.
I replaced the EVE Asset Builder\tools\astcenc.exe with the apropriate version for my system from the 4.5.0 package and so far it seems to be working fine, I still have to see what happens when using the converted fonts though.

I just realized, it has been 10 years since the launch of the FT800.

Please either try the last version I attached (and modify the pins if necessary), or attach a version with the modifications that you did, or well, preferably both. :-)

Hi,

I know that platformio it's better than arduino, but i'm used to work with arduino IDE.

I get you, but it is not so much platformio against arduino but using platformio to do arduino programing. :-)
For me this is not exactly about platformio either, more using platformio with vscode as vscode is a much better editor.
Platformio does a few things better than the arduino ide, like supporting more boards out of the box and allowing to set build flags for example.

On the other side there are limits to what you can do with platformio, like there is no Baremetall support for the RP2040, "only" Arduino,
the ATSAM I am mostly using do not have CMSIS/Baremetall support either in the "Atmel SAM" framework, "only" Arduino und Zyphr RTOS.
Next I have two newer STM32 Nucleo boards that I can not use with platformio, yet.
Then there is RX660, S32K, RH850, PIC, probably countless other controllers with no suport or limited support.
Just saying, I believe the gras is greener over here but it is not all green either. :-)

Trying to compile on Arduino IDE the "hello world" example for an ESP32 i cannot compile, i get theese errors on EVE_cpp_target.cpp, lines 232, 233, and 238. Compiler doesn't know "SPI2_HOST", so i've changed to "VSPI_HOST", and them another compiler error, compiler doesn't know "SPI_DMA_CH_AUTO", after investigating this value can be true or false. Wether i put true or false arduino compiles successfully the example, but after uploading to my Riverdi RiTFT50 it doesn't do anything, black screen.

Can you Rudolph help me to make it work?

Thnak you for your work and help.

Which ESP32 package are you using exactly in what version and with what Arduino IDE?

I checked platform-espressif32 and arduino-esp32.
This sounds like a compatibility issue between one using ESP-IDF 5 and the other using ESP-IDF 4.
However, the latest version of arduino-esp32 is v2.0.9 and it is using ESP-IDF v4.4.4.
And platform-espressif32 added support for arduino-esp32 v2.0.9 with release 6.3.0.
So this really should be the same arduino core that both are using.

Ok, lets see what happens, I am using Arduino IDE 2.1.0 since this is the one I currently have in working condition.
I added https://espressif.github.io/arduino-esp32/package_esp32_index.json to the boards manager and installed the esp32 package v2.0.9.

Ugh, ESP32 board overflow error. :-) First world problems, what board do I actually have? :-)

I selected "ESP32 Wrover Module" for a quick test and apart from a few warnings about missing initializers it compiles.
Fixed these.

I have a "BPI-Leaf-S3" that I only bought for the ESP-S3. And it actually is in the list of boards, nice.
With platformio I usually build for dfrobot_firebeetle2_esp32s3 which is close enough and also in the list.

Checking the pins, EVE_target_Arduino_ESP32.h has other pins configured as I have wired, so I just changed these.
EVE_target_Arduino_ESP32.h is not displayed by the Arduino IDE though since it is in a sub-folder, so you need to add it to the sketch.

...
#if !defined(EVE_CS)
#define EVE_CS 10
#endif

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

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

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

#if !defined(EVE_MOSI)
#define EVE_MOSI 11
#endif
...

With platformio I can set these in the platformio.ini and therefore do not need to change that file.

Checking EVE_config.h, it's set to EVE_RVT50H which I also happen to have on my desk now.
The EVE_RiTFT50 is for RVT50xQBxxxxx which is using a BT815.
But I also happen to have one of these. :-)

Still compiles and now I uploaded it to the board - works. :-)

As you said, in most application cases where the MCU wants to read or write, a standard SPI write would be most efficient.
There can be cases where it may be beneficial such as to reduce latency. e.g. if you want to do a read immediately after an operation which uses the co-processor, then waiting for the command to complete and then doing a SPI read would have more latency than adding a REGREAD command in your list of commands. For latency, one case may be reading the REG_CLOCK.

Ah, yes, thank you.
That is probably not something I will ever use but latency is a good argument.
Then I maybe should change how my function currently works as right now I have it implemented as stand-alone command.
And thinking about it, I would rather use CMD_MEMCPY to read some register as it can be anywhere in the list of commands.
CMD_REGREAD would be something for the end of the command-list since it writes to RAM_CMD and then you need to find out to where exactly.
As I am using REG_CMDB_WRITE (I dropped FT80x support), I am not keeping track of where in RAM_CMD EVE currently is,
so I could not even make my EVE_cmd_regread() function return the offset for reading out the value later.

You could also write many registers together even if not in adjacent registers (e.g. call CMD_PCLKFREQ and then write the display registers)

Yes - but what do you mean in context of CMD_REGREAD?

For RAM_JBOOT, this is not designed to be accessed from the host MCU directly and so should only be used with the recommended methods (such as the custom touch settings in the BT817 datasheet)

I am aware, but I still had to try out if using CMD_REGREAD is working differently in this region. :-)

Yes, we have implemented the commands in BRT_AN_025 directly and so they just add a dummy value which is replaced by the co-processor. We tend to use helper functions instead which then wrap those into more useful commands where you get the value back from the function (via return or pointer). We will look at adding some more of the EVE_LIB functions as helpers in the examples which we are producing for BRT_AN_025 to make these easier to use though, and so thanks for your feedback on this point.

I also find the documentation for these odd, or rather the given C function prototypes.

I implented
void EVE_cmd_fontcachequery(uint32_t *p_total, int32_t *p_used);
and not
void cmd_fontcachequery( uint32_t total, int32_t used );

My function does not write the values to RAM_CMD, it writes two 0UL and then reads from RAM_CMD and
writes back the retreived values if the pointers are not NULL.

Additionally, using "int32_t" for "used" does not seem to make any sense here.
Even your own example code agrees with me on this:

uint32_t total, used;
uint16_t ram_fifo_offset = rd16(REG_CMD_WRITE);
cmd_fontachequery(total, used);
total = rd32(RAM_CMD + (ram_fifo_offset + 4) % 4096);
used = rd32(RAM_CMD + (ram_fifo_offset + 8) % 4096);

It should not be possible for "used" to ever have a negative value.

Please review every single signed parameter and change it to unsigned when applicable. :-)
I wrote this at least once before in some other post here, a signed radius parameter for CMD_CLOCK makes no sense and there are likely more examples to be found.

Hi Rudolph,
Thanks for your detailed information, we will review your feedback,
Yes, the main difference is that having the BLOB and Flash in full speed prevents the command from setting a value which exceeds the spec of the PLL frequency. Without these it may set a value which exceeds the allowable spec and so may affect reliable operation.

Best Regards, BRT Community

Thank you for the confirmation!
As I wrote, I never encountered the issue but at the very least my code is running more robust now after I changed it to not use CMD_PLKFREQ anymore.
Not that CMD_PLKFREQ is not working, but as I provide a library for anyone to use I can not rely on the content of an external flash that might not even be there.
I do not even have flash initialization in my init function so it can be done if required.

I believe that table is not incorrect, but a bit misleading.
I believe this desribes ranges around 1.8V, 2.5V and 3.3V for all VCCIOn voltages.
I do wonder why this is structured as it is, why isn't the voltage range just from 1.62V to 3.6V?

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