Does m_xfer_done need to be set to false before calling nrf_drv_twi_rx? If so, does while (m_xfer_done == false); loop need to be called on every read?
Does m_xfer_done need to be set to false before calling nrf_drv_twi_rx? If so, does while (m_xfer_done == false); loop need to be called on every read?
Hello,
Does m_xfer_done need to be set to false before calling nrf_drv_twi_rx?
I assume you are looking at the TWI_sensor example, in which case the answer is yes. This is because the m_xfer_done is set to true following the NRF_DRV_TWI_EVT_DONE event. If you are not resetting it to false before the next read_sensor_data call, then the CPU will move on to the second transfer immediately, and the nrf_drv_twi_tx will fail with NRF_ERROR_BUSY.
If so, does while (m_xfer_done == false); loop need to be called on every read?
It depends - if you are using the m_xfer_done flag to ensure that the driver has enough time to complete a transfer before another one is scheduled, like in the example, then the answer is yes. If you are asking about it in the general sense, then the answer is no.
I suppose you could also attempt to go into sleep for the waiting time, like calling nrf_pwer_mgmt_run but this will only work if your application only does TWI transfers - like in the example - since the CPU will wake and continue whenever an event is generated. If you are in a BLE connection, or have another peripheral also generating events, you can not guarantee that the twi transfer has finished before the next event is generated - which therefore is unreliable.
I suspect here that you would like to avoid having the CPU waste cycles waiting for the transfer to finish, so that the next one can be started, is this correct?
You could implement a mechanism yourself using timers or the NRF_DRV_TWI_EVT_DONE event, to avoid having the CPU waste cycles in the while loop. For example, every time a transfer is started you start a timer, and no other transfer can be initiated while this is timer is not yet expired. Then, you will have to account for what to do with the transfers that the CPU would have scheduled in this time.
Alternatively, if you are using the nrfx_twim driver you could implement this as a queue of transfers, that will trigger periodically by a timer, using the nrfx_twim_xfer function along with the NRFX_TWIM_FLAG_REPEATED_XFER flag, for instance.
Best regards,
Karl
Hello,
Does m_xfer_done need to be set to false before calling nrf_drv_twi_rx?
I assume you are looking at the TWI_sensor example, in which case the answer is yes. This is because the m_xfer_done is set to true following the NRF_DRV_TWI_EVT_DONE event. If you are not resetting it to false before the next read_sensor_data call, then the CPU will move on to the second transfer immediately, and the nrf_drv_twi_tx will fail with NRF_ERROR_BUSY.
If so, does while (m_xfer_done == false); loop need to be called on every read?
It depends - if you are using the m_xfer_done flag to ensure that the driver has enough time to complete a transfer before another one is scheduled, like in the example, then the answer is yes. If you are asking about it in the general sense, then the answer is no.
I suppose you could also attempt to go into sleep for the waiting time, like calling nrf_pwer_mgmt_run but this will only work if your application only does TWI transfers - like in the example - since the CPU will wake and continue whenever an event is generated. If you are in a BLE connection, or have another peripheral also generating events, you can not guarantee that the twi transfer has finished before the next event is generated - which therefore is unreliable.
I suspect here that you would like to avoid having the CPU waste cycles waiting for the transfer to finish, so that the next one can be started, is this correct?
You could implement a mechanism yourself using timers or the NRF_DRV_TWI_EVT_DONE event, to avoid having the CPU waste cycles in the while loop. For example, every time a transfer is started you start a timer, and no other transfer can be initiated while this is timer is not yet expired. Then, you will have to account for what to do with the transfers that the CPU would have scheduled in this time.
Alternatively, if you are using the nrfx_twim driver you could implement this as a queue of transfers, that will trigger periodically by a timer, using the nrfx_twim_xfer function along with the NRFX_TWIM_FLAG_REPEATED_XFER flag, for instance.
Best regards,
Karl
