The default so far was 0, which meant there would be no significant
digits at all, yielding results that looked strange/wrong to the user.
Long-term all remaining drivers should be fixed to use the actual,
correct digits and spec_digits values according to the device's
capabilities and/or datasheet/manual. Until that is done, a default
of digits=2 is used as a temporary workaround.
This fixes the remaining parts of bug #815.
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.
When a meter display 105.2 kΩ, libsigrok will return 105200 Ω
but it is really valuable to know that the last 2 digits are not
significant, so encoding.digits should be set to -2.
This would allow a sigrok client to display 105200 as 105.2 k
instead of 105.200 k.
055804e89e changed the outgoing
SCPI message termination by always adding a newline. This results
in the following log output:
sr: [00:00.003102] scpi: Opening VXI device vxi/192.168.178.43.
sr: [00:00.005648] scpi_vxi: Successfully sent SCPI command: '*IDN?
'.
sr: [00:00.005931] scpi: Got response: 'YOKOGAWA,710130,91HC30402,F3.73', length 31.
This patch restores the previous unterminated SCPI message logging:
sr: [00:00.005462] scpi: Opening VXI device vxi/192.168.178.43.
sr: [00:00.007515] scpi_vxi: Successfully sent SCPI command: '*IDN?'.
sr: [00:00.007860] scpi: Got response: 'YOKOGAWA,710130,91HC30402,F3.73', length 31.
As it's located in the general logging mechanism, we deal with any
additional (and unwanted) newlines this way.
This single object also contains the sr_drivers_init function, that will
always be referenced. That ensures that the drivers object files won't
be optimized out during static linking due to the fact that they are
not referenced directly.
This addresses (parts of) bug #802.
These functions were only used in the SR_DF_ANALOG_OLD case,
whereas the SR_DF_ANALOG case already used functions and lists
from src/analog.c.
This closes bug #636.
When config_list() gets NULL as sdi, it must return driver opts.
Some drivers, including zeroplus, don't check sdi and return both
driver opts and device opts.
Now that std_serial_dev_acquisition_stop() has the same signature as
the sr_dev_driver dev_acquisition_stop() callback it is possible to remove
the wrapper functions and use std_serial_dev_acquisition_stop() directly
has the callback function.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All callers of std_serial_dev_acquisition_stop() currently pass the same
callback for the dev_close_fn parameter as the dev_close callback of their
sr_dev_driver struct. Remove the dev_close_fn parameter and invoke the
drivers dev_close() callback directly. This simplifies the API and ensures
consistent behaviour between different drivers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All callers of std_serial_dev_acquisition_stop() currently pass sdi->conn
for the serial parameter. And the other std_serial helper functions already
require that the conn field of the sr_driver_inst passed to the functions
points to the sr_serial_dev_inst associated with the device.
Modify std_serial_dev_acquisition_stop() to follow the same pattern and
remove the serial parameter. This simplifies the API and ensures consistent
behaviour between different drivers.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some of the standard helper functions take a log prefix parameter that is
used when printing messages. This log prefix is almost always identical to
the name field in the driver's sr_dev_driver struct. The only exception are
drivers which register multiple sr_dev_driver structs.
Instead of passing the log prefix as a parameter simply use the driver's
name. This simplifies the API, gives consistent behaviour between different
drivers and also makes it easier to identify where the message originates
when a driver registers sr_dev_driver structs.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
All drivers with the exception of pce-322a pass their dev_close callback to
std_serial_dev_acquisition_stop(). The pce-322a passes std_serial_dev_close()
which is also called from its dev_close() callback and replicates the other
functionality of its dev_close() callback directly in
std_serial_dev_acquisition_stop().
Refactor this to pass the dev_close callback function directly to
std_serial_dev_acquisition_stop(). This makes sure that the driver is
consistent with other drivers and also removes duplicated code.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new software limit helper functions rather than open-coding their
functionality.
This also fixes the issue that driver the does not reset all the limit
statistics in acquisition_start().
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new software limit helper functions rather than open-coding their
functionality.
This also fixes the issue that the driver does not reset the limit
statistics in acquisition_start(). It also makes the time limit work, which
previously was only a stub implementation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Use the new software limit helper functions rather than open-coding their
functionality.
This also fixes the issue that the driver does not reset the limit
statistics in acquisition_start(). It also makes the time limit work, which
previously was only a stub implementation.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The version field in the norma-dmm driver state struct is initialized, but
never read and the same information is also already available in the
sr_dev_inst struct version field. So remove it to simplify the code.
This allows to get rid of the custom dev_close() callback and just use the
standard std_serial_dev_close() instead.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
../src/hardware/appa-55ii/api.c: In function ‘scan’:
../src/hardware/appa-55ii/api.c:47:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/arachnid-labs-re-load-pro/api.c: In function ‘scan’:
../src/hardware/arachnid-labs-re-load-pro/api.c:62:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/atten-pps3xxx/api.c: In function ‘scan’:
../src/hardware/atten-pps3xxx/api.c:81:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/brymen-dmm/api.c: In function ‘scan’:
../src/hardware/brymen-dmm/api.c:89:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/cem-dt-885x/api.c: In function ‘scan’:
../src/hardware/cem-dt-885x/api.c:74:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/conrad-digi-35-cpu/api.c: In function ‘scan’:
../src/hardware/conrad-digi-35-cpu/api.c:45:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/demo/demo.c: In function ‘scan’:
../src/hardware/demo/demo.c:255:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/fluke-dmm/api.c: In function ‘fluke_scan’:
../src/hardware/fluke-dmm/api.c:64:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/gmc-mh-1x-2x/api.c: In function ‘scan_1x_2x_rs232’:
../src/hardware/gmc-mh-1x-2x/api.c:147:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/gmc-mh-1x-2x/api.c: In function ‘scan_2x_bd232’:
../src/hardware/gmc-mh-1x-2x/api.c:234:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/ikalogic-scanaplus/api.c: In function ‘scan’:
../src/hardware/ikalogic-scanaplus/api.c:69:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
../src/hardware/tondaj-sl-814/api.c: In function ‘scan’:
../src/hardware/tondaj-sl-814/api.c:44:22: warning: variable ‘drvc’ set but not used [-Wunused-but-set-variable]
struct drv_context *drvc;
^
Some driver scan() functions only ever return a single device. For those it
is possible to slightly simplify the handling of the device list by
creating it on demand when the function returns.
Some drivers also have the following expression:
devices = g_slist_append(devices, sdi);
...
if (!devices)
...
This check will never evaluate to false so it is dropped as well.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
A common task during device scan is to add the newly discovered devices to
the instance list of the driver. Currently this is done by each driver on
its own. This patch introduces a new helper function std_scan_complete()
which takes care of this. The function should be called at the end of a
driver's scan() callback before returning the device list.
Doing this with a helper function provides guaranteed consistent behaviour
among drivers and hopefully paves the way to moving more standard
functionality directly into the sigrok core.
Another common task that every driver has to do for each device instance is
to initialize the device's driver field. So this is done in the new helper
function as well.
All drivers that can make use of the new helper are updated.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Some drivers set the device instance list to NULL in their scan() callback.
This means the driver loses all references to any devices contained in that
list and their resources will be leaked. Drivers can't free the devices at
this point either since an application might still use a device on the
list. So the existing devices on the instance list need to remain
unmodified during the scan() callback, even if that means that there will
be duplicates on the instance list. Only an explicit invocation of
sr_dev_clear() by the application is allowed to free the devices on the
instance list and reset the list.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The link-mso19 driver currently iterates the device instance list of the
driver to get the device instance for which the callback is called.
But the device instance is actually passed to the callback as the cb_data
parameter, so just use that instead and remove the lookup loop.
Besides that the current lookup loop does not even compile either.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The link-mso19 open-codes the std_dev_clear() function and uses it as its
custom dev_clear() callback. The std_dev_clear() function is automatically
called if no custom dev_clear() callback is specified, so just drop custom
implementation and use the default.
This also fixes a memory leak where the link-mso19 driver did not properly
free its driver state struct in the dev_clear() callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
sdi is allocated using g_malloc0() which can never fail, in addition to
that sdi is already dereferenced before the check, which makes the check
useless. So remove it.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
HP instruments predating the 488.2 and SCPI standards do not
necessarily have a SCPI-compliant command set. The HP6630A series of
supplies is one such example.
While scpi-pps is flexible enough to accomodate almost any command
syntax given the right profile, it still assumes that "*IDN?" is the
correct question to ask the instrument. Since older HP gear instead
responds to "ID?", this assumption is no longer true.
Thus sr_scpi_get_hw_id() is not appropriate for these instruments, and
the shadow driver added here only replaces that function call, while
reusing the rest of the existing logic. The extra noise is necessary
in order to propagate this through the .scan member of the driver.
Use the standard connection_id field from the struct sr_dev_inst for
storing the device address rather than using the custom address field in
the driver state struct. This makes things more consistent with the
framework.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
The sigrok core needs a list of all available drivers. Currently this list
is manually maintained by updating a global list whenever a driver is added
or removed.
Introduce a new special section that contains the list of all drivers. The
SR_REGISTER_DEV_DRIVER() and SR_REGISTER_DEV_DRIVER_LIST() macro is used to
add drivers to this new list. This is done by placing the pointers to the
driver into a special section. Since nothing else is in this section it is
known that it is simply a list of driver pointers and the core can iterate
over it as if it was an array.
The advantage of this approach is that the code necessary to add a driver
to the list is completely contained to the driver source and it is no
longer necessary to maintain a global list. If a driver is built it will
automatically appear in the list, if it is not built in won't. This means
that the list is always correct, whereas the previous approach used ifdefs
in the global driver list file which could get out-of-sync with the actual
condition when the driver was built.
Any sr_dev_driver structs that are no longer used outside the driver module
are marked as static.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Most drivers have a forward declaration to their sr_dev_driver struct at
the beginning of the driver file. This is due to historic reasons and often
no longer required. So remove all the unnecessary forward declarations.
Some drivers still require the forward declaration, but only reference the
driver struct from within the driver scan() callback. Since the driver
struct is passed to the scan callback replace the references to the global
variable with the local parameter. In some cases this requires adding the
parameter to some of the helper functions that are called from the scan()
callback.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Binary block data is specified in IEEE 488.2. First character is '#',
followed by a single ascii digit denoting the the number of digits needed
for the length specification. Length is given in bytes.
This allows drivers to replace retrieval of comma separated ASCII values
with binary formats. See bug #791.
The method accepts strings with numbers in scientific or normal notation,
e.g. -1.25 or 3.37e-6. The numeric range is limited by the sr_rational
range, i.e +-9.2e18, resolution is ~19 digits.
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.
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>
Accept (and set to default) 0 for numchannels which means 'unlimited'.
I think it is convenient to read all channels of a vcd file by default.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Benefits:
* only channels really used in vcd will be added
* we can give them the proper name found in the vcd file
* less code :)
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Current code moves the identifier string one byte to the front to
overwrite the bit value, so 'tokens[i]' is a string to compare against
the desired value. This copying is unnecessary, just pass a properly
setup pointer.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
No need to bail out on vectors. As long as there are tokens left, we can
try to parse the rest. Also, print a message so the user knows what's
going on. Here is a testcase vcd:
$timescale 1 ns $end
$var wire 1 n0 addr_0 $end
$var wire 1 n1 addr_1 $end
$enddefinitions $end
#0
0n0
b1 n1
#1
1n0
b0 n1
#2
0n0
b1 n1
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
If we hit the missing identifier case, then we reached the end of the
token list. So, we should break out of the loop, and not continue.
Otherwise we will go past the end of the array as this minimal testcase
shows:
$timescale 1 ns $end
$var wire 1 n0 addr_0 $end
$enddefinitions $end
1
gives:
$ ./sigrok-cli -I vcd -i no_mod.vcd -O vcd -o /tmp/o.vcd
Segmentation fault
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
A $var block can have an optional index item which looks like '[<sth>]'.
Parse it, too, and append it to the channel name.
This fixes bug #322. A first version was posted by Simon Richter. This
version is rebased and simplified.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
As we're downsampling, several record time stamps can match the specified
trigger time. For this reason, it's possible that several trigger packets
are sent when a file is loaded. This prevents the issue and sends a
trigger packet only on the first matching record.
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(
^
There is no status bit for RMS. We know about RMS if certain modes are
active. So, drop this superfluous variable.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
The primary display is the power factor, the secondary is the frequency.
This got mixed up, so change the order. We also need to fix the
conversion factor.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
is_power_apparent_power is index 0 of function 0x39, so it is better to
process it first and the later indices after that (we need to add
another one with a different patch later).
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
Testing showed that AC current needs to be handled different from DC.
Note that ACA is still untested because of limited testing equipment.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
It was confusing to see the display value (5 digits) printed in debug
output as a float. Print it the same way as shown on the real device,
without comma, of course.
This also allows to simplify the code a little.
Signed-off-by: Wolfram Sang <wsa@the-dreams.de>
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.