I do not see in your code to which address the command is written to.

numberCommand.Instruction = 0xB0; // Get the first byte, should 0xB0 (0x10) to write

And the rest?
The intended target is probably REG_CMDB_WRITE?
I never used HAL_QSPI_Command() or HAL_QSPI_Transmit().
CS likely is hardware controlled?

What does this look like on the logic analyzer? The whole sequence for this function and perhaps some bits and pieces before and after.

And then I would not be immediately concerned about this:
TFT_qspi_cmd_rotate(1);
space = TFT_qspi_read16(REG_CMDB_SPACE); //When it fails, always 4084

Yes ok, I get that it hangs for you it it does that but some commands just need a few cycles to complete and immediately reading back REG_CMDB_SPACE might be just too fast in this case.
My EVE_cmd_setrotate() function is setup as a standalone function and waits for the command to complete, so reading REG_CMDB_SPACE untill it returns 0xffcU.

What STM32 are you even using? Some STM32H7xx?

As I am still not seeing the board "Discussion - Software" while beeing logged in, I am asking here.
I wrote an email to the board admin address a while ago about this.

I am working on an exporter script for ESE that generates code which is compatible with my library FT81x / BT81x library.
I used one of the existing exporter scripts as a starting point and things are starting to make sense.

However, I just found that comments seem to be stripped from the data that is send to the converter script.
All comments, lines that only have a comment end up empty, lines that end up in comments have the comments removed.

All exporter scripts have this however:
  if (line.lstrip()).startswith("//"):
and
  functionName, functionArgs, comment = parseCommand(line, functionMap, convertArgs)

My .ese file:
        "",
        "/* foo */",
        "// foo",
        "VERTEX_FORMAT(0) // boo",
        "",

The result when printing out each line raw with
f.write("//  " + line + "\n")
plus either the parsed command line or
f.write("    \n")
in case the line was empty:
// 
   
// 
   
//  VERTEX_FORMAT(0)
    EVE_vertex_format(0);
// 
   

So, not only are all comments stripped, the lines with comments end up beeing empty lines instead of beeing removed.
Is this actually working as intended?

The BT82X Series Programming Guide 1.0 is released. :-)
I only saw it two days ago and I did not really have much time for it so far though.

One thing, I found CMD_ARC, nice.
But, this is the description:
"The arc command draws a circular arc. The end caps of the arc are rounded. If the angles specify a complete circle, a disc is drawn."

Is that correct? So not a circle, but a a fully filled round area like with POINTS?

void cmd_arc( int16_t x, int16_t y, unint16_t r0, unint16_t r1, uint16_t a0, uint16_t a1 );

That u*n*int16_t is an interesting typo. :-)

But more importantly, why is the inner and out radius limited to 1..511?
Hmm, yes, radius, not diameter, so quite big - but still, no flat arc over the complete height of the display for example.

And is there any way to influence the roundness of the end caps?

Thank you for the confirmation, I will shuffle a few bits around in my library then. 

The BRT_AN_088_FT81x_BT88x-Programming-Guide.pdf v1.0 documents CMD_SYNC for FT81x and BT88x.
But the earlier FT81X_Series_Programmer_Guide.pdf v1.0 does not have this command.

Do FT81x have CMD_SYNC?

Edit: I guess FT81x do have CMD_SYNC, I just noticed that CMD_SETBITMAP is command #0x43 while CMD_SYNC is #0x42.
And #0x44 is CMD_FLASHERASE.
So not mentioning CMD_SYNC in the FT81x documentation is likely an oversight which has been correct with BRT_AN_088.

Ok, a datasheet is released now, but this leaves me a little confused.

So far EVE5 was anounced as BT822 with 1Gbit of embedded DDR3L.
And now we got a datasheet for a BT820 with up to 4GBit of external DDR memory?

The clock source is a 38.4MHz crystal, but the system clock is 72MHz?

The fonts remained unchanged - really?

As I predicted, the SPI host interface has been updated from 22 bit adressing.
But I am not 100% sure how it is working so far.

Ok, the BT820 has 31 bit adressing with the MSB beeing the "WR" bit, so writing when it is set to '1'.
Also it is Addr3, Addr2, Addr1, Addr0, followed by Data0, Data1 and so on.

As it always was since FT800, address and data use different byte orders, ok then.

When reading from the BT820 there no longer is a simple dummy byte though, first the address is send, then data is read untill 0x01 is returned, when 0x01 was returned the following transfers are for the actual data bytes.
Well, at least reads are less common and usually short.
I wonder how long that polling can last though.

"The transactions are word based, i.e., the data width must be in blocks of 32 bit when accessing the
registers and the DDR memory of the BT820. Addressing to the registers and the DDR memory must also
be word aligned, i.e., the last two bits of the received address is ignored"
"The write data is expected to be in blocks of 32-bit. Any incomplete data is discarded when SS_N deactivates."

Ok, I guess implementing rd8, rd16, wr8 and wr16 functions won't be necessary then.

That seems to be pretty clear so far.

Then we have host commands.
Ok, host commands are always 5 bytes long.
The ACTIVE command is just 0x00 0x00 0x00 0x00 0x00.
And writing parameters such as the the memory configuration is done with:
0xff Command Parameter 0x00 0x00
And then we still have POWERDOWN, STANDBY and SLEEP, at least.

So the host controller will do 32 bit transfers for the most part but still has to be able to do 8 bit tranfers,
for the host commands at startup and to poll for 0x01 during every read sequence, correct?


Now for the touch engine, turns out that resistive touch is not supported directly after all.
It is supported by using an external resistive touch controller that is connected via I2C.
Interesting.

A memory map is missing from the first revision of the datasheet.

And speaking of memory, that 1Gbit still is a surprise for me, I have no idea what this could be filled with.
Well, more can't really hurt, that "24-bit RGB framebuffer up to 2048 x 2048 pixels" would be 16Mbyte.
The registers, fonts, FIFO, ROM(s) and display lists likely also use regions in RAM.


The most interesting question is still when I can buy anything with a BT82x on it though. :-)

Ok, no more questions then, the suspense though. :-)

One final remark though, I noticed that the BT822 is using a 38.4MHz crystal on the "Block Diagram" image.
That is an odd value.