Detect whether the FX2 firmware of the LWLA device exhibits the
short transfer bug. If so, work around the problem by limiting
reads to at most 64 bytes at a time. This slows down the memory
read after acquisition quite noticably, but makes the device
usable even in adverse conditions.
Reduce the number of long registers read in bulk during status
polling from 10 to 5. The LWLA1034 driver used to do that already
in an earlier iteration, which was then changed to be more like
the original vendor software. The reason for bringing it back now
is that it reduces the response size to 40 bytes, which works
around the spurious 64 byte limit bug in the FX2 firmware of the
LWLA devices.
The sr_input_dev_inst_get API documentation guarantees an input is fully
initialized as soon as the device instance is returned. An sdi
implementation should not set sdi_ready any earlier.
This fixes parts of bug #387.
The source file enum.hpp was not found when not building in the source
tree. Also, extraction of the brief description did not work correctly
when there was additional XML markup inside the <para> element.
The sixth character from ISET? is read and discarded. If the device is
turned off and on again, this won't be there and causes 10 ms delay in
every ISET? Luckily, this value isn't queried that often. To get the
sixth byte, the *IDN? command has to be issued before ISET?.
==18779== 800,000 bytes in 196 blocks are definitely lost in loss record 29 of 29
==18779== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==18779== by 0x4E635C3: receive (analog.c:319)
==18779== by 0x40870B: datafeed_in (session.c:316)
==18779== by 0x4E59D4E: sr_session_send (session.c:1201)
==18779== by 0x4E59F8B: sr_session_send (session.c:1159)
==18779== by 0x4E62595: send_chunk (wav.c:234)
==18779== by 0x4E62A06: process_buffer (wav.c:290)
==18779== by 0x40954A: load_input_file_module (input.c:123)
==18779== by 0x4097AB: load_input_file (input.c:157)
==18779== by 0x40531E: main (main.c:288)
==17549== 32 (16 direct, 16 indirect) bytes in 1 blocks are definitely lost in loss record 22 of 39
==17549== at 0x4C29110: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==17549== by 0x5359200: g_malloc (in /usr/lib64/libglib-2.0.so.0.4200.2)
==17549== by 0x536EE2D: g_slice_alloc (in /usr/lib64/libglib-2.0.so.0.4200.2)
==17549== by 0x5370165: g_slist_append (in /usr/lib64/libglib-2.0.so.0.4200.2)
==17549== by 0x4E595C3: sr_session_datafeed_callback_add (session.c:512)
==17549== by 0x409527: load_input_file_module (input.c:111)
==17549== by 0x4097AB: load_input_file (input.c:157)
==17549== by 0x40531E: main (main.c:288)
==7478== Invalid write of size 8
==7478== at 0x4E59182: sr_session_dev_remove_all (session.c:302)
==7478== by 0x4E591CD: sr_session_destroy (session.c:265)
==7478== by 0x4095D9: load_input_file_module (input.c:143)
==7478== by 0x4097AB: load_input_file (input.c:157)
==7478== by 0x40531E: main (main.c:288)
==7478== Address 0x7877eb8 is 88 bytes inside a block of size 96 free'd
==7478== at 0x4C2A37C: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==7478== by 0x4E5F454: sr_input_free (input.c:573)
==7478== by 0x4095C3: load_input_file_module (input.c:140)
==7478== by 0x4097AB: load_input_file (input.c:157)
==7478== by 0x40531E: main (main.c:288)
Do not use size_t for values whose width is defined by the device,
not the host. Also don't use size_t for simple indices with known
small range, unless type compatibility considerations apply.
Refactor the sysclk-lwla driver to separate the generic logic from
the model-specific implementation. Based on this, implement support
for the SysClk LWLA1016 device.
On some systems it can happen that the USB 'bus' number is a lot larger
than 64, but sr_usb_find() currently errors out if it is > 64.
Example:
Bus 250 Device 006: ID 1ab1:04ce 1ab1 DS1000Z Series[...]
Increase that limit so that the code will work everywhere. This bus number
is queried via libusb_get_bus_number() which returns an uint8_t, so we're
limiting to 255 here.
Thanks to 'ssi' on IRC for reporting the issue.