2024-03-27 09:59 AM - edited 2024-03-28 01:31 AM
Hi,
I am trying to understand the difference between blocking/non-blocking rfal apis.
ReturnCode rfalNfcvPollerReadMultipleBlocks( uint8_t flags, const uint8_t* uid, uint8_t firstBlockNum, uint8_t numOfBlocks, uint8_t* rxBuf, uint16_t rxBufLen, uint16_t *rcvLen );
It seems to me that the above api is a blocking one. How can I achieve the same functionality in a non-blocking way ?
The reason I am asking this is because it seems that this api is taking too much time to execute (Without the time required to perform I2C read). Is my understanding correct on the RFAL library sequence for the above api ?
I am concerned about step 2 as it is a busy wait loop and other threads seem to be starving.
Solved! Go to Solution.
2024-03-29 06:43 AM
Hi
rfalNfcvPollerReadMultipleBlocks is a blocking API. The duration of this call depends on the number of blocks requested.
You can try to use rfalNfcvPollerReadMultipleBlocks with a smaller number of requested blocks or use a loop of rfalNfcvPollerReadSingleBlocks to avoid a too long blocking time.
Or you can format the rfalNfcvPollerReadMultipleBlocks request and send it through non blocking rfalStartTransceive / rfalGetTransceiveStatus.
Rgds
BT
2024-03-29 06:43 AM
Hi
rfalNfcvPollerReadMultipleBlocks is a blocking API. The duration of this call depends on the number of blocks requested.
You can try to use rfalNfcvPollerReadMultipleBlocks with a smaller number of requested blocks or use a loop of rfalNfcvPollerReadSingleBlocks to avoid a too long blocking time.
Or you can format the rfalNfcvPollerReadMultipleBlocks request and send it through non blocking rfalStartTransceive / rfalGetTransceiveStatus.
Rgds
BT