Mares Smart Dive Computer + Bluelink pro
torvalds at linux-foundation.org
Thu Sep 27 08:55:10 PDT 2018
On Thu, Sep 27, 2018 at 6:26 AM Jef Driesen <jef at libdivecomputer.org> wrote:
> The semantics depends on the transport type, and not whether the actual
> parameter is NULL or not:
I hope you don't actually mind my commit e97886a994:
because it actually keeps the debugging code, and *allows* a user to
pass a NULL pointer for the "I want everything" case.
I really don't want to change the Mares back-end to have to know about
"sometimes things are packetized".
That's actually particularly true for the Mares for another reason:
the packets I'm seeing on BLE are not consistent.
For example, the 140-byte reply (plus the AA and EA bytes around it)
to the "get version" command doesn't come in as 7 packets of 20 bytes
of data plus one packet with the AA/EA bytes.
No, it comes in as *random* packets. Many of them have the full
20-byte payload, yes, but there are single-byte packets, and there are
various other odd sizes too. Pretty much anything between 1-20 bytes.
The reason is that clearly the USB dongle is just a "wait for data to
come on the serial side, pass it in packets on the BLE side when some
buffer has filled or when a timer event happens".
So the Mares BLE dongle at least *really* acts as a serial stream over
BLE, with no packetization at all on the protocol level.
So for Mares, BLE still acts as "stream protocol", even though the
_physical_ layer is packetized.
> The main reason why the iostream code always passes a non NULL pointer
> to the underlying implementation is because it needs the size for the
Yes, I realized that when I looked at it, but originally I just looked
at "what does the Mares back-end do, and what do we do on the BLE
So my initial reaction had been to just do the "act like a stream" on
the BLE side, but then that was defeated by the iostream code.
So doing it at the iostream side made all the issues just go away.
> For a packet based transport (e.g. ble and usbhid), the implementation
> should return a packet and indicate the size of that packet in the
> actual parameter. Thus the actual parameter is mandatory, and passing in
> a NULL pointer is indeed a very bad idea here.
See above. As far as the Mares is concerned, BLE really isn't "packetized".
I could do the looping in the mares backend instead, but that seems
silly. This is bound to come up in other situations too, as BLE gets
More information about the subsurface