Mares Smart Dive Computer + Bluelink pro

[Linus Torvalds]

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:

    https://github.com/torvalds/libdc-for-dirk/commit/e97886a994c18844bdcb1e1832ce4475dbe409b0

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
> logging.

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
side".

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 common.

                   Linus