Open markushx opened 4 years ago
Hey awesome projects! thanks for the questions.
Would it be possible to use rust-radio-hal for the radio-related platform
It certainly should be, though it does to some extend depend on the correspondence between the functions defined in radio-hal
and required in other places. I am totally open to extending radio-hal
to support APIs like this.
I have a background plan of defining / implementing an ieee802154 API and an abstract LoRaWAN
API, but haven't had the time for this yet.
In terms of rust binding, you might find it useful to define a trait with the required methods for interaction from the rust side, then to define c ABI compatible callers for that that are used by the c library. I did this a while back for one of the radio drivers to support a fully rust API using a c driver over a rust trait for SPI and GPIO. It has since been replaced with a pure rust implementation, but, exists around this commit.
How actively is the radio HAL maintained currently?
Pretty actively maintained, though not guaranteed to be stable just yet. There's a bit more experimentation to do around how to effectively split and expose APIs, and some common radio functionality to be added, but I have been deploying radio drivers based on this for ~2 years now.
At the moment it's a personal project but should more people adopt this my intent is to migrate ownership of both this and the related drivers to rust-embedded
or a wider-community equivalent.
Is there a HAL implementation for nrf52/53?
Not for radio-hal
at this time, you might be interested to look at https://github.com/jonas-schievink/rubble which targets the nRF52. There is an embedded-hal
implementation here and the nRF52 platform gets quite a lot of use with rust.
Hey awesome projects! thanks for the questions.
Would it be possible to use rust-radio-hal for the radio-related platform
It certainly should be, though it does to some extend depend on the correspondence between the functions defined in
radio-hal
and required in other places. I am totally open to extendingradio-hal
to support APIs like this.
Will take a look and report back if something is missing.
I have a background plan of defining / implementing an ieee802154 API and an abstract
LoRaWAN
API, but haven't had the time for this yet.
Alright, will watch the repo.
In terms of rust binding, you might find it useful to define a trait with the required methods for interaction from the rust side, then to define c ABI compatible callers for that that are used by the c library. I did this a while back for one of the radio drivers to support a fully rust API using a c driver over a rust trait for SPI and GPIO. It has since been replaced with a pure rust implementation, but, exists around this commit.
Certainly interesting and intended, but likely to be above my Rust-foo right now. Will dive more into the referenced code. Feedback on https://gitlab.com/markushx/opentrust/ and/or idiomatic wrapper API proposals are more than welcome.
How actively is the radio HAL maintained currently?
Pretty actively maintained, though not guaranteed to be stable just yet. There's a bit more experimentation to do around how to effectively split and expose APIs, and some common radio functionality to be added, but I have been deploying radio drivers based on this for ~2 years now.
At the moment it's a personal project but should more people adopt this my intent is to migrate ownership of both this and the related drivers to
rust-embedded
or a wider-community equivalent.Is there a HAL implementation for nrf52/53?
Not for
radio-hal
at this time, you might be interested to look at https://github.com/jonas-schievink/rubble which targets the nRF52. There is anembedded-hal
implementation here and the nRF52 platform gets quite a lot of use with rust.
BLE is (at least currently) only the secondary transport (mostly for commissioning), 15.4 the primary. I am aware of the nrf-hal.
Thanks.
Hi @ryankurte,
I am working on bindgen'ing OpenThread (https://gitlab.com/markushx/opentrust/) and am looking for an easy way to fulfil its required platform functions.
Several questions: