Hello all,
Recently, I have mentioned some planned BLE-related changes to the
newtmgr tool. I wanted to share some of what I was thinking. Please
feel free to comment and criticize as needed.
* All BLE code gets removed from the newtmgr tool. The gatt library is
also removed.
* A separate tool, blehostd, runs in its own process. This tool:
* Is a Mynewt app running in the Mynewt simulator.
* Contains the NimBLE host and UART BLE transport.
* Caches information about connected peers (who is connected and how
their services, characteristics, and descriptors map to attribute
handles).
* Communicates with other processes via JSON over a streaming UNIX domain
socket.
* Exposes the host API via JSON-encoded requests, responses, and
events.
* Controller is accessed via UART device (/dev/cu.<...>). This could be
a Mynewt device running the blehci app, or any other controller.
The blehostd app solves a few problems for us:
* Fixes the bugginess and lack of cross platform support in
newtmgr (caused by the gatt library).
* Exposes a generic interface into the NimBLE host for software
other than newtmgr.
Here is how I envision newtmgr using BLE:
1. If an instance of blehostd isn't already running for this
controller [*]:
a. Open and bind to a socket.
b. Start an instance of blehostd, passing it the socket filename
and the controller's /dev filename.
2. Newtmgr tells blehostd to connect to the destination device.
If the device is already connected: blehostd immediately responds,
indicating the connection handle of the device.
Else: The response indicates that the connection attempt is in
progress. Eventually, blehostd sends an event indicating
success and a connection handle, or failure.
3. Newtmgr asks blehostd if the peer's newtmgr characteristic has been
discovered yet.
Yes: blehostd's response indicates the characteristic's
attribute handle.
No: newtmgr tells blehostd to discover the newtmgr
characteristic. After discovery completes, newtmgr repeats
this step so that it knows the characteristic's value handle.
4. Newtmgr builds the CBOR newtmgr request, as always.
5. Newtmgr encodes the CBOR newtmgr request as a bluetooth ATT write
command, and tells blehostd to write it to the peer's newtmgr
characteristic.
6. blehostd immediately responds, indicating success or failure.
7. If successful, blehostd sends an event containing to the peer's
notification (corresponding to its newtmgr response).
[*] This might be a bit tricky to get right. The goal is to not have to
connect and perform service discovery for each newtmgr command.
Ideally, blehostd would stick around until some idle timeout is
exceeded. Then, newtmgr could just reuse the existing socket and
blehostd instance to immediately send a follow-up command. This is more
of an optimization, so it can probably come later.
All comments welcome.
Thanks,
Chris
