Some drivers check in some of their driver callbacks if the driver has been
initialized and return an error if it has not.
For the scan() callback the sigrok core checks if the driver has been
initialized and if not returns an error. So it is not possible that the
scan() callback gets called if the driver is not initialized. Without the
scan() callback succeeding it is not possible to get a reference to a
device which is associated with the driver, so it is not possible that any
of the device specific callbacks is called without the driver first being
initialized either.
In conclusion these checks are not necessary since they never evaluate to
true and can be dropped. If they should ever become necessary they should
be done in the sigrok core so all drivers and all callbacks are equally
handled.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
SR_CONF_CONTINUOUS is a capability option indicating whether a device
supports continuous capture or not. If the option exists the device
supports continuous capture and otherwise it doesn't. There is no value
associated with it and hence setting the SR_CONF_SET flag is nonsensical.
None of the drivers which set SR_CONF_SET for SR_CONF_CONTINUOUS handle it
in their config_set() callback and return an error if an application tried
to perform a config_set() operation for SR_CONF_CONTINUOUS.
Simply remove the SR_CONF_SET flag from all SR_CONF_CONTINUOUS options.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Every single hardware driver has the very same implementation of the
dev_list() callback. Put this into a helper function in the standard helper
library and use it throughout the drivers. This reduces boiler-plate code
by quite a bit.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
If a driver does not implement a dev_clear() callback the core will
automatically call std_dev_clear(di, NULL). Remove all driver dev_clear()
implementations that are identical to default. This reduces the amount of
boiler-plate code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
std_init() allocates a drv_context struct which needs to be freed by the
driver in its cleanup struct. But the vast majority of drivers does never
does this causing memory leaks.
Instead of addressing the issue by manually adding code to free the struct
to each driver introduce a new helper function std_cleanup() that takes
care of this. In addition to freeing the drv_context struct std_cleanup()
also invokes sr_dev_clear() which takes care of freeing all devices
attached to the driver.
Combining both operations in the same helper function allows to use
std_cleanup() as the cleanup callback for all existing drivers, which
reduces the amount of boiler-plate code quite a bit.
All drivers are updated to use the new helper function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Devices for the scpi-pps driver do have additional data attached to it that
needs to be freed when the device is freed. While the driver gets it right
for the cleanup() callback it does not for the dev_clear() callback. This
will cause memory leaks when sr_dev_clear() is called for this driver.
To fix this let the dev_clear() free the additional data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Devices for the deree-de5000 driver do have additional data attached to it
that needs to be freed when the device is freed. While the driver gets it
right for the cleanup() callback it does not implement a dev_clear()
callback, so the default dev_clear() implementation is used which will not
free the additional data. This will cause memory leaks when sr_dev_clear()
is called for this driver.
To fix this provide a dev_clear() implementation that frees the additional
data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Devices for the demo driver do have additional data attached to it that
needs to be freed when the device is freed. While the driver gets it right
for the cleanup() callback it does not implement a dev_clear() callback, so
the default dev_clear() implementation is used which will not free the
additional data. This will cause memory leaks when sr_dev_clear() is called
for this driver.
To fix this provide a dev_clear() implementation that frees the additional
data.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
When g_file_get_contents() encounters an error a new GError will be
allocated and passed back to the application. The application is
responsible for freeing this GError.
The baylibre-acme driver currently does not do this and as a result leaks
memory during the scan process when no device is found.
Add the missing g_error_free() invocations to fix the issue.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Make sure to free the FTDI device list and the FTDI context in scan_all()
otherwise memory leaks can be observed. Also make sure to free the FTDI
context in scan_device() on the error path.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
This makes the code shorter, simpler and more consistent, and also
ensures that the (same) debug messages are always emitted and the
packet.payload field is consistently set to NULL always, etc.
The USBee AX hardware needs a sampling clock that is lower than
the 30MHz or 48MHz that the FX2 has to offer. This flag will enable
clocking via the CTL2 pin that is an even divisor of the main clock.
The driver did not look at the mq_flags provided with the
SR_CONF_MEASURED_QUANTITY key, and it defaulted to DC measurements.
Use the second member of the tuple provided by the config key, which
represents the flags for the measurement, and set the instrument's
measurement mode accordingly.
Due to a PEBKAC error, after the last sample was sent, a new
measurement was triggered, but its value was never sent down the
session bus. This is easily fixed by incrementing devc->num_samples
right after a measurement is sent instead of when a measurement is
retriggered.
Using non power of 2 sizes causes the driver to not work on OS X.
Depending on the usb transfer mode the buffer sizes will map
perfectly to the underlying transport protocol.
scpi_serial generate an POLLIN event after the requested data is returned
by the instrument. For USBTMC it is necessary to
1. send an REQUEST_DEV_DEP_MSG_IN request
2. submit an USB bulk read transfer asynchronously.
Using the synchronous libusb_bulk_read() does not generate an POLLIN event.
Solving this properly needs major surgery in spci_usbtmc_libusb.
After acquisition start, DSLogic stores samples in memory, and when done it
sends a USB packet with the trigger position.
This initial fillup can take some time. If the user requests a session stop
in between, the USB transfer is cancelled and the session hangs because it
is not closed properly.
This commit manages this case and closes the session properly when
acquisition is stopped by the user.
Signed-off-by: Diego F. Asanza <f.asanza@gmail.com>
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?.
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.
The driver should now be able to cope with e.g. multiple ChronoVu LA8
and/or ChronoVu LA16 devices being connected to the same PC.
It now also provides the serial number and connection ID, which can be
used by frontends to differentiate multiple devices.
Also improve the scanopts / drvopts / devopts lists handling.
This fixes bug #504.
With the current driver API and the corresponding session event
handling, it is not possible to destroy and then re-create an
event source with the same key within the same main loop iteration.
The next generation driver API will fix this problem. But for now,
just change the driver to make do without that sort of thing. Also
increase the I/O timeout to 100 ms to be safer in the event of all
kind of delays the OS environment may induce.
This fixes bug #678.
Evaluate all 64 bit of the duration field in the capture status
record. Although unlikely in practical use, due to compression
it is possible for the duration in ms to exceed 32 bit.
During initialization of the LWLA1034, read the 64-bit test word
twice and verify the result of the second read only. This better
matches what the original vendor software does.
Apparently, these four registers form an interface for indirect
access to another internal 64 bit wide memory. This is likely the
same memory as that accessed by the bulk transfer commands 7 and 8.
Added support for SR_CONF_REGULATION which returns value for CH1
Also VELLEMAN LABPS3005D (only device currently supported) sends single
'M' character in beginning of return value, which is specially discarded.
Trying to configure an invalid capture ratio would reset the
previously configured value. Instead, we should just reject the
new value and keep the original one.
With this driver it is possible to set voltage target and current
limit. Also enabling and disabling the output is possible.
Analog output sends read back values from output. If output is
disabled analog outputs 0.00.
In protocol.c there is a g_usleep() call. This gives almost
every time enough time for PSU to parse and process input.
Multichannel devices aren't supported.
Instead of using a non-standard packed attribute, read the contents of the
probe EEPROM into a buffer and then process it using the R* macros.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Standard integer types may differ in size on different targets. Use fixed-size
types instead.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Lars-Peter Clausen
Bert Vermeulen
Uwe Hermann
Benjamin Larsson
Joel Holdsworth
Alexandru Gagniuc
Sergey Alirzaev
Markus Siegert
Stefan Brüns
Diego F. Asanza
Soeren Apel
Chriter
Aurelien Jacobs
Daniel Elstner
Tilman Sauerbeck
Hannu Vuolasaho
Matthieu Gaillet
jry
Martin Ling
Karl Palsson
Bartosz Golaszewski
Martin Lederhilger