I'm not sure what the implications would be here on the iOS app we wrote
that is based on the newtmgr protocol and makes use of the current BLE
service and characteristics, although we could rewrite it if necessary.
We use the currently defined newtmgr protocol and GATT services/chars to
get task info and statistic and stream them live onto the mobile device,
which I think provides a unique window into your device in a
non-invasive way.
I'm certainly OK with BLE being removed from the newtmgr tool and having
that supported by a dedicated tool or service based on UART/HCI, but
just to be sure are there any implications here for the newtmgr protocol
running on a mynewt app? It sounds like we should still be OK with the
app, though, and this is limited to the newtmgr tool itself not the
newtmgr protocol implementation or the BLE transport in the Mynewt app.
One advantage of taking the HCI approach talking to a Mynewt target over
UART is that you can add support to any OS, not just systems that
support BLE, and not having to depend on a specific OS or BlueZ version.
You need to do some work up front and it would require another nRF5x
board, but it solves more problems than it creates in my opinion.
Alternatively, you could use the simulator and try to add some hooks
into CoreBluetooth and BlueZ (so no additional HW required), but that's
ultimately frustrating and a significant maintenance burden. UART/HCI
seems like less work both short and long term, and the requirements for
an additional nRF5x board seems relatively trivial.
Removing the dependency on the current GO lib and moving to HCI/UART and
a dedicated Mynewt app is a +1 for me and worth doing before 1.0, even
if it's a major change ... with the caveat that I hope this won't break
anything with the newtmgr protocol that will cause us to have to rewrite
the newtmgr tool we wrote and want to release around the same time as
1.0.0 final. :)
On 24/01/17 23:49, Christopher Collins wrote:
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
