scpi-pps: Chroma 62000P: Get capabilities from device name
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.
Aurelien Jacobs [Sun, 15 Mar 2015 17:43:06 +0000 (18:43 +0100)]
Rename SR_CONF_OUTPUT_* to SR_CONF_*.
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.
Aurelien Jacobs [Sat, 9 May 2015 21:06:10 +0000 (23:06 +0200)]
scpi-pps: don't fail acquisition start for devices with no CMD_SELECT_CHANNEL
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.
scpi-pps: Add infrastructure for controlling output frequency
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.
global: Treat SR_CONF_OUTPUT_FREQUENCY as float instead of uint64_t
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
scpi: Accept *IDN responses with more than four tokens
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'
Compile with -std=c11 along with _POSIX_C_SOURCE=200112L.
With gcc 5.1 released and defaulting to std=gnu11, the code will be compiled
according to different standards depending on the compiler version so we
should better specify explicitly what standard we are targetting.
C11 is now quite mature, it is supported in the just release Debian stable
(gcc 4.9) and also in old-stable (gcc 4.7), so there should be no reason to
use anything more ancient.
We also should have no reason to need any non-standard GNU extension.
So using only C11 + POSIX sounds like the best option right now.
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.
Uwe Hermann [Sun, 12 Apr 2015 17:28:03 +0000 (19:28 +0200)]
windows: Fix various compiler warnings.
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,
^
Uwe Hermann [Sun, 12 Apr 2015 16:54:43 +0000 (18:54 +0200)]
input/wav: windows: Fix a compiler warning.
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
^
Uwe Hermann [Sun, 12 Apr 2015 15:26:48 +0000 (17:26 +0200)]
baylibre-acme: Fix a compiler warning.
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;
^
baylibre-acme: Set update_interval when modifing samplerate.
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.
Uwe Hermann [Sat, 4 Apr 2015 18:57:22 +0000 (20:57 +0200)]
sr_driver_list() now takes a context pointer.
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).
Martin Ling [Wed, 25 Mar 2015 05:16:06 +0000 (05:16 +0000)]
Call libusb_get_next_timeout() to get minimum timeout for g_poll().
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.
Martin Ling [Tue, 24 Mar 2015 19:06:17 +0000 (20:06 +0100)]
Initial fix attempt for a thread-related issue on Windows.
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 <redacted> 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).