Support for nrf5340 dual core architecture

[igiona]

I'm quite familiar with the nrf52 family and I used the SoftDevice extensively in C and I did some fairly simple work in Rust using embassy-softdevice. Recently I started looking into the nrf5340, and I though giving trouble a shot 'cause Nordic doesn't support the nrf53 family within the SoftDevice stack anymore :'(

I never worked on a dual core microcontroller in Rust, hence I'm not sure where to start here? I saw that there is some support for the nrf5340 chip within embassy, but the examples do not really showcase the usage of the double cores.

Any suggestion on how to get started with trouble on that chip?

[lulf]

I think with the nrf53, you can run the controller on the network core, and then trouble on the application core, communicating over the IPC bus. You'd need to implement the traits from bt-hci that send/receive HCI packets to the network core.

[igiona]

I think with the nrf53, you can run the controller on the network core, and then trouble on the application core, communicating over the IPC bus. You'd need to implement the traits from bt-hci that send/receive HCI packets to the network core.

Are you aware of any non-sdc controller available for the nrf5340?

Why should trouble run on the app-core in your opinion? I would have rather placed it in the net-core and I would have communicated over IPC only at an higher level of abstraction (like GATT read/write/notifications). The app-core is quite power hungry, hence I wouldn't bothered waking it app at every "low-level" BLE event.

In general, I'm still not quite sure how to handle 2 applications in one rust project... would you handled them as completely separated apps that communicate over an IPC API?

[lulf]

I think with the nrf53, you can run the controller on the network core, and then trouble on the application core, communicating over the IPC bus. You'd need to implement the traits from bt-hci that send/receive HCI packets to the network core.

Are you aware of any non-sdc controller available for the nrf5340?

I'm not very familiar with it, but my impression was that Nordic provides a controller firmware that you flash to the network core and that's all you need.

Why should trouble run on the app-core in your opinion? I would have rather placed it in the net-core and I would have communicated over IPC only at an higher level of abstraction (like GATT read/write/notifications). The app-core is quite power hungry, hence I wouldn't bothered waking it app at every "low-level" BLE event.

Keep in mind even Trouble does not get notified of low level events. If you're using only GATT, there will not be any 'hidden' events on a connection other than the initial 'connected', 'gatt events' and 'disconnected', so I doubt you would save a lot of power by running trouble on the net core (and more likely complicate your firmware build/deployment model).

In general, I'm still not quite sure how to handle 2 applications in one rust project... would you handled them as completely separated apps that communicate over an IPC API?

I think you'd generally treat them as separate build targets/firmware, but they may share some common crates for type definitions over the IPC etc.

[igiona]

Thanks for the inputs!

I'm not very familiar with it, but my impression was that Nordic provides a controller firmware that you flash to the network core and that's all you need.

Your impression was right: https://docs.nordicsemi.com/bundle/ncs-latest/page/nrf/app_dev/device_guides/nrf53/features_nrf53.html#bluetooth_low_energy

To me it still seems like a waste of resources, to run only the controller on a dedicated CPU, in the nrf52 series app and BLE are coexisting with pretty decent performances after all... but I might underestimate all the job that the controller (and multi-protocol stuff) need to do...

I'll keep you posted here with any progress on this...

[canatella]

@lulf : I'm looking at the feasibility of using embassy on an nrf5340 platform. And I was wondering, isn't the implementation as "simple" as implementing the bt-hci::transport::Transport trait like in ble_bas_peripheral.rs? I don't have much knowledge of the low level bluetooth stuff nor of the rust embassy bluetooth stack so excuse me if this is stupid. I just know that the nordic radio application on the net core just behaves as a controller, reading/transmitting hci packet using an ipc that I know nothing about...

Thanks for any insights!

[igiona]

That's my understanding too.

Trouble is, you need first to implement Open amp RPMSG protocol in order to be able to talk to the net-core running the BLE controller.

I started gathering some documents etc. But I must say that the documentation I found so far isn't that great.

[canatella]

Yep, been looking a bit around too and indeed, documentation is a bit lacking... Most interesting things I found is https://github.com/nxp-mcuxpresso/rpmsg-lite/tree/main/lib. It looks small enough as a basis to understand this ipc stuff is working. I'll see if I can get to that at some point.

[0e4ef622]

Zephyr supports other IPC backends like ICMsg and ICBMsg, might be simpler to implement. Also somewhat relevant https://github.com/apache/mynewt-nimble/pull/1882

[Abrahamh08]

Zephyr supports other IPC backends like ICMsg and ICBMsg, might be simpler to implement. Also somewhat relevant apache/mynewt-nimble#1882

https://github.com/0e4ef622/icmsg-rs/tree/feat/trouble-sdc-example/examples/trouble-sdc-nrf5340

We wrote this example similar to the ICMsg backend (ICBMsg todo) that works for peripheral bonding exposing a BAS using the dual-core architecture. IPC'ing the RNG is also todo.