Previously the concepts of initLength and lenth were clearly separated.
However, this was at the cost of registering all characteristics in the
SoftDevice as having variable length. Clearly, this is not the desired
behaviour. Therefore, an additional field '_hasVariableLen' is added to the
GattAttribute to address the problem. Also, the GattAttribute and
GattCharacteristic constructors have been modified to take a boolean that
sets '_hasVariableLen'.
**NOTE:** Changes to this module will cause projects to fail the build stage
if changes to the BLE_API are not published first.
In previous versions of BLE_API the GattCharacteristic initLen parameter is
named minLen as well. When the characteristic is committed to the SoftDevice
the value of initial length is also used as the minimum length of the
characteristic value. Furthermore, the test (max_length == min_length) is used
to determine whether the characteristic value has variable length. This is
slightly confusing and also causes problems if the user wishes to use a
characteristic with variable length but the initial lenght is equal to max
length.
To solve this problem the characteristic is now always committed to the
SoftDevice as variable. Furthermore, the API only maintains the current lenght
and the max length i.e. the field initialLen in the GattAttribute is removed.
In nRF5xGattServer all calls to getInitialLength() are removed and replaced
with getLength().
*NOTES:*
* This change requires updates to ble.
* Ideally we would like the characteristics to be declared as 'variable' only
when necessary, but this requires changing the signature of the
GattCharacteristic and GattAttribute constructors. Therefore, it will be part
of a separate pull request.
The ble-nrf51822 implementation of the BLE API executes callbacks for radio
notification events at very high priority. This functionality is replaced by
executing the radio notification callback at a lower priority. When using
mbed OS the callback is posted through minar. In mbed classic the callback is
executed directly, but from a lower priority. Note that minar or callback
execution in mbed classic could not be posted/generated directly from the
radio notification handler because this causes race conditions that may lead
to a hard-fault. Alternatively, a Timeout was used to post the callback in
another context with lower priority.
