Closed pkral78 closed 3 years ago
Hello,
Why would you need to wait AFTER you send the command? You can deal with this behavior by adding a check on BUSY signal state at the very beginning of your implementations of both llcc68_hal_write
and llcc68_hal_read
so you wait for the chip to be ready before you start sending data over SPI.
Note that if the chip is in sleep mode, BUSY is asserted until you wake the chip up (with toggling NSS).
Hello,
you're right, maximal Tsw is under 600ns what is neglible (until transaction is queued and driven by DMA which is not my case), so there is zero chance to outrun BUSY before next transaction. So checking BUSY before transaction is right approach.
Thank you. I close this issue.
Hello,
it seems that some write command trigger BUSY signal while some does not. For example:
In current API HAL definition it is then difficult to distinguish if it is neccessary to wait or not. While it is possible to pass such information using context parameter, it delegates such responsiblity to caller. I would like to see that this kind of information is handled inside HAL itself. Also defining maximum timeout for command would be usefull.