Only scan for hpib-pps devices when a user provided conn= specification
was given. This avoids breaking SCPI devices by emitting non-standard
requests before reliable device identification.
Re-use HMP4000 options and channel groups, only keep separate channel
specs for HMP2000 devices. HMP2030 has three identical 32V/5A channels.
HMP2020 has one 10A channel and one 5A channel.
Specs published by R&S suggest that 10A channels support 0.2mA resolution,
while only 5A channels resolve to 0.1mA (up to 1A full scale, 1mA above 1A).
Stop using the unusal "mixed" mode (local interface available during
remote operation) for HMP4000, applications may not be prepared for this
use case. Use traditional "remote" and "local" modes instead. This change
also ends remote mode after the application is done using the device.
List both vendor names "HAMEG" and "ROHDE&SCHWARZ" in the scpi-pps
driver, either responses were seen for HMP4000 devices. Unfortunately
vendor names don't support regex matches, so they require individual
profile items. The items also "violate" the alpha sort order in the list
of profiles, but keeping the series' models together is more important.
Add a declaration for the HMP4030 device which re-uses the HMP4040 data
but open codes the smaller channel count. Ideally the .probe_channels()
routine would receive the scpi_pps item as a parameter, and could yield
model specific result data from common information for the series. The
implementation in this commit is the least intrusive approach until
something better becomes available.
This shall cover the whole HMP4000 series:
https://www.rohde-schwarz.com/product/hmp4000
This commit introduces initial support for the HMP4040 power supply by
Rohde & Schwarz. It allows to configure the device and "statically" read
back current state. Automatic status updates with per-channel details
are not available yet (common support is missing).
[ gsi: drop status update remainder, address minor style nits ]
The comment says "A requested value is certainly on the way", but the code no
longer works this way. The receive handler requests a value and blocks until
it is received. There is no value pending between receive handler calls, so
this code now only leads to a timeout.
Acquisition won't work correctly in a multi-threaded environment, when
config_set() and config_get() are called with a channel group.
The channel switching itself has moved to scpi/scpi.c, to be able to
handle switching in a thread safe way.
Use of the thread safe SCPI functions, so no write+read operation is
interruped.
Also return float values instead of double value in acquisition mode.
This is related to bug #779.
This makes the code more consistent with the rest of the code-base
and also allows std_gvar_min_max_step_array() to work here.
Without this change:
src/hardware/scpi-pps/api.c: In function ‘config_list’:
src/hardware/scpi-pps/api.c:570:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->voltage);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/scpi-pps/api.c:573:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->frequency);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/scpi-pps/api.c:576:40: warning: passing argument 1 of ‘std_gvar_min_max_step_array’ from incompatible pointer type [-Wincompatible-pointer-types]
*data = std_gvar_min_max_step_array(ch_spec->current);
^~~~~~~
In file included from src/scpi.h:30:0,
from src/hardware/scpi-pps/api.c:23:
src/libsigrok-internal.h:964:19: note: expected ‘const double *’ but argument is of type ‘const float *’
SR_PRIV GVariant *std_gvar_min_max_step_array(const double a[3]);
^~~~~~~~~~~~~~~~~~~~~~~~~~~
This ensures consistent handling of the SR_CONF_SCAN_OPTIONS and
SR_CONF_DEVICE_OPTIONS (with sdi NULL or non-NULL) config keys
and also reduces copy-pasted boilerplate in the drivers a bit.
This function does not handle channel-group specific items, that's
very driver-specific and thus left to the individual drivers.
Also move some generic checks and error messages from the drivers into
the sr_config_list() wrapper.
Until now, clear_helper() callbacks for std_dev_clear_with_callback()
were expected to g_free(devc), but not all of them did that.
Have std_dev_clear_with_callback() unconditionally g_free(sdi->priv)
(i.e., devc), regardless of whether a clear_helper() callback was
provided or not. It was doing g_free(sdi->priv) when no callback
was provided already anyway.
This makes the individual drivers' clear_helper() implementations
shorter and prevents errors such as missing g_free(devc) calls.
This works, because all drivers either call std_dev_clear_with_callback()
directly, or indirectly via std_dev_clear().
This also allows us to remove some no-longer needed dev_clear()
and clear_helper() implementations that only did g_free(devc)
in favor of std_dev_clear().
Gerhard Sittig
Petteri Aimonen
Florian Schmidt
Mike Walters
Uwe Hermann
Frank Stettner
Mike Williams
Martin Ling