add nrf52-hal-common crate #5
Conversation
This commit takes what I believe to be the lowest maintenance approach to sharing a common implementation between two device crates. The common crate has a set of features that cause the underlying svd2rust generated device crate to be imported as `target_device`. The implementation in that crate then targets `target_device` rather than directly using either `nrf52` or `nrf523840`. This avoids littering the module with conditional code and/or macros. The consuming hal crates re-export the items from the common crate and augment with any other additional functionality. One downside to this approach is that the `nrf-hal-common` crate cannot be successfully compiled when multiple targets are built. This is fine in practice but does mean that building in a workspace will fail when that workspace enables multiple devices. For that reason this commit adjusts the travis config to build the crates individually.
|
Sorry, I'm a bit swamped right now. I'll take a look as soon as I take a chance, probably later this week. |
|
@wez I haven't forgotten this. Still busy though. I expect to have time to review next week. Very sorry to keep this hanging for so long! |
There was a problem hiding this comment.
If found a few things to complain about (as is my wont), but nothing major. Overall, this looks great!
Thank you for doing this @wez, and sorry again that I wasn't able to review this sooner.
|
Thanks again, @wez! I don't know if anyone else wants to take a look, but from my perspective, this is good to merge. |
|
I'm just going to merge this now. This has been open long enough, and I need to make some changes for my downstream project that are currently being complicated by all the open pull requests :) |
Update README.md
This commit takes what I believe to be the lowest maintenance approach
to sharing a common implementation between two device crates.
The common crate has a set of features that cause the underlying
svd2rust generated device crate to be imported as
target_device.The implementation in that crate then targets
target_deviceratherthan directly using either
nrf52ornrf523840.This avoids littering the module with conditional code and/or macros.
The consuming hal crates re-export the items from the common crate
and augment with any other additional functionality.
One downside to this approach is that the
nrf-hal-commoncrate cannotbe successfully compiled when multiple targets are built. This is
fine in practice but does mean that building in a workspace will
fail when that workspace enables multiple devices.
For that reason this commit adjusts the travis config to build the
crates individually.
Refs: jamesmunns/nrf52-hal#9