On Thu, Sep 27, 2018 at 6:26 AM Jef Driesen <[email protected]> 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
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
