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.
