In some situations, the reply to the *IDN? command contains an
additional trailing 0x01 byte for unknown reasons.
This issue seems to be reproducible by changing the voltage using the knobs
on the device, then turning on the output and turning it off again.
The next korad-kaxxxxp scan() operation would contain the trailing 0x01
byte, which would lead to the detection of the device in libsigrok no
longer working until the next power-cycle.
Work around this issue by treating both the ID string with and without
the trailing 0x01 byte as valid.
This is a desperate measure to improve the success rate of device
initialization even after it got into a bad state. Combine this
with a reduced USB timeout (1 second) so that if it fails, it fails
quickly. Also ignore USB errors from the initial dummy read of the
device test ID.
Detect whether the FX2 firmware of the LWLA device exhibits the
short transfer bug. If so, work around the problem by limiting
reads to at most 64 bytes at a time. This slows down the memory
read after acquisition quite noticably, but makes the device
usable even in adverse conditions.
Reduce the number of long registers read in bulk during status
polling from 10 to 5. The LWLA1034 driver used to do that already
in an earlier iteration, which was then changed to be more like
the original vendor software. The reason for bringing it back now
is that it reduces the response size to 40 bytes, which works
around the spurious 64 byte limit bug in the FX2 firmware of the
LWLA devices.
The sixth character from ISET? is read and discarded. If the device is
turned off and on again, this won't be there and causes 10 ms delay in
every ISET? Luckily, this value isn't queried that often. To get the
sixth byte, the *IDN? command has to be issued before ISET?.
Do not use size_t for values whose width is defined by the device,
not the host. Also don't use size_t for simple indices with known
small range, unless type compatibility considerations apply.
Refactor the sysclk-lwla driver to separate the generic logic from
the model-specific implementation. Based on this, implement support
for the SysClk LWLA1016 device.
The driver should now be able to cope with e.g. multiple ChronoVu LA8
and/or ChronoVu LA16 devices being connected to the same PC.
It now also provides the serial number and connection ID, which can be
used by frontends to differentiate multiple devices.
Also improve the scanopts / drvopts / devopts lists handling.
This fixes bug #504.
With the current driver API and the corresponding session event
handling, it is not possible to destroy and then re-create an
event source with the same key within the same main loop iteration.
The next generation driver API will fix this problem. But for now,
just change the driver to make do without that sort of thing. Also
increase the I/O timeout to 100 ms to be safer in the event of all
kind of delays the OS environment may induce.
This fixes bug #678.
Evaluate all 64 bit of the duration field in the capture status
record. Although unlikely in practical use, due to compression
it is possible for the duration in ms to exceed 32 bit.
During initialization of the LWLA1034, read the 64-bit test word
twice and verify the result of the second read only. This better
matches what the original vendor software does.
Apparently, these four registers form an interface for indirect
access to another internal 64 bit wide memory. This is likely the
same memory as that accessed by the bulk transfer commands 7 and 8.
Added support for SR_CONF_REGULATION which returns value for CH1
Also VELLEMAN LABPS3005D (only device currently supported) sends single
'M' character in beginning of return value, which is specially discarded.
Trying to configure an invalid capture ratio would reset the
previously configured value. Instead, we should just reject the
new value and keep the original one.
With this driver it is possible to set voltage target and current
limit. Also enabling and disabling the output is possible.
Analog output sends read back values from output. If output is
disabled analog outputs 0.00.
In protocol.c there is a g_usleep() call. This gives almost
every time enough time for PSU to parse and process input.
Multichannel devices aren't supported.
Instead of using a non-standard packed attribute, read the contents of the
probe EEPROM into a buffer and then process it using the R* macros.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Standard integer types may differ in size on different targets. Use fixed-size
types instead.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
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;
^ ~~~~~~~~~
Timer intervals shorter than about 100 ms are unnecessarily taxing
on system resources. Also, on systems like Windows the smallest
resolvable time unit without using high precision timers is about
15 ms. Regular timer intervals should be well above that value to
avoid being dominated by noise and round-off.
Firmware versions starting with 00.02.04 apparently cause the in and out
bulk endpoints to end up in a HALT state. This is likely related to the
larger transfer size quirk implemented in the Linux kernel for the Rigol
DS1000: this USBTMC implementation does not have that workaround.
Instead, if the firmware version is >= 00.02.04, both endpoints have the HALT
condition cleared on device close.
This fixes bug #354.
GPIO direction should be set once right after exporting. There's no need
to reset it again - in fact it's a bug which causes the probe to be reset
every time the value is read/set and gives incorrect results when reading
the GPIO values with direction == 'in'.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Revision B of ACME hardware introduces probes with on-board at24cs02
EEPROM. Extend the ACME driver to support reading the contents of
the EEPROM via linux' sysfs interface.
Also: make the driver be able to tell the difference between revisions,
add new GPIO layout and set the shunt resistance for revB at probe
registration.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Only perform a single check at initialization time to see if the probe is
equipped with a power-switch. This is done in preparation for revision B
support which has this kind of information encoded in EEPROM.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
After opening the USB device, set the device configuration to 1.
Actually, do it twice, just as the vendor driver seems to do. This
is supposed to trigger a lightweight reset of the device.
Originally, I omitted this reset sequence from the sigrok driver
because it simply did not work at all for me. However, it does seem
to work now, so that may have been a problem in libusb or the kernel
which is now fixed.
With some luck, this change may finally fix#327.
Use states SR_ST_ACTIVE and SR_ST_INACTIVE to indicate that the
device is open or closed, respectively. Do not use any of the
other state values. Improve the robustness of the open and close
methods in face of errors. Introduce a separate flag to indicate
that a running acquisition should be canceled.
Prepare the trigger masks at config_commit() time, so that the
trigger setup can be validated before starting an acquisition.
Accordingly, do actually report validation errors back to the
caller.
It turns out that g_stat() breaks apart when using 64 bit stat on
32-bit systems. Since the actual type of GStatBuf is decided when
glib/gstdio.h is included, it is thus possible for GLib itself to
be compiled with a different type than user code.
Ouch. Unfortunately going back to plain stat() also means that we
lose Unicode filename support on Windows.
Since Autoconf places some important feature flags only into the
configuration header, it is necessary to include it globally to
guarantee a consistent build.
A few of these were pretty serious, like missing arguments,
passing integers where a string was expected, and so on.
In some places, change the types used by the code rather than
just the format strings.
The Hung-Chang DSO-2100 is a parallel port PC oscilloscope sold back
in 1999 under brand names like Protek and Voltcraft.
This inital version of the driver has the following limitations:
- Hardcoded calibration values. All parameters are set to 50%.
- No support for auto triggering
- No support for TV sync trigger modes
- No support for the "scroll acquisition" mode
In scroll acquisition mode the device behaves more like a multimeter
and reports the current voltage of a probe on request. While in this
mode the sample rate is limited by the parallel port interface, it is
the only way to capture both channels at the same time (well, sort of).
Calibration would need auto triggering. The calibration values are very
temperature dependent and the device takes literally hours to reach its
final temperature. Every vdiv setting needs its own set of calibration
values. Without hardware modifications, the calibration settings wear
of in less than a second while waiting for a trigger because the
capacitors storing those values are not recharged in state 0x21.
In sr_session_iteration(), remove the inverted evaluation of the
block parameter if a USB source is present. This stops the deluge
of USB event callbacks due to the timeout always being zero.
Also, just for cleanliness, initialize the revents member of each
GPollFD instance to zero.
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.
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
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,
^
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>
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>
There's indeed no g_fclose() unfortunately. The g_*() wrappers for file
handling are mainly there to deal with portability issues in file names
(encoding, character sets, etc) on different platforms.
Use PRIu64 to avoid the following compiler warning:
CC src/hardware/baylibre-acme/gpio.lo
protocol.c: In function 'bl_acme_set_shunt':
protocol.c:341:2: warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'uint64_t' [-Wformat=]
g_fprintf(fd, "%llu\n", MOHM_TO_UOHM(shunt));
^
Implement support for SR_CONF_PROBE_FACTOR setting in BayLibre ACME
driver. Given the channel-group parameter this allows to set the
shunt resistance for each probe.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
Implement basic functionalities for baylibre-acme. Add support
for common config options, device detection and sample reading.
Signed-off-by: Bartosz Golaszewski <bgolaszewski@baylibre.com>
We try to find the smallest diff by comparing each diff with
the previously known smallest diff, so initially, this smallest diff
should be INFINITY so that we are sure to find a smaller one.
This fixes the following exception:
sr: rigol-ds: Negative vdiv index: -1.
Caught exception: not applicable
These are available on e.g. Rigol DS1102E (or "upgraded" DS1052E).
Without this, if one of the channels happens to have been set to
one of the missing vdiv settings frontends (e.g. PulseView) will
have some trouble using the scope:
sr: hwdriver: sr_config_get(): key 30012 (vdiv) sdi 0x11bcb70 cg CH1
sr: rigol-ds: Negative vdiv index: -1.
std::exception
(lwla_convert_trigger): Fix trigger mask computation bug introduced
by recent change: Widen constant to 64 bit before shifting so that
channel nunmbers beyond 32 are processed correctly.
Use g_malloc0() for small allocations and assume they always
succeed. Simplify error handling in a few places accordingly.
Don't always sanity-check parameters for non-public (SR_PRIV)
functions, we require the developers to invoke them correctly.
This allows further error handling simplifications.
It fills the fields with reasonable default values that should suit
most of the drivers. Drivers are obviously free to override the fields
they want after initializing.
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.
Add a driver for the DER EE DE-5000 LCR meter. This meter is based on
the Cyrustek ES51919/ES51920 chipset and communicates with the host
computer via an optional connectivity kit.
The kit uses an optoisolated unidirectional link to connect to the
meter and an USB cable on the host side. Internally the connection is
using the FTDI FT232R USB UART chip i.e. from the host computer point
of view the meter is connected into an RS-232 serial port.
This driver implements just a thin shim layer for registering the
driver and uses the es51919 module for all the actual work.
Set this new parameter to 0 (no timeout) at every call site. This is
consistent with previous behaviour, so cannot cause any regressions.
Waiting forever for a serial operation is clearly always wrong. Without
specific knowledge of each device and driver however, I can't choose
appropriate timeouts for each call. The maintainers of these drivers
will need to do so, and also add appropriate handling of timeouts.
When this commit is merged, a bug should be entered for each driver
that is touched by it.
Previously, sdi->index was used to tell several identical fx2lafw-compatible
devices apart. This was a bit of a hack, so this patch makes it use physical
device connections instead. They're guaranteed to remain the same even if
the USB device reconnects.
These calls are executed from an event handler and were previously nonblocking,
but they have no partial read/write handling. The code is already marked TODO
for improvement.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. It only reads one byte, and a zero result is handled
appropriately.
This call was previously explicitly nonblocking, but has no partial write
handling. It sends a short packet so should be OK to block, most likely the
output buffer will be empty anyway.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. It only reads one byte, and a zero result is handled
appropriately.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
These calls are executed from an event handler and were previously nonblocking,
but have no partial write handling. They send short packets so should be OK to
block, most likely the output buffer will be empty anyway.
Fix error handling for some: serial_write can return any negative error code.
This call was previously nonblocking, but there is no handling of partial
writes. It is called from config_set where it is free to block.
Also fix error handling: serial_write can return any negative error code,
not just -1.
These calls were already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. They only read one byte. A return value of zero is not
handled, but should not occur in theory due to the G_IO_IN check. It might be
good to add handling of a zero return anyway, since I'm not sure if this is
always accurate.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. It only reads one byte, and a zero result is handled
appropriately.
These calls are executed from an event handler and were previously nonblocking,
but have no partial write handling. They send short packets so should be OK to
block, most likely the output buffer will be empty anyway.
Also fix error handling for these calls, which seems to have been retained from
previous direct usage of write() to a serial port fd.
These calls were previously nonblocking, but have no partial write handling.
They are made from scan and acquisition_start contexts where they are free
to block.
Remove the SERIAL_NONBLOCK at open, which only applied during scan, since all
calls in the scan are now explicitly blocking.
Also fix error handling for these calls, which appears to have been kept
from a previous direct usage of write() on a serial port fd.
This call was already nonblocking since the driver opens the port with the
SERIAL_NONBLOCK flag. Only one byte is read. The case of 0 being returned
is not handled, but the call is only made if G_IO_IN occurred so in theory,
there should be a byte available. It might be wise to add handling for a
return of 0 nonetheless, as I'm not sure if this is always accurate.
This is an odd one. These calls are made from a receive handler so should not
block, and appear to be setup correctly to handle partial reads or no data
available. However, the driver was not opening the port with SERIAL_NONBLOCK
so these calls would have been blocking. Make them nonblocking.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
These calls were already nonblocking since this driver opened the port with
the SERIAL_NONBLOCK flag. Having marked them as such, we can remove the flag.
Also remove an unnecessary reopen of the port to change its blocking status.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
This call is executed from an event handler and was previously nonblocking,
but has no partial write handling. It sends a short packet so should be OK
to block, most likely the output buffer will be empty anyway.
This is called at scan time so free to block. There is no partial write
handling and a response is expected afterwards. This should therefore be a
blocking call.
This call is executed from an event handler context was previously
nonblocking, however there is no handling for a partial write.
The output buffer is unlikely to be full and the commands to be sent
are short, so it should be OK to make this a blocking call.
This call is executed at scan time so is free to block. There is no
handling for a partial write and a response is expected immediately
afterwards. It should therefore be a blocking call.
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.
Uwe Hermann
Daniel Elstner
Tilman Sauerbeck
Hannu Vuolasaho
Matthieu Gaillet
jry
Martin Ling
Karl Palsson
Bartosz Golaszewski
Martin Lederhilger
Bert Vermeulen
Aurelien Jacobs
Daniel Glöckner
Hubert CHAUMETTE
Soeren Apel
Daniel King
Daniel Lezcano
Daniel Gröber
Carl-Fredrik Sundström
Alexandru Gagniuc
Marcus Comstedt
eightdot
Baruch Even
Daniel Elstner
Mathias Katzer
Tim Hatch
Uffe Jakobsen
Janne Huttunen