Async Radio driver for embassry_nrf

[guissalustiano]

Hi! I'm Interested in developing some Bluetooth tools for Rust (as my bachelor's thesis), as a first step, I would like to implement the Radio driver with async support. Do you think it makes sense?

I started the development here but I'm unsure about the best API approach. The radio hardware varies between the boards, a quick resume:

Board	BLE 1M	BLE 2M	BLE 512K	BLE 128K	802.15.4	Nordic 1M	Nordic 2M
nrf52805	✅	✅	❌	❌	❌	✅	✅
nrf52810	✅	✅	❌	❌	❌	✅	✅
nrf52811	✅	✅	✅	✅	✅	✅	✅
nrf52820	✅	✅	✅	✅	✅	✅	✅
nrf52832	✅	✅	❌	❌	❌	✅	✅
nrf52833	✅	✅	✅	✅	✅	✅	✅
nrf52840	✅	✅	✅	✅	✅	✅	✅
nrf5340	✅	✅	✅	✅	✅	✅	✅
nrf9160	❌	❌	❌	❌	❌	❌	❌

Desing

Given the uncertainty of the best interface and based on the feedback I will move development to another project, in order to iterate faster, and perhaps in the future create a generic library for any framework. However, for this, I need some primitives to access the radio and wait for the interruption, and this must be implemented here as it requires access to the poll executor.

Steps

First, implement POC to understand the necessary register and interrupts, and based on that implement a low-level API (specify for BLE now, but could be extended to others formats later)

• [X] Implement blocking transmission
• [X] Implement blocking receive
• [X] Implement async transmission
• [x] Implement async receive
• [x] Define a low-level API on the embassy and move the work to another repository

Previous related issues:

• 432

• 1800

References

1. Bluetooth 5.4 Link Layer Specification
2. Ruble - Rust BLE 4.2 library unmaintained
3. Book Getting Started with Bluetooth Low Energy - Pag. 17
4. Zerphy Radio driver interface

[lulf]

Hi @guissalustiano I think it's a great initiative, but also a very big one. It's also a question how much of this needs to be in embassy or not. For instance, the LoRa and LoRaWAN work was recently moved out of the embassy repo into a separate organization https://github.com/lora-rs, and I'm wondering if it would be better for work like this to keep the HAL-dependent parts in this repo, and the HAL-independent parts of the stack outside as much as possible. This also has other benefits such as allowing other HALs to benefit from your work.

[guissalustiano]

Hey, just an update. Based on @lulf feedback I decided to move the work to a separate repo, there are a lot of agnostic functions like the package structures and serialization. And also make it easier to iterate over the interface. I tried to define a basic trait there that I plan to use with the embassy hal to implement other layers.

Here are two working low-level examples using the current trait:

• beacon
• scanner

Still a lot of work to do, but is good to see some progress!