how to use NRF RPC without thread_custom_data

[loquat]

I want to use NRF RPC.

It seems to use thread_custom_data.

But, My application also use thread_custom_data.

Is there a way to use NRF RPC without thread_custom_data?
If not, please tell me a module that does not use thread_custom_data with the same functionality as NRF RPC.

[Sigurd Hellesvik]

Hi,

Is there a way to use NRF RPC without thread_custom_data?

From what I can tell, thread_custom_data is only used by the nRF RPC drivers in these two functions.

I do not think you can configure the nRF Connect SDK to change this.
However, since it is just two lines, you can patch your version of the nRF Connect SDK to make the nRF RPC use something else for this.

See Managing the code base

If not, please tell me a module that does not use thread_custom_data with the same functionality as NRF RPC.

Can you describe the use-case here a bit?

[loquat]

Can not NRF_RPC and thread_custom_data use coexist?
It's an unfortunate design.

Is there any mention of such restrictions somewhere?

[Sigurd Hellesvik]

Hi,

If I read Thread Custom Data docs, I can see that they say:

"A thread can only access its own
custom data, and not that of another thread."

This makes it look like you can use custom thread data for multiple different threads, right?

[loquat]

I'm on C++ and using my own framework.
This framework defines a "class AppThread"
Thread_custom_data stores "AppThread*".
On the other hand, NRF_RPC also uses thread_custom_data, so it conflicts.
Is there a workaround left for me other than fixing NRF_RPC?

Is there a problem with using k_thread->init_data like thread_custom_data?

[ovrebekk]

Hi 

Sigurd is currently on vacation, and I will help out in the mean time. 

Probably the easiest workaround would be to have a single thread accessing the nrf_rpc commands, and avoid using your framework for this particular thread. The main problem of this method is that if other threads need to communicate over RPC they need to pass the message to the other thread first. 

If you are already using some kind of message queue or similar to buffer commands then the impact should be small, but if you have a lot of RPC calls being triggered from various threads then the impact will be higher and you will lose some efficiency. 

loquat said:

Is there a problem with using k_thread->init_data like thread_custom_data?

I can't find any reference to the init_data field after the thread has been initialized, so using it might work, but I wouldn't recommend it as this is not tested. Also, the use of the init_data field might change in a future update. 

Best regards
Torbjørn

[loquat]

OK.Thanks.