Add ability to get full address bytes & address type to nrf52 Ficr #2074
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
bradjc
reviewed
Aug 14, 2020
chips/nrf52/src/ficr.rs
Outdated
| @@ -376,6 +383,28 @@ impl Ficr { | |||
| regs.deviceaddr0.read(DeviceAddress0::DEVICEADDRESS) | |||
| } | |||
|
|
|||
| pub fn full_address(&self) -> [u8; 6] { | |||
There was a problem hiding this comment.
Can we just call this address() and remove the address function that exists? I'm not sure what the old version is for, and make allcheck still works after I deleted it.
Otherwise looks good.
There was a problem hiding this comment.
Sounds good. I've renamed it!
And thanks for looking over this!
This changes the `Ficr::address` function to retrieve the full address as bytes (as opposed to the first 32bits of a 48bit address), and adds a new function `Ficr::address_type` to retrieve the address type. I'm adding these mainly so we can easily use the device's builtin address as its BLE address. Signed-off-by: David Ross <David.Ross@wdc.com>
daboross
force-pushed
the
add-nrf52-full-device-address-and-type
branch
from
dc05764
to
e487d96
Compare
hudson-ayers
approved these changes
Aug 14, 2020
daboross
pushed a commit
to daboross/tock
that referenced
this pull request
Aug 15, 2020
This is following a rebase on top of tock#2074, which now uses `address()` rather than `full_address()` for retrieving the device address.
ppannuto
approved these changes
Aug 17, 2020
alistair23
approved these changes
Aug 17, 2020
|
bors r+ |
alistair23
pushed a commit
to alistair23/tock
that referenced
this pull request
Dec 4, 2020
This is following a rebase on top of tock#2074, which now uses `address()` rather than `full_address()` for retrieving the device address.
bradjc
pushed a commit
that referenced
this pull request
Dec 9, 2020
This is following a rebase on top of #2074, which now uses `address()` rather than `full_address()` for retrieving the device address.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Pull Request Overview
This adds the ability to get the full address as bytes (as opposed to part of the address, or the full address as a string), and a secondary function to get the address type.
I'm mainly interested in using this in order to use the device's address as the device's Bluetooth LE address.
I added the "full_address" function alongside the existing address function for backwards compatibility, but I think it might be better overall to expose just one function returning a
[u8; 6]. As far as I can tell from the documentation, deviceaddr0 and deviceaddr1 are always meant to be used as a pair?Testing Strategy
Printing the device address & address type on a local nrf52840dk module
TODO or Help Wanted
Documentation Updated
/docs, or no updates are required.Formatting
make prepush.