summaryrefslogtreecommitdiffstats
path: root/icons/trash-forbidden.png
diff options
context:
space:
mode:
authorGravatar Jan Mulder <jlmulder@xs4all.nl>2017-07-05 18:37:21 +0200
committerGravatar Jan Mulder <jlmulder@xs4all.nl>2017-07-11 13:17:00 +0200
commitb7057c414fc43bb81fc0d01bc07f32d18bce8ab0 (patch)
tree820eb498d61c6e315d68e52f8e909a9ac227d72f /icons/trash-forbidden.png
parentd233725519ca08d1d0e25c63550c44963dc2c093 (diff)
downloadsubsurface-b7057c414fc43bb81fc0d01bc07f32d18bce8ab0.tar.gz
OSTC over BLE: take care of credits
Handle credits. Do not just ask for maximum credits all the time as this will stop the download. Also do not let the credits go back to 0 (while this might work, this is not tested). Getting back the 0 credits stops the download, and even when it can be restarted, it is less efficient (and not needed). Notice also that it takes some time before a grant request is honoured. During testing I saw reception of up to 25 packets between request and grant. So a lower bound for the request of 32 packets seems resonable. One aspect the Telit/Stollmann TIO puzzeled me. Sections 4.1 and 4.2 both talk about credits, but my hyphothesis is that there are two credits counters in play. One for traffic either way. This commit only deals with credits granted by Subsurface to the OSTC to send data. Credits granted by the OSTC to allow Subsurface to send new commands is NOT part of this commit, and is seemingly not needed in our scenario. As we only send new commands to the OSTC when a previous one is finished (per HW's interface spec), the OSTC does not run out of credits to receive commands. Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Diffstat (limited to 'icons/trash-forbidden.png')
0 files changed, 0 insertions, 0 deletions