For some reason, uploading the FPGA binary into DSLogic in small chunks
does not work. In this commit, the whole binary image is loaded into memory
and transfer is done in one chunk.
Furthermore, the FPGA configuration structure was not initialized
properly. This was changed with the initialization values taken from the
original DSLogic software.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
Certain output modules do not understand double-precision data.
Although we need double precision to represent the full resolution
of 7.5 digit readings, temporarily convert data to single precision
so that the output modules understand it. While the reasing might be
off by a few counts, we ensure the output modules do not display
completely bogus data.
For details, see bug #779.
KNOWN ISSUES:
- When sampling with 100 NPLC, the poll function will timeout a few
times before the first sample is acquired. Increasing the timeout
passed to sr_scpi_source_add() will cause all the other commands to
be processed slowly, producing a sampling rate of about one sample
every ten seconds.
- Support for plug-in cards (44491A and 44492A) is not implemented.
- Support for AC, AC+DC and four-wire resistance measurements is not
implemented.
- Support for configuring the frequency measurement source is not
implemented.
Note: This commit is based on the initial implementation by
Christer Ekholm (but stashed into one commit), with some adaptations
(forward porting, coding style and consistency fixes) by Uwe Hermann.
The firmware has "on\n" and "off\n" commands since 1.10, so use them.
Apparently you can only set the state (on/off) of the load, but it's
not possible to query the current state.
Also note that the __ namespace is reserved by POSIX for its private
usage, so user land software should never rely on any kind of API
with a __ prefix.
For session sources without a file descriptor to poll a negative number
should be passed for the fd parameter. The hung-chang-dso-2100 driver
currently passes 0 instead, which is the stdin stream. Fix the issue by
passing -1 for the fd parameter.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
src/hardware/lecroy-logicstudio/protocol.c: In function 'handle_fetch_samples_done':
src/hardware/lecroy-logicstudio/protocol.c:261:3: warning: passing argument 6 of 'libusb_fill_bulk_transfer' from incompatible pointer type
recv_bulk_transfer, (void *)sdi, USB_TIMEOUT_MS);
^
In file included from ./src/libsigrok-internal.h:31:0,
from src/hardware/lecroy-logicstudio/protocol.h:26,
from src/hardware/lecroy-logicstudio/protocol.c:23:
/home/uwe/sr_mingw/include/libusb-1.0/libusb.h:1546:20: note: expected 'libusb_transfer_cb_fn' but argument is of type 'void (*)(struct libusb_transfer *)'
static inline void libusb_fill_bulk_transfer(struct libusb_transfer *transfer,
^
src/hardware/lecroy-logicstudio/protocol.c: In function 'fetch_samples_async':
src/hardware/lecroy-logicstudio/protocol.c:314:4: warning: passing argument 6 of 'write_registers_async' from incompatible pointer type
handle_fetch_samples_done);
^
src/hardware/lecroy-logicstudio/protocol.c:200:12: note: expected 'libusb_transfer_cb_fn' but argument is of type 'void (*)(struct libusb_transfer *)'
static int write_registers_async(const struct sr_dev_inst *sdi,
^
src/hardware/lecroy-logicstudio/protocol.c: In function 'lls_start_acquisition':
src/hardware/lecroy-logicstudio/protocol.c:1122:3: warning: passing argument 6 of 'libusb_fill_interrupt_transfer' from incompatible pointer type
recv_intr_transfer, (void *) sdi, USB_TIMEOUT_MS);
^
In file included from ./src/libsigrok-internal.h:31:0,
from src/hardware/lecroy-logicstudio/protocol.h:26,
from src/hardware/lecroy-logicstudio/protocol.c:23:
/home/uwe/sr_mingw/include/libusb-1.0/libusb.h:1602:20: note: expected 'libusb_transfer_cb_fn' but argument is of type 'void (*)(struct libusb_transfer *)'
static inline void libusb_fill_interrupt_transfer(
^
This g_close(), the only one in the whole code-base, would unnecessarily
raise the minimum glib version to 2.36.
Thanks to Daniel Glöckner for the report.
This fixes bug #724.
In some situations, the reply to the *IDN? command contains an
additional trailing 0x01 byte for unknown reasons.
This issue seems to be reproducible by changing the voltage using the knobs
on the device, then turning on the output and turning it off again.
The next korad-kaxxxxp scan() operation would contain the trailing 0x01
byte, which would lead to the detection of the device in libsigrok no
longer working until the next power-cycle.
Work around this issue by treating both the ID string with and without
the trailing 0x01 byte as valid.
This is a desperate measure to improve the success rate of device
initialization even after it got into a bad state. Combine this
with a reduced USB timeout (1 second) so that if it fails, it fails
quickly. Also ignore USB errors from the initial dummy read of the
device test ID.
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 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?.
Diego F. Asanza
Soeren Apel
Uwe Hermann
Sergey Alirzaev
Alexandru Gagniuc
Chriter
Aurelien Jacobs
Lars-Peter Clausen
Daniel Elstner
Tilman Sauerbeck
Hannu Vuolasaho