Though, I'm still at a loss as to the benefit of doing so with the exception of suppressing updates to REG_CMD_WRITE.
There is no benefit to write to RAM_CMD + offset over writing to REG_CMDB_WRITE.
Well okay, it works on FT80x as well.
But what is REG_CMDB_WRITE actually meant to be used for?
In AN_390 we find this:
"To offload work from the MCU for checking the free space in the circular buffer, the FT81x offers
two auxiliary registers “REG_CMDB_SPACE” and “REG_CMDB_WRITE” for bulk transfers. It
enables the MCU to write commands and data to the co-processor in a bulk transfer, without
computing the free space in the circular buffer and increasing the address. As long as the amount
of data to be transferred is less than the value in the register “REG_CMDB_SPACE”, the MCU is
able to safely write all the data to “REG_CMDB_WRITE” in one write transfer."
Well, when I started to play with EVE back in december 2015 I was using a VM800B35A with a FT800.
So no REG_CMDB_SPACE.
But I also did not have the issue that led to implementing REG_CMDB_WRITE, I never had to "offload work from the MCU for checking the free space" as my library never did check the free space.
That is a concept that I decided very early on to not copy from the original FTDI driver.
I still remember that I was very surprised when I found out that the FTDI driver was reading REG_CMD_READ and REG_CMD_WRITE on every single command to calculate the free space in the FIFO.
My library still does not calculate the free space in the FIFO and I am also not using REG_CMDB_SPACE.
My EVE_busy() function does only read REG_CMD_READ and compares that with my own "cmdOffset" var that all my commands update and that gets written to REG_CMD_WRITE.
And this works just fine since the FIFO is always empty anyways.
At least when writing a chunk of data of <4k for a new display list every 20ms.
So my library already has very low overhead and it supports FT80x as well, so I never really had to change
it to use REG_CMDB_WRITE, I never had the problem that lead to implementing it.
And even less so since I started to use DMA to transfer the display list to the cmd FIFO.
I plan to drop FT80x support with 5.0 of my library and this will happen when I implement support for BT817/BT818.
Switching over to REG_CMDB_WRITE then should save a few addtional clock cycles per command, like <10 or so.
Hmm, the longer I think about this the more I know that I need to test this. :-)
What could potentially benefit from REG_CMDB_WRITE and REG_CMDB_SPACE would be CMD_LOADIMAGE.
2k at 8MHz is ~3ms. (calculated with 12 bits per byte to account for the pauses between bytes)
I did a test a while back with a FT813 and decoding a 3867 bytes .png took 53ms.
And decoding a .jpg with 3903 bytes took 480µs
So sending a 64k .jpg in 2k chunks would mean that this would take about 96ms,
the FIFO would always be empty for the second packet.
At a theorethical 80Mhz for the SPI the transfer would take less time than the decoding.
I am sending the data in chunks of 3840 bytes now so 64k would take 17 chunks and a few bytes.
With about ~5.8ms for 3840 bytes and 17 times waiting for 0.5µs this is about 107ms.
So that would shave off about 10ms and not even with 10 images of 64k this would really make a noticeable difference.
At least not when you only load the images once when starting the program.
I wanted to calculate that for .png as well but decided after a couple of steps to not do it fully. :-)
Using .png is not really a valid option in the first place, even less so since we got ASTC.