On 04-07-17 20:30, Linus Torvalds wrote:
On Tue, Jul 4, 2017 at 10:04 AM, Jan Mulder <jlmul...@xs4all.nl> wrote:
:-) What I can add to my use case ... even the communication stops, the
"download mode enabled" stays on on the OSTC3.
Looking at the dump, I think this is a flow control issue with that
"rx/tx credit" thing.
In particular, I think - if I read that dump correctly - that in
packet 90 you set that receive credit to the max by writing one byte
of 255 to handle 18.
And I didn't count the exact number of Handle Value Notification
packets you get on the handle 0x0f, but it's definitely in the ~250
packet range (starts at packet 131, ends at packet 395, with roughly a
dozen packets that we send in between.
If it's not exactly 255 packets, it's something very close.
So I think you may need to write that credit thing every once in a while..
Linus
Indeed, that was something I was thinking of myself. And to check this
idea I already did write the 255 value to that same descriptor I write
it to in the initialization on every call of the write() function. They
showed up correctly in the logging, including write confirmation. But
all this, the stopping behavior was identical. That made me think it was
not related to the initial credit setting.
This all said. I just counted the received packets ... and it is spot on
255 packets. So I'm now sure that it is related to that credit thing,
but still very unsure how to fix that, given my earlier attempt. I just
further tested setting the initial credits to 200, and, yes, I receive
exactly 200 packets from the OSTC.
A relevant fragment of that TIO doc: "It is the Terminal I/O client's
responsibility to track the number of UART credits granted by the server
(peripheral) by adding the number of received credits to a
credit counter and decrementing the credit counter for each UART data
packet written to the server. Once the credit counter reaches 0, the
Terminal I/O client shall not send any UART data until having received
additional UART credits from the server." (in this text, the Terminal
I/O client is Subsurface, and the "server" is the TIO implementation on
the Telit/Stollmann chip).
Ok, the current Subsurface code does not track "the credit counter", but
the quoted section is highly unclear (to me). Only tracking the counter
on Subsurface side will not help the OSTC to decide to stop sending. It
needs to be communicated too, and the only way seems the already tried
resetting it back to 255. What I'm going to try is, indeed tracking the
counter, and send the newly wanted packets, but taking care not to ask
more than the 1 byte can handle (that might explain why just asking for
255 when there al still 50 left does not work) ... what a pain ...
--jan
_______________________________________________
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
