]> sigrok.org Git - libsigrok.git/commit
rdtech-um: rework serial reception and processing, including re-sync
authorGerhard Sittig <redacted>
Wed, 15 Mar 2023 19:39:10 +0000 (20:39 +0100)
committerGerhard Sittig <redacted>
Thu, 16 Mar 2023 13:29:30 +0000 (14:29 +0100)
commit481f894fb2a125a5186b096a05dc2d62f7f986be
tree2ba3530555227176c33722613ae72d2801574500
parent7cfa93b013341e1980461c4a56c8d8c0bca800c8
rdtech-um: rework serial reception and processing, including re-sync

The previous implementation was expensive on the serial transport and
kept calling into this layer for individual bytes, to simplify the logic
which synchronized to the packetized input stream. And it used to block
in main loop calls until reception of a packet completes, which could
take some 200ms in the RFCOMM setup, and not much less for USB CDC.

Rework the call chain from main loop receive callbacks to processing
packets. Grab receive data in large chunks from the serial layer. Try
to rate limit the synchronization to the packet stream and associated
diagnostics messages. Process more return values and stop acquisition
upon errors. Move the checksum test to the packet content processor.
Check acquisition limits in the spot which just submitted more data
(keep another check in the periodic callback to handle time limits).
Strive for fast yet rate limited transmission of periodic measurement
requests, to initiate the reception of more sample values.

Shorten more lines (and avoid continuations and line breaks) by renaming
routines and variables. Pass packet content references such that content
handlers need not know about reception details, and reception can chunk
data differently in future versions.

This implementation became rather complex, most of all because of UI
concerns and robustness, as well as potential for future extension of
the scope of these code paths. The loss of synchronization and slow
reception of packets in chunks in combination with periodic request
transmission based on intervals results in "interesting" behaviour.
Maybe something simpler is desirable which is more expensive to run
but easier to maintain and reason about?
src/hardware/rdtech-um/protocol.c