Make vxi.h the first #include in all affected files and #undef the
_POSIX_C_SOURCE macro in vxi.h.
This avoids various build issues on e.g. FreeBSD or Mac OS X where
setting _POSIX_C_SOURCE leads to the unavailability of certain types
such as u_long (as used in the VXI/RPC code).
This type consists of an array, with each item a two-member tuple,
representing an MQ/MQflags pair: the first item is the MQ (type
G_VARIANT_TYPE_UINT32), and the second is the MQ flags value
(G_VARIANT_TYPE_UINT64).
A GVariant of type SR_T_MQLIST can thus always represent more than
one MQ/MQflag pair.
The tables defined with this struct can now be used for information
on items other than config keys.
Functions to access these tables have been renamed sr_key_info_[name_]get.
These take an extra argument, keytype, which should be set to SR_KEY_CONFIG
to get the config key tables. Other key types will be added.
Move the include flags for files in the source tree from
configure.ac to Makefile.am where they belong. Also use
AM_CPPFLAGS instead of CFLAGS/CXXFLAGS to make sure the
files in the build/source tree are always picked up first.
Also, remove the include/libsigrok sub-directory from the
search path, thereby making the <libsigrok/> prefix mandatory
when building libsigrok itself. This matches the convention
already imposed on users of the library.
- Don't #include <errno.h> in files that don't actually need it.
- Don't use strerror() on error codes from functions that don't set
errno. Replace strerror() with sr_strerror() for libsigrok functions.
Fixes a bug where new acquisition failes due to leftover pipes from
previous acquisitions:
sr: demo: dev_acquisition_start: pipe() failed
Indeed, PulseView had 2024 pipes opened. With this fix, it stabilizes at
33 with sampling thread active.
Signed-off-by: Hubert CHAUMETTE <hchaumette@baylibre.com>
Move the libusb_detach_kernel_driver() call after the code that
sets the usb->devhdl pointer, otherwise it'll be NULL and result
in a segfault.
#0 libusb_kernel_driver_active (dev=0x0, interface_number=0) at libusb/core.c:1711
#1 dev_open (sdi=0x12d99f0) at src/hardware/fx2lafw/api.c:374
[...]
Tested on a device with the default Cypress VID/PID and one with
the Saleae Logic VID/PID, both works fine.
The timerfd descriptor is closed automatically by
g_io_channel_shutdown(). No need to close it manually.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
At high sampling rates and maximum channels we are not able to acquire
samples fast enough, even though frontends still think that samples
arrive on time. This causes visible shifts in frontend plots.
To compensate for the delay introduce the following workaround: check
if we are late (if any clock events have been missed) and resend the
last frame n times (n == number of missed clock events).
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Currently baylibre-acme uses a fake pipe as the input channel required by
libsigrok API and calls sleep() in the data acquisition callback to create
intervals between measurements.
Switch to a more elegant approach: use Linux' timerfd and set a periodic
timer equal to the sampling rate. Then read the data every time the timer
expires.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Opening a file has a cost (security, allocation, syscalls). The
read_sample() function always does an open/read/close sequence.
In order to optimize that, let's open the file at the moment the
acquisition starts, close it when the acquisition stops and make
read_sample() only lseek() to the beginning of the file and read
the value.
Signed-off-by: Daniel Lezcano <daniel.lezcano@free.fr>
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This was originally done as an optimization in combination with a list
reversal which has since been removed from the code. Thus, un-reverse
the channels so that the UI lists them in the correct order again.
The Chroma 62000P series comes in various models with different
current and voltage capabilities. These are encoded in the *IDN
string, so just get them from there, rather than needing a profile
for every model.
All those options are currently applied only to power-supplies
but they could apply as well to electronic loads, except for the
fact that electronic loads channels are called inputs and not
outputs.
Also when you think about an SMU (or any kind of 4-quadrants
power-supply), their channels can both source and sink current,
so they can be considered as input as much as output.
Those SR_CONF_* are thus renamed so that they can be used in all
those situations.
For devices such as the HP 6632B the following invocation was failing due to
scpi_cmd(sdi, SCPI_CMD_SELECT_CHANNEL, ...) returning SR_OK_CONTINUE.
./sigrok-cli -d scpi-pps:conn=/dev/ttyUSB0:serialcomm=9600/8n1 --continuous
sr: session: sr_session_start: could not start an acquisition (not enough data to decide error status yet)
Failed to start session.
This patch only adds the needed infrastructure to control output
frequency in the same manner as output voltage or current limit. This
does require a new field in the channel_spec struct, for the sake of
symmetry.
This makes 'output_frequency' symmetrical with 'output_current' and
'output_voltage'. On a more fundamental level, there's no reason why
frequency should be treated as a discrete quantity, other than
"es51919 used it this way".
Only the capabilities which map directly to SCPI commands supported by
sigrok are implemented at this time. This is sufficient to control
the most often used functionality of this AC source
Some devices with more than one microcontroller report the firmware
version for each of them, giving us more than four tokens. When that
happens, sigrok aborts, even though it received a valid response.
This happens, for example with the Chroma 61604:
'Chroma ATE,61604,001060,1.25,1.34,1.20'
isascii() is a superset of isalpha() and isblank() so the current
code doesn't really make sense.
Moreover, isascii(x) is just a funky and non standard way to
write x < 128.
../src/backend.c: In function 'sr_init':
../src/backend.c:435:1: warning: label 'done' defined but not used [-Wunused-label]
done:
^
../src/device.c: In function 'sr_dev_inst_connid_get':
../src/device.c:525:7: warning: unused variable 'connection_id' [-Wunused-variable]
char connection_id[64];
^
../src/device.c:524:20: warning: unused variable 'b' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:17: warning: unused variable 'a' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:14: warning: unused variable 'i' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:9: warning: unused variable 'cnt' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:524:6: warning: unused variable 'r' [-Wunused-variable]
int r, cnt, i, a, b;
^
../src/device.c:523:22: warning: unused variable 'drvc' [-Wunused-variable]
struct drv_context *drvc;
^
Check the return value of sr_gpio_setval_export() in bl_acme_set_power_off()
and return an appropriate error if the call fails.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This reverts commit 4cd97e5ad7.
We should actually check the return value of sr_gpio_setval_export().
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Add LIBUSB_CALL where needed to avoid warnings such as the following:
In file included from src/hardware/hantek-dso/api.c:34:0:
src/hardware/hantek-dso/dso.h:212:13:
note: expected 'libusb_transfer_cb_fn' but argument is of type 'void (*)(struct libusb_transfer *)'
SR_PRIV int dso_get_channeldata(const struct sr_dev_inst *sdi,
^
src/input/wav.c:41:0: warning: "WAVE_FORMAT_PCM" redefined
#define WAVE_FORMAT_PCM 0x0001
^
In file included from [...]/include/windows.h:86:0,
from [...]/include/libusb-1.0/libusb.h:70,
from ./src/libsigrok-internal.h:31,
from src/input/wav.c:28:
[...]/include/mmsystem.h:482:0: note: this is the location of the previous definition
#define WAVE_FORMAT_PCM 1
^
CC src/hardware/baylibre-acme/protocol.lo
../src/hardware/baylibre-acme/protocol.c: In function 'bl_acme_set_power_off':
../src/hardware/baylibre-acme/protocol.c:417:6: warning: variable 'val' set but not used [-Wunused-but-set-variable]
int val;
^
Both ina2xx and tmp401 linux drivers used by baylibre-acme expose
the standard hwmon update_interval attribute, which affects the internal
update interval of the chip.
When setting samplerate for data acquisition try to modify this
attribute accordingly.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
PROBE_FACTOR and POWER_OFF options are advertised for all ACME probes
(channel groups) regardless of whether they actually have given capability.
Check these options in config_list() at runtime and only advertise them
for probes which support them.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
This requires sr_hw_cleanup_all() and sanity_check_all_drivers()
to also take a context.
The (runtime) generation of the driver list now happens in sr_init()
and sr_driver_list() always returns that pre-generated list. This fixes
a segfault when (correctly) invoking multiple sr_init() and sr_exit()
calls with different contexts (caught by the unit tests).
This fixes bug #565.
We should have been doing this all along, but we get away with it
on Linux where libusb can do everything with fds, and we get away
with it for many drivers that have a short timeout on their events.
On Windows though, handling this correctly is essential.
Fixes bug #343.
This temporarily reverts commit 421bc3eba0.
We cannot yet use the sr_config_*() wrappers, otherwise loading *.sr
files is broken. A fix is being worked on.
This is a partial fix for bug #343, which lead to a large amount of
handles being created, and eventually to a frontend "hang".
It's not yet a "full" fix as some issues are still observable,
but it successfully improves the situation on Windows to the extent
that frontend hangs due to large amounts of handles no longer seem
to happen.
Thanks to Boris Gjenero <boris.gjenero@gmail.com> for the debugging
efforts, testing, and updating of this patch!
Additionally, this seems to also fix a "SysClk LWLA hanging" bug
and apparently not receiving any samples during an acquisition
(tested on an LWLA1034).
This closes bug #328.
Tested on an MSO1104Z with firmware 00.04.02.SP4.
The analog channels are captured correctly. For the MSO series, with digital
channels, there are two outstanding issues:
1. Logic data is retrieved per-channel, one byte per sample, with the value
in the LSB of each byte. The current datafeed logic format doesn't allow
this format to be passed on directly. I suggest we resolve that rather than
making the driver buffer and interleave the data.
As stands, the code will retrieve data for all channels and pass it onto
the datafeed with unitsize=1. Channel D0 can used correctly if selected
alone. For other channels, data is passed to the frontend but the API does
not provide a way to associate it with the correct channel.
2. Channels CH3 and CH4 are multiplexed with D0-7 and D8-15 respectively, so
enabling these is mutually exclusive. We don't currently have a way to
express this constraint to the frontend.
Daniel Glöckner
Uwe Hermann
Bert Vermeulen
Daniel Elstner
Soeren Apel
Aurelien Jacobs
Hubert CHAUMETTE
Daniel King
Bartosz Golaszewski
Daniel Lezcano
Daniel Gröber
Carl-Fredrik Sundström
Alexandru Gagniuc
Marcus Comstedt
Martin Ling