On 05-07-17 20:01, Jan Mulder wrote:
On 05-07-17 18:23, Linus Torvalds wrote:
On Wed, Jul 5, 2017 at 8:57 AM, Matthias Heinrichs
<[email protected]> wrote:
Theoretically, this should happen through the flow control lines from
the
Bluetooth Chipset to our applications processor. When using BLE (Due
to the
much lower end-to-end baud rate), the flow control already is very
active
and controlling the bytes from the OSTC to the Bluetooth chipset. When
looking at the snoop file, it shouldn't hurt to reset this credit
counter
from time to time to 255. Or try a higher number like 65536?
Specification
says 255 but have you tried higher values?
It says it's only a single byte, so 255 is the max..
Linus
I made some progress by sending new credits, but it seems a bit more
complex that just sending a new 255 credits from time to time, but I'm
sure it going to work. I already had about 800 packets incoming during
my testing, but things seems very fragile. So too much WIP to push
anything out.
This all said, I really appreciate that you (Matthias and Linus) give
input to this subject.
Time for an update (finally). Good news this time. I just successfully
downloaded 118 dives from my OSTC3 over BLE. To be complete in my
description, this download ended in a libdivecomputer parsing failure on
dive 119, but at this point in time, I do not expect this to be a BLE
related thing. Simply downloading a couple of new dives, just works
without error at the end.
I did the following to the Subsurface code (functionally, code details
can be read from the commits I'm going to produce).
1) I undid the the aggressive "read until there is no more data coming"
in the BLEObject::read(). Not only because it breaks non-OSTC usage, but
simply because it is wrong.
2) As suggested by Anton, I implemented a more friendly read one level
above. ble_serial_read() now reads not only one packet, but reads up to
the requested size parameter. For example, the OSTC libdc parser code
reads from individual bytes, up to 1K blocks for the larger data parts
(profile data). I cannot test this adapted behavior of the serial ble
read for other that OSTC, but I have good hopes that this will work for
any serial over BLE libdb interface (assuming that these call this
function with the proper size parameter).
3) Implemented "credit management". Despite a simple concept, and
seemingly good documentation in the earlier mentioned TIO document, it
is a tricky process. Asking for to much or to little credit will stall
the download at some point, tripping a timeout. I spend (too) much time
understanding why my download stopped in a deterministic way after
correctly downloading 14 dives (and almost 13K 20-byte BLE packets).
--jan
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
