Some usage problems about BLE stack "nimble"

[donghengqaz]

I think the "nimble" is not well designed for async message management, like reading sensor data from remote BLE service characteristics, and if it cost about 1s.
In esp-idf, I can read sensor data in nimble callback function and then send result, so the client in host side always can get the data. But in toit, we need application update this characteristics and then client is able to get this data.
My request is as following:

1. support to create a characteristics which has no value, and client's reading cause a timeout if application don't set value
2. support to remove its data after client finishes reading, if client continues to read, it follows step 1

[mikkeldamsgaard]

There is a way to do it with the current implementation.

1. Setup a Write attribute (REQUET_READ)
2. Setup a Notification attribute (READ_RESULT)

Then client subscribes to the READ_RESULT and writes to REQUEST_READ (any payload) when it wants sensor data.

The toit app will then sit in a loop and wait for a requiest to REQUEST_READ and read the sensor and notify the READ_RESULT.

I acknowledge that we can not at the moment implement any existing BLE scheme with the toit driver. The read with callback is something that we have discussed and will probably make it at some point.

[donghengqaz]

Yes, this is a solution, or maybe this is the really right solution to write BLE application. But some users like me, we are trying to porting application from C/C++ to toit, so we hope to keep the original behavior instead of refactoring the host tool or phone APP.
So now we have to add delay in host tool and phone APP to wait for toit application finished setting value, because adding delay is much easier and we should not refactor the host tool and phone APP deeply. But this is not a root solution in my opinion, although delay make the behavior a like. Because in original C/C++ application, host tool and phone APP also wait for some time to get BLE response in this case.

[mikkeldamsgaard]

Should be fixed in #1470. Please check it out and let me know if that solves the problem.

[donghengqaz]

Thanks for your kind help and solution, I'm refactoring BLE provisioning based on your PR. But it looks that your implement makes toit application much more complex, for example:

now there are 2 block functions:

• characteristics.read(wait for host writing data)
• characteristics.handle_read_request (wait for host reading data)

so I have a create 2 tasks in toit application: read task(wait for host writing data) and write task(wait for host reading data), then the read task should control the state and sync the result to write task. If it is, I think this is much more complex than adding delay to host applications.

[donghengqaz]

I almost finish this, if you have time, please take a look the BLE receive request usage: toitware/toit-provision#5.

[mikkeldamsgaard]

Yes, you are right, you will need more tasks to handle the long waits.

[floitsch]

Still looking into the provisioning case, but if (and I'm not there yet) the callback is only at a certain time, can I handle the data just then? The issue would be that I might start handling the read-request after the read-request was done. Would that work, or do I have to start handling read-requests before the first request comes in?

[floitsch]

Some experiments later:
it looks like I can't just start listening too late. Ideally, in the provisioning context, I would characteristic.read followed by a characteristic.handle_read_request. If I just do it in sequence things fail. If I start handling the request before the call to characteristic.read it works, even though the Toit code of handle_read_request is clearly executed after the read.

Maybe we can change this. It would make the provisioning code nicer.