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.

Quote from: Rudolph on November 23, 2022, 03:40:57 PM

But that is just a theory for the moment, I am not entirely sure that the 40x40 pixels the font
converter outputs is really the size of the glyph.

The font convertor will take into account all character sizes in the input character set but doesn't not alter the glyph size for each individual character. For example, some characters may extend below the normal font baseline, and some may extend above the average character height, this is taken into account when setting the overall glyph width and height for all characters, so each glyph may be 40*40 but the given character within this glyph may not utilise the full 40*40 pixel size.

Well, that wasn't the question.
The question is if the width and heigth the font converter is reporting is actually the size of the bitmaps
as this looks like this is not necessarily the case:

Generated Folder: NotoSansSC-Regular_36_Extend
Format:           COMPRESSED_RGBA_ASTC_8x8_KHR
Compressed:       thorough
Layout Width:     80
Layout Height:    8
Pixel Width:      40
Pixel Height:     64

Generated Folder: NotoSansSC-Regular_36_Extend
Format:           COMPRESSED_RGBA_ASTC_10x5_KHR
Compressed:       thorough
Layout Width:     64
Layout Height:    8
Pixel Width:      40
Pixel Height:     40

The same font converted to the same target size should not have a height of 64 for ASTC 8x8 and
a height of 40 for ASTC 10x5.

Using a smaller size I get this:
Generated Folder: NotoSansSC-Regular_32_Extend
Format:           COMPRESSED_RGBA_ASTC_8x8_KHR
Compressed:       thorough
Layout Width:     64
Layout Height:    5
Pixel Width:      32
Pixel Height:     40

And the only reason I am asking is that knowing the sizes of the glyphs in bytes helps with setting up the fontcache.
Well, maybe that is something that the font converter could output in addition, bytes per glyph.

Quote from: Rudolph on November 23, 2022, 04:10:10 PM

As a side note, I wish we had more than 32 bitmap-handles and could setup/query more than one font cache.

I believe this is being looked at for future EVE revisions.

Best Regards,
BRT Community

Not that I am unhappy with BT817 but nice. 
If I were asked, I would have a few more ideas to add.

You can find an example of how to utilise CMD_FONTCACHE at the following:
https://github.com/BRTSG-FOSS/EveApps/blob/825eaeb620274d29082388f448a263525d5fa886/SampleApp/Font/Src/Font.c

As a side note, I wish we had more than 32 bitmap-handles and could setup/query more than one font cache.

As for Adaptive frame rate, you can write the register during your initialization sequence, during your 'configuration of LCD' block, but the LCD must support this feature if it is to be beneficial.

REG_ADAPTIVE_FRAMERATE has a reset value of 0x1 so it is enabled by default.
It does not seem to do anything though, at least not in regards of saving the pixel engine from crashing when there is not enough time per line.

REG_AH_HCYCLE_MAX has a reset value of 0x0 so adaptive HSYNC is disabled by default.
Hence my recommendation:
"Setup REG_AH_HCYCLE_MAX to for example HCYCLE + 500, the reset value is zero."

This is likely to be a bandwidth issue between the BT817 and the SPI-Flash.
I converted NotoSansSC-Regular.otf with your table and EAB outputs 48x48 pixel for the glyhs for a size of 36.

So the first thing you can try is to use much smaller fonts, like 24.
Just to test this.
24 is converted here to 24x32 pixel and is using ASTC 8x8 on setting "auto".

If that works with more characters this is a bandwidth issue.

 
Next you can setup the font-cache for the larger font, see CMD_FONTCACHE.
This way a subset of glyphs is fetched from RAM_G.
CMD_FONTCACHEQUERY helps tuning the memory for the cache.

ASTC 10x5 is 2.56 bits per pixel.
So 40 * 40 * 2.56 is 4096.
A glyph needs to be 32 byte aligned but 4096 is divisible by 32.
For 20 chars fontcache we need 4096 * 20 = 81920 bytes.
Note that the start of the cache needs to be 64-byte aligned.

ASTC 8x8 uses 2 bits per pixel:
40 * 40 * 2 = 3200.
20 * 3200 = 64000 bytes

EAB 2.6.1 converts NotoSansSC-Regular.otf to ASTC 8x8 for me when set to "Auto".
Generated Folder: NotoSansSC-Regular_36_Extend
Format:           COMPRESSED_RGBA_ASTC_8x8_KHR
Compressed:       thorough
Layout Width:     80
Layout Height:    8
Pixel Width:      40
Pixel Height:     64
Number of characters in xfont file:      65408
Number of characters in user input file: 292
   Success: 287
   Fail:    5
   Fail code point: 0x5f00, 0x8a00, 0x9000, 0x9600, 0x9700
NotoSansSC-Regular_36_ASTC.xfont and NotoSansSC-Regular_36_ASTC.glyph are generated successfully.

40 * 64 * 2 = 5120
20 * 5120 = 102400 bytes


The "Fail: 5" is interesting as EAB 2.5.1 did not have any fails.

Hmm, when I manually set it to 10x5 I get this:
Generated Folder: NotoSansSC-Regular_36_Extend
Format:           COMPRESSED_RGBA_ASTC_10x5_KHR
Compressed:       thorough
Layout Width:     64
Layout Height:    8
Pixel Width:      40
Pixel Height:     40
Number of characters in xfont file:      65408
Number of characters in user input file: 292
   Success: 287
   Fail:    5
   Fail code point: 0x5f00, 0x8a00, 0x9000, 0x9600, 0x9700

So the same amount of characters for the same map but somehow the glyphs are smaller?
How? Why?

Ok, setting it to 10x8 for 1.6 bits per pixel the result is 40x40 pixel for the glyphs.
40 * 40 * 1.6 = 2560 (2560 % 32 = 0)
20 * 2560 = 51200 bytes


And one last thing.
Setup REG_AH_HCYCLE_MAX to for example HCYCLE + 500, the reset value is zero.

Well ok, that is -1 if you treat it like an int16_t. 
My point was though that the BT81x Programming Guide is using uint16_t result and is saying "Set to -1 on success".
So technically it either is int16_t or it returns 0xffff on success. :-)
And of course you do not get a value out of a function like the API is now.

Another issues I came across is with all the int16_t parameters that do not seem to make sense.
Like int16_t font in cmd_button, cmd_text, cmd_toggle, cmd_keys and cmd_number.
While this is for the BITMAP_HANDLE which has a valid range from 0 to 31.
16 bits is fine, making it 8 bit would require a pad-byte for the commands - but why signed?
And then we have cmd_romfont, cmd_setfont, cmd_setfont2 and cmd_fontcache which all use uint32_t font.

We have int16_t width and height options for cmd_button, cmd_keys, cmd_scrollbar, cmd_sketch, cmd_slider and cmd_progress - why not uint16_t?
cmd_toggle - int16_t width
cmd_clock, cmd_dial, cmd_gauge - int16_t radius

And cmd_calibratesub is using uint16_t for width and height.

So far I did not bother too much, I put in a cast and it worked.
But now that I started to do MISRA-C 2012 checks I had to put in quite a number of extra casts to tell the static code analyzer tool that
I really want to put two int16_t values in one uint32_t value.

This is what I meant by API inconsistencies, if there is no compelling reason to not do this the API in the programming guide would benefit from some cleanup,
make it unsigned wherever possible and wherever negative values are impossible.

I just tried this and it works:
EVE_cmd_gauge(400, 200, 100, 0, 3, 2, 100, 1000);
EVE_cmd_button(400, 300, 100, 100, 28, 0, "Hello!");

This however does not work not at all:
EVE_cmd_gauge(400, 200, -100, 0, 3, 2, 100, 1000);
EVE_cmd_button(400, 300, -100, 100, 28, 0, "Hello!");
EVE_cmd_button(400, 300, 100, -100, 28, 0, "Hello!");
EVE_cmd_button(400, 300, 100, 100, -28, 0, "Hello!");

With all these I get a black screen as if the co-processor is not happy about the commands.
And trying the cmd_button in EVE Screen Editor it actually tells me "Co-processor engine fault".

So why signed parameters when going negative is not an option?

As I am going thru the MISRA-C report for my library I am finding API inconsistencies.

CMD_BITMAP_TRANSFORM
The given C prototype has "uint16_t result" as last parameter.
While this by itself is not correct and "result" should either be the return value or a pointer,
the description for result is:
"result return. Set to -1 on success, or 0 if it is not possible to find the solution matrix."

Which one is it, uint16_t or int16_t?
And actually the native type for RAM_CMD would be uint32_t.

About the suggestions for a new prefix, I like your prefix EVE_ but if you want to avoid lint notes... maybe something like BT_EVE_ . But I think your prefix is ​​fine, and you shouldn't change it.

At least right now I am going with MISRA C 2012 and ignore the issue. :-)
Usually MISRA checks are out of reach for me and I guess for almost everone who uses my library.
At least I got no report regarding MISRA.
Well, I usually compile with -Wall -Wextra -pedantic and fixed what cppcheck found.

I had the opportunity though to generate a MISRA C 2012 report and that was not pretty.
There will be fixes. :-)