Here's a patch to "Ignore requests to set coupling for the Hantek 6022BE",
this clears the LIBUSB errors for me.
Also in the patch:
- There is a crash because config_list() can be called with sdi == NULL.
This can be reproduced by doing:
"sigrok-cli.exe --driver hantek-6xxx --show"
- There seems to be a very unsafe loop in config_set() when setting COUPLING;
the coupling vector is assumed to be zero terminated, but is not declared
as such.
Note: The same issue is present also for other hardware, at least for
hantek-dso/api.c. The patch is only for hantek-6xxx though.
There were issues when using non-power-of-two data sizes with e.g.
the Hantek 6022BE device. For example, on Windows the acquisition would
simply hang and never complete:
hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_ERROR received 0 bytes
The issue was reported by Erik Montnemery on the mailing list, the
original patch was posted by "mmark" here (thanks!):
http://www.eevblog.com/forum/testgear/sainsmart-dds120-usb-oscilloscope-(buudai-bm102)/msg911729/#msg911729
The issue has been verified by me on Windows and Linux, and also that
this change does indeed fix it (tested Hantek 6022BE and Sainsmart DDS120).
Neither PulseView nor sigrok-cli hang anymore on Windows, and on Linux
the log messages suggest improvements as well:
-hantek-6xxx: data_amount 712
+hantek-6xxx: data_amount: 200 (rounded to power of 2: 512)
-hantek-6xxx: receive_transfer(): calculated samplerate == 2327ks/s
-hantek-6xxx: receive_transfer(): status LIBUSB_TRANSFER_OVERFLOW received 512 bytes.
+hantek-6xxx: receive_transfer(): calculated samplerate == 1969ks/s
+hantek-6xxx: receive_transfer(): status LIBUSB_SUCCESS / LIBUSB_TRANSFER_COMPLETED received 512 bytes.
This fixes bug #821.
Some functions in std.c were using
const char *prefix = sdi->driver->name;
but were called from input/output modules as well (which don't have
a "driver" field).
As a temporary workaround, use "unknown" as prefix in such cases until
a more permanent solution is implemented.
This fixes bug #813.
This fixes the following build issue on OSX:
Undefined symbols for architecture x86_64:
"_sr_drivers_init", referenced from:
_sr_init in backend.o
This closes bug #802.
Aurelien Jacobs
Uwe Hermann
Erik Montnemery
Sebastian Zagrodzki
Mike Meyer
Benjamin Larsson
Thomas