GitLab

* Fix H5Transport timeout issues

This commit addresses timeout issues that sometimes occur when calling sd_rpc_open.

The problem is identified to be in the transport layers.

The issue is addressed by:
    - Improving the state machine in H5Transport and improving UartBoost implementation
    - Requiring latest version of Boost (1.67). This to make sure all fixes in Boost ASIO serialport are included.

State machine
=============
The H5Transport is now waiting for the internal state machine to be ready before opening the serial port that sets state machine values.
The state machine transitions cover more exit criterias and the order of evaluating the exit criterias are improved.

Two new states are added: STATE_CLOSED and STATE_NO_RESPONSE. 

The state machine enters STATE_CLOSED when the user close the transport.
The state machine enters STATE_NO_RESPONSE when the device does not reply on packets sent after n number of retries.

The new states are used to give a more precise return value from sd_rpc_open.

toString methods on ExitCriterias based classes are added to simplify
debugging.

Integrations tests
==================
Integration tests for open close functionality has been added for pc-ble-driver, H5Transport and UartBoost.

The integration tests are implemented with the use of Catch2, a header file library test framework.
Initially Boost Test Library was used, but since we are considering moving away from Boost, we try not to add more Boost dependencies.

The old test that tested the Boost serial port implementation is removed.

Build system
============
The Boost library file names made by jam (boost build system) has changed for Windows builds.
For cmake to find the libraries one need to use a recent version of cmake.

We have tested it with cmake 3.11 and set it as a requirement.

Other changes
=============
* General changes to the source code:
    - Added const-ness where applicable
    - Where applicable, changed pointers to type pointed to or *_ptr
    - Made payload into an alias (from std::vector<uint8_t>)
    - Expose methods and functions to facilitate integration testing
    - Typedefs changes to using
    - Changed callback names to make it clearer if callback was intended for local transport or upper transport

Branch workflow
===============
We are now changing the pc-ble-driver git workflow.
Fixes and improvements that are relevant for all major versions of the driver are fixed in master then cherry picked into the major version branches.

To get to this state, this commit contains cherry picked commits from different branches.

Here is a table of cherry picked commits:
Uart boost fixes:
85cee39958f43d3fc07d596221af3b9a88b64bec
f566ce385ffbdd149274ae247f42447b5297490b
d8711bed9de7513ac68e6ca091fe6fc96ce93af9

H5Transport fixes:
e72d446f6d4de062535e8ec18b3caba8769aad32
6cfae50d4e3ae9103349e6c57de158511262d6e7

Spurious wakeup fixes and state machine fixes:
21e2556644633f5280edb9ddb88dcfabe9b2c807

Use correct config_tag when calling adv_start

The example was using the default cfg_tag when calling adv_start, instead of the cfg_tag that was used together with cfg_set. This made att_mtu_exchange_reply fail since the connection was not configured with sufficiently large att_mtu.

Fix patch on unix

Add stddef.h as include to heart_rate_monitor example

Macro BLE_EVT_LEN_MAX(ATT_MTU) in ble.h gave an implicit declaration of function 'offsetof'.

Fixed serialization transport to access queue in a safe manner

Version dependent typedef for boost asio service

Add fix for spurious condition variable wakeup

Fix typo in packet error encoding

Add updated connectivity hex files

Fix problem related to control packet state transitions

Connectivity firmware does not reply to control packets in between timeout intervals. Setting the timeout too high will thus result in lower responsiveness from connectivity.

Update connectivity firmware version

The statemachine required too many criterias for changing from uninitialized to initialized state. According to the Bluetooth specfication (V4.2 [Vol 4, Part D], 8.X) it is sufficient to to receive a CONFIG_RESPONSE to transition to initialized state.
In addition there were missing mutex unlocks at reception of some control packets when in uninitized state. This would leave the state machine silently waiting for certain packets without responding to the incoming packets, or retransmitting according to what packet was expected.
Also added response to CONFIG packet in active state, as described in specification.

Feature/reset refactor

Update readme