To capture more than 16MSamples the hardware run length encoding option
must be enabled, or captured data present errors.
RLE encoding/decoding is done in hardware. Data streamed to the USB interface
is not encoded.
This commit enables RLE encoding for captures longer than 16MSamples.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
This commit expands support for acquisition using an external clock,
now allowing the user to select the clock edge.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
For low sampling speeds (up to 25MHz) DSLogic offers a streaming mode where
samples are sent directly to the USB interface, like a fx2lafw device.
For high sampling speeds (up to 400MHz) only buffer mode is supported.
This commit allows the user to set which mode should be used. The configuration
is done by using SR_CONF_CONTINUOUS.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
SR_CONF_CONTINUOUS is used to check if a device supports continuous sampling
or not. As such, the type boolean is better suited.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
The DSLogic provides two FPGA images: one for 3.3V and the other for 5V logic.
The DSLogic Pro allows to set an arbitrary voltage threshold via USB command.
This commit adds support for the DSLogic to load the FPGA image according to
an user-selectable voltage threshold.
For the DSLogic Pro, one of two fixed voltage thresholds are set, depending on
the user-selected value.
Tested with DSLogic and DSLogic Pro.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
Tested-by: Andrew Bradford <andrew@bradfordembedded.com>
This commit implements DSLogic trigger functionality.
The following triggers are working:
- trigger on rising edge
- trigger on falling edge
- trigger on any edge
- trigger on logic one
- trigger on logic zero
Pre-trigger capture ratio is also working.
Signed-off-by: Diego Asanza <f.asanza@gmail.com>
Tested-by: Andrew Bradford <andrew@bradfordembedded.com>
The demo device has support for specifying the number of analog and logic
channels it should have. Currently this does not work correctly if one of
them is set to zero. Being able to set the number of channels to zero for
one of the channel types is quite useful for corner case testing though.
Make the following modifications to handle it correctly:
1) If the channel count is zero no channel group for that channel type
should be created since a channel group needs at least one channel.
2) Drop the check if logic_unitsize is less or equal to zero in
prepare_data() since this condition will always be true if the number of
logic channels is zero and it is not possible to create a demo device with
only analog channels.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
zip_append_analog() does not free most of the memory it allocates. Address
this by moving all sanity checks that do not rely on anything else at the
beginning of the function before any allocations are done. And then make
sure to properly free all allocated memory on all paths leaving the
function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
0 is a valid index for a channel. Using it as the value for the terminating
entry of analog_index_map causes zip_append_analog() to falsely assume that
no channel was found when a packet for a channel with index 0 was received.
This prevents the data for the channel to be added to the sigrok session
file.
Instead use -1, which is not a valid channel index, as
the terminating entry value.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Now that the signature of std_init() matches that of the driver init()
callback we can remove all wrapper functions around std_init() and use it
directly as the init() callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
std_init() checks if the pass in struct sr_dev_driver is non-NULL and
prints a error message and returns an error if it is NULL.
std_init() is exclusively called from driver init() callbacks for which the
core already checks if the struct sr_dev_driver is non-NULL before invoking
the callback. This means the check in std_init() will always evaluate to
false. So drop this check.
This also means that the prefix parameter that was used in the error
message is no longer needed and can be removed from the function signature.
Doing so will make the std_init() function signature identical to the
init() callback signature which will allow to directly use it as such.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The std_init() callback has the order of the first two paramters opposite
to the init() callback. This is primarily due to historical development.
Since the std_init() function is usually called from a driver's init()
callback aligning the order will allow direct register pass through rather
than having to swap them around. It also allow to eventually use the
std_init() function directly as the init() callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The zeroplus-logic-cube driver uses libusb_get_device_list() but neglects
to call the matching libusb_device_list_free() on the error path. This will
leak the memory allocated for the list as well as all the devices.
To address the issue use sr_usb_open() instead of open-coding its
functionality. sr_usb_open() correctly handles freeing the device list.
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The victor-dmm driver uses libusb_get_device_list() but neglects to call
the matching libusb_device_list_free() on the error path of libusb_open().
This will leak the memory allocated for the list as well as all the
devices.
To address the issue use sr_usb_open() instead of open-coding its
functionality. sr_usb_open() correctly handles freeing the device list.
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The testo driver uses libusb_get_device_list() but neglects to call the
matching libusb_device_list_free() on the error path. This will leak the
memory allocated for the list as well as all the devices.
To address the issue use sr_usb_open() instead of open-coding its
functionality. sr_usb_open() correctly handles freeing the device list.
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
lascar_scan() calls libusb_get_device_list() but never the matching
libusb_free_device_list(). This will leak the memory allocated for the
device list as well as all the devices. To fix this add the missing
libusb_free_device_list().
While we are at it also make sure to handle errors returned by
libusb_get_device_list().
The issue was discovered using the following coccinelle semantic patch:
// <smpl>
@@
identifier devlist;
expression ctx, ret;
statement S;
@@
(
libusb_get_device_list(ctx, &devlist);
|
ret = libusb_get_device_list(ctx, &devlist);
if (ret < 0) S
)
... when != libusb_free_device_list(devlist, ...)
*return ...;
// </smpl>
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
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.
On the high-end bench multimeters, resistance can be measured with a
kelvin connection as well as the more common two wire method. Provide
a flag which can indicate if four-wire mode is used.
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.
g_variant_print() allocates memory during call. Save the pointer
so that it can be free'd afterwards.
==10048== 16 bytes in 1 blocks are definitely lost in loss record 17 of 37
==10048== at 0x4C2DEAE: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10048== by 0x536C85D: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x53877C6: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x5388B60: g_string_append_vprintf (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x5388D83: g_string_append_printf (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x539D034: g_variant_print_string (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x539C92C: g_variant_print (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x4E5F713: log_key (hwdriver.c:597)
==10048== by 0x4E5FCD5: sr_config_set (hwdriver.c:752)
==10048== by 0x408C1A: run_session (session.c:661)
==10048== by 0x404FC5: main (main.c:267)
==10048==
==10048== 16 bytes in 1 blocks are definitely lost in loss record 18 of 37
==10048== at 0x4C2DEAE: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==10048== by 0x536C85D: g_realloc (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x53877C6: ??? (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x5388B60: g_string_append_vprintf (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x5388D83: g_string_append_printf (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x539D034: g_variant_print_string (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x539C92C: g_variant_print (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4400.1)
==10048== by 0x4E5F713: log_key (hwdriver.c:597)
==10048== by 0x4E5FBDD: sr_config_get (hwdriver.c:709)
==10048== by 0x4080D7: datafeed_in (session.c:196)
==10048== by 0x4E5D47E: sr_session_send (session.c:1192)
==10048== by 0x4E62682: std_session_send_df_header (std.c:101)
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.
While some transports add a terminating (carriagereturn+)linefeed
unconditionally, the USBTMC transport does not. At least the R&S HMO1002
requires the linefeed and locks up otherwise. Fixes bug #784.
This changes the TCP and VXI transport from CR+LF to LF only.
Also fixes a possible memory leak for VXI, where the temporary command
buffer was not freed in case of a write error.
According to USBTMC usb488 subclass spec, wValue hast to be 0 for both
LOCAL_LOCKOUT and GO_TO_LOCAL. At least required for R&S HMO1002, the
bad request results in a STALL. Fixes bug #783.
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>
According to the infos I have, VCD files should be plain ASCII, but we
got report of a version adding a UTF8 BOM at the beginning of the file,
so we need to skip it.
This fixes bug #755.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
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.
High precision multimeters have a special setting, called "number of
powerline cycles" (NPLC) which determines the integration time of the
ADC in terms of the power line period. Some devices need their NPLC
adjusted from the default value before they can measure at their full
rated precision.
Devices connected on a real GPIB bus are placed in remote mode when
opening them. libgpib does not automatically place devices back in
local mode when closing the handle. It is thus possible to lock out a
GPIB device by probing it with libsigrok.
This happens on the HP 3457A meter, which does not have a "LOCAL"
command, and must be put back in local mode via GPIB handshake.
ibloc() takes care of this, and it does it on a per-device basis,
such that other devices on the GPIB bus are not affected.
libgpib has an error_string which formats a numeric error code into a
human-readable description. Use that instead of printing the numeric
code, as it makes debugging easier.
- Don't set capturefile if no logic channels are saved
- Don't set total probes if no logic channels are saved
- Save analog channels without index gaps (e.g. probe1/probe4)
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.
We want the size of the struct, not of a pointer to the struct. And to
be absolutely future proof, dereference the pointer we are assigning the
memory to (not the one we are copying the data from). Found by Coverity,
CID 50858.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
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.