When libsigrok is compiled with link-time-optimization, the linker
stumbles over the section named the same as the function. Whether this
is a compiler/linker bug or a coding error is unknown.
Renaming the special section (to the same as already used on OS X) avoids
the problem.
This fixes bug #1416.
Introduce the lcr/vc4080.c source file which implements the parser for
the serial data stream of the Voltcraft 4080 LCR meter. Add the meter to
the list of supported devices in the serial-lcr driver, as well as the
PeakTech 2165 LCR meter which is another compatible device.
This implementation contains a workaround for USB based serial cables
which seem to suffer from incomplete parity handling (observed with the
FT232R based PeakTech cable). Similar approaches were seen in existing
DMM drivers.
This implementation supports the main and secondary displays. The D and Q
"displays" which are communicated in the serial packets appear unreliable
and redundant, users can have the D and Q values shown in the supported
displays.
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.
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.
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.
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.
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.
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.
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.
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.
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. :)
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.
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.
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.
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.
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.
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.
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.
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.
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 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.
Add an "eevblog-121gw" subdriver entry for the EEVblog 121GW multimeter.
Use device dependent channel names instead of the default "P1" etc names.
It's assumed that the device's binary packet data is available at a COM
port. This means that an external BT to UART gateway is required until
BLE communication will be one of libsigrok's native connection types.
Introduce the dmm/eev121gw.c source file with parse routines for the
EEVblog 121GW meter's 19-bytes binary packets. Get the values and MQ
properties of the device's several displays (main, sub, bar) in several
individual parse calls.
This commit introduces initial support for the device. Some of the modes
and features are untested, as are some of the device's ranges.
Introduce common support for hex dumps in the string util collection.
There are explicit allocation and release routines for the textual
representation of the data bytes, so that callers are free to chose
whether and how to decorate the dump and where to send the message.
Applications are not prepared to handle changes in the channel list
between multiple acquisitions from the same source (device drivers
or input modules). Introduce common helpers to compare channels and
channel lists.
There was the sr_channel_new() allocation routine, but releasing that
allocation was open-coded in call sites. Add the sr_channel_free()
routine for code re-use and consistency.
Example:
In file included from src/hardware/kecheng-kc-330b/protocol.h:26,
from src/hardware/kecheng-kc-330b/api.c:22:
src/hardware/kecheng-kc-330b/api.c: In function ‘config_list’:
src/libsigrok-internal.h:51:34: warning: division ‘sizeof (void *) / sizeof (void)’ does not compute the number of array elements [-Wsizeof-pointer-div]
#define ARRAY_SIZE(a) (sizeof(a) / sizeof((a)[0]))
^
src/libsigrok-internal.h:55:32: note: in expansion of macro ‘ARRAY_SIZE’
#define ARRAY_AND_SIZE(a) (a), ARRAY_SIZE(a)
^~~~~~~~~~
src/libsigrok-internal.h:964:43: note: in expansion of macro ‘ARRAY_AND_SIZE’
std_opts_config_list(key, data, sdi, cg, ARRAY_AND_SIZE(scanopts), \
^~~~~~~~~~~~~~
src/hardware/kecheng-kc-330b/api.c:296:10: note: in expansion of macro ‘STD_CONFIG_LIST’
return STD_CONFIG_LIST(key, data, sdi, cg, NULL, drvopts, devopts);
^~~~~~~~~~~~~~~
When users don't specify the input format, applications can try to have
the format auto-detected. Some of the tests were weak and could result
in false positives.
Add a 'confidence' parameter to the input modules' format_match()
method. Claim high confidence (1) for those formats which can check
magic strings or the presence of essential keywords (vcd, wav). Claim
medium confidence (10) for those formats which happened to mis-detect
inputs in the past (trace32_ad). Claim weak confidence (100) for those
formats which totally lack reliable conditions and rather guess than
detect (chronovu_la8).
Prefer the best match in public scan routines. Return at most one module
to callers even if multiple modules matched, to keep the current API.
This addresses part of bug #1200.
Optionally create multiple analog channels in serial-dmm's scan()
routine. Allow the meters' parse routines to fill in more than one
analog value from the inspection of a single packet.
Use "large" (4 times 14 bytes) packets for the Metex M-3860M and the
PeakTech 4390A meters, and have those large packets parsed by wrapping
the routines for regular 14-byte Metex packets, and sending four values
to the session bus after reception of one large packet.
Thanks to Frank Stettner <frank-stettner@gmx.net> for testing and
fixing the initial implementation of this extension.
Some drivers used locale dependent functions for converting strings
to float/double values. These functions fail when the decimal mark
is a "," in the locale settings but the string contains a ".".
This fixes bug #1064.
Stefan Brüns
Gerhard Sittig
Uwe Hermann
Vitaliy Vorobyov
Frank Stettner
Soeren Apel
Matthias Schulz
Mandl