On Sun, 2020-05-03 at 20:23 +0200, Wolfram Sang wrote:
>
> --- a/src/hardware/openbench-logic-sniffer/api.c
> +++ b/src/hardware/openbench-logic-sniffer/api.c
> @@ -136,19 +136,22 @@ static GSList *scan(struct sr_dev_driver *di, GSList
> *options)
> g_usleep(RESPONSE_DELAY_US);
>
> if (serial_has_receive_data(serial) == 0) {
> - sr_dbg("Didn't get any reply.");
> + sr_dbg("Didn't get any ID reply.");
> return NULL;
> }
>
> ret = serial_read_blocking(serial, buf, 4, serial_timeout(serial, 4));
> if (ret != 4) {
> - sr_err("Invalid reply (expected 4 bytes, got %d).", ret);
> + sr_err("Invalid ID reply (expected 4 bytes, got %d).", ret);
> return NULL;
> }
Hi! You asked (off list) about the motivation for the "has RX
data" check before the blocking receive call.
Must say "it's always been there". Recent changes by me which
might have made you ask me were purely mechanical. Got curious,
did follow several versions of annotated sources and changes of
that specific code path, and saw that the logic dates back to
2015-03 and bug 562.
I can see a point in only starting to block for the complete
response when reception started in the first place (after the
first byte arrived). Not sure whether there are supported
platforms or serial transports where timeouts are unreliable.
Though that's just a guess of mine. The current implementation
would bail out in the total absence of any response data, in any
case. Seems acceptable to me.
virtually yours
Gerhard Sittig
--
If you don't understand or are scared by any of the above
ask your parents or an adult to help you.
_______________________________________________
sigrok-devel mailing list
sigrok-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sigrok-devel
