kingst-la2016: shuffle code order to follow application perspective

Sort "set threshold voltage" code blocks into numerical order of voltage
levels for improved readability. It's surprising to find ">= 2.9V" then
"<= -0.4V" and then "between those" at the end.

Move the la2016_has_triggered() routine next to run_state() since both
of them inspect the device's current run state. Closer inspection even
suggests that one is named inappropriately (not renamed in this commit,
to help reviewers).

The purpose of the set_run_mode() routine's argument most probably is
"mode", and not the surprising "fast blinking". Indicators may just be
a byproduct of setting mode to run or halt.

Make the set_defaults() invocation in la2016_init_device() stand out
more perceivably. Don't hide it in a return statement.

kingst-la2016: unobfuscate "user specified threshold" reference

Use a symbolic name for the "user specified input threshold" item's
position in the set of choices. Stick with array size for the complete
list of items instead of hiding the size behind an unrelated name. This
improves readability of the config get/set/list routines. Trim a text
line length while we are here.

The single variable for several purposes (user specified value, and
fixed value derived from currently selected choice out of a premade
set) still looks suspicious, and is not addressed in this commit.

kingst-la2016: concentrate magic numbers in central location

Eliminate open coded magic values which are spilled across the driver's
implementation. Concentrate tunables or derived values in a central spot
at the top of the source files near other declarations. Rephrase some
values to better reflect their purpose or magnitude.

Few values remain dubious. Add TODO comments for awareness.

kingst-la2016: rephrase FPGA bitstream content zero padding

The upload_fpga_bitstream() routine open codes a magic length for the
padded file content, which is hard to relate to a firmware file size,
and impossible to spot during maintenance. Declare an assumed chunk size
instead and let the resource file handling code path determine the needed
length of zero padding. Drop an unneeded device context member variable.

kingst-la2016: make FPGA bitstream upload optional

Separate the FPGA bitstream upload logic into the strict file content
upload, and the register access to initialize and enable a currently
loaded bitstream. Check before upload whether a working bitstream is
available in the device.

This eliminates a 600ms delay in every device open code path after the
initial upload. Which speeds up the start of an acquisition. Works in
Pulseview as well as sigrok-cli, even across process invocations.

Unfortunately test conditions are rather weak, they are constrained by
an arbitrary vendor's choice. Stricter checks can get added later if
the need arises (when incompatible device firmware versions are seen,
and more reliable test criteria become available). The implementation
lends itself to transparent robustness improvements.

kingst-la2016: rephrase USB renum code path after firmware upload

The dev_open() routine postprocesses USB renumeration after a previous
FX2 MCU firmware upload. Concentrate all tunables in the driver's header
file, and discuss their meaning in relation to each other. Rephrase the
logic to start checking earlier, and keep checking for longer, adjust
diagnostics in the process. Void the "firmware uploaded" flag when the
upload took effect. Consistently use u64 for timestamps. Rename a few
variables to improve readabilty.

kingst-la2016: address style nits, brace location, indentation

Avoid indentation by means of spaces, and excess indentation. Break long
text lines. Adjust braces location to match the sigrok project's style.

kingst-la2016: rephrase comments for style, readability, and text length

Rephrase comments in the Kingst LA2016 driver to better match the sigrok
project's style. Consistently start with capitals and end in punctuation.
Use all upper case for acronyms to improve readability.

Keep text lines to an acceptable length. Use consistent open and close
phrases for multi-line comments. Drop C++ style comments. Add braces
where comments and one-line code results in multi-line branches of flow
control statements.

This commit also consistently uses lower case for hex literals, and
unobfuscates a few other literals: Use 0xff everywhere for unknown USB
addresses, prefer 1800 * 1000 over 18e5 for a 1.8 seconds interval.

kingst-la2016: rephrase diagnostics to improve user perception

Rephrase diagnostics messages so that users easier can digest them. Keep
implementation details out of messages which are seen by default, stick
those into developer centric messages that correspond to higher verbosity
levels. Consistently start with capital letters and end in punctuation.
Drop exclamation marks. Use all caps for acronyms. Don't break format
strings so that developers can search for messages reported by users.
Break a few long source code text lines (but not all of them).

kingst-la2016: style nits, consistent #define indentation

Consistently use TAB characters to indent #define directives' values.
Remove an unused directive. See whitespace ignoring diff for review.

kingst-la2016: style nits, remove not needed include directives

kingst-la2016: sort include directives

kingst-la2016: move acquisition abort from api.c to protocol.c

There was the abort_acquisition() routine (whithout a prefix) and the
la2016_abort_acquisition() routine (with a prefix). Fold the termination
of USB reception into the drivers's SR_PRIV routine which resides in
protocol.c, which eliminates the misplaced api.c implementation. Change
a few more receive callback related routines from SR_PRIV to static now
that their calls are intra compile unit.

kingst-la2016: move USB communication from api.c to protocol.c

Move the Kingst LA2016 driver's "receive data" callback (device's
USB communication) to protocol.c where it belongs. This is a pure
move between source code files, behaviour does not change.

kingst-la2016: rename routine before moving from api.c to protocol.c

The Kingst LA2016 driver implementation would not follow the typical
separation of api.c and protocol.c responsibilities, instead encodes
USB communication to the device on the api.c side. Rename a driver
routine before moving it between files, provide an SR_PRIV decoration.

rdtech-dps: Use big endian register access for DPS devices

Adresses an issue which was introduced in commit d7a4dad881bf.

Fixes bug #1760

Signed-off-by: Volodymyr Ananiev <redacted>

rigol-ds: improve robustness in samplerate getting code path

The rigol-ds driver's acquisition start routine tries to determine the
samplerate, which depends on devices' protocol version and communication
of SCPI requests. The logic potentially used an uninitialized variable
(for protocol versions below V3).

Rephrase the samplerate getting code path, apply stricter checks and
extend diagnostics. Make sure the XINC retrieval did yield a non-zero
value, to also avoid a division by zero.

Address style issues while we are here. Use braces for all branches when
one of them is complex. Eliminate trailing whitespace at ends of lines.

    src/hardware/rigol-ds/api.c:1029:7: warning: variable 'xinc' is used uninitialized whenever '&&' condition is false [-Wsometimes-uninitialized]
                    if (devc->model->series->protocol >= PROTOCOL_V3 &&
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    src/hardware/rigol-ds/api.c:1034:28: note: uninitialized use occurs here
                    devc->sample_rate = 1. / xinc;
                                             ^~~~
    src/hardware/rigol-ds/api.c:1029:7: note: remove the '&&' if its condition is always true
                    if (devc->model->series->protocol >= PROTOCOL_V3 &&
                        ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    src/hardware/rigol-ds/api.c:1028:13: note: initialize the variable 'xinc' to silence this warning
                    float xinc;
                              ^
                               = 0.0

session: address deprecation of g_memdup(), prepare use of g_memdup2()

The g_memdup() routine was deprecated and (very) soon will become
obsolete. Use g_memdup2() when available, which is preferred for its
use of proper size data types.

This is inspired by pulseview commit cf0109112932 which references the
https://discourse.gnome.org/t/port-your-module-from-g-memdup-to-g-memdup2-now/5538
article.

input/vcd: detect and skip string data types (value not used)

The nMigen utility was reported to emit string values in VCD files (by
means of the pyvcd Python module). The $var declaration specifies the
'string' data type, and text values are prefixed with 's' similar to
integer or real numbers and bit vectors.

It is desirable to process these files and skip the unsupported type
which does not map to any sigrok channel type. Add support to detect the
type in declarations and change entries, skip these change entries and
emit warnings so that users remain aware of the incomplete import. Check
the validity of the entry though, to keep robustness of the existing
implementation of the VCD input module.

The validity check is an educated guess that was written in the absence
of an official specification or any public documentation, encodes rather
arbitrary assumptions. Deals with cases that were reported, may need
more test coverage and future tweaking. This version forbids whitespace
in values, and exclusively accepts printable ASCII in the string
presentation, with a few escape sequences. Empty strings are covered.

This also resolves bug #1757.

Reported-By: Anton Blanchard <redacted> via github PR 157

input/vcd: raise severity of messages about unsupported data types

The VCD input module did check for unsupported data types in $var
declarations. But the emitted message only was of INFO level and thus
would not be seen at the default log level. Use ERR instead to raise
awareness. Let users see by default that the input contains data which
cannot get processed (and why the import terminated prematurely).

This addresses part of bug #1757.

ftdi: address ftdi_usb_purge_buffers() deprecation in libftdi 1.5

The ftdi_usb_purge_buffers() implementation suffered from an incorrect
implementation (inverse semantics). Library version 1.5 introduced a set
of substitute routines, and deprecated the existing purge API. Parameters
are identical, so we get away with a mere replacement of the routine name
which gets invoked. Which simplifies call sites, and concentrates all the
version dependency cruft in a central spot. The fact that all drivers
always flushed RX and TX and never individually also helped.

input/vcd: silence printf() format compiler warning

uni-t-ut181a: drop serial flush() after open()

The driver's call became obsolete when common code added flush() to the
open() sequence.

uni-t-ut181a: silence compiler warning, use of uninitialized variable

The ut181a driver's acquisition start routine may face a previously
unknown data source value, which is potentially unhandled when the
source code becomes inconsistent during maintenance. Add a default
case to handle the condition, which silences a compiler warning.

    src/hardware/uni-t-ut181a/api.c:505:13: warning: variable 'ret' is used uninitialized whenever 'if' condition is false [-Wsometimes-uninitialized]
            } else if (devc->data_source >= DATA_SOURCE_REC_FIRST) {
                       ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    src/hardware/uni-t-ut181a/api.c:536:6: note: uninitialized use occurs here
            if (ret < 0)
                ^~~
    src/hardware/uni-t-ut181a/api.c:505:9: note: remove the 'if' if its condition is always true
            } else if (devc->data_source >= DATA_SOURCE_REC_FIRST) {
                   ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    src/hardware/uni-t-ut181a/api.c:467:9: note: initialize the variable 'ret' to silence this warning
            int ret;
                   ^
                    = 0

configure: Hameg HMO does not strictly depend on serial communication

Remove the hameg-hmo driver's dependency on the serial_comm physical
transport. This is too strict a constraint, the scope communicates via
SCPI and can use any of the supported transports.

rdtech-tc/um: silence "missing field identifier" compiler warning

There are rather conservative build setups which complain about missing
fields in initializers. Rephrase the profile sentinels in the rdtech-tc
and rdtech-um drivers for maximum portability across toolchain setups.

  src/hardware/rdtech-um/protocol.c:45:10: warning: missing field 'spec' initializer [-Wmissing-field-initializers]
          { NULL, },
                  ^

binary helpers: add "invalid" enum item, improve readability

The "binary value" helpers would not follow the sigrok project's style
of only using non-zero values for valid enum items (a zero value is
assumed to always represent something "inactive" or "invalid").

Introduce the "invalid" item in the enum declaration to fixup the style
issue. Rephrase the bv_get_value() routine's length specs to improve
readability, match numbers in length specs to the numbers in conversion
routine references.

doc: fix a trivial typo in the ASIX OMEGA section of README.devices

input/stf: move trigger packet emission to feed queue (including flush)

Use the recently extended feed queue API which transparently flushes
previously accumulated logic data before sending a trigger packet.

input: optionally send trigger markers from common feed queue helper

This further simplifies callers, which need not care about flushing
previously queued samples before a trigger packet is sent. The queue
itself handles the order of packet initiation.

configure: make zlib an optional dependency which input/stf depends on

The STF input module calls into the zlib's crc32() routine, although
this dependency is not checked for and need not be satisfied. This went
unnoticed because zlib is rather ubiquitous, most development machines
provide it.

Extend the configure script to check for the zlib presence. Absence is
non-fatal (the library is truly optional). Reflect the version details
in the libsigrok version output, update the README. Make the STF input
module depend on the zlib presence, which makes the module optional.

It's unfortunate that the MiniLZO library which the libsigrok source
embeds does not provide the CRC32 calculation. Else we could have used
it instead of introducing another external dependency.

This implementation attempts to properly separate the autoconf/shell
layer from the automake layer from the C language preprocessor, and
separate the zlib library availability from the compression and CRC32
calculation availability from the STF input module applicability. This
shall prepare more zlib use in future implementations.

serial: move sr_serial_extract_options() out of "have serial comm" condition

The sr_serial_extract_options() routine strictly operates on variables
and is applicable to any driver which accepts conn= specs. No physical
serial communication is involved, the HAVE_SERIAL_COMM condition check
is too strict a constraint.

This silences warnings in build configurations where serial communication
is not available:

   ../src/scpi/scpi.c: In function 'sr_scpi_scan':
  src/scpi/scpi.c:325 col 2: warning: implicit declaration of function 'sr_serial_extract_options' [-Wimplicit-function-declaration]
     (void)sr_serial_extract_options(options, &resource, &serialcomm);
     ^

Implementation detail: List the serial.c source file two times in the
Makefile to avoid confusion when the file is "missing" in the list of
related source files in the "serial comm supported" case. All serial.c
content already was under the HAVE_SERIAL_COMM condition, so compiling
that file in all build configurations is not an issue.

kingst-la2016: handle sdi==NULL in config_list

The hardware driver API specifies that the sdi argument to config_list
is optional and can be NULL. This change handles that case, instead of
dereferencing without a check.

input/stf: introduce support for Asix' Sigma Test File format

Introduce the 'stf' input module which interprets *.stf captures
which are the Asix Sigma vendor software's native format. This
implementation supports Sigma Test Files, but does not support
Omega Test Files because ZIP archive handling is not available
in sigrok input modules. This implementation depends on miniLZO.

The input module was tested with vendor provided example captures.
Automatic file format detection, GUI initiated file re-read, and
50MHz as well as 200MHz captures were tested, and successfully
decode I2C, UART, and USB traffic. The trigger position works
(when the file content is plausible, the USB dump was not).

configure: hook up minilzo to the libsigrok build, reflect its version

Add the minilzo/ directory to the list of source files for the libsigrok
build. Have the minilzo library use the project's config.h file, extend
the set of autoconf checks. This approach follows the documentation in
the README.LZO file. It avoids the dependency on an external library and
its version or configuration.

Reflect the minilzo version in the libsigrok version output. The example
application which ships with the library suggests that failed init calls
typically originate from compile issues. Present the same error message
to sigrok users as the example application does.

minilzo: import content of upstream minilzo-2.10.tar.gz archive

The miniLZO distribution is a stripped down version of the LZO library,
and can be preferrable over the larger external dependency. Import the
content of the upstream's minilzo-2.10.tar.gz archive, which is released
under the GPL and thus is compatible with libsigrok.

README.devices: discuss ASIX OMEGA in RTM CLI mode (vendor application)

A stub sigrok driver can use the vendor's command line application to
make principal Asix Omega operation available. Outline the approach and
discuss the requirements for this setup in the README.devices file.

asix-omega-rtm-cli: Implement RTM for ASIX OMEGA via external CLI process

The ASIX OMEGA vendor software provides a commandline application which
puts the device in "real time mode". The process' stdout provides a
continuous RLE compressed stream of samples for the 16 input signals,
recorded at 200MHz. The sigrok driver starts and terminates this process
for the duration of the acquisition.

This simple approach makes the OMEGA device available in a basic mode of
operation. The samplerate is fixed, hardware triggers are not available.
The binary data format is used to reduce the amount of inter process
communication. The vendor's Windows software also executes in Linux
under wine(1). All device detection, USB communication via FTDI FIFO
mode, firmware download, etc are transparently dealt with. This mode of
operation is an officially supported and documented feature.

The sigrok driver accepts the OMEGARTMCLI environment variable as the
specification of the vendor application's location, or falls back to the
omegartmcli executable name which should be in PATH. The conn= spec in
the sn= format can select one out of multiple connected devices.

The driver was tested on Linux with --samples and --time as well as with
Pulseview and manual acquisition stop while a huge limit was configured
that would not take effect.

asix-omega-rtm-cli: Initial driver skeleton.

sw_limits: extend API to "get remaining counts" before the limit is reached

The current sw_limits API provides routines which interface nicely with
config get/set and Glib data types, and which check whether a limit was
exceeded after previous submission of samples (summary result).

Device drivers may want to check _before_ a limit was reached, some may
want to cap to-get-submitted sample data such that a limit gets reached
but is not exceeded. This need becomes more obvious when devices with
efficient hardware compression "severely overshoot" the user specified
limits when the check is only done late after submission of another
chunk of data which results from uncompression.

Introduce an API routine which gets the remaining count until the limit
is reached. Phrase the implementation for cheapest cost of execution.
These routines may execute in tight loops in acquisition code paths.

input: accept const sdi in feed queue API

The common feed queue support code needs an sdi to submit sample data to
the session feed. Decorate this argument as const to silence compiler
warnings. This matches the sr_session_send() API.

kingst-la2016: setup usb transfer sizes to be multiple of endpoint max packet size, as required by WinUSB RAW_IO policy

zketech-ebd-usb: Minor style fixes

zketech-ebd-usb: Style fixes

zketech-ebd-usb: Multiple fixes and upgrades.

- fix load toggling at acquisition stop
- messages are sent byte per byte with a pause in between since bytes were
  sometimes dropped
- incoming stream is parsed continuously instead of using a fixed length (the
  messages have a constant start/stop)
- add under-voltage threshold (under which the load would stop) as configuration
- add D+/D- voltage measurements as two new channels (had to rename the
  existing to avoid confusion)

kingst-la2016: Minor style fixes

kingst-la2016: add support for kingst la1016

The Kingst LA2016 and LA1016 use the same hardware, just the coding
of authentication IC U10 is different. U10 limits the LA1016 to
using an FPGA bitstream that samples at a maximum of 100MHz. Other
than that, the devices operate identically and the driver just needs
to select the correct bitstream and limit the maximum sample rate
appropriately. This commit adds support for the existing two hardware
revisions of LA1016, which require different bitstreams.

kingst-la2016: avoid filling the log file with redundant messages during long captures

kingst-la2016: add support for both LA2016 hardware revisions

A magic number within the device eeprom identifies the device
type and hardware revision. Using this number, the correct
fpga bitstream is selected and loaded.

kingst-la2016: remove unnecessary initialisation code

The OEM software communicates with device IC U10 to perform challenge-response
authentication, ensuring the device is genuine. We have no knowledge of the
obfuscation or encryption method used. Additionally it is a rolling code, so
the response changes even with same challenge. In any case, we can just ignore
this IC U10, it does not hinder sigrok support. Removing this code from
the initialisation routine. See schematic in wiki for more info on U10.

kingst-la2016: fix segfault that often occurs when a capture is aborted

kingst-la2016: fix fpga register alignment for sampling configuration

kingst-la2016: fix input threshold adjustment

There are, in fact, two pwm outputs which must both be configured to
control the dac output which offsets input signals. See the last two
pages of the schematic (on wiki) for details.

kingst-la2016: fix the fpga register addresses

Fix the address of registers within the fpga which are used for contolling
input thresholds, sampling, triggering and bulk transfers. These addresses
were derived from observations of the usb bus and of the internal la2016
spi bus. See wiki for captures of spi bus activity.

kingst-la2016: replace usb control transfer brequest numbers with more meaningful tokens

ols: Fix off-by-one when setting up trigger stages

The additional stage prevented OLS from using 4 stages.

ols: Fix demuxer operation

On my OLS with Demon Core (v3.07), the following command produces only low
levels on channels 8-15:
sigrok-cli -d ols:conn=/dev/ttyACM0 --output-format ascii:width=128 \
  --config='samplerate=200M:pattern=Internal:captureratio=50' \
  --channels 0-15 --samples 32 --triggers "12=1"

This doesn't make sense since it only triggers if channel 12 is high.
By not overwriting the channel data, I get the desired output. The data
is processed in groups of 2 bytes, so there's no need to fold back "input"
from devc->sample[2..3] because these bytes are always zero.

ols: Don't silently ignore error when setting up the device

ols: Don't store temporary data in device context

ols: Provide sample count in RLE mode

It just means "number of compressed samples", but it's still highly useful
to decice how much data to capture. If this is unavailable, PulseView
provides a weird list of up to 1 TSmpl, which makes even less sense.

ols: Clean up: Obey code style

scpi-pps: Support for the EEZ PSU series

There is currently one released model and one other model under
development. This change aims to support both of them, though it's been
tested primarily with the original H24005 series and only with the
simulator for the BB3 series.

[ gsi: address style nits ]

scpi-pps: Data capture dynamically-probed channels

For the few device profiles that probe the device dynamically to determine
channel settings, the results end up in the dynamically-allocated
devc->channels instead of in the statically-configured
devc->device->channels field.

Previously this would crash by dereferencing a null ch_spec for the
device types that do dynamic channel configuration.

[ gsi: address minor style nits ]

Add support for TENMA 72-2710 V6.6 power supply

itech-it8500: Remove SR_MQFLAG_DC from power values.

hp-59306a: Rename channel groups from CHn to Rn

Also fix the long name in the sr_dev_driver struct

hp-59306a: Add GET for config key SR_CONF_CONN

hp-59306a: Enable/disable all outputs at once.

input/saleae: silence overzealous compiler warning

Although the number of channels in data files saved by the Saleae export
feature remains small, recent compilers keep complaining about potential
truncation. Use a larger buffer to silence the warning message. No change
in behaviour.

dmm/bm52x: silence overzealous compiler warning

Although the number of recordings in the BM52x DMM remains small, recent
compilers keep complaining about potential truncation. Use a larger
buffer to silence the warning message. No change in behaviour.

tests: unbreak endianess conversion test routine (too small a buffer)

Writing four times 48 bits to a buffer that is two times 64 bits will
exceed that buffer. Fix an issue introduced in commit 8f87c5284bf0.

doc: update README.devices for conn=sn=<serno> (driver specific)

Mention the optional availability of the conn=sn=<serno> format to
select one of several connected devices.

dcttech-usbrelay: accept conn=sn=<serno> user specs in probe

Add support for the "-d dcttech-usbrelay:conn=sn=<serno>" syntax.

This dramatically increases usability when multiple cards are attached
(a very likely condition given the low channel count of these devices),
while other means to select one card out of a set of cards either don't
exist or are heavily constrained: Identical VID:PID numbers are shared
across all card variants. HIDAPI paths are rather platform dependent and
may even be incompatible with the conn= syntax. Some platforms may even
refuse to open() paths which result from their own enumeration. Which
leaves relay card serial numbers as the only reliable and portable
method for selection. Being convenient is just a bonus.

conrad-digi-35-cpu: Remove CH1 from device.

This device is write only and does not transmit any measurement data.
Therefore a channel is not necessary.

dcttech-usbrelay: support conn=vid.pid specs in addition to paths

Extend the scan code path, accept user provided conn= specs in the
"vid.pid" format. Everything else is assumed to be a hidapi compatible
"path" and may suffer from conn= parser limitations. Unfortunately the
hidapi API won't let us lookup paths from bus.addr specs which would
work when multiple cards need to be told apart.

dcttech-usbrelay: accept conn= spec different from hidapi enum details

Rework the scan and probe routines. Skip the USB enumeration's result
set when the user provided a conn= spec, instead exclusively open the
specified device. It's acceptable when this user spec does not match
the details which the hidapi enumeration would yield. [ This version
prepares but does not implement yet support for "funny" hidapi(3) paths
on platforms beyond Linux. ]

This also weakens the logic which determines the relay count from the
USB product string. Any trailing number is accepted. Which allows to use
compatible devices with differing vendor/product strings when conn= is
specified. The previous "USBRelay" prefix check remains in place for
automatic enumeration.

Beautify diagnostics, even phrase debug and spew level messages such
that they can be presented to users. Makes -l 5 look more consistent.

dcttech-usbrelay: rework scan (enumeration) and probe (identification)

Move all of the sdi creation into the probe routine which communicates
to the relay card. Extend diagnostics in that code path. Which leaves
pure USB enumeration in the scan routine.

dcttech-usbrelay: adjust serial number and connection string logic

Store the USB relay card's serial number such that users can tell apart
multiple connected cards. Hold the HIDAPI path in the 'connection_id'
member because 'conn' is something internal, not for display purposes.

contrib: add udev rule for V-USB based HID devices (USB relay card)

Add the USB identification of the dcttech.com USBRelay<n> card. Which
happens to be shared with other V-USB based firmware projects. Thus is
rather generic. The USB relay card is just the first supported device
of that kind.

dcttech-usbrelay: implement multiplexer driver for USB relay card

Implement support for the "www.dcttech.com USBRelay<n>" card. This V-USB
based HID device communicates HID reports to control up to 8 relays. The
driver depends on the HIDAPI external dependency for maximum portability.

Support for the conn= parameters is limited. A path that HIDAPI can open
is expected, which depends on the platform and HIDAPI implementation,
and may not always be expressed by means of sigrok command line options.
See README.devices for a discussion.

The USB serial number is not considered. This is an implementation
detail of the relay card's firmware. HID reports carry a five character
identifier for the board.

Relay state is cached in the driver. It's assumed that relay state won't
change outside of libsigrok control as long as the device is opened. The
single request to activate/deactivate all relays at once is supported.

dcttech-usbrelay: Initial driver skeleton.

hp-3478a: Fix switching from 4-wire to 2-wire measurement.

The measured quantity flags for the measurement mode can only contain one flag
at maximum. Therefore the quantity flags handling can be simplified, which also
fixes a bug when switching from 4-wire resistance measurement to 2-wire mode.

hp-3478a: Only match when conn= is given to avoid false probe positives.

The HP 3478A device would not reliably identify by means of SCPI queries. The
previous scan() implementation would have matched any connected SCPI device,
then upset these devices by emitting non-SCPI requests.

Tighten the scope of the hp-3478a probe, only scan for devices when a conn=
spec was provided. This avoids false positives and malfunction of other
devices, and still lets users address the problematic device. This is similar
to serial-dmm and unspecific cables and has proven to work there.

scpi_vxi: Unbreak MacOS build (vxi.h inclusion order).

Undo the #include statement order change of commit 7414fb55cb1f. It's
essential on MacOS to include vxi.h early to keep related u_long et al
data types available. See commit d40b8557a962 for a discussion.

Also drop the inclusion of rpc/rpc.h from scpi_vxi.c because it is not
used in that source file, instead is a vxi.h dependency and is included
there.

[ gsi: rephrase commit message ]

hp-3478a: avoid NULL dereference in config API routines

The 'sdi' parameter to config API calls can be NULL. Only dereference
after checking its validity.

Reported-By: Alexandre Ferreira <redacted>

doc: update IRC reference to Libera.Chat

rigol-ds: fix use-after-free

This amends commit 4fad41a8a4f3 which fixed a leak but introduced the
use after free.

scpi_vxi: fix memory leak for SCPI response data in VXI support code

Routine scpi_vxi_read_data() invokes device_read_1(), which provides a
static buffer where dynamically allocated memory for SCPI response data
is kept. Release this memory after getting a copy of the response data,
before the next device_read_1() call loses the reference.

Valgrind stats without the fix:

  ==238825== LEAK SUMMARY:
  ==238825== definitely lost: 45,547,737 bytes in 18,331 blocks
  ==238825== indirectly lost: 0 bytes in 0 blocks
  ==238825== possibly lost: 48,154 bytes in 14 blocks
  ==238825== still reachable: 42,859 bytes in 288 blocks
  ==238825== suppressed: 0 bytes in 0 blocks

Valgrind stats with the fix:

  ==239413== LEAK SUMMARY:
  ==239413== definitely lost: 40 bytes in 2 blocks
  ==239413== indirectly lost: 0 bytes in 0 blocks
  ==239413== possibly lost: 0 bytes in 0 blocks
  ==239413== still reachable: 38,613 bytes in 287 blocks
  ==239413== suppressed: 0 bytes in 0 blocks

Remaining leaks in scpi_vxi_open() are of lesser severity because they
don't accumulate during execution.

[ gsi: rebase to recent master, reword commit message ]

scpi_vxi: readability nits in the SCPI via VXI source code

Address style nits to improve readablity and future maintenance.
Move system header includes before application level includes. Move
assignments out of variable declaration blocks. Separate function calls
and assignments from error checks and flow control. Break a long line.
Add braces around conditional multi line statements.

All these adjustments are cosmetical. Behaviour does not change.

contrib: add udev rule for Agilent 34460A USBTMC

scpi-dmm: Add support for Agilent 34460A

[ gsi: rebase and squash, specify delays like Keysight 34465A ]

scpi-dmm: add short measurement delay for 34465A

With Keysight 34465A the VOLT:AC and FREQ functions keep suffering from
USB timeouts and pipe errors. Add a 10ms delay between initiating the
acquisition and checking for completion before fetching the result.

The weird thing is that when successful responses are seen after
temporary failure, enlarging the delay does not make them go away.
Instead the USB errors keep moving to a different spot. Measurements do
arrive though, so this is just annyoing but not a blocker.

  sr: [00:00.134038] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:00.136043] scpi: Got response: '"FREQ +3.00000000E+00,+3.00000000E-06"', length 38.
  sr: [00:00.136119] scpi-dmm: dev_acquisition_start: Precision: '"FREQ +3.00000000E+00,+3.00000000E-06"'
  sr: [00:00.136251] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.184211] scpi: Got response: '1', length 1.
  sr: [00:00.184481] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
  sr: [00:00.234800] session: bus: Received SR_DF_HEADER packet.
  cli: Received SR_DF_HEADER.
  sr: [00:00.245597] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.246050] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
  sr: [00:01.256495] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.291871] scpi_usbtmc: USBTMC invalid bulk in header.
  sr: [00:01.302392] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.401959] scpi: Got response: '1', length 1.
  sr: [00:01.402135] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.403392] scpi: Got response: '1', length 1.
  sr: [00:01.403566] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:01.405769] scpi: Got response: '"FREQ +3.00000000E+00,+3.00000000E-06"', length 38.
  sr: [00:01.406020] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.407500] scpi: Got response: '1', length 1.
  sr: [00:01.407674] scpi_usbtmc: Successfully sent SCPI command: 'FETCH?'.
  sr: [00:01.409107] scpi: Got response: '+9.00555531E+01', length 15.

Experimentation suggests that 200ms timeouts reduce the probability of
these USB communication errors. But if functions tend to respond that
differently, are delay time specs per MQ required? The implementation of
the driver currently assumes a single delay spec.

scpi-dmm: model and MQ dependent delay before measurement

Some models are slow to start a measurement acquisition in specific MQs
(meter functions). An "*OPC?" query went unanswered after "INIT" was
sent. This was observed on 34405A in temperature, frequency, resistance,
AC voltage and current mode.

Add an optional per-model measurement delay that is used when the MQ
specifies that the delay is applicable. Because functions are changed
rarely but measurements are taken many times, only the first reading
is delayed while later readings are seen at the expected interval. Not
delaying the first reading will result in device errors.

  sr: [00:00.875162] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:00.881666] scpi: Got response: '"FREQ +1.00000E+00,+1.00000E-05"', length 32.
  sr: [00:00.881700] scpi-dmm: dev_acquisition_start: Precision: '"FREQ +1.00000E+00,+1.00000E-05"'
  sr: [00:00.881840] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.883966] scpi: Got response: '1', length 1.
  sr: [00:00.884139] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
  sr: [00:01.884420] session: bus: Received SR_DF_HEADER packet.
  cli: Received SR_DF_HEADER.
  sr: [00:01.895260] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:02.895766] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
  sr: [00:02.906302] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:02.910703] scpi_usbtmc: USBTMC invalid bulk in header.
  sr: [00:02.921244] scpi_usbtmc: USBTMC bulk out transfer error: LIBUSB_ERROR_PIPE.
  sr: [00:02.931802] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:02.932276] scpi: Got response: '1', length 1.
  sr: [00:02.932425] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:02.934790] scpi: Got response: '1', length 1.
  sr: [00:02.935155] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:02.941564] scpi: Got response: '"FREQ +1.00000E+00,+1.00000E-05"', length 32.

  sr: [00:00.173408] hwdriver: scpi-dmm: Starting acquisition.
  sr: [00:00.173569] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.334312] scpi: Got response: '1', length 1.
  sr: [00:00.334544] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:00.341070] scpi: Got response: '"RES +1.00000E+02,+1.00000E-03"', length 31.
  sr: [00:00.341307] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.343636] scpi: Got response: '1', length 1.
  sr: [00:00.343872] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:00.350093] scpi: Got response: '"RES +1.00000E+02,+1.00000E-03"', length 31.
  sr: [00:00.350157] scpi-dmm: dev_acquisition_start: Precision: '"RES +1.00000E+02,+1.00000E-03"'
  sr: [00:00.350342] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:00.352524] scpi: Got response: '1', length 1.
  sr: [00:00.352832] scpi_usbtmc: Successfully sent SCPI command: 'INIT'.
  sr: [00:00.352901] session: bus: Received SR_DF_HEADER packet.
  cli: Received SR_DF_HEADER.
  sr: [00:00.363675] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:01.364363] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
  sr: [00:01.374904] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:02.375380] scpi_usbtmc: USBTMC bulk in transfer error: LIBUSB_ERROR_TIMEOUT.
  sr: [00:02.385872] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:03.232457] scpi_usbtmc: USBTMC invalid bulk in header.
  sr: [00:03.243003] scpi_usbtmc: USBTMC bulk out transfer error: LIBUSB_ERROR_PIPE.
  sr: [00:03.253464] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:03.256568] scpi: Got response: '1', length 1.
  sr: [00:03.256902] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:03.259440] scpi: Got response: '1', length 1.
  sr: [00:03.259713] scpi_usbtmc: Successfully sent SCPI command: 'CONF?'.
  sr: [00:03.266070] scpi: Got response: '"RES +1.00000E+08,+1.00000E+3"', length 30.
  sr: [00:03.266456] scpi_usbtmc: Successfully sent SCPI command: '*OPC?'.
  sr: [00:03.268501] scpi: Got response: '1', length 1.
  sr: [00:03.268961] scpi_usbtmc: Successfully sent SCPI command: 'READ?'.
  sr: [00:03.353589] scpi: Got response: '+9.90000000E+37 ', length 16.

Declare a 2500ms measurement initiation delay for 34405A which was found
by experimentation. This is huge but was found to be necessary.

Of course all other meter functions are unaffected by this commit. As
are the meters which specify no delay.

scpi-dmm: model and MQ dependent delay when switching functions

Some models are slow to switch meter functions to specific MQs. This was
observed with 34405A and AC V/I modes, where USB connections timed out
and suffered from pipe errors.

Add an optional delay after "CONF:<mode> [<range>]" SCPI requests. The
duration of the delay is per model, the use of the delay is per MQ on
that model. The 200ms delay for 34405A was found by experimentation.

Speaking about 34405A: Only the "INIT" request in temperature mode
remains as an issue, which is not covered by this commit's approach.

scpi-dmm: use different Agilent SCPI command for range and measurment

Don't use the "[SENS:]<mode>:RANGE..." request on Agilent protocol
speaking devices. Use "CONF:<mode> [<range>]" instead. This was tested
with all devices which reference this model.

In theory there is the question whether previously configured ranges
should be re-used when (exclusively) the MQ is switched. It's assumed
that this is not useful, instead users or their applications should
select the function first and optionally pick the range then. Re-use of
e.g. 10k resistance range when switching to capacitance might be seen as
confusing (and results in errors in the device).

Use the combination of INIT and FETCH? to get measurements. The READ?
request is more complex and might "undo" what INIT already initiated.
This improves perception of the 34405A meter's operation.

scpi-dmm: rephrase read timeout decls, put "unit" after "ms value"

Rephrase the SCPI read timeouts in scpi-dmm model declarations. Shuffle
the order of product terms such that the milliseconds "unit" goes last,
and the milliseconds value goes first. Assume that "2500 * 1000 [us]"
better reflects the intention than "1000 * 2500" does.

fluke-45: drop serial port echo test, was disabled for years

The Fluke 45 driver's ECHO_TEST broke other people's SCPI device
identification and was disabled in 2018-11. Remove the dead code which
is impossible to resurrect. Its purpose was questionable to begin with.

Should users be affected, then the echo would break the identification
phase. The check cannot be done before identification without affecting
other connected devices, cannot be done after the identification either
when that very identification systematically fails. Should a user meet
this condition then applications' logs are available to see why *IDN?
fails, assuming that users are not aware of their serial port or device
configuration. The request's reflection in the place of a response gives
a strong hint.

hp-3457a: only probe when conn= was specified, to not break SCPI devices

Only scan for hp-3457a devices when the user specified which connection
to use. This avoids breaking SCPI devices by emitting non-standard
requests before reliable device identification.

scpi-pps: don't break SCPI devices when scanning for HP-IB devices

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.

scpi: style nits in sr_scpi_scan(), prefer common helper

Improve readability and simplify maintenance of the sr_scpi_scan()
routine.

Move initial assignment and subsequent update of variables in closer
proximity, don't hide assignments in declaration blocks. Use common
helper code where available. Split complex conditions into individual
terms which are easier to review and reason about. Don't mix calls and
value checks and flow control in the same statement.