How to write from co-processor to host?

[JuanAlm]

I am working with a custom board. There is an nrf52840 radio co-processor running the example NCP openthread mode. This radio co-processor is connected to the host micro through a UART. They are working perfectly transmitting openthread messages etc within the openthread network.The project has "overlay_multiprotocol_ble" and its working right too.

But what if I want to modify the radio firmware to send a custom message, just 10 bytes when I push a button for example. 

Should I send it with UART using UART HAL? Isn't that UART being hogged by SPINEL? Might I load the spinel instance and use it? are the spinel messages coded with HDLC-lite or I have to encode it?

What about if I want to send messages to the host micro from my mobile via bluetooth? Is there an NCP Blueetooth version? Could it NCP bluetooth version share the spinel connection to the host? I have checked this info and I see that BLE HCI exists and it is like NCP, a coprocessor mode, isn't it? Checking spinel documentation I noticed that spinel is compatible with HCI . Is there any example or could you guide me how to configure OT NCP + BLE HCI in multiprotocol mode?

Thanks!

EDIT1:
I found this entry and it's pretty much what I want. The only difference is that in my case Openthread is running in NCP mode. But I know that multiprotocol can run in dynamic mode and in switched mode. Is it possible to run BLE HCI and OpenThread NCP in switched mode and use the UART with Spinel (in case Openthread works) or HCI (in case BLE works) ?

[Edvin]

Hello,

I found this entry and it's pretty much what I want.

What entry is this?

I am not convinced that switched mode is any easier than dynamic mode, to be honest. I could be wrong, but let me run this by our openthread team. 

Regarding the rest of your questions, I am not sure what you found, what it answered, and what questions that remain. Perhaps you can clarify?

Best regards,

Edvin

[JuanAlm]

Oh sorry, I edited the message. I was referring to this post

To summarize my post I have the following question:

1º) When I build the Openthread NCP example and add "overlay_multiprotocol_ble" does it work in DYNAMIC or SWITCHED mode?

2º) Is there any configuration to switch between modes?

3º) Ble would be working in SoC mode. How can I set multiprotocol with BLE working in coprocessor mode?

4º) In case BLE and OT are both working in dynamic coprocessor mode, when BLE is active, would HCI work through UART? And when BLE is off and OT is on would HCI be disabled and Spinel working?

EDIT1:

1º) I have find this info. It seems BLE multiprotocol is working in dinamic mode.

[Edvin]

The multiprotcol modes are always dynamic (in our stacks). The way this works in general in our stacks is that you have a network protocol (openthread), running "at all times", and then the BLE stack will take over when it needs radio access. Since the nature of the radio in BLE is only in short bursts, this works fine.

2: No, they will be running concurrently.

3/4: Now, regarding the partial stacks, I need to look into the details. This is a bit of a corner case. Let me run this by our Openthread team, and I will get back to you.

Best regards,

Edvin

[JuanAlm]

Any progress? =)

[Edvin]

Hello,

The reply that I received from our Thread team says that none of the coprocessor architectures support multiprotocol. 

So if you want to switch between these, you either need to re-program the board on every swap, or you can try to work it out using a bootloader.

Out of the box, the bootloader doesn't really support what you are looking for. It is possible to swap between the applications, but they are by default written to be running from the same application slot, meaning they actually need to switch places every time you want to switch, and this takes some time. Alternatively, you can look into trying to make one of the applications run from the secondary slot, and make the bootloader only start the application that you would need. But as I mentioned, this is not supported out of the box, so it would require some changes in the bootloader.

Best regards,

Edvin