On Fri, Mar 31, 2017 at 03:49:05PM -0700, will sanfilippo wrote: > Hello: > > There has been some discussion of this already on the list but nothing has > been done yet so I wanted to resurrect the conversation with some proposals. > > What we are trying to do here is the following: > 1) Have the controller get a public device address without it being hardcoded. > 2) Have the ability to read a chip-specific random static address if the chip > has one programmed. > > The proposal is the following:
> 1) Add two new API. These will be platform specific and will be placed > in the ble_hw.c file: > /* These API will return -1 if no address available. If available, will > return 0 > and will place the address in *addr */ > int ble_hw_get_public_addr(ble_addr_t *addr) > int ble_hw_get_static_addr(ble_addr_t *addr) [...] That sounds good to me. This covers all the use cases I can think of. As you mentioned, Bluetooth is somewhat asymmetric regarding public and random addresses. The controller is in charge of the public address while the host is in charge of the static random address. With the API you proposed, I think the workflow would look something like this: 1. At init time, controller calls ble_hs_get_public_addr(). If this call yields an address, the controller configures itself to use it. 2. If app wants a static random address, it calls ble_hw_get_static_addr(). If a random address is available, the application configures the host to use it with a call to ble_hs_id_set_rnd(). Does that sound about right? In thinking about this, I realized the host interface is missing something. There is currently no way for an application to ask the host for its public address. An application may want to know this to determine if it should configure a random address (or just for reporting purposes). The host does know its own public address--it gets it from the controller at startup--it just doesn't expose it to the application. Chris
