To start direct connectable advertising on the cordio stack, the programmer should call the function DmConnAccept instead of the function DmAdvStart .
This functions expect the target address and address type as parameter, which are passed to the controller when the programmer sets the advertising parameters and not known when advertising_enable is called.
Therefore, this information should be kept in memory when advertising parameters are set and retrieved when advertising is enable to choose the right call to start (or stop) advertising.
Timeout of direct advertising is also handled in an uncommon way, a connection timeout is received. Similarly, DmConnClose should be called to stop connectable direct advertising.
The state is kept in an array of direct_adv_cb_t. Each items contains a peer address, the peer address type, the connection handle and the advertising handle as well as a state which indicate if the advertising is running, pending or not used.
When advertising parameters are set, the state is updated to match the target address or disable direct advertising management for the advertising set being configured.
When advertising is enabled, the pal dispatch the operation to the right calls (DmAdvStart/DmConnAccept or DmAdvStop/DmConnClose).
When an advertising timeout happen or a connection is made, the pal cleans any direct advertising state of this advertising set
Nothing in the Bluetooth standard prevents update of advertising payload while advertising is active.
This limitation wasn't present in previous version of the stack and is not present for extended advertising.
For actual connections, full ConnectionParameters is used. But
as per BLE specification, Generic Access Service can display
preferred connection parameters which is a smaller subset and
ConnectionParams_t matches exactly. Thus we rename/repurpose
it to PreferredConnectionParams_t.
Functions in Cordio for device name & appearance are currently
unused as they are both part of and dependent on deprecated
Mbed OS BLE APIs.
Nonetheless we want to keep them (and disable using macros)
so we can reintroduce them and make improvements in the future
as needed.
Remove lwIP reliant networking and BLE tests for baremetal
Mbed OS 5 ported lwIP in its OS mode and uses threads. Networking
that rely on lwIP needs to be removed so it can be compiled with the
baremetal profile.
The BLE cordio Greentea tests are also disabled given that the feature
is not supported without an RTOS.