I was thinking that sys/config might be a bit heavyweight for this especially given how in some cases we are really trying to get rid of as much code as possible.
> On Oct 30, 2016, at 12:57 PM, Christopher Collins <[email protected]> wrote: > > On Sat, Oct 29, 2016 at 10:55:46AM -0700, will sanfilippo wrote: >> Hello: >> >> First off, a bit of background regarding addresses in BLE. A BLE >> device must have a device address. This address can be either a public >> device address or a random device address. It may have both but must >> have at least one. >> >> Currently, the nimble controller gets its public device address by the >> application setting a global variable. This is obviously less than >> ideal; the address should come from some non-volatile memory. One of >> the main reasons that we “punted” on this was that we really didnt >> know how customers would program these devices and I didnt think the >> address would go into our config area. Well, I guess it could come >> from the config package assuming that the config came from some area >> in the hw… > > If you are up for it, I think using the sys/config package is a good > idea. The config package does not impose any restrictions on where the > value is stored, so it should be suitable for pretty much any system. A > benefit is that config settings are already generically accessible > through the shell and newtmgr. > > Of course, using sys/config for this purpose implies a dependency on > this package for all BLE apps. Also, adding a new config setting seems > to be a fairly heavyweight operation that requires a bit of code. > > [...] > >> So here are some questions: >> 1) What happens if there is a random address programmed in one of >> these places? I presume that the nimble stack should use it. >> 2) What happens if there is a random address in one of these locations >> but the host sends the set random address command? I presume the >> nimble stack should use the host provided random address. >> >> The more I think about this, I am thinking that the code should always >> look in both locations and populate any addresses it finds. Hopefully >> folks wont program two public device addresses or two random >> addresses. If they do, the one in the UICR will take precedence. > > I think that sounds totally reasonable. > > Chris
