non blocking TWI from app_timer callback

[chladm]

Hi,

I have blocking TWI operation in app_timer callback to read fifo from accelerometer. It works just fine but I want to make it non-blocking to decrease current consumption. I am not able to do it. Could you please help me?

I tried to change the TWI IRQ priority from 3 to 1 but it had no effect. Variable FIFO_read is still false.

I use nRF51822QFACA, SDK10, Softdevice S110 v.8

volatile bool FIFO_read = false;
void twi_handler(nrf_drv_twi_evt_t const * p_event, void * p_context)
{
	if(p_event->type == NRF_DRV_TWI_RX_DONE)
	{
		FIFO_read = true;
	}
				
}

static void accel_timeout_handler(void * p_context)
{
    uint8_t tx_x[] = {0x28};	//X axis out low
	uint8_t tx_fifostatus[] = {0x2F};	//fifo status
	uint8_t rx_x[192];
	uint8_t rx_fifostatus[1];
	uint8_t number_of_registers = 6;
	
	const nrf_drv_twi_t p_twi_instance = NRF_DRV_TWI_INSTANCE(0);
   nrf_drv_twi_config_t p_twi_config;
   p_twi_config.scl = 2;
   p_twi_config.sda = 1;
   p_twi_config.frequency = NRF_TWI_FREQ_400K;
   p_twi_config.interrupt_priority = 1;
  uint32_t err_code = NRF_SUCCESS;
	err_code = nrf_drv_twi_init(&p_twi_instance, &p_twi_config, twi_handler, NULL);
	nrf_drv_twi_enable(&p_twi_instance);
	
	err_code = nrf_drv_twi_tx(&p_twi_instance, 0x19, tx_fifostatus, sizeof(tx_fifostatus), true);
	err_code = nrf_drv_twi_rx(&p_twi_instance, 0x19, rx_fifostatus, sizeof(rx_fifostatus), false);
		
	err_code = nrf_drv_twi_tx(&p_twi_instance, 0x19, tx_x, sizeof(tx_x), true);
	FIFO_read = false;
	err_code = nrf_drv_twi_rx(&p_twi_instance, 0x19, rx_x, (rx_fifostatus[0] & 0x3F) * number_of_registers , false);
	do{
		__WFE();
	}
	while(FIFO_read == false);
}

Thank you.

[chladm]

I am using Softdevice S110 v.8

Current consumptions which I described were while in BLE connection.

#define MIN_CONN_INTERVAL                0x05AC	/**< Minimum acceptable connection interval (1,815 seconds). */
#define MAX_CONN_INTERVAL                0x0640	/**< Maximum acceptable connection interval (2 second). */
#define SLAVE_LATENCY                    0      /**< Slave latency. */
#define CONN_SUP_TIMEOUT                 0x0C80 /**< Connection supervisory timeout (32 seconds). */


#define FIRST_CONN_PARAMS_UPDATE_DELAY   APP_TIMER_TICKS(10000, APP_TIMER_PRESCALER)/**< Time from initiating event (connect or start of notification) to first time sd_ble_gap_conn_param_update is called (5 seconds). */
#define NEXT_CONN_PARAMS_UPDATE_DELAY    APP_TIMER_TICKS(30000, APP_TIMER_PRESCALER)/**< Time between each call to sd_ble_gap_conn_param_update after the first call (30 seconds). */
#define MAX_CONN_PARAMS_UPDATE_COUNT     10                                         /**< Number of attempts before giving up the connection parameter negotiation. */

#define SEC_PARAM_BOND                   1                                          /**< Perform bonding. */
#define SEC_PARAM_MITM                   0                                          /**< Man In The Middle protection not required. */
#define SEC_PARAM_IO_CAPABILITIES        BLE_GAP_IO_CAPS_NONE                       /**< No I/O capabilities. */
#define SEC_PARAM_OOB                    0                                          /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE           7                                          /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE           16                                         /**< Maximum encryption key size. */

Thanks

[Jared]

My guess it that your application doesn't use that much time in the WFE loop, and therefore has minimal gain in power savings from switching to non-blocking.

[chladm]

Application is reading 192 registers via TWI every 2,5 seconds to read whole FIFO from accelerometer.

Do you think using SPI instead of TWI will have significant effect? What current consumption would you expect with SPI?

Thanks

[Jared]

Hi,

 Sorry for the late reply.

chladm said:

Do you think using SPI instead of TWI will have significant effect? What current consumption would you expect with SPI?

 This is discussed in this thread. 

regards

Jared

[chladm]

Thank you Jared.