On Mon, Mar 13, 2017 at 6:06 PM, will sanfilippo <[email protected]> wrote: > amit: > > There is already a function to return the device id. It is named > hal_bsp_hw_id() and exists in hw/mcu/nordic/nrf52xxx/src/nrf52_hw_id. Many > chips come with some form of unique id which was why this was placed in > hw/mcu.
Yes, thank you. I can reuse this API (for demo purposes), something like: rc = hal_bsp_hw_id(g_dev_addr, BLE_DEV_ADDR_LEN); assert(rc == BLE_DEV_ADDR_LEN); > I do not think I would put the API for ble device address in the same place. > Why? Because it is BLE specific. This device id is not. I guess folks can > make an argument that a public device address is just a 6-byte MAC address > and thus could be used for protocols other than BLE. The random static > address is BLE specific though. > > > My vote would be to place this API in one of the following directories: > hw/drivers/nimble/nrf5xxx/src/ /* there is a file called > ble_hw.c in this dir that might be a good fit */ > hw/mcu/nordic/nrf5xxx/src/ /* depending on whether we > think this should be a hal */ Agree with you and I'm also more inclined towards: hw/drivers/nimble/nrf5xxx/src > Finally, as for the naming convention, if this thing is going to be called > generically by code outside a nordic specific directory I would not name it > nrf_xxx. Once we have consensus where to place these API I think the name > will follow... if above is agreed, then nrf5xxx_get_devaddr_type() and nrf5xxx_get_devid() might be okay. Thanks, Amit -- Sent from Bahamas, while drinking chi-chi and piña colada.
