add "LE Device Address" 0x1B to advertising data types
Fork of BLE_API by
CONTRIBUTING.md@867:b099c28e8e28, 2015-11-02 (annotated)
- Committer:
- rgrover1
- Date:
- Mon Nov 02 09:09:08 2015 +0000
- Revision:
- 867:b099c28e8e28
- Child:
- 940:ae3eaccfac3a
Synchronized with git rev 2f92904f
Author: Rohit Grover
Release 2.0.0
=============
* Major change to the APIs around stack initialization. BLE::init() is now
meant to only trigger the initialization of the underlying BLE stack. init()
now takes a completion callback as an optional parameter; this callback gets
invoked when initialization completes.
- There's a new type: BLE::InitializationCompleteCallback_t
- There's a new API: BLEInstanceBase::hasInitialized() which transports
need to implement.
- If no init-completion callback is setup, the application can still
determine the status of initialization using BLE::hasInitialized().
!This update may require in a minor change to existing apps!
mbed-classic demos would look something like:
```
main() {
BLE::Instance().init();
while (!BLE::Instance().hasInitialized()) {
/* spin wait */
}
/* rest of the initialization ending in the waitForEvent loop */
}
```
whereas mbedOS demos would look like:
```
void bleInitComplete(BLE &ble, ble_error_t error)
{
WsfTrace("bleInitComplete");
if (error != BLE_ERROR_NONE) {
WsfTrace("initailization failed with error: %u", error);
return;
}
if (ble.getInstanceID() == BLE::DEFAULT_INSTANCE) {
/* use the BLE instance */
}
}
extern "C" void app_start(int argc, char *argv[])
{
BLE::Instance().init(bleInitComplete);
}
```
The Nordic stack initializes right-away, and so existing demos based on Nordic should continue to work.
* There's a new API: BLE::getInstanceID(), which simply returns the ID of an
instance.
* Reduce the memory footprint consumed by a FunctionPointerWithContext to 20
bytes (originally, it was 32 bytes !). Also enforce alignment constraints
of the embedded pointer to member function. This should help with the size
of a GattCharacteristic.
* Add EnvironmentalService.h under services/.
* There have been minor improvements to EddystoneService and EddystoneConfigService.
* We've added a CONTRIBUTING.md to help guide user contributions.
Who changed what in which revision?
User | Revision | Line number | New contents of line |
---|---|---|---|
rgrover1 | 867:b099c28e8e28 | 1 | # Hello! |
rgrover1 | 867:b099c28e8e28 | 2 | We are an open source project of [ARM mbed](www.mbed.com). Contributions via [pull request](https://github.com/armmbed/yotta/pulls), and [bug reports](https://github.com/armmbed/yotta/issues) are welcome! |
rgrover1 | 867:b099c28e8e28 | 3 | |
rgrover1 | 867:b099c28e8e28 | 4 | Please submit your pull request to the 'develop' branch of this module. Commits to develop will merge into master at the time of the next release. |
rgrover1 | 867:b099c28e8e28 | 5 | |
rgrover1 | 867:b099c28e8e28 | 6 | # Contributor agreement |
rgrover1 | 867:b099c28e8e28 | 7 | For your pull request to be accepted, we will need you to agree to our [contributor agreement](http://developer.mbed.org/contributor_agreement/) to give us the necessary rights to use and distribute your contributions. (To click through the agreement create an account on mbed.com and log in.) |