Gerhard Sittig [Wed, 12 Jun 2019 21:58:24 +0000 (23:58 +0200)]
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.
Gerhard Sittig [Tue, 11 Jun 2019 16:56:04 +0000 (18:56 +0200)]
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).
Gerhard Sittig [Thu, 9 May 2019 16:11:07 +0000 (18:11 +0200)]
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.
Gerhard Sittig [Mon, 10 Jun 2019 18:15:24 +0000 (20:15 +0200)]
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.
Gerhard Sittig [Sun, 9 Jun 2019 16:28:48 +0000 (18:28 +0200)]
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.
Gerhard Sittig [Sun, 9 Jun 2019 08:48:21 +0000 (10:48 +0200)]
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.
Gerhard Sittig [Sun, 9 Jun 2019 15:03:31 +0000 (17:03 +0200)]
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).
Gerhard Sittig [Sun, 9 Jun 2019 07:03:22 +0000 (09:03 +0200)]
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.
Gerhard Sittig [Sun, 9 Jun 2019 08:15:37 +0000 (10:15 +0200)]
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.
Gerhard Sittig [Sun, 9 Jun 2019 06:25:54 +0000 (08:25 +0200)]
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.
Gerhard Sittig [Sun, 9 Jun 2019 08:34:51 +0000 (10:34 +0200)]
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.
Gerhard Sittig [Sun, 9 Jun 2019 08:18:52 +0000 (10:18 +0200)]
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).
Gerhard Sittig [Wed, 1 May 2019 20:01:48 +0000 (22:01 +0200)]
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.
Gerhard Sittig [Wed, 1 May 2019 18:23:48 +0000 (20:23 +0200)]
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.
Gerhard Sittig [Wed, 1 May 2019 18:11:46 +0000 (20:11 +0200)]
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.
Gerhard Sittig [Wed, 1 May 2019 17:50:01 +0000 (19:50 +0200)]
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.
Gerhard Sittig [Wed, 3 Apr 2019 05:52:00 +0000 (07:52 +0200)]
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.
Gerhard Sittig [Sat, 4 May 2019 08:20:21 +0000 (10:20 +0200)]
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.
Gerhard Sittig [Sat, 4 May 2019 07:59:15 +0000 (09:59 +0200)]
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.
Gerhard Sittig [Tue, 30 Apr 2019 18:33:14 +0000 (20:33 +0200)]
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.
Gerhard Sittig [Thu, 27 Dec 2018 21:12:20 +0000 (22:12 +0100)]
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.
Gerhard Sittig [Sun, 30 Dec 2018 19:46:51 +0000 (20:46 +0100)]
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. :)
Gerhard Sittig [Thu, 27 Dec 2018 13:22:34 +0000 (14:22 +0100)]
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.
Gerhard Sittig [Sun, 28 May 2017 06:39:19 +0000 (08:39 +0200)]
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.
Gerhard Sittig [Fri, 6 Oct 2017 00:52:29 +0000 (01:52 +0100)]
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.
Gerhard Sittig [Fri, 17 Mar 2017 21:39:46 +0000 (22:39 +0100)]
serial_hid: implement serial over HID transport
Do implement the transport methods for serial communication underneath
the common layer, by communicating HID requests and payload data by
means of HIDAPI library calls.
This commit adds the common logic of serial-over-HID communication and
implements the full internal serial transport API, including reception
in the background. But it does not yet support a single HID chip (which
each run their own proprietary protocol).
The implementation works with either hidapi-libusb or hidapi-hidraw
variant of the HIDAPI library, but was only tested on Linux.
Gerhard Sittig [Sun, 26 Mar 2017 14:48:36 +0000 (15:48 +0100)]
serial: prepare serial over HID in common layer and build support
Search for the optional HIDAPI library. Call the library's init and exit
routine, and print version information. Extend the common serial layer's
code paths for open, list, and find USB to also support serial over HID.
This commit prepares serial over HID, but the HIDAPI specific transport
for serial communication still is empty in this implementation.
Gerhard Sittig [Sat, 30 Sep 2017 12:10:10 +0000 (14:10 +0200)]
serial: introduce local receive data buffer
Add a local RX buffer to the common code of libsigrok's serial layer.
Callers of the serial layer's API won't notice, this is an internal
detail of how alternative transports receive their data from the
physical line, and pass it to read() calls emitted by device drivers.
The libserialport specific code still calls into the library, and does
not use the RX buffer. Future HID and BLE support will use the buffer.
Gerhard Sittig [Thu, 27 Dec 2018 13:29:00 +0000 (14:29 +0100)]
serial: make LCR, modbus, SCPI over serial depend on generic serial comm
Add guards around the implementation of ES51919 chip support for LCR, as
well as modbus and SCPI over serial. To accept when the source files get
compiled in the absence of their dependencies, end up with an empty
implementation in that case.
This approach can simplify build rules when several optional external
dependencies result in differing sets of supported communication means.
Gerhard Sittig [Sun, 28 Jan 2018 17:07:38 +0000 (18:07 +0100)]
serial: prepare for the absence of libserialport
Only reference the libserialport header when the library is available.
Allow to always compile the serial.c source file, but optionally end
up with an empty implementation. Make the sr_serial_dev_inst symbol
available outside of HAVE_SERIAL_COMM such that empty stub code can
compile. This prepares the introduction of alternative transports for
serial communication, while all of them remain optional.
The libsigrok serial layer internally uses parity and flow control
symbols which are provided by libserialport. Optionally locally declare
these symbols when libserialport is not available.
Gerhard Sittig [Mon, 29 Apr 2019 16:57:04 +0000 (18:57 +0200)]
configure: make device drivers depend on "serial comm" not libserialport
A previous commit introduced the more generic "have serial communication"
condition, and adjusted the list of available libsigrok dependencies.
This commit adjusts device driver dependency declarations. This allows
to build e.g. DMM drivers in the presence of RFCOMM support but in the
absence of libserialport, because any of several optional external libs
can make serial communication available.
Gerhard Sittig [Sun, 3 Jun 2018 04:34:27 +0000 (06:34 +0200)]
serial: introduce more general "have serial comm" feature flag
Introduce the HAVE_SERIAL_COMM identifier, which gets derived from, but
need not be identical to the HAVE_LIBSERIALPORT condition.
Derive the NEED_SERIAL automake condition from the general availability
of serial communication not the specific libserialport library.
Adjust source code references. Stick with HAVE_LIBSERIALPORT where the
specific library is meant, but switch to HAVE_SERIAL_COMM where the
availability of serial communication in general is meant.
Gerhard Sittig [Sat, 30 Sep 2017 23:21:08 +0000 (00:21 +0100)]
serial: prepare alternative transports for serial communication
Add an indirection between the common serial communication code and the
libserialport specific support code. Prepare the use of alternative
transports like USB HID in the future. Decide in the open() routine
which transport to use for subsequent operations (based on port names).
In theory only the transport specific layer depends on the libserialport
library's availability. In this implementation all support for serial
communication still depends on the HAVE_LIBSERIALPORT preprocessor
symbol. This needs to get addressed in later commits.
Gerhard Sittig [Sun, 3 Jun 2018 14:49:45 +0000 (16:49 +0200)]
ols: use serial layer's "has receive data" query
Eliminate a direct libserialport dependency in the OLS device driver.
Use libsigrok's internal serial layer's API instead to check for the
availability of receive data.
Gerhard Sittig [Sun, 3 Jun 2018 10:17:09 +0000 (12:17 +0200)]
serial: introduce "has receive data" query
Add a serial_has_receive_data() routine to the serial layer's API which
returns the number of (known to be) available RX data bytes. Implement
support in the libserialport specific code.
Gerhard Sittig [Fri, 17 Mar 2017 21:15:37 +0000 (22:15 +0100)]
serial_libsp: move libserialport specific code to separate source file
Introduce a new serial_libsp.c source file, and move code from serial.c
there which is specific to libserialport. Keep the existing serial.c API
in place, this is a pure internal refactoring.
Adjust a little whitespace while we are here. Rearrange long lines to
keep related parameter groups adjacent (like pointer and size, or UART
frame length and flow control). Consistently reduce indentation of
continuation lines.
Gerhard Sittig [Sun, 26 Mar 2017 15:56:36 +0000 (16:56 +0100)]
serial: determine timeout from most recent set_params() values
Store the most recent successfully applied set of parameters for serial
communication. Re-use these values as a fallback to calculate timeouts,
when the underlying transport fails to provide the current settings.
The rohde-schwarz-sme-0x device driver used to unconditionally reference
a libserialport header file. Remove that reference, it's not needed in
this specific driver.
Gerhard Sittig [Wed, 1 May 2019 04:19:55 +0000 (06:19 +0200)]
doc: update manual driver addition in the HACKING document
Build support has changed to use linker sections for driver registration.
Update the subsection in the HACKING document which discusses the manual
addition of device drivers, to match what the new-driver script does for
driver authors.
Andreas Piesk [Mon, 13 May 2019 19:33:32 +0000 (21:33 +0200)]
saleae-logic16: Warn (instead of erroring out) if FPGA is unsupported
Don't exit with an error if the FPGA is detected as unsupported.
Just issue a warning with the detected version and continue. I have such
a clone and it works with the original Saleae software and with sigrok
despite the fact that its FPGA version is 0xff.
Uwe Hermann [Wed, 1 May 2019 13:33:05 +0000 (15:33 +0200)]
Fix an issue when building in directories that are symlinks.
Explicitly use SRCDIR and BUILDDIR in Doxyfile files to reference input
files. This seems to be a sufficient fix for an issue where the build
would fail when libsigrok/ was located in a directory that was a symlink.
Gerd v. Egidy [Sun, 10 Feb 2019 19:14:27 +0000 (20:14 +0100)]
agilent-dmm: add basic support for Agilent/Keysight U127x
Their commands are very similar to the U123x series, they just
add some more modes and the second channel. So use the re-functions
and just extend them where necessary.
Gerhard Sittig [Sun, 19 Mar 2017 15:11:56 +0000 (16:11 +0100)]
serial: update doxygen comments (flush vs drain, in vs out params)
It's important to remain aware that the serial layer's flush and drain
semantics differs from e.g. filesystem calls. The libserialport API is
said to follow the termios example.
Extend comments in the libsigrok API, to not depend on the libserialport
layer and the availability of its documentation. This raises awareness
during maintenance of sigrok device drivers, as well as the pending
addition of alternative transports for serial communication.
Adjust the doxygen comment for the read line routine while we are here.
Add "in" and "out" attributes for routine parameters.
Gerhard Sittig [Mon, 22 Apr 2019 08:28:07 +0000 (10:28 +0200)]
libsigrok-internal.h: fix source file references in comments
The src/hardware/ subdirectory exclusively contains device drivers these
days, while common support code has moved to the src/dmm/, src/lcr/,
src/scale/, etc directories or src/ itself. Adjust comments in the
libsigrok-internal.h declaration blocks which reference source files.
Gerhard Sittig [Mon, 2 Oct 2017 15:26:52 +0000 (16:26 +0100)]
device: rephrase sizeof() calls for reduced redundancy, use malloc0
Just allocate the memory needed to hold the very variable's size. No
need to duplicate the variable's type. Reduces redundancy and increases
robustness during maintenance.
Use g_malloc0() in sr_serial_new() to make sure all of the structure is
initialized.
Uwe Hermann [Mon, 22 Apr 2019 11:12:20 +0000 (13:12 +0200)]
sysclk-sla5032: Fix compiler warnings (max vs. MAX).
src/hardware/sysclk-sla5032/protocol.c: In function ‘la_start_acquisition’:
src/hardware/sysclk-sla5032/protocol.c:244:8: warning: implicit declaration of function ‘max’ [-Wimplicit-function-declaration]
pre = max(pre, 2);
^~~
Frank Stettner [Wed, 10 Apr 2019 09:54:37 +0000 (11:54 +0200)]
scpi-pps: Add config keys SR_CONF_OVER_VOLTAGE_PROTECTION_ACTIVE,
SR_CONF_OVER_CURRENT_PROTECTION_ACTIVE and
SR_CONF_OVER_TEMPERATURE_PROTECTION_ACTIVE to HP 66xxA power supplies.
Frank Stettner [Tue, 9 Apr 2019 13:47:19 +0000 (15:47 +0200)]
scpi-pps: Add config keys SR_CONF_OVER_VOLTAGE_PROTECTION_ACTIVE,
SR_CONF_OVER_CURRENT_PROTECTION_ACTIVE and
SR_CONF_OVER_TEMPERATURE_PROTECTION_ACTIVE to HP 66xxB power supplies.