[WIP] sys- and high-level bindings to the nrf-802154 C driver in nrfxlib
#78
Conversation
f24b7f6 to
f8c0cd3
Compare
|
This is pretty terrible, and I can't believe Nordic can make such a gross error, so I might be missing something. A second pair of eyes looking at it would be appreciated! |
|
Thanks for working on this! I think it probably makes the most sense for these crates to live in a separate repo. I'm mostly focused on bluetooth so it will be hard for me to review and test this. If there's any changes you need to |
Putting the 802.15.4 driver in a separate repo might mean that yours and that separate repo would have to agree on the exact same git hash used for the 3 GIT submodules. Or at least for the two "nrf(x)" ones. I don't know enough of the nRF echosystem to say whether mpsl being compiled against one "nrfxlib" GIT rev, and nrf-802154 against another would necessarily fly. It seems this repo is simply tracking the tip of the main branch for every GIT submodule, and since the content is copied at the time of publishing on crates.io (right?) it would not be easy for me to figure out which mpsl version exactly ended up in the Would you be open to setting a GIT rev hash in the git submodules and then having a process to raise the hash (which should end up maybe in bumping the minor version of the mpsl and sdc modules)? Or if you would say the above would not be necessary, perhaps to explain why it would not be necessary, in the context of the nRF development flow (as in, are they really keeping their main branches totally backwards-compatible, so that mixing and matching the mpsl blob from one GIT rev with the open-source nrf-802154 C code from another GIT rev would be OK)? |
|
Ah no, I stand corrected. So yeah, if only you bump the minor rev of |
44b0228 to
242eaff
Compare
242eaff to
f3d3210
Compare
|
Yes, there shouldn't be any need to match the exact nrfxlib version between the two crates. We need to be sure to bump the major version of nrf-mpsl and nrf-mpsl-sys when updating to a new version of nrfxlib that has breaking changes in the ABI. |
|
Closed in favor of maintaining the |
The high-level
nrf-802154crate is yet to be implemented in flesh, but I'm seeking early feedback whether such a contribution would be accepted, and whether thesysbindings (which should be fairly complete though untested) follow the established project conventions.(
The primary use-case for this is the
rs-matter+rs-matter-embassycrates, which need a good 802.15.4 driver for Thread, and ideally - co-existence between BLE and Thread, as not all Matter controllers (Alexa) support non-concurrent Matter commissioning, where the BLE radio runs standalone before Thread/802.15.4 is being activated.Also, I have been having so far mixed results with the
embassy-nrf802.15.4 pure-Rust driver, which I attribute to my lame pure-Rust implementation of the MAC-level features that theopenthreadlib requires. So in a way, I need a stable, battle-tested reference implementation of the 802.15.4 protocol which is known to work well, as the alternatives are not there yet (including the 802.15.4 Rust driver for the Espressif chips).)
The one friction point I see is that the 802.15.4 radio is open source (putting aside the closed-source
sllib inside it which optionally binds it to thempsllayer I think), unlike thenrf-mpsl-sysandnrf-sdc-sysbindings, which are closed source and thus do not need to be compiled from C code on-the-fly.For now, I'm compiling the C source code with
clang(which is assumed to be available on the developer's machine, and which is necessary anyway so as thebindgenutility to do its job in this and other crates). This is the easiest option for the user I think , because otherwise one needs to install thearm-none-eabiGCC toolchain.The additional tools that are necessary are
cmake,gmake(and/orninja) and likely anarutility for the.alibs. There could be more and I need to check that.The one annoyance with
clangis it does not have a sysroot. Sysroot comes with thearm-none-eabicross-toolchain, but requiring the GCC cross toolchain just for the sysroot includes would mean we would do a full circle and then we could just as well build the C sources witharm-eabi-none-gcc.To avoid the need for the GCC sysroot, I had to define a "minimal" one, which consists of 4
mem*functions in thestring.hheader, as well as theassertmacro in theassert.hheader, which are both part of the project.The user is expected to provide at runtime impls for the
mem*functions with e.g.tinyrlibcor similar.====
Future
If
clang,cmake, and the rest are considered too much of a burden for the user, we might implement what theopenthreadwrapper does: we could compile (and even rust-bindgen!) the 802.15.4 driver during CI, and then push to GIT the generated artefacts. This way, the users would have a "pure Rust" experience by default - yet - the security-paranoid ones would still have the option to (re)-build the C lib and the Rust bindings at build time usingbuild.rs.