Radio API

[ryankurte]

I suspect this is likely to be a bit contentious, but, how do we feel about the addition of a generic Radio interface for RF devices?

On one hand, it's unlikely to generalise well to all radio implementations. On the other, if we cover most of them we might be able to avoid the fragmentation in radio driver styles that exists in the world of C (and that'd make me really happy).

Some examples of existing interfaces:

• Contiki OS
• Riot OS
• Mbed OS

The requirements I have for such are:

• common configuration options to simplify stack implementations
• simple polled methods for transmit and receive
• callbacks for radio initiated state changes etc.
• support for 802.15.4(g) radios, though not strictly using the 15.4 phy interface because it's a nightmare

I've been playing with an implementation based on what I think are the best bits of each of them, would definitely appreciate any thoughts.

[thejpster]

Having spent most of my professional life making radios, I'm not entirely convinced this will work. The purpose of a HAL is to ensure hardware can be swapped out, and where that ability is useful, it will be part of that particular wireless protocol spec. The HCI layer in the Bluetooth spec is a good example - you can use any vendor's HCI baseband with any HCI implementing stack (in theory). The sort of HAL that might be useful for a wide range of packet networks is a socket API, like the Berkeley Socket API. I don't know how that would look in Rust though. It would also be good to see an AT command client interface for communicating with AT devices too, but that's more of a protocol implementation rather than a HAL. Cheers Jonathan

[therealprof]

I tend to agree with @thejpster here. The only thing that would probably be applicable here is a PHY layer HAL which might actually work great for Ethernet but not others. I'd actually be down for that, I really would like to use https://github.com/m-labs/smoltcp some time soon.

The mentioned implementations are full "OS"es with plenty of the OSI layers implemented so scope is really far beyond the Rust embedded-hal.

[ryankurte]

@thejpster Same, but, after working on far too many ISM band digital radio IC drivers and ports for all the projects I listed, I have the opposite opinion 😂

Some protocols do have specs, but modern digital radio ICs are capable of supporting a huge number of protocols, so those protocol abstractions (when they exist) are typically too high level for drivers to be useful.
You're correct that it won't work for everything, but I'd challenge you to find a (perhaps not wifi/ble) protocol that you can't build on top of a state/send/receive/interrupt interface like this.

Also I think the existence of this abstraction in every IoT OSs with a variety of protocols on top is pretty good validation that it's useful. The operating systems above run 802.15.4(g), Thread, Dash7, LoRA/LoRAWAN, and proprietary stuff, all on top of those common phy interfaces.

@therealprof this is a physical layer HAL? Sorry if that was unclear, could rename to RadioPhy or something. It provides a packet interface to the physical radio peripheral that exists in most of the ICs I use (not to say it's not useful for external packet radio devices too), that can be built on to support the rest of those OSI layers you mentioned.

IMO having something like this to generalise the physical layer is the first step to building up the rest of the LP-WAN networking components (which is basically why I'm interested in rust).
I'd definitely support an EthernetPhy and I think the sockets api is a great idea if even more abstract from embedded hardware than this.

[therealprof]

I'd very much support a PHY HAL, although I'm not quite sure whether this is possible for wireless protocols at all since those usually have far more drastic requirements than Ethernet or the usual serial busses. I'd be happy to be convinced otherwise. The OSes do quite a bit of black magic to make all layers work so I'm not sure whether that will compare.

[ryankurte]

Closing until I've had a chance to prove it across a couple of devices.