Data from callback initialiser to callback?

RE: Data from callback initialiser to callback?

Einar Thorsrud — Mon, 29 Feb 2016 06:36:09 GMT

You are right, of course. This is actually a typo in my comment. You should keep the transaction static, but remove const and set transaction.p_user_data outside the initialization, as described (i will update the comment to keep it static). The reason for this is as describer in your quote above, that the memory must be valid after the function has returned, thus it cannot be located on the stack.

I see no problem with moving your ble_os_t m_our_service. As long as you can access it from where you need it, you should be OK.

RE: Data from callback initialiser to callback?

Sensors — Sun, 28 Feb 2016 16:51:43 GMT

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]

RE: Data from callback initialiser to callback?

Sensors — Fri, 26 Feb 2016 14:13:36 GMT

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

RE: Data from callback initialiser to callback?

Einar Thorsrud — Thu, 25 Feb 2016 13:53:45 GMT

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.

RE: Data from callback initialiser to callback?

Sensors — Thu, 25 Feb 2016 13:01:27 GMT

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?

RE: Data from callback initialiser to callback?

Sensors — Thu, 25 Feb 2016 13:01:03 GMT

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));

RE: Data from callback initialiser to callback?

Einar Thorsrud — Thu, 25 Feb 2016 12:08:30 GMT

The problem here is that the transaction is static, therefore the initializer is only run once, and cannot be dynamic. You can remove const, and set transaction.p_user_data outside the static initialization. However, this may be dangerous in your case, as that means that if you make a subsequent call to your rh_read() function before the previous transfer has completed, you will modify (corrupt) the transfer struct that is to be used in the previously scheduled transaction.

Therefore, if you want to schedule multiple transfers simultaneously, you need multiple instances of app_twi_transaction_t. How you do this depend on your code, but it does not have to be complex.

RE: Data from callback initialiser to callback?

Sensors — Wed, 24 Feb 2016 15:46:45 GMT

This is how I tried to do it to get the error that 'initialiser is not a compile-time constant'

void rh_read(ble_os_t *m_our_service)
{
	
	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         = &m_our_service,
	.p_transfers         = transfers,
	.number_of_transfers = sizeof(transfers) / sizeof(transfers[0])
	};
	
	APP_ERROR_CHECK(app_twi_schedule(&m_app_twi, &transaction));
}

This function is called from main.c, where the ble_os_t m_our_service; is also instantiated.

EDIT: the app_twi_transaction_t is populated as a const. I don't know why, but that's what it was in the app_twi example so I didn't want to change it.

RE: Data from callback initialiser to callback?

Einar Thorsrud — Wed, 24 Feb 2016 12:58:17 GMT

How do you populate the app_twi_transaction_t instance and call app_twi_schedule()? I do not see why it should be a requirement that the pointer is a constant.

RE: Data from callback initialiser to callback?

Sensors — Wed, 24 Feb 2016 12:38:32 GMT

I can't pass it as p_user_data in the transaction data since an m_our_service argument passed into the function is 'not a compile time constant'.

RE: Data from callback initialiser to callback?

Einar Thorsrud — Wed, 24 Feb 2016 12:22:35 GMT

The TWI transaction manager is intended for this type of situations, and app_twi_schedule() should do the trick. As stated in the documentation, transactions can be requested from different contexts, including interrupt handlers. The library takes care of proper synchronization.

You should be able to pass user data between where you schedule the transaction and the callback using p_user_data - it is exactly what it is intended for. Why can you not do that?

Static variables, such as your m_our_service, cannot be accessed outside that file. There are a number of ways of managing this however. The dirty way, which I do not recommend, is to remove the static keyword from the declaration, and declare the same variable name as extern where you need it (or in a header file that you include). This would then be a global variable. Another possible approach, which is much cleaner, is to move the data you want to share to a separate .c file. Then you can create an accompanying header file with an accessor function (à la m_our_service_t * our_service_ptr_get() {return &m_our_service;};).