Data from callback initialiser to callback?

[Sensors]

I have a bluetooth service which I want to have to initialise a TWI transaction (using app_twi). I want to get the data back from the TWI transaction, but I can't figure quite the best way to do that. I have the ble service and TWI working separately, it's just bringing them together neatly that is awkward it seems.

I was previously trying to figure out out to get data back from a callback function, but I thought it might be easier to instead move the TWi transaction instantiation to the service file itself, that way the callback can occur in the same file as the data is required.

Where I am struggling now is in having the callback function send the data to the characteristic update function. The update function as always been located in service.c, but was previously called from main.c by a timeout interrupt where the data also originated. This was fine since the data structure (`ble_os_t m_our_service;) for the service is instantiated in main.c and it could be passed through to update function.

Now however, the updated data is coming from within the service.c.

The rh_read() function is called in the timer timout interrupt as before, but this generates a callback when the TWI transfer is complete. But since it's a callback, it doens't have access to the m_our_service data structure which is required by the update characteristic function, our_humidity_characteristic_update(&m_our_service, &rh_conv);

I can't pass it as p_user_data in the transaction data since it's 'not a compile time constant'.

How can I safely pass the required data structure through when there is this disconnection between transfer initiator and callback function?

static void rh_read_callback(ret_code_t result, void * p_data)
{
	nrf_gpio_pin_toggle(LED);

	
	if(result != NRF_SUCCESS)
	{
		printf("Transfer failure - twi_read_callback - Error: %d\r\n", (int)result); 
	}else{
		
		uint16_t rh_raw = (m_sht21_buffer[0]<<8) | (m_sht21_buffer[1]&0xFC) ; // 8 bit	
		uint16_t rh_conv   = -6 + ((125 * rh_raw)>>16); 	// RH= -6 + 125 * SRH/2^16 // 34us as floats, 2us as ints
		
		printf("\033[2J\033[1;1H");
		printf("RH real: %d%%\n\r\n", rh_conv);
		
		our_humidity_characteristic_update(&m_our_service, &rh_conv);     //////////////// PROBLEM
		
	}
}


void rh_read(void)
{
	
	
	static app_twi_transfer_t transfers[] = 
	{
		SHT21_RH_READ(&m_sht21_buffer[0])
	};
	static app_twi_transaction_t const transaction =
	{
	.callback            = rh_read_callback,
	.p_user_data         = NULL,
	.p_transfers         = transfers,
	.number_of_transfers = sizeof(transfers) / sizeof(transfers[0])
	};
	
	APP_ERROR_CHECK(app_twi_schedule(&m_app_twi, &transaction));
}

Later on I will have a few services accessing the TWI at potentially conflicting intervals. Will use of the app_twi_schedule() like I have here prevent any issues with that?

[Sensors]

Okay, I'll try that for now. If I was making other transfers at different frequencies they would be instantiated in relation to other services in their own respective files. That would mean I'd have to have a new instance of app_twi_transaction_t anyway.

In this case the only thing that still may cause an issue, as you pointed out, would be making another call to rh_read(). The transfers should be instantiated by a timer, so I just need to make sure the timer can't tick over faster than the sample period for each sensor. To avoid the scenario of corruption, I suppose I could just have a variable local to each service file to confirm the callback has completed, and in rh_read() do something like:

while(!callback_complete); 
APP_ERROR_CHECK(app_twi_schedule(&m_app_twi, &transaction));

[Sensors]

Though polling isn't ideal, it should only cause a polling delay if I've broken the rule of trying to sample faster than the sampling period.

Does this sounds like a reasonably safe solution?

[Einar Thorsrud]

Yes, this is a sensible solution given that you do not need to schedule more than one transaction at a time. You should also remember to make sure that you poll the flag in a lower priority than you update the flag with, if not you risk a deadlock.

[Sensors]

Accidentally converted this to an answer.

What I was trying to do, was ask about the dangers of making the ble_os_t m_our_service local to service.c.

I figure by doing this I remove the pain of having to pass that in, it's then accessible to every function, and I can't see much reason to instantiate it in main.c when it's only ever used in the service file.

My service file would then look like this: gist.github.com/.../02be1cb5af43b5145fb5

[Sensors]

As a follow up to your comment about removing the static from the transaction...

I went back to some older code and found this comment:

// [these structures have to be "static" - they cannot be placed on stack
//  since the transaction is scheduled and these structures most likely
//  will be referred after this function returns]