It is common for application to need to know the number of bonds stored at any
time, for the purposes of bond management. This simple addition allows
applicaitons to discover the number of bonds present using the existing API.
Introduce abality to explicitly perform a notify/indicate opertion on a characteristic.
This brings benefits of a reduce RAM footprint for storing GattCharacterisitics.
n.b. temporary measure until ARM mbed integrate more generic optimisations.
The new API is added to the Security Manager. Its declaration is as follows:
virtual ble_error_t getAddressesFromBondTable(Gap::Whitelist_t &addresses)
The resulting Whitelist_t structure can then be used as the actual whitelist
passes to Gap::setWhitelist().
Note that for peers that have private resolvable addresses, then an address of
the same type will be returned.
This is the finilised experimental API that introduces support for
whitelisting. The changes are focused in Gap and introduces the following
functions, that are expected to be implemented by each of the vendor specific
glue code (e.g. ble-nrf51822 module):
- getMaxWhitelistSize(): Get the maximum whitelist size, this can be set by
using a yotta config definition.
- getWhitelist(): Gets a copy of the internal whitelist containing BLE
addresses.
- setWhitelist(): Replace the whitelist with new addresses.
- setAdvertisingPolicyMode(), setScanningPolicyMode() and
setInitiatorPolicyMode(): Functions used to set the relevan policy filter
mode as described in the BLE Specification v4.2 Vol 6, Part B, Section 4.2.1.
- getAdvertisingPolicyMode(), getScanningPolicyMode() and
getInitiatorPolicyMode(): Functions used to get the relevan policy filter
mode as described in the BLE Specification v4.2 Vol 6, Part B, Section 4.2.1.
The following enumerators were added to Gap to describe the desired policy
filter mode:
- AdvertisingPolicyMode_t
- ScanningPolicyMode_t
- InitiatorPolicyMode_t
Finally, the following typedef was added to provide a view of the
underlying implementation's internal whitelist:
- Whitelist_t
**NOTE:** Clearly, these API additions require changes to the underlying
implementation!
Accumulate and update advertising payload now differ in their implementations.
Accumulate updates the previous value, if it is UUID then the previously added
values are kept and the new one is simple appended. In contrast, update
replaces the previous value in all cases.
Add an additional error code to the ble_error_t enum to describe a failure
state caused by the internal platform-specific stack. This state was not
described by any of the existing error codes.
Modify the functions addData() and updateData() to correctly update the payload
information for a specified AD type if that type was already present in the
payload. For addData() if the AD type is not found, it is added to the payload.
In contrast, in updateData() if the AD type is not found an error is returned.
Documentation was updated accordingly.