Closed pan- closed 7 years ago
@apalmieriGH Could you look at this ? It should fix the example BLE_LEDBlinker.
I think it will be necessary to go further at some point, almost every state in the gatt client is specific to one and one connection only, launching multiple request in parallel might lead to undefined behavior.
One solution would be to have a class named BlueNRGGattClient
which own an instance of a class named BlueNRGGattConnectionClient
for each connection. The class BlueNRGGattConnectionClient
would be identical to the current BlueNRGGattClient
and BlueNRGGattClient
would just act as a proxy to its instances of BlueNRGGattConnectionClient
.
I believe it is an easy change and it shouldn't require more logic, just forwarding from BlueNRGGattClient
to the appropriate BlueNRGGattConnectionClient
.
What do you think ?
@apalmieriGH Any update on this ?
Instead of calling the GattClient read callback once the data is received, the callback is called once the procedure has completed, this prevent users to launch another procedure while another one is already ongoing.
It was also possible that the flag currentState in the function gattProcedureCompleteCB got overriden by a user callback. Reordering the reset of this flag and returning immediatelly once the treatment has been done prevent this wrong behavior.
As a consequence, it is not required for a client to wait before calling aci_gatt_read_charac_val.