Repository navigation
Provisions for running on systems where nimble is already built #5
Description
Activity
If I'm understanding this correctly, we essentially have the following scenario:
- Instead of building+linking NimBLE via
apache-nimble/build.rs, you want to build it and link it yourself. - RIOT OS already handles the execution of the controller tasks.
- You would still like to use the high-level bindings provided via
apache-nimble
In that case, yes, I think for the most part, those points you listed are correct.
A way to switch raw from apache-riot-sys to using re-exports of the OS's header generation.
The build script essentially needs an "off" switch -- there's another component in this case that takes care of linking, and that is by static linking in this case.
(assuming you meant
apache-nimble-sys)This makes sense to me. My initial thought to do this would be to add an "empty" port layer (maybe a
port-layer-customfeature flag or something along those lines): essentially just disables the build scripts. Perhaps you can use an environment variable so thatapache-nimble-syscan generate the bindings from your version of NimBLE (as opposed to the one in this repo).Actually running the controller tasks likely needs to be feature gated: In RIOT, this is already being run in a thread.
For this point in particular, I don't know if we need to add another feature flag. In the example, we use
NimbleController::create_taskto run the controller. If RIOT already handles the controller tasks itself, you can probably just omit thatcreate_taskcall, and continue to useNimbleControllerwithtrouble.What is the intended scope of the apache-nimble crate?
The scope of that crate isn't super well-defined, besides being "higher-level abstractions on top of the low-level bindings provided by
apache-nimble-sys". It might be confusing that theapache-nimble/build.rsdoes actually compile and link the NimBLE code, but it's mainly like that because I thought it would be easier if the crate just did the building+linking itself (as opposed to users of theapache-nimblecrate needing to compile and link NimBLE themselves). For now, I'm okay with the ability to disable the building+linking parts. I think the idea of splitting the high-level API is interesting, but I'm not sure right now what that would look like, or if it's even worth pursuing. Would need to give it some more thought.- Instead of building+linking NimBLE via
Yes, we have the same scenario in mind. Thanks, I'll give it a try with a PR, then.
Actually running the controller tasks likely needs to be feature gated
I don't know if we need to add another feature flag
I'll give that another look. IIRC, the provided implementations called functions that for some reason were not even available. Might be that I found what caused that and fixed it differently down the line; I'll see that once I more systematically collect all the things that are currently spread across my checkouts.
I'd like to use these crates (mainly apache-nimble, and trouble building on it) on RIOT OS; I figure the situation with other C RTOSes might be similar when they come to a point where applications and modules can be built in Rust. Nimble is already built as part of RIOT OS (currently 1.5, but 1.8 is WIP), so I'd need to apply a few configurable changes.
As far as I can assess things so far (I got things to build but did not test running), this will need:
I should have a draft PR ready soon-ish, but at this point I'm unsure: What is the intended scope of the apache-nimble crate? I plan on using this with trouble sitting on top of it, so the part of the apache-nimble crate that is not modified is the
impl bt_hci::controller::Controller for NimbleController-- is that the core of apache-nimble (in which case I do think that it makes sense to allow disabling the build and link parts), or rather something that would be shared as an external component (so it may make sense to split that into a sharable component)?