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
