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.
This patchset was originally done by eightdot <gituser@eightdot.eu> by
manually forward-porting parts of the changes done by Bert Vermeulen (see
previous commits), but then heavily modified by Uwe Hermann to be based on
top off the (git-)rebased patches from Bert Vermeulen instead.
Note: This initial DSLogic code is *not* yet in a working or usable
state. It should be considered as a basis for further work only, for now.
CC src/hardware/openbench-logic-sniffer/api.lo
../src/hardware/openbench-logic-sniffer/api.c: In function 'scan':
../src/hardware/openbench-logic-sniffer/api.c:103:10: warning: unused
variable 'probefd' [-Wunused-variable]
GPollFD probefd;
^
Use the more portable sp_input_waiting() instead of g_poll() with FDs.
Thanks to Martin Ling for the hints. This is tested on Linux and Win7
using an OLS; scanning for the device and starting an acquisition works.
Also, add some more debug output.
This fixes bug #562.
Split device options into general and channel group settings, and
adjust config_list() callback appropriately.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>