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>
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.
This fixes parts of bug #423.
The list of fixed warnings:
src/output/srzip.c:285:3: warning: Value stored to 'ret' is never read
ret = zip_append(o, logic->data, logic->unitsize, logic->length);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/scpi/scpi.c:610:2: warning: Value stored to 'ret' is never read
ret = SR_OK;
^ ~~~~~
src/scpi/scpi.c:667:2: warning: Value stored to 'ret' is never read
ret = SR_OK;
^ ~~~~~
src/dmm/vc870.c:410:2: warning: Value stored to 'info_local' is never read
info_local = (struct vc870_info *)info;
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/conrad-digi-35-cpu/api.c:130:2: warning: Value stored to 'ret' is never read
ret = SR_OK;
^ ~~~~~
src/hardware/fx2lafw/api.c:658:2: warning: Value stored to 'timeout' is never read
timeout = fx2lafw_get_timeout(devc);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~
src/hardware/gmc-mh-1x-2x/protocol.c:941:3: warning: Value stored to 'retc' is never read
retc = SR_ERR_ARG;
^ ~~~~~~~~~~
src/hardware/gmc-mh-1x-2x/api.c:168:2: warning: Value stored to 'model' is never read
model = METRAHIT_NONE;
^ ~~~~~~~~~~~~~
src/hardware/ikalogic-scanalogic2/api.c:325:2: warning: Value stored to 'ret' is never read
ret = SR_OK;
^ ~~~~~
src/hardware/openbench-logic-sniffer/api.c:185:3: warning: Value stored to 'devc' is never read
devc = sdi->priv;
^ ~~~~~~~~~
src/hardware/rigol-ds/api.c:813:3: warning: Value stored to 'devc' is never read
devc = sdi->priv;
^ ~~~~~~~~~
src/hardware/scpi-pps/api.c:405:2: warning: Value stored to 'ret' is never read
ret = SR_OK;
^ ~~~~~
src/hardware/yokogawa-dlm/api.c:239:2: warning: Value stored to 'ret' is never read
ret = SR_ERR_NA;
^ ~~~~~~~~~
Since Autoconf places some important feature flags only into the
configuration header, it is necessary to include it globally to
guarantee a consistent build.
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.
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.
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
If the number and specs of the device's channels are not static, i.e.
need to be probed, this facility is needed.
Initially this will be used for the Philips PM2800 series, where only
the model returned by *IDN? is needed. However this could also be used
to do actual discovery with vendor-specific SCPI commands.
At least the Rigol DP800 series trigger the beeper when changing
channels remotely. Which gets rather annoying when doing acquisition
on three channels as fast as you can.
Every driver now publishes its device option config keys, i.e. the
list fetched with sr_config_list(SR_CONF_DEVICE_OPTIONS), with a
set of flags indicating which methods are implemented by the driver
for that key.
The config keys are OR'ed with any combination of SR_CONF_GET,
SR_CONF_SET and SR_CONF_LIST. These are defined as the high bits
of the uint32_t config key. Clients can OR config keys with
SR_CONF_MASK to strip out these bits. This mask will be kept up to
date if other bits are added to the capabilities list; clients MUST
therefore use SR_CONF_MASK for this.
Some keys don't have capability bits added, such as the informative
device type keys (SR_CONF_MULTIMETER, SR_CONF_OSCILLOSCOPE, ...) and
SR_CONF_CONTINUOUS.
Scan options do not have capabilities bits.