serial-lcr: also request packets before initial state retrieval

Commit cb5cd1538f5d introduced packet request support in the serial-lcr
device driver. Calls were added to the detection of the device's
presence, and the periodic acquisition of measurement data. Add another
call to the device configuration retrieval that follows the presence
detection, without it communication timed out with no data received.

Also slightly raise the timeout for this device configuration gathering
phase. With one second sharp, the VC4080 was detected, but getting its
current configuration kept failing. This device's serial communication
is extra slow (1200 bps) and the packets are rather large (39 bytes).
Which made the stream detect's receive routine stop checking for the
availability of more data while a packet was being received.

serial-lcr: move probe, dev inst creation, data read out of scan

Move the initial device probe (LCR packet validity check), the creation
of the device instance after successful probe, and the subsequent packet
inspection after resource allocation out of the scan routine. This shall
improve readability of the serial-lcr driver's probe logic, and reduces
diffs when handling of multiple connections gets added later.

Add a developer comment, the serial-lcr driver needs to handle multiple
connections when the conn= spec is ambiguous (multiple cables of the
same type, with the same VID:PID).

dmm/bm86x.c: reduce verbosity level (packet request)

Remove a debug message from the Brymen BM86x meter's packet request method.

serial_hid: reduce verbosity, drop excessive debug messages

The HID transport for serial communication was rather noisy at log
levels of 4 and above. Now that test coverage was increased and
operation is stable, drop a lot of the excessive and redundant debug
messages in regular code paths.

config keys: Revert re-orderings to avoid ABI changes.

hameg-hmo: Fix two compiler warnings (-Wstringop-truncation).

  src/hardware/hameg-hmo/protocol.c: In function ‘hmo_scope_state_get’:
  src/hardware/hameg-hmo/protocol.c:1130:2: warning: ‘strncpy’ specified bound 20 equals destination size [-Wstringop-truncation]
    strncpy(state->trigger_pattern,
    ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     sr_scpi_unquote_string(tmp_str),
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
     MAX_ANALOG_CHANNEL_COUNT + MAX_DIGITAL_CHANNEL_COUNT);
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    CC       src/hardware/hp-3478a/api.lo
    CC       src/hardware/hung-chang-dso-2100/protocol.lo
  src/hardware/hameg-hmo/api.c: In function ‘config_set’:
  src/hardware/hameg-hmo/api.c:388:3: warning: ‘strncpy’ specified bound 20 equals destination size [-Wstringop-truncation]
     strncpy(state->trigger_pattern,
     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      tmp_str,
      ~~~~~~~~
      MAX_ANALOG_CHANNEL_COUNT + MAX_DIGITAL_CHANNEL_COUNT);
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

hameg-hmo: Fix two compiler warnings (-Warray-bounds).

  src/hardware/hameg-hmo/protocol.c: In function ‘hmo_scope_state_get’:
  src/hardware/hameg-hmo/protocol.c:1035:31: warning: array subscript 0 is above array bounds of ‘char *[0]’ [-Warray-bounds]
     g_free(logic_threshold_short[i]);
            ~~~~~~~~~~~~~~~~~~~~~^~~
  src/hardware/hameg-hmo/protocol.c:1035:31: warning: array subscript 0 is above array bounds of ‘char *[0]’ [-Warray-bounds]
  src/hardware/hameg-hmo/protocol.c:974:24: warning: array subscript 0 is above array bounds of ‘char *[0]’ [-Warray-bounds]
     logic_threshold_short[i] = g_strdup((*config->logic_threshold)[i]);
     ~~~~~~~~~~~~~~~~~~~~~^~~
  src/hardware/hameg-hmo/protocol.c:974:24: warning: array subscript 0 is above array bounds of ‘char *[0]’ [-Warray-bounds]

hameg-hmo: Add SR_CONF_HIGH_RESOLUTION and SR_CONF_PEAK_DETECTION.

Implement High Resolution mode and Peak Detection settings.

Beautify the code by reordering the Trigger Source settings
definitions.

hameg-hmo: Get SCPI_CMD_GET_HORIZONTAL_DIV at runtime.

Get the number of horizontal divisions from the device (at runtime)
instead of hardcoding its value in the driver.

hameg-hmo: Don't hardcode POD/channel numbers.

Don't hardcode the number of PODs or the number of logic (digital)
channels per POD.

hameg-hmo: Remove duplicate function call.

This call was inadvertently left around in commit
8cccbac8da97397b61aa094c67e62ee922b628ed.

hameg-hmo: Rename SCPI_CMD_GET_VERTICAL_DIV to *_SCALE.

Fix the name of the SCPI command used to get the vertical scale.

hameg-hmo: Beautify trigger pattern.

Beautify the trigger pattern by removing the quotes from the SCPI response
using sr_scpi_unquote_string() and improve the string pattern handling.

hameg-hmo: Add missing 1ns timebase for some models.

Extend the timebase setting down to 1ns from the current limit
of 2ns for all supported series except the HMO Compact.

hameg-hmo: Add missing quotes for SCPI_CMD_SET_TRIGGER_PATTERN.

hameg-hmo: Add RTA4000 MSO support (untested).

According to the latest available version of the manual, as
for the RTB2000 and RTM3000 series, the RTA4000 series also
uses a slightly different dialect than other previously
supported models, in particular when it comes to the POD
(logic channel groups) handling.

I do not have such model available for testing therefore, as
for the RTB2000 and RTM3000 support recently introduced, I do
not know whether or not the RTA4000 also understands the
existing dialect. In doubt, the new official dialect is
implemented by this patch.

hameg-hmo: Add RTB2000 and RTM3000 MSO support (untested).

According to the latest available version of the manual, they
both use a slightly different dialect than currently supported
models, in particular when it comes to the POD (logic channel
groups) handling.

I do not have any of the above models available for testing
therefore I do not know whether or not they also understand
the existing dialect. In doubt, the new official dialect is
implemented by this patch.

hameg-hmo: Add SR_CONF_LOGIC_ANALYZER drvopt.

hameg-hmo: Fix the upper limit for the vertical scale.

hameg-hmo: Only update states after successful SCPI SET.

Update the oscilloscope state with new settings only after
they have been successfully stored in the device to avoid
an inconsistent state in case of SCPI SET command failure.

hameg-hmo: Fix for an incorrect samplerate being returned.

The hameg-hmo driver returns an incorrect sample rate: to reproduce this
bug, set the maximum sample rate from the ACQUIRE menu.

This patch fixes the driver so that the correct sample rate is returned.

hameg-hmo: Avoid bogus SCPI timeouts.

During the initial configuration phase of the hameg-hmo driver
only send an OPC command if a SCPI command has been previously
sent to the device so that bogus SCPI timeouts are avoided.

hameg-hmo: Use 1-based (not 0-based) POD numbers.

The current starting index for the POD name is currently wrong as it is zero.

The official POD numbering starts instead at 1 (see device panel, buttons
and manual), so the current index used for message printing and groups
naming in the driver needs to be incremented by one.

hameg-hmo: SR_CONF_LIMIT_SAMPLES/_FRAMES don't support _GET.

The samples and frame acquisition limits are not stored in the device or
elsewhere. Therefore they should not be read.

hameg-hmo: Avoid a double-free.

Avoid double memory freeing leading to segmentation fault in when a SCPI
command fails to get a string due conditions such as a timeout or an invalid
command.

hameg-hmo: Add SR_CONF_TRIGGER_PATTERN support.

Introduce support for the Pattern Trigger functionality, sometimes also
called Logic Trigger.

hameg-hmo: When setting slope, also set trigger type to edge.

When setting the type of slope for the edge trigger function, also set the
trigger type to edge because it is not necessarily configured that way and
therefore such functionality might fail to work properly!

This fixes parts of bug #1328.

hameg-hmo: Remove unused SCPI command enums, sort entries.

hameg-hmo: Add support for the HMO1202 MSO.

hameg-hmo: Initial R&S RTC1000 MSO support attempt.

(might need testing)

hameg-hmo: Add support for SR_CONF_LOGIC_THRESHOLD/_CUSTOM.

Update the Hameg/Rohde&Schwarz HMO driver (hameg-hmo) so that it
is possible to configure the logic threshold for digital signals.

The user can get or set the logic threshold configuration using
the channel group POD0 (and/or POD1 where available), for example:

sigrok-cli --driver hameg-hmo --get logic_threshold -g POD0
sigrok-cli --driver hameg-hmo --config logic_threshold=TTL --set -g POD0

sigrok-cli --driver hameg-hmo --get logic_threshold_custom -g POD0
sigrok-cli --driver hameg-hmo --config logic_threshold_custom=0.7 --set -g POD0

hameg-hmo: Update the default serial port options.

Update the default serial port options for Rohde&Schwarz and
Hameg mixed-signal oscilloscope devices connected through USB.

Also, remove misplaced and unused serial port configuration option.

This patch complements fa3d104f17966dd66664f5ee1cccd05856a7e312
in terms of updating the USB PIDs for new devices (HMO series).

This fixes parts of bug #1321.

hameg-hmo: Try to find a valid serialcomm if none is supplied.

If no serial port option is specified on the command-line using the
"serialcomm" driver option, but the device is connected through USB
and it requires a known default serial port option, then use it in
order to avoid data corruption or even worse problems.

Note: the easiest way to reproduce data corruption on HMO3000 series
is to start an analog data acquisition (e.g. on channel CH1) after
switching from Ethernet mode to USB VCP mode (HO732 USB/Ethernet interface).

This fixes parts of bug #1321.

hameg-hmo: Avoid getting stuck upon SCPI timeouts.

Correctly set the length of the buffer used to hold the SCPI response
from the device containing the binary acquisition data.

If a timeout occurs, truncate the buffer and send the partial response
from the device instead of getting stuck on timeouts!

Thanks to Stefan Brüns for reviewing the first version of this patch
and spotting out a serious problem with it.

This fixes bug #1323.

hameg-hmo: Add SR_CONF_LIMIT_SAMPLES support.

At the moment only the maximum number of frames to be acquired can be
configured for the Hameg/Rohde&Schwarz HMO mixed-signal oscilloscope
series driver (hameg-hmo).

This patch adds support to configure the number of samples to acquire
in both analog and digital (logic) mode.

hameg-hmo: Add support for 16 digital (logic) channels.

This patch introduces the support for 16 digital (logic) channels for the
following oscilloscope models: HMO3032, HMO3042, HMO3052 and HMO3522
(previously only 8 digital channels were supported, i.e. only 1 POD).

hameg-hmo: Remove invalid HMO2522, add missing HMO3522.

This patch takes care of removing an invalid product model (HMO2522)
and adds a missing product model (HMO3522) in the hameg-hmo driver,
thus extending the number of supported oscilloscope models.

This fixes bug #1322.

hameg-hmo: Use g_byte_array_free() instead of g_free().

Use the appropriate glib function to free memory (byte array).

This fixes bug #1324.

Update the pkg-config (.pc) entry for libsigrok.

std: std_gvar_tuple_array/_rational: Fix GVariantBuilder type.

Fix the type of container used to initialize the GVariantBuilder
structure which builds an array of tuples.

hantek-4032l: Fix broken triggering on low signal.

The trigger range/mask "compression" procedure is apparently not
required and breaks triggering on a low line state.

This has been verified to fix the issue on a Hantek 4032L with FPGA
version 0x4303. It is possible that the procedure mentioned above
might be required for other FPGA versions, though that is unknown.

If you experience trigger issues with other FPGA versions, please
contact us for further debugging and testing.

This fixes bug #1402.

hantek-4032l: Cosmetics.

rigol-ds: Add Agilent DSO1000B series IDs

scpi-pps: Support HP 66312a

bindings: Avoid "using namespace" in headers.

This fixes bug #1354.

udev: Add Siglent SDS1104X-E VID/PID.

This fixes bug #1357.

serial_hid: Don't print empty strings, [aaaa.bbbb] VID/PID format.

std: Factor out std_dummy_set_params().

dmm/bm86x: unbreak temperature modes (two probes and no probes)

The Brymen BM86x supports up to two temperature probes. The dual display
can show individual temperatures of the two probes or differences. The
previous implementation "detected" a value of zero degrees when no probe
was attached and the display showed dash lines. When cycling assignments
of probes to displays, some valid combinations did not result in values
shown by the libsigrok driver.

An implementation detail of the formerly separate brymen-bm86x driver
was lost during recent migration of the dmm/bm86x parser into the
serial-dmm driver. When the meter's temperature function is selected,
it's essential to inspect the primary display's flags and digits, to
determine the secondary display's quantity and unit. Previous versions
never bothered to explicitly check for the "----" digits text, but the
combination of the primary's last digit showing C/F as well as the
binary C/F flags before the value provided hints which the secondary
displays group of digits and flags did not.

This fixes bug #1394.

dmm/bm86x: drop local packet dump, already done in serial-dmm

doc: update README.devices, victor-dmm has moved into serial-dmm

serial_hid: make --list-serial output compatible with conn=, print "VID.PID"

When the list of all connections gets created which are supported by the
HID serial transport, items contain a "hid/ch9325/raw=/dev/hidraw3" path
and a "1a86:e008" pair of vendor and product IDs.

Separate the VID/PID pair by a period not a colon, so that --list-serial
output immediately becomes usable with "--driver <name>:conn=<spec>"
invocations. Eliminate the necessity to adjust clipboard context by the
user. This improves usability in cases where not a single connection
gets addressed, but a group of connections gets specified by ambiguous
conn= specs.

$ sigrok-cli -d uni-t-ut32x:conn=1a86.e008 --scan

serial_hid: address constness nits

serial-lcr: add support for packet request

Some meters require the reception of a request before they provide
acquisition data. Add support for the chip driver's .packet_request()
routine, and timeout handling in the serial-lcr driver. This follows
the serial-dmm model.

serial-lcr: add support for chip specific channel names

Allow LCR chip drivers to specify custom printf() formats for their
channel names. Default to "P1" etc in the absence of format specs.
This implementation is similar to serial-dmm.

lcr/es51919: minor style nits in the ES51919 packet parser

Use macros for frequency constants. They hopfully are more readable than
large number literals with their magnitude being not as apparent.

dmm/eev121gw: visibility nits (single display parse routine)

The EEVBlog 121GW meter support always registers the three-displays
parse routine with the serial-dmm device driver. The single-display
routine need not be public. Adjust the visibility.

Reduce indentation for a continued line in a nearby declaration
while we are here.

ipdbg-la: Fix an issue when capture rate is 100%.

If the capture ratio was set to 100%, the delay counter-value has an
overflow and a delay of 0 samples is used.

This fixes bug #1393.

serial: Shorten a few code snippets.

serial_hid.h: Update SER_HID_CHUNK_SIZE comment.

udev: Split SiLabs CP210x/CP2110 items, mention more devices.

serial-lcr: Replace duplicated std_session_send_frame_end().

configure.ac: Clarify/fix some pkg-config package names.

Eliminate VID_PID_TERM in favor of ALL_ZERO.

ftdi-la: Fix VID/PID format in a log message.

Before: 0x 403:0x6001
After:  0x0403:0x6001

ftdi-la: do enter the error path upon VID:PID mismatch

Bug #1390 reports that "!desc" is always true (should be: false?). But
the actual problem would be that 'desc' is _not_ NULL when none of the
supported chips' VID:PID matched (FT232H happens to "get found" then,
erroneously).

Add a sentinel to the table of supported chips, such that 'desc' becomes
NULL upon mismatch, and the error path is entered.

serial-dmm: rename victor-dmm-ser entry, default to USB HID cable

The serial-dmm entry for Victor DMMs is able to communicate to either
geniune COM ports (RS232 or USB CDC) or the obfuscating USB HID cables.
The victor-dmm driver became obsolete and was removed. Rename the
serial-dmm entry, remove the no longer needed "-ser" suffix. Suggest a
default connection via the obfuscating USB HID cable, accept user
provided overrides for regular serial cables (same behaviour as before,
connection spec for serial ports keeps being mandatory).

victor-dmm: remove obsolete device driver, has moved to serial-dmm

Remove the victor-dmm device driver. Its functionality is contained in
the Victor specific serial-over-HID transport, the FS9922 DMM parser,
and the serial-dmm device driver. The additional implementation became
obsolete.

serial-hid: add support for (scrambling) Victor DMM cables

Introduce a serial transport which undoes the Victor DMM cable's
obfuscation to the DMM chip's original data packet. Which allows to
re-use the existing FS9922 support code, obsoleting the victor-dmm
device driver.

uni-t-ut32x: don't provide a default conn= spec in the driver source

This undoes the essence of commit bf700f679af2, which introduced the
default conn= spec. Which improved usability: Users just select the
device and need not specify the connection. But also resulted in the
UT32x thermometer driver's probe to "succeed" as soon as the WCH CH9325
chip was found, no data check was involved in the scan. Unfortunately
this chip is also used in the popular UT-D04 cable, and thus there were
many false positives.

brymen-bm86x: retire libusb using driver, has moved to serial-dmm

Remove the src/hardware/brymen-bm86x/ hierarchy of source files. Its
functionality has moved to the bm86x packet parser and the serial-dmm
device driver.

serial-dmm: bm86x: increase packet request frequency

Request packets from the Brymen BM86x meter much faster. The previous
implementation in the separate driver used to immediately send another
request when a measurement arrived, with a 10ms granularity in the poll
routine, and a 500ms timeout between requests.

Considering the meter's update rate, stick with the 500ms timeout, but
increase the maximum request rate to 10 per second, with a minimum of 2
per second. This receives measurement data at the meter's capability
(compare DC and AC modes, seems to automatically adjust to the internal
operation, and match the display update rate).

dmm/bm86x: add Brymen BM86x packet parser, register with serial-dmm

Move Brymen BM86x specific packet parse logic to a new src/dmm/bm86x.c
source file, and register the routines with the serial-dmm driver's list
of supported devices. Which obsoletes the src/hardware/brymen-bm86x/
hierarchy.

This implementation differs from the previous version: The parse routine
gets called multiple times after one DMM packet was received. Values for
the displays get extracted in separate invocations, the received packet
is considered read-only. Unsupported LCD segment combinations for digits
get logged. Low battery gets logged with higher severity -- the validity
of measurement values is uncertain after all. The parse routine uses
longer identifiers. Packet reception uses whichever serial transport is
available (need no longer be strictly USB HID nor libusb based). All
features of the previous implementation are believed to still be present
in this version.

This configuration queries measurement values each 0.5 seconds and
re-sends a not responded to request after 1.5 seconds. Which follows the
combination of the vendor's suggested flow (frequency) and the previous
implementation's timeout (3x 500ms). This implementation does not try to
re-connect to the HID device for each measurement, and neither checks
for the 4.0 seconds timeout (vendor's suggested flow). Local experiments
work without these.

brymen-bm86x: rename specific Brymen BM86x driver (libusb implementation)

The src/hardware/brymen-bm86x/ source code contains specific support for
the Brymen BM86x devices, and directly depends on the libusb library.
Rename the registered device (append the "-usb" suffix) before adding
BM86x support to the serial-dmm driver.

serial-hid: introduce support for Brymen BU-86X IR adapters

The Brymen BU-86X infrared adapters are sold with BM869s meters. Raw
streams of data bytes get communicated by means of HID reports with
report number 0 and up to 8 data bytes each. Communication parameters
are fixed and need no configuration.

serial-dmm: add support for default connections (USB cables)

Some meters which are supported by the serial-dmm driver don't strictly
require the user's COM port specification. When a known (usually bundled,
or even builtin) cable type is used, we can provide a default conn= spec
and thus improve usability. Prepare the DMM_CONN() macro, accept user
overrides.

serial-dmm: fixup 'conn' vs 'serialcomm' confusion

The 'conn' field in the device context and the CONN values in the
declarations of supported DMM models seemed inappropriate. They specify
the communication parameters (UART frame format and bitrate), not the
connection (port name). Adjust the respective identifiers.

Also rephrase the evaluation logic. Instead of checking for the absence
of user specs and optionally assigning a fallback value, just preset
from defaults and override from user specs when present. This simplifies
the logic (eliminates a check).

serial-dmm: alpha-sort check for devices with multiple displays

bluetooth: silence compiler warning (missing writev(2) declaration)

serial-lcr: move device driver code from src/lcr/ to src/hardware/

Keep the ES51919 chip support in the src/lcr/ directory, and move device
driver specific code to the src/hardware/serial-lcr/ directory. Implement
the same driver layout for LCR meters as is used for DMM devices.

This also addresses a few issues in the serial-lcr driver: Unbreak --get
and --show, do process a few LCR packets after probing the device, to
gather current parameter values. Keep sending meta packets when these
parameters change during acquisition, like the previous implementation
did. Use common code for frame/time limits.

Note that although LCR meters usually operate with AC to classify L/C/R
components, one of the officially supported modes is DC resistance.
Which means that an output frequency of 0 is not just a fallback when
packet parsing fails, it's also a regular value of the freq parameter.
List all supported frequencies including DC in strict numerical order.

Although all currently supported devices use the same ES51919 chip, the
implementation is prepared to support other devices which use different
LCR meter chips as well. The list of known equivalent circuit models and
output frequencies is kept in src/lcr/ chip support. It's assumed that
one LCR packet communicates the data for all channels/displays similar
to the serial-dmm driver implementation.

sw_limits: add support for maximum frame counts

output: also print meta strings in analog output module

Meta packets not only communicate numbers, but also strings. Print them.
This unbreaks the reflection of LCR meters' equivalent circuit model.

serial-dmm: drop obsolete redundant 'baudrate' parameter value

The serial communication timing parameters during probe get determined
from earlier serial port configuration, which obsoletes the redundant
'baudrate' parameter, and eliminates potential inconsistency between
user specified parameters and builtin default values.

kern-scale: drop obsolete redundant 'baudrate' parameter value

The serial communication timing parameters during probe get determined
from earlier serial port configuration, which obsoletes the redundant
'baudrate' parameter, and eliminates potential inconsistency between
user specified parameters and builtin default values.

serial: use timeout API in stream detect, obsoletes bitrate param

The serial_stream_detect() routine needs to estimate the time which is
needed to communicate a given amount of data. Since the serial port got
opened and configured before, the serial communication parameters are
known, and callers need not redundantly specify the bit rate.

serial: add support for optional "RX chunk" callback

The previous implementation provided a raw input stream of RX data from
read() calls to device drivers. This works great with genuine COM ports,
as well as with most setups which involve simple "cable expanders".

Recent additions of alternative transports (serial over HID and BLE)
added more protocol layers to the setup, and some device drivers are
reported to depend on the very framing of these transports: Mooshimeter
cares about individual BLE notification "frames", and the information
cannot get derived from the payload bytes. Some HID based cables which
obscure the DMM chips' serial protocol, or some HID based setups which
the serial layer does not abstract away as "a cable" may suffer from
similar requirements (do some drivers require access to individual HID
reports? Ikalogic? Victor DMM?).

Add support for an optional "RX chunk callback" which takes precedence
over "mere payload byte streams". Instead of returning payload bytes
from read() calls, the serial layer can call an application defined
routine and pass data bytes in the very framing which the physical
transport happens to use.

It's still up to the implementation of the specific transport whether
the callback approach is supported, and whether the wire's framing is
obeyed or whether payload data keeps getting provided as one raw stream.
It's also implementation dependent whether data reception transparently
occurs in background, or whether callers need to periodically "stimulate"
data reception by calling read or check routines which happen to call
back into the caller should RX data become available.

The approach that got implemented here is not universally applicable,
but serves those specific environments that were identified so far.

udev: drop links to device/cable wiki pages from udev rule set

udev: mark SiLabs CP2102 as generic, add SiLabs CP2110

The CP210x USB to UART bridge is not specific to CEM DT-8852, it's a
generic bridge chip that is also used in other cables and devices. Add
the CP2110 USB HID to UART bridge that is found in UNI-T cables and
devices, and reported to also be used in Voltcraft devices.

udev: add 'hidraw' subsystem to 60-libsigrok.rules

WCH CH9325 and SiL CP2110 chips (and other HID cables) won't match the
currently used 'usb' subsystem when the platform registers these as
'hidraw' devices. Adjust the 60-libsigrok.rules SUBSYSTEM condition.

doc: discuss how to enable PC communication on LCR meters

doc: outline conn= specs for HID and Bluetooth in README.devices

Add more examples of conn= specs for HID and Bluetooth devices to the
section which discusses COM ports. Outline the formal syntax and its
optional fields. Discuss how colons in device addresses interfere with
"-d <drv>:conn=<spec>" environments.

doc: update README, optional conn= specs for UNI-T meters

Recent adjustment in the libsigrok serial layer changed whether conn=
specs are mandatory or optional for some of the UNI-T meters.

doc: update README for serial over Bluetooth

Mention the optional external BlueZ dependency. Provide conn= examples
for Bluetooth communication. Mention the UT-D07 adapter.

serial_bt: implement the serial over Bluetooth transport (conn=bt/...)

Introduce the serial_bt.c source file which implements the methods of a
serial transport and calls into the platform agnostic src/bt/ support
code.

Implement support for several chips and modules: RFCOMM (BT classic,
tested with HC-05), BLE122 (tested with 121GW), Nordic nRF51, and TI
CC254x (the latter untested). Read support is assumed to be complete,
write support for BLE may be incomplete due to lack of access to
hardware for tests.

bluetooth: introduce Bluetooth communication API, implement BlueZ support

Create a src/bt/ subdirectory for source files. Declare a platform
agnostic internal API for Bluetooth communication, and provide an
implementation of that portable API when the BlueZ library is available.

This implementation assumes that HAVE_BLUETOOTH and HAVE_LIBBLUEZ can be
used interchangeably, which is true for this initial version. When
support for other platforms gets added, the common and the specific
parts need to get sorted. Trying that now would involve guessing. :)

build: prepare serial over Bluetooth, search for optional BlueZ lib

Adding Bluetooth communication is desirable for all sigrok supported
platforms. The BlueZ library is available on Linux which will receive
support first. Check for the BlueZ library's presence, determine a
HAVE_BLUETOOTH summary state, and extend the HAVE_SERIAL_COMM check.
Print version details for the external library.

This commit extends build support and version information, but does not
yet include the implementation of the serial transport primitives.

doc: mention serial-over-HID in README.devices (UT-D09 cable)

serial-lcr: add driver item for the UNI-T UT612 model

Register another driver for the UNI-T UT612 LCR meter, which is based on the
ES51919/ES51920 chipset, too. This device had been usable before when the
internal UART connection was made accessible (read: with a hack). It became
officially supported in unmodified form with the addition of transparent
serial over HID support for SiLabs CP2110 chips.

uni-t-ut32x: migrate from USB transfers to serial-over-HID communication

Switch the UT32x driver from running specific USB transfers to generic
serial communication. Preset the bitrate and frame format, but allow for
user specified overrides as well. Default to the WCH CH9325 HID chip,
but allow for overrides or more specific selection so that users can
resolve ambiguities with multiple cables.

The switch from libusb to hidapi removes a limitation that specifically
was reported for the Mac platform. The serial-over-HID variant should
now work as well. See bug #555.

Drop the background transfers. Stick with a local acquisition stop
routine, because a STOP request needs to get sent to the device. Reduce
the receive buffer size such that either blocking or non-blocking calls
will work. The additional flexibility of the buffer handling and packet
processing does not harm.

serial_hid: add support for the SiLabs CP2110 chip (UT-D09, UT612)

Also reported to be seen in Voltcraft devices (VC-650, VC-890).